Sidekiqを使っていて思ったこと・躓いた点など
業務でSidekiqを使ったので思ったことを書く。
Sidekiqは大量のリクエストを受け付けてバックグラウンドで非同期処理をやってくれるRuby製のOSSです。
Getting Started · mperham/sidekiq Wiki · GitHub
今回、同期処理で動いてる更新機能について、裏側の部分は非同期にしてほしいという依頼だった。まさにSidekiqの出番という感じ。
今回、ActiveJobは併用してないので詳しくは知らないのですがこちらが参考になりそうです。
業務ではResqueも併用して使われてて、Sidekiqも使われてるという状況で、どっちが良いのかよく分らなかった。
Sidekiqのいいとこ・ダルいとこ
いいとこ
- 大量のリクエストに耐えうる
- マルチスレッドで動き、処理速度が比較的早い
- メモリ効率が良い
- ダッシュボードからキューを削除したりエンキューできる
- pry仕込んでデバッグできる（Rails consoleでしか動かない）
- RSpecでテスト書きやすい
Resqueはシングルスレッドで、メモリが肥大化しがちなのがネックなのでそれを置き換えているという点で良い。
rails consoleで動作確認するときは以下のようにクラスを初期化したうえでperformメソッドを呼び出すと動く。
SidekiqWorker::Foo.new.perform
ダルいとこ
- pryを使ったデバッグがRails consoleでのみ有効で、実際にリアルタイムでバックグラウンド処理を実行してるときには無視される
- Workerのソースコード修正したらSidekiqの再起動が必要
ダルすぎる。
docker環境でrails/sidekiqのコンテナを動かしている場合、workerジョブのソースコードおよびジョブが呼び出しているソースを修正した場合、それがたとえタイポの修正とかであっても、コンテナを再起動しないと変更差分を確認できない。Sidekiqは元のソースコードを読み込んだうえで起動されるので致し方ないっぽい。
参考
