⚙️
Sidekiqはどう動くのか？
Redisベースのバックグラウンドジョブキューシステム
SidekiqはRubyの代表的なバックグラウンドジョブプロセッサです。Webリクエスト中の時間がかかるタスクをRedisキューにシリアライズされたジョブとして投入し（perform_async）、別のSidekiqワーカープロセスがマルチスレッドでキューからジョブを取り出して処理します。Webプロセスは即座にレスポンスを返すことができ、実際の処理はバックグラウンドで行われます。失敗したジョブは自動リトライされ、Dead状態のジョブはWeb UIでモニタリング可能です。
構造ダイアグラム
🌐
Webプロセス
Rails / Puma
MyWorker.perform_async(id)
① LPUSH (enqueue)
→
🗄️
Redis
queue:default
queue:mailers
retryセット
deadセット
② BRPOP (dequeue)
→
⚙️
Sidekiqワーカー
マルチスレッドプロセス
Thread 1: メール
Thread 2: エンコード
Thread 3: 待機
失敗時のリトライフロー:
失敗
→
retryキュー（exponential backoff）
→
25回リトライ
→
Deadキュー
キーポイント
- Webプロセスとワーカープロセスは<strong>別プロセス</strong>（同じコードベース）
- Redisがキューの役割 — ジョブはJSONでシリアライズ
- BRPOP: キューが空ならブロッキング待機（ポーリングではない）
- ワーカーはマルチスレッドで同時に複数ジョブを処理
動作フロー
1
WebリクエストでMyWorker.perform_async(args)を呼び出し
2
ジョブ情報がJSONにシリアライズされRedisキューにLPUSH
3
SidekiqワーカープロセスがRedisからBRPOPでジョブを取り出し
4
ワーカーがperform(args)メソッドを実行（別スレッド）
5
成功時ジョブ削除、失敗時retryキューに移動（exponential backoff）
6
最大リトライ超過時Deadキューに移動（手動確認が必要）
メリット
- ✓ Web応答速度の改善（重いタスクの分離）
- ✓ 自動リトライ（exponential backoff）
- ✓ マルチスレッドによる高スループット
- ✓ Sidekiq Web UIでモニタリング
デメリット
- ✗ Redis依存（Redisダウン = ジョブ処理停止）
- ✗ ジョブシリアライズの制約（複雑なオブジェクト渡し不可）
- ✗ マルチスレッド安全性への注意
- ✗ 重複実行の可能性（冪等性が必要）
ユースケース
メール/通知送信
画像/動画エンコーディング
外部API呼び出し（決済、配送）
CSV/PDFの大量生成
データ同期/整理