Rails7.1へアップデートする場合、Ransack はバージョン4にアップデートする必要があります。

Ransackが古い状態だと以下のエラーになります。

NoMethodError: undefined method `table_name' for

Ransack 4の更新内容

検索・ソートできるDB項目を制限する機能が追加されました。

そのため、Ransackをアップデートすると、検索・ソートできる項目を指定する必要があります。

検索・ソートできる項目を指定しないとエラーになりますが、項目を指定するのは、かなり手間です。

かなり手間なので、簡単な対応方法を記載します。

Ransack 4に簡単に対応する方法

ApplicationRecordクラスに以下のコードを記載するとエラーは消え、今まで通り使えます！

  def self.ransackable_attributes(auth_object = nil)
    # 全ての列を検索可能にする
    authorizable_ransackable_attributes
  end
  def self.ransackable_associations(auth_object = nil)
    # 全ての関連テーブルを検索可能にする
    authorizable_ransackable_associations
  end

本来であれば、検索・ソートできる項目を指定していくのが良いと思いますが、既存アプリのアップデートで時間がない場合など、簡単にRansack 4に対応させたい時は、上記の方法で、今まで通り使えるようになります。

具体的には

• リトライ
• サーバプロセスが落ちると、jobのデータは失われる
• メモリ肥大化する問題
• 並列実行数制御

について記載します。

Sidekiqを正しく理解して安全に使おう！という記事になります。

まずはSidekiqとは？について記載していきます。

Sidekiqとは

 Railsで非同期処理を行うためのgemです。複数の非同期処理を同時に実行することができ、サーバリソースを有効活用できます。

以下、処理イメージです。

1. Rails WEBサーバがリクエストを受け付ける
2. Rails WEBサーバは非同期でしたい処理をRedisにjobとして格納する
3. Sidekiqが動いているサーバがRedisからjobを取得する
4. Sidekiqはjobの内容にしたがって処理を実行する

Simple, efficient background jobs for Ruby

Sidekiq is a simple, efficient framework for background jobs in Ruby

sidekiq.org

AWS SQSと連携させて、非同期処理を行うShoryukenというgemもあります。

[注意点①]プログラムで例外発生時は、リトライされる

デフォルトのリトライの仕様は以下の通りとなります。約21日間リトライが行われます。

リトライ回数：25回

リトライの間隔：リトライ回数の4乗＋15秒間隔くらい。正確な計算式は以下の通り

(retry_count ** 4) + 15 + (rand(10) * (retry_count + 1))

Error Handling

Simple, efficient background processing for Ruby. Contribute to sidekiq/sidekiq development by creating an account on GitHub.

github.com

リトライで解消する可能性がある場合は、リトライは有効かと思いますが、何度リトライしても失敗するようなエラーの場合はサーバ負荷をかけるだけなので、リトライさせないようにしておくと良さそうです。

リトライ回数をデフォルトから変更するなど、リトライ時の処理を設計して実装しておきましょ！

[注意点②]サーバプロセスが落ちると、jobのデータは失われる

サーバプロセスが落ちると、jobのデータは失われてしまいます。

Sidekiq Pro(Sidekiqの有料版)のsuper_fetchを使用すると、サーバプロセスが落ちてもjobデータが失われなくなりますので、Sidekiq Proを検討しましょ

Reliability

Simple, efficient background processing for Ruby. Contribute to sidekiq/sidekiq development by creating an account on GitHub.

github.com

または、Sidekiqをやめて、Shoryukenの検討をしましょ。

ShoryukenではSQSを使用しますが、サーバプロセスが落ちてもSQSのデータ失われないためです。

[注意点③]メモリ肥大化する問題

大量のメモリを消費する問題があります。

メモリの問題に関しては、以下の記事を参考に設定を変更して対応しましょ

Ruby: mallocでマルチスレッドプログラムのメモリが倍増する理由（翻訳）｜TechRacho by BPS株式会社

概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Malloc Can Double Multi-threaded Ruby Program Memory Usage 原文公開日: 2017/12/04 著者: Nate Berkopec -- 『Complete Guide to Rails Perform...

techracho.bpsinc.jp

[注意点④]並列実行数制御

大量に同時実行するとインフラ負荷がかかりすぎる場合、並列実行数制御をしましょ！

インフラ負荷とは以下のようなイメージでいます。

• 大量に同時実行すると
  • Sidekiqが動いているサーバに負荷がかかる
  • DBに負荷がかかる

並列実行数制御にはsidekiq-limit_fetch というgemを使います。

sidekiq-limit_fetch | RubyGems.org | コミュニティのgemホスティングサービス

rubygems.org

注意点として、Sidekiq Proを使用している場合、sidekiq-limit_fetchは正常に動作しないので要注意です。

GitHub - deanpcmad/sidekiq-limit_fetch: A Sidekiq plugin to support advanced queue control (limiting, pausing, blocking, querying)

A Sidekiq plugin to support advanced queue control (limiting, pausing, blocking, querying) - deanpcmad/sidekiq-limit_fetch

github.com

Sidekiq Proを使用している場合は

• Sidekiq Enterpriseの導入を検討する
• 自分で並列実行数を制御するプログラムを作成する
  • 以下のようなイメージです
    • 「Sidekiq::Workers.new」で実行中のjobを取得し、並列実行数をチェックする
      • 並列実行数をチェックした結果、処理実行して良い場合、そのまま処理実行
      • 並列実行数をチェックした結果、並列実行の上限を超えている場合、「perform_later」でjobをredisに戻し、処理を終了する

まとめ

Sidekiqを使用する際の注意点について記載しました。

まとめると

• リトライ
  • リトライ回数を意識して設計しましょ
• サーバプロセスが落ちると、jobのデータは失われる
  • Sidekiq Proを検討しましょ
• メモリ肥大化する問題
  • メモリに関する設定を見直しましょ

ということです★