バックグラウンドジョブのキューアダプタの技術選定：Good Job を選んだ理由
主な選択肢として Sidekiq、Solid Queue、Good Job の3つを検討しました。今回のプロジェクトにおける選定プロセスをまとめます。
環境
- Ruby on Rails 8.1.3
- Docker（開発環境）
- Render（本番環境）
- PostgreSQL（DB）
選定の軸
開発初期はジョブ失敗の原因調査が頻繁に発生することを想定し、次の2点を重視しました。
- 追加インフラなしで動作すること（DB のみで完結すること）
- ジョブの監視・デバッグがしやすいこと
各ライブラリの比較
Sidekiq ― 却下
高機能で実績も豊富だが、動作に Redis が必要なため、別途インフラを用意する必要がある。追加インフラなしで動かすという方針に反するため、導入コストの観点から除外した。
Solid Queue ― 却下
Rails 8 からデフォルトのジョブアダプタとして採用されており、設定がほぼ不要で DB だけで動作する点は理想的。しかし標準では管理 UI が用意されていない。ジョブのエラー確認やリトライ状況の把握を GUI 上で行うには、別途 Mission Control Jobs という gem を追加導入する必要がある。
Good Job ― ✅ 採用
Solid Queue と同様に DB だけで動作し、追加インフラは不要。そのうえで管理画面が最初から組み込まれているのが決め手となった。ジョブの実行履歴・エラー内容・リトライ状況を GUI 上ですぐに確認できる状態でスタートできる。
なお Good Job は PostgreSQL 専用だが、このプロジェクトでは PostgreSQL を採用しているため制約にはならない。
選定まとめ
| ライブラリ | 追加インフラ不要 | 管理 UI 組み込み | 採否 |
|---|---|---|---|
| Sidekiq | ❌（Redis 必須） | — | ❌ |
| Solid Queue | ✅ | ❌（別 gem 必要） | ❌ |
| Good Job | ✅ | ✅ | ✅ |
まず「追加インフラなし」の軸で Sidekiq が外れた
また、残った Solid Queue と Good Job の比較では管理画面がすぐに使えるか否かが決め手となった。開発初期のデバッグ効率を最優先した結果、Good Job を採用した。