概要
- Rails 8では Redisが標準スタックから除外 され、SolidQueueなどの新機能がDBベースで動作
- SolidQueueは PostgreSQLなどのRDBMSを利用してジョブキューを管理 し、Redis不要に
- Redis導入・運用のコストや複雑さを削減し、 Railsアプリのシンプル化が可能
- SolidQueueは 高機能（定期実行・同時実行制限・UI）を標準装備
- Redisが必要なケースもあるが、 大半のアプリはSolidQueueで十分対応可能
Rails 8でRedisが不要になった理由
- Rails 8 では、 SolidQueue（ジョブキュー）・SolidCache（キャッシュ）・SolidCable（ActionCableメッセージ） が標準搭載
- これらは 既存のRDBMS（PostgreSQL/SQLite/MySQL）上で動作 し、 Redisの役割を完全に代替
- ほとんどのRailsアプリで Redisを削除可能、運用コスト・複雑さの低減
Redis運用の隠れたコスト
- Redisサーバのデプロイ・バージョン管理・パッチ適用・監視 の必要性
- 永続化戦略（RDB/AOF/両方）・メモリ制限・エビクションポリシー の設定
- ネットワーク接続・ファイアウォール・クライアント認証・HA構成 の維持
- Sidekiqプロセスのオーケストレーション や 異なるデータストア（RDBMS/Redis）間のデバッグ の煩雑さ
- バックアップ戦略の二重管理 も必要
SolidQueueの仕組み
- PostgreSQL 9.5以降のFOR UPDATE SKIP LOCKED を活用して、 ロック競合せずにジョブを分配
- ジョブの状態管理用テーブル：
- solid_queue_jobs （全ジョブのメタデータ記録）
- solid_queue_scheduled_executions （スケジュール待ちジョブ）
- solid_queue_ready_executions （即時実行待ちジョブ）
- ワーカーはreadyテーブルをポーリングし、SKIP LOCKEDで同時にジョブ取得
- MVCC＋autovacuum で大量のinsert/deleteにも耐性
定期実行ジョブ（Recurring Jobs）
- Sidekiqではsidekiq-cron等が必要 だが、 SolidQueueはcron風定期実行を標準搭載
- config/recurring.yml でスケジュール記述
- GoodJob由来の決定論的スケジューリング でクラッシュ耐性
ジョブ同時実行数制限（Concurrency Limit）
- Sidekiq Enterpriseの有償機能 だったが、 SolidQueueは標準で対応
- limits_concurrency で単位ごとの同時実行数・期間を制御
- solid_queue_semaphores/blocked_executions テーブルで待機ジョブ管理
- ジョブ終了時に自動で次のジョブをアンブロック
Mission Controlによる監視・管理
- Mission Control Jobs はSolidQueue専用の無料・OSSダッシュボード
- リアルタイム状態・失敗ジョブ・リトライ・スケジュール可視化・メトリクス を提供
- SQLで直接ジョブデータをクエリ可能、外部ツール不要
SidekiqからSolidQueueへの移行手順
- queue_adapterを:solid_queueに変更
- SolidQueue gem導入・マイグレーション実行
- Sidekiq-cron等のスケジュールをrecurring.ymlへ変換
- Procfileのjobsプロセスをsolid_queue:startに変更
- Redis/Sidekiq関連gemを削除し、bundle clean
SolidQueueが適さないケース
- 常時数千ジョブ/秒以上の高負荷
- 1ms未満の超低レイテンシが必須
- 複雑なpub/subやレート制限・カウンター用途
- 例：リアルタイムビッディング、HFT、Shopify級の超大規模
実用的なSolidQueueセットアップ例
- 新規Rails 8アプリ作成時、SolidQueue/SolidCache/SolidCableは自動設定
- queue用DB接続をdatabase.ymlで分離推奨
- Mission Controlの認証設定・マウント
- Procfileでjobsプロセス追加
- テストジョブで動作確認
- 単一DB運用も可能だが、分離接続が推奨
よくある注意点・運用Tips
- Mission Controlの本番運用時は認証強化必須
- ポーリング間隔調整でレイテンシ最適化可能
- ActionCable/Turbo Streams利用時はSolidCable用DB接続も設定
- サーバ起動時にすべてのプロセスを同時起動
スケーラビリティとパフォーマンス
- ほとんどのRailsアプリはSolidQueueで十分スケール
- 例：37signalsはPostgreSQLのみで日2,000万ジョブ処理
- Redis+Sidekiqに比べ、運用シナリオ・障害パターンが少なくシンプル
- 99%以上のRailsアプリでSolidQueueが最適解
まとめ
- Redis/Sidekiqの組み合わせは依然優秀 だが、 ほとんどのRails 8アプリはSolidQueueで十分
- インフラのシンプル化と運用負荷の軽減 が最大のメリット
- 新しいRails 8の流儀としてSolidQueue導入を推奨
- フィードバックや意見も歓迎