実務で扱っているアプリケーション(Rails)に非同期処理を導入することになり、代表的なgemの特徴・メリット・デメリットを調査しました。せっかくなので簡単にまとめておきます。
調査対象のgem
- Sidekiq
- Shoryuken
- Rescue
- Delayed_job
比較表
GitHubスター数は2023年9月頃のものです。また「〇、△、✕」は条件次第で変わってくるものもあると思います、参考程度の認識でお願いします。
| Sidekiq | Shoryuken | Rescue | Delayed_job | |
|---|---|---|---|---|
| GitHubスター数 | 12.7k | 2k | 9.3k | 4.8k |
| キューイング | Redis | AmazonSQS | Redis | RDB |
| 処理方式 | マルチスレッド | マルチスレッド | シングルスレッド | シングルスレッド |
| パフォーマンス | 〇 | 〇 | △ | ✕ |
| 耐障害性 | △ | 〇 | △ | △ |
| コスト | △ | 〇 | △ | 〇 |
| リトライ処理 | 〇 | 〇 | ✕ | 〇 |
| メリット | ・高性能 ・導入事例が多い |
・耐障害性高(キューのロストリスク無し) ・高性能 ・低コスト |
・比較的高性能 ・メモリリーク/肥大化のリスクなし(jobごとに子プロセス起動) |
・導入しやすい(Redis不要) ・低コスト |
| デメリット | ・スレッドセーフな実装が求められる |
・個人が開発したGem ・導入事例が少ない ・スレッドセーフな実装が必要 ・ローカルでの検証が若干手間 |
・job大量実行時はフォークのオーバーヘッドでパフォーマンス低下 ・自動リトライ無し |
・RDBゆえにパフォーマンス低 ・大規模アプリケーションには不向き |
補足
-
パフォーマンス
マルチスレッドのSidekiq, Shoryukenが優勢、キューイングがRDBであるがゆえにDelayed_jobは劣勢。 -
耐障害性
盤石なAmazonSQSを扱うShoryukenが優勢。その他も構成次第では耐障害性を高めることは可能な認識。 -
コスト
低コストなSQSを扱うShoryuken、RDBを流用できるDelayed_jobが優勢。 -
リトライ処理
唯一Rescueがjobエラー時の自動リトライ処理がない。(ジョブ毎に個別に実装が必要)
結論
私のチームではSidekiqを扱うことで決まりました。理由としては、チーム内にSidekiqの経験豊富な方がいたという点が大きいです。またShoryukenは個人が開発したgemであったり、Rescueはリトライ処理がなかったり、Delayed_jobは小規模アプリケーション向きだったり決め手に欠きました。
スレッドセーフについて
「スレッドセーフとは何か」は別記事でまとめたいと思います。ちなみにチームメンバーのベテランエンジニアの方はこれまで何度もSidekiqを扱ってきたが、あまりスレッドセーフを意識することはなかったとのこと。
Sidekiq扱っている皆さん、ジョブの実装時にスレッドセーフはどこまで意識していますか？よかったら教えてください！