Solid Queue — Rails 8時代のジョブバックエンドはSidekiqから移行すべきか

Rails 8でデフォルトのジョブバックエンドがSolid Queueになった。長年Sidekiqがデファクトスタンダードだったが、今後の新規プロジェクトではSolid Queueが標準になりつつある。

Sidekiq → Solid Queue の最大の動機: Redis不要

バックエンド	依存	特徴
delayed_job	DB (AR)	老舗。メンテナンス停滞気味
Sidekiq	Redis	長年のデファクト。高速・高機能
Solid Queue	DB (AR)	Rails 8デフォルト。Redis不要

Rails 8の「No PaaS」思想（Kamal, Solid Queue, Solid Cache, Solid Cable）はRedisを運用スタックから外す方向に明確に舵を切っている。Solid Queueに移行すればRedisサーバーの運用・コストがまるごと不要になる。

Fiber化でDBコネクション問題も解消へ

Solid Queueをfiber-basedに改造した事例が話題になっていた。

モデル	100 concurrent jobs	DB connections
Thread	各スレッドが独立にDBクエリ可能	102
Fiber	同時に1つしか実行されないので接続共有	3

Fiberは協調的マルチタスクで、I/O待ちでyieldすると別のFiberに切り替わる。同一スレッド内で動くためDBコネクションを共有できる。LLM streamingのようなI/Oバウンドなジョブでは20%高速化という報告もある。

スループットの目安

瞬発1,000 jobs/sec、通常500 jobs/sec以内なら全く問題ない。

規模	jobs/sec	Solid Queue
小〜中規模	~500	余裕
中〜大	~1,000	問題なし
大規模	~5,000+	要チューニング（DB次第）
超大規模	10,000+	Sidekiqが有利

Solid QueueはFOR UPDATE SKIP LOCKEDで行ロック競合を回避する設計。通常のRDS/Cloud SQLなら数千rows/secのINSERT + UPDATEは楽勝。

cron的な定期実行もbuilt-in

Sidekiq時代にsidekiq-cronやwheneverを別途入れていた定期実行も、Solid Queue単体でできる。

# config/recurring.yml
production:
  periodic_cleanup:
    class: CleanupJob
    schedule: every day at 9am

  sync_data:
    class: SyncJob
    schedule: every 5 minutes

  nightly_batch:
    class: NightlyBatchJob
    schedule: "0 3 * * *"

dispatcherプロセスがスケジュールを監視し、時刻が来たら自動でenqueueする。DBロックで排他制御されるため複数プロセスでも重複実行されない。

Solid Queueを避けるべきケース

1. DBがすでにボトルネック — ジョブキューのクエリがアプリDBに負荷を追加する（対策: Solid Queue用に別DBを設定）
2. Ruby/Rails以外のワーカーがキューを共有する — PythonやGoのワーカーが同じキューから取り出す構成ではRedisの方が言語非依存
3. 1秒未満のリアルタイム性が必要 — DBポーリング間隔（デフォルト1秒）の遅延が許容できない場合

逆に言えば、上記に該当しない通常のRailsアプリならSolid Queue一択でよい。