障害の根本原因を探る

非同期バッチ処理二重実行障害：技術的・組織的根本原因分析

Tags: バッチ処理, 非同期処理, 冪等性, 障害分析, 根本原因

システム運用において、定期的に実行されるバッチ処理は重要な役割を担います。しかし、この非同期で動作するバッチ処理において、予期せぬ障害として「二重実行によるデータ不整合」が発生することがあります。これは、本来一度だけ実行されるべき処理が複数回実行されてしまうことで、データベースのデータが重複したり、不正な状態になったりする深刻な問題です。

本稿では、このバッチ処理の二重実行障害について、その技術的・組織的な根本原因を掘り下げて分析し、同様の事態を防ぐための具体的な再発防止策について考察します。

障害事象の概要：バッチ処理の二重実行

発生する障害は、特定のバッチ処理が同時刻または近接した時刻に複数インスタンス起動し、それぞれが同じ処理対象データに対して更新処理を行ってしまうというものです。これにより、例えばユーザーへの通知メールが二重送信されたり、ポイント付与処理が重複したり、注文ステータスが不正に変更されたりといったデータ不整合が発生します。

この種の問題は、システムの規模が大きくなり、バッチ処理の数や実行頻度が増加するにつれて、発生リスクが高まります。また、一時的なシステム負荷増や、インフラストラクチャの不安定性などもトリガーとなることがあります。

技術的な根本原因の分析

バッチ処理の二重実行が発生する技術的な背景には、主に「排他制御の不備」が存在します。バッチ処理は非同期で独立して実行されることが多いですが、同じデータリソースに対して操作を行う場合は、その実行を適切に制御する必要があります。

考えられる技術的な根本原因としては、以下の点が挙げられます。

  1. 多重起動防止機構の実装漏れまたは不備:

    • 最も直接的な原因は、バッチ処理が複数起動した場合に、後続の起動を検知して停止させる仕組み（排他制御）が実装されていない、あるいは適切に機能していないことです。
    • 排他制御の実装方法としては、以下のようなものが考えられますが、それぞれに考慮すべき点があります。
      • ファイルロック: 特定のファイルが存在するかどうかで排他制御を行う方法ですが、NFSなどの分散ファイルシステムではロックが正常に機能しない、ファイル削除漏れでデッドロックするなど、リスクがあります。
      • データベース上のフラグ/ロック: データベースのテーブルに実行中のバッチ名などのフラグを立てる方法や、特定のレコードに対してDBロックを取得する方法です。しかし、DB接続断やアプリケーション異常終了時にロックが解放されないリスク、複数のDBインスタンスに跨がる場合に同期が難しいなどの課題があります。
      • 分散ロックサービス: Redis, ZooKeeper, Consulなどの分散ロック機能を利用する方法です。比較的堅牢な排他制御を実現できますが、これらのサービス自体の可用性や、ネットワーク遅延、ロックの有効期限（Lease）の設計などを考慮する必要があります。
    • これらの排他制御機構が実装されていても、例外処理でのロック解放漏れや、タイムアウト設定の不備、ネットワーク分断時の挙動などによって、多重起動を許してしまうケースがあります。

  2. スケジューラまたは実行基盤の問題:

    • バッチ処理を起動するスケジューラ（Cron, Quartz, AWS Step Functionsなど）や、バッチを実行するワーカープロセス（Kubernetes Pod, ECS Task, VMなど）の設計や設定に問題がある場合です。
    • スケジューラが誤って同じジョブを複数回起動指示を出したり、一時的な通信エラーをリトライした結果、重複して起動されたりすることがあります。
    • コンテナオーケストレーション環境などでは、ノード障害や再配置の際に、予期せずPodが再起動されることでバッチ処理も再実行されてしまう可能性があります。
    • 複数のワーカーノードでバッチ処理を並列実行している場合、処理対象データの分割方法や、各ワーカーが処理中のデータを適切に管理する仕組みがないと、複数のワーカーが同じデータを処理してしまう可能性があります。

  3. 処理の冪等性（Idempotency）に関する考慮不足:

    • バッチ処理は、同じ入力に対して何度実行されても同じ結果となる「冪等性」を持つように設計することが望ましいとされています。しかし、多くのバッチ処理、特に更新処理を含むものは、設計段階でこの冪等性が十分に考慮されていないことがあります。
    • 例えば、「残高に1000円を追加する」という処理は冪等ではありません（二回実行すると2000円追加される）。これを冪等にするには、「残高を特定の金額にする」あるいは「トランザクションIDと金額を記録し、既にそのトランザクションIDが処理済みであればスキップする」といった設計が必要になります。
    • 冪等性の設計が不十分な場合、例え二重実行が発生しても、その影響を最小限に抑えることができません。

組織的な根本原因の分析

技術的な問題の背景には、しばしば組織的、あるいはプロセス上の問題が潜んでいます。バッチ処理の二重実行障害における組織的な根本原因としては、以下が考えられます。

  1. 設計・レビュープロセスの不備:

    • 非同期処理や分散システムにおける排他制御、冪等性の重要性に関するチーム内の知識不足。
    • バッチ処理の設計レビュー時に、多重起動のリスクや冪等性に関する考慮が十分に確認されていない。
    • インフラストラクチャ（スケジューラ、実行基盤）とアプリケーションの連携に関する考慮不足。

  2. テストプロセスの不備:

    • バッチ処理の単体テストや結合テストにおいて、複数起動シナリオや異常終了後のリトライシナリオが考慮されていない。
    • 本番環境に近い構成での負荷テストや、障害注入テスト（ネットワーク分断、プロセス強制終了など）が実施されていない。

  3. 運用体制・プロセスの不備:

    • バッチ処理の実行状況（正常終了、エラー、実行時間など）を監視する仕組みが不十分。
    • 障害発生時の対応マニュアルが整備されておらず、手動での再実行判断や手順が属人化している。
    • 開発チームと運用チーム間の、バッチ処理の特性やリスクに関する情報共有が不足している。

  4. ナレッジマネジメントの不足:

    • 過去に発生した類似の障害事例や、排他制御・冪等性に関するベストプラクティスが組織内で共有されていない。

具体的な調査手順と切り分け方

障害発生時、二重実行によるデータ不整合であると疑われる場合の一般的な調査手順と切り分け方のポイントを以下に示します。

  1. 事象の正確な把握: いつ、どのバッチ処理で、どのようなデータ不整合が発生したのか、具体的な日時、処理対象、不整合の内容（例: レコード重複、数値の二重加算）を特定します。
  2. バッチ処理の実行履歴確認: スケジューラのログや、バッチ処理自身のログを参照し、問題の発生時刻に、当該バッチ処理が複数回起動されていないか確認します。同時刻に起動しているか、短時間のうちに再起動されているかなどが重要な手がかりとなります。
  3. アプリケーションログの分析: バッチ処理のログの詳細を確認し、処理の開始・終了、処理対象データのID、取得したロックの情報（もしあれば）、発生したエラーなどを時系列で追います。複数のインスタンスのログを突き合わせることで、どちらが先に実行され、どこで競合が発生したのかが見えてくる場合があります。
  4. システムログ・インフラログの確認: スケジューラ、ワーカープロセスが動作しているサーバ/コンテナのシステムログ、実行基盤（Kubernetes, ECSなど）のイベントログ、ネットワークログなどを確認します。予期せぬプロセス終了、リソース不足、ネットワーク障害などが起きていないか確認します。
  5. 処理対象データの状態確認: 不整合が発生したデータの状態をDBなどで直接確認します。データのタイムスタンプや、バージョン情報、特定のフラグなどを確認することで、どのインスタンスによって、どのような順序で処理されたのか推測できることがあります。
  6. コードレビュー: バッチ処理のコード、特に起動時の排他制御、処理対象データの取得・更新部分、エラーハンドリング、リトライ処理の実装をレビューします。想定外のシナリオで排他制御が Bypass されないか、冪等性が考慮されているかなどを確認します。

これらの調査を通じて、「なぜ複数起動したのか（技術・組織）」と「複数起動しても影響がなかったはずなのに、なぜ不整合が起きたのか（技術・組織）」という二つの側面に分けて原因を深掘りすることが重要です。

再発防止策

根本原因の分析を踏まえ、再発防止のために以下の技術的・組織的な対策を検討します。

技術的対策

組織的対策

まとめ

非同期バッチ処理の二重実行によるデータ不整合は、技術的な排他制御や冪等性の実装不備だけでなく、設計・テスト・運用といった組織的なプロセスの問題が複合的に絡み合って発生する複雑な障害です。

障害発生時には、スケジューラやバッチ処理自身のログ、システムログなどを詳細に分析し、二重実行の事実とその発生タイミング、そしてデータがどのように影響を受けたのかを正確に把握することが、根本原因にたどり着くための第一歩となります。

再発防止のためには、技術的な側面では堅牢な排他制御と冪等性の設計・実装が不可欠です。同時に、組織的な側面から、設計レビュー、テスト、運用、情報共有のプロセスを見直し、改善していくことが、よりレジリエントなシステム構築には欠かせません。

本稿が、バッチ処理の運用に関わる皆様の障害対応力向上の一助となれば幸いです。