複数の NestJS ノードで cron ジョブをどう調整する？

Question

IT Interview Practice · Accepted Answer

まず「cronjobを1つのノードだけで実行する」の意味を決めます。**同時実行の防止と、業務上の効果が繰り返されることの防止は別の要件です。**共有スケジューラーは実行を調整しますが、処理自体も障害後の再試行に耐えなければなりません。

3つのNestJSノードに配置した日次請求ジョブを考えます。予定した処理を実行しつつ、ワーカーの再起動で別の請求書を作らないようにしたい状況です。

## 1. すべてのノードが開始する理由を理解する

各アプリケーションインスタンスは自分のcronコールバックを登録します。予定時刻になると、それぞれが独立して開始できます。

```text
00:00 -> Node A -> invoice task
      -> Node B -> invoice task
      -> Node C -> invoice task
```

ローカルのisRunningフラグは1つのプロセスにしか存在しません。NestJSのwaitForCompletionはそのインスタンス内のコールバック重複を防げますが、他のノードとは調整しません。同じフラグを3つのノードに追加しても、判断は3つに分かれたままです。[NestJSのスケジューリング](https://docs.nestjs.com/techniques/task-scheduling)。

どの仕事が存在し、誰が処理してよいかを決める共有の場所が必要です。

## 2. 調整モデルを選ぶ

| 状況 | 検討する方法 | 残る責任 |
| --- | --- | --- |
| 基盤にスケジュール実行機能がある | Webインスタンスの外で予定を管理する | 重複実行、復旧、実行漏れの動作を設定する。 |
| チームがBullMQを運用している | 共有Job Schedulerと専用キュー | 全体の並行数と安全な再試行を設定する。 |
| 既存処理をアプリケーションノードに残す必要がある | 共有ロックまたはリース | 所有権、期限切れ、古いワーカーを正しく扱う。 |

請求の例でRedisとBullMQがすでにあるなら、安定したスケジューラーIDを使う共有スケジューラーは実用的な候補です。予定とワーカーを分け、Webノードの追加で独立した予定が増えないようにします。

対応するBullMQバージョンでは、専用キューのグローバル並行数を1にします。全ワーカーを通じたアクティブジョブ数を制限できます。各ワーカーのローカル並行数を1にするだけでは、複数ワーカーが別々のジョブを同時に実行できます。[グローバル並行数](https://docs.bullmq.io/guide/queues/global-concurrency)。

昨日の処理がまだ続いている場合に、待つ、飛ばす、複数回分をまとめるのどれにするか決めます。タイムゾーンと、停止中に抜けた業務日を後から処理するかも定めます。

## 3. ジョブだけでなく請求書を守る

ワーカーが請求書を作成した後、完了を記録する前に停止したとします。復旧時には、請求書が存在するのにジョブが再実行される可能性があります。

```text
[Create invoice] -> [Crash before completion]
                              |
                            [Retry]
                              |
                  [Same business key: reuse result]
```

顧客と請求期間の組み合わせなど、安定した業務キーを使います。ローカルデータベース内の処理なら、一意制約とトランザクションで請求書作成と実行完了記録を結び付けられます。再試行は別の請求書を作らず、既存の結果を見つけます。

外部サービスでは、対応していれば冪等性キーを使い、結果が不明な処理は照合します。キューのジョブIDや保存されたジョブ記録だけでは、業務処理が永久に重複しない保証にはなりません。[冪等なジョブ](https://docs.bullmq.io/patterns/idempotent-jobs)。

## 4. ロックの保証と限界を知る

共有ロックは原子的に取得します。所有権トークン、有効期限、更新を使い、トークンがまだ一致する場合だけ解放します。そうしないと、古いワーカーが新しいワーカーのロックを解放する恐れがあります。

期限切れには別の問題もあります。一時停止したワーカーがリース期限後に再開し、その間に新しいワーカーが動いている場合です。重要な書き込みでは、増加する所有権番号を受信側が確認して古いワーカーを拒否するfencing tokenが必要になることがあります。長いタイムアウトを設定するだけでは、この危険は消えません。

調整機構が使えないとき、所有権なしに実行するより待つべきかを決めます。重大な影響のある仕事では、待つほうが安全な場合が多いです。

## 5. 障害パターンを検証する

複数ノード、請求書作成直後の停止、リースより長い中断、Redisとの接続断、ローリングデプロイを試します。業務日、ワーカー、試行、結果を記録し、試行の繰り返しと効果の重複を区別できるようにします。

**要点：**予定を調整 → 共有の実行数を制限 → 業務処理を再試行可能にする → 復旧をテスト。「アクティブジョブが1つ」だけでは、業務効果が正確に1回という証明にはなりません。

状況	検討する方法	残る責任
基盤にスケジュール実行機能がある	Webインスタンスの外で予定を管理する	重複実行、復旧、実行漏れの動作を設定する。
チームがBullMQを運用している	共有Job Schedulerと専用キュー	全体の並行数と安全な再試行を設定する。
既存処理をアプリケーションノードに残す必要がある	共有ロックまたはリース	所有権、期限切れ、古いワーカーを正しく扱う。

1. すべてのノードが開始する理由を理解する

2. 調整モデルを選ぶ

3. ジョブだけでなく請求書を守る

4. ロックの保証と限界を知る

5. 障害パターンを検証する

関連する質問