BullMQ の長所と短所、適した用途は？

Question

IT Interview Practice · Accepted Answer

BullMQはRedisを使うNode.js向けのジョブキューです。適しているかは、**HTTPレスポンスの後で完了してよく、追跡や再試行が必要な仕事**から考えます。

大きなレポートを例にします。リクエストの中で生成すると、ユーザーはタイムアウトまで待たされるかもしれません。キューなら処理を受け付け、ジョブIDを返し、別途実行できます。

## 1. キューに移すと何が変わるかを見る

```text
[User] -> [API: submit job] -> [Redis / BullMQ] -> [Worker]
                |                                   |
          [Return job ID]                       [Saved report]
```

プロデューサーがジョブを送り、ワーカーが実行します。ユーザーは進捗を確認し、完成したら保存済みレポートをダウンロードします。

レポートの処理時間そのものは必要です。改善するのは、処理の存続が1本のHTTP接続に依存しなくなることと、APIサーバーとは別にワーカーを管理できることです。

## 2. 利点を要件に対応させる

| 必要なこと | BullMQの機能 | アプリケーションで決めること |
| --- | --- | --- |
| 一時的な障害から回復する | 待機時間を設けた再試行 | 再試行すべきエラーと打ち切る条件。 |
| 後で、または予定に従って実行する | 遅延ジョブとスケジュール | 必要な時刻精度と停止後の動作。 |
| 処理負荷を抑える | 並行数とレート制限 | データベースや外部サービスにとって安全な上限。 |
| バックグラウンド容量を増やす | ワーカーの追加 | 次の依存先が増加分に耐えられるか。 |

レポートでは、状態管理や再試行の仕組みを一から作らずに済みます。進捗確認と障害調査のための状態情報も得られます。ワーカーの追加が有効なのは、依存先を過負荷にせず完了を早められる範囲です。

## 3. 正しさに関する主な責任を理解する

ワーカーはレポートを保存した後、ジョブ完了を記録する前に停止することがあります。再試行で同じ処理が繰り返される可能性があります。課金や通知では、このパターンの影響がさらに大きくなります。

要求された仕事に安定した業務上の識別子を使います。同じ識別子で繰り返しても、効果を追加するのではなく、意図した結果を再利用するか安全に置き換えます。これが冪等性です。外部への効果では、提供元の対応機能を利用し、不確定な結果を照合します。[冪等なジョブ](https://docs.bullmq.io/patterns/idempotent-jobs)。

データベースへの保存とジョブ作成が両方必要なら、その間の隙間を考えます。outboxは業務レコードと同じトランザクションで指示を記録し、後でパブリッシャーがキューに送ります。配送は重複し得るので、ワーカーの冪等性は引き続き必要です。

## 4. Redisとワーカーの運用もコストに含める

Redisは未処理の仕事を持つため、永続化、メモリ方針、復旧計画が重要です。キューにはnoevictionを設定します。メモリ確保のために黙ってキーを消す動作は、保持すべきジョブには不向きです。アプリ再起動への耐性がRedisの全障害を覆うと思わず、復旧を試します。[本番運用の指針](https://docs.bullmq.io/guide/going-to-production)。

大きなレポートファイルは適切なストレージに置き、ジョブには参照を渡します。完了・失敗したジョブの保存期間を決め、Redisの使用量を管理します。

CPU負荷の高い処理はワーカーのイベントループを止め、ロック更新を妨げることがあります。その結果、ジョブが停止状態と判断され再処理される可能性があります。負荷に合ったワーカースレッドや隔離されたプロセッサーを使い、停止ジョブを監視します。[停止ジョブ](https://docs.bullmq.io/guide/jobs/stalled)。

## 5. 条件付きで推奨する

- Node.jsアプリに監視可能なバックグラウンド処理、再試行、個別に拡張できるワーカーが必要で、チームがRedisを安定運用できるならBullMQを選びます。
- 永続的な追跡や独立実行が不要な小さなローカル処理は、単純なままにします。
- 主目的がキュー内の仕事の完了ではなく、複数の独立したコンシューマーによる長期間の再読み取りなら、永続的なイベントログを検討します。

レポートの例では、依存先の失敗、出力保存後のワーカー停止、障害後の復旧を試します。ユーザーに正しい状態が見え、再試行で矛盾した出力ができないことを確認します。

**要点：**BullMQはジョブを調整します。業務上の正しさはアプリケーションが担い、キューの運用責任はチームに残ります。

必要なこと	BullMQの機能	アプリケーションで決めること
一時的な障害から回復する	待機時間を設けた再試行	再試行すべきエラーと打ち切る条件。
後で、または予定に従って実行する	遅延ジョブとスケジュール	必要な時刻精度と停止後の動作。
処理負荷を抑える	並行数とレート制限	データベースや外部サービスにとって安全な上限。
バックグラウンド容量を増やす	ワーカーの追加	次の依存先が増加分に耐えられるか。

1. キューに移すと何が変わるかを見る

2. 利点を要件に対応させる

3. 正しさに関する主な責任を理解する

4. Redisとワーカーの運用もコストに含める

5. 条件付きで推奨する

関連する質問