Zenn
📝

SAGAパターンの補償アクション失敗にどう立ち向かうか？DLQとリトライ戦略

に公開
saga
tech

SAGAパターンの補償アクション失敗にどう立ち向かうか？DLQとリトライ戦略

マイクロサービスアーキテクチャで分散トランザクションを実現するSAGAパターンは、その柔軟性から多くのシステムで採用されています。
しかし、SAGAパターンの核となる「補償アクション」が失敗した場合、データの一貫性をどう保つかという課題に直面します。

例えば、サービスA、サービスB、サービスCへと順にリクエストが進むSAGAトランザクションを考えてみましょう。

サービスCでエラーが発生し、ロールバック処理が開始。
サービスBの補償アクションは成功したものの、サービスAの補償アクションがエラーになってしまった…。

  1. サービスAへのリクエスト → 成功
  2. サービスBへのリクエスト → 成功
  3. サービスCへのリクエスト → エラー
  4. サービスBへの補償アクション → 成功
  5. サービスAへの補償アクション → エラー

このような状況では、どのような対応が必要なのでしょうか？

この記事では、補償アクションの失敗という厄介な問題への対処法、特にデッドレターキュー（DLQ）とリトライ戦略を中心に検討します。

補償アクション失敗が引き起こす問題

SAGAパターンでは、各ローカルトランザクションの完了後に、次のステップに進みます。
途中でエラーが発生した場合、それまでに完了したトランザクションを取り消すための補償アクションが実行されます。
この補償アクションが失敗すると、システムは不整合な状態に陥ってしまう可能性があります。
データの一貫性はシステムにおける最重要課題の一つであり、補償アクションの成功はSAGAパターンを運用する上で極めて重要です。

基本戦略：補償アクションは「必ず」成功させる

大前提として、補償アクションは必ず実行され、成功するまで面倒を見る必要があります。
この考え方に基づき、具体的な対応策を見ていきましょう。

失敗への多層的アプローチ

サービスAの補償アクションが失敗した場合、以下のような多層的なアプローチで対応します。

1. 堅牢なリトライ処理の実装

補償アクションの呼び出しに失敗した場合、まずリトライ処理を試みます。

  • 即時リトライ:
    ネットワークの一時的な不安定さなどが原因である可能性を考慮し、数回程度の即時リトライを行います。
  • 間隔を空けたリトライ（Exponential Backoff + Jitter）:
    即時リトライで解決しない場合、リトライ間隔を指数関数的に増やしながら再試行します（例: 1秒後、2秒後、4秒後…）。さらに、ジッター（ランダムな遅延）を加えることで、多数のリクエストが同時に集中し、対象サービスに過度な負荷をかけるのを防ぎます。
  • リトライ回数の上限設定:
    無限にリトライを繰り返すのではなく、現実的な上限回数を設けます。

2. デッドレターキュー（DLQ）の活用

設定したリトライ上限に達しても補償アクションが成功しない場合、そのメッセージ（補償アクションを実行するための情報）をデッドレターキュー（DLQ）に送信します。

DLQに格納されたメッセージは、システムが自動的に処理できなかった「問題のある」メッセージです。これらのメッセージに対しては、以下のような対応を行います。

  • 定期的なリトライ:
    DLQからメッセージを定期的に読み出し、サービスAの補償アクションエンドポイントが復旧するまで、あるいは問題が解決するまでリトライを継続する専用のプロセスやワーカーを用意します。
  • 手動での再処理トリガー:
    運用者が状況を確認した上で、手動でDLQ内のメッセージの再処理をトリガーできる仕組みも有効です。

3. 監視とアラート体制の確立

DLQにメッセージが滞留し始めた場合、それはシステムに何らかの問題が発生しているサインです。

  • DLQのキュー長や最も古いメッセージの経過時間などを監視します。
  • 閾値を超えた場合に、開発者や運用者にアラートを通知する仕組みを構築します。これにより、問題の早期発見と迅速な対応が可能になります。

4. 手動介入（最終手段）

自動リトライやDLQからの再処理でも解決しない、根深い問題が発生している場合も想定しておく必要があります。

  • ログやDLQ内のメッセージ内容を詳細に調査し、失敗の原因を特定します。
  • 必要に応じて、データベースの直接修正や、手動での補償処理実行など、人手による介入を行います。
  • このような手動介入が必要になった場合に備え、運用手順書や専用の管理ツールを事前に準備しておくことが望ましいです。

補償アクション自体の設計で考慮すべきこと

補償アクションの失敗リスクを低減し、万が一失敗した場合の影響を最小限に抑えるためには、補償アクション自体の設計も重要です。

  • 冪等性（Idempotency）:
    補償アクションは、何度実行しても結果が変わらないように設計します（冪等性を担保します）。これにより、リトライ処理が安全に行え、「複数回実行されてしまったらどうしよう」という懸念を排除できます。
  • 簡潔性と高可用性:
    補償アクションのロジックは可能な限りシンプルにし、外部サービスへの依存を減らすことで、それ自体が失敗しにくいようにします。また、補償アクションを実行するエンドポイント自体も高可用性を確保するべきです。
  • 補償の順序:
    基本的には、SAGAで実行されたトランザクションの逆順で補償アクションを実行します。ただし、ビジネスロジックやデータの依存関係によっては、順序の入れ替えや並行実行が許容されるケースもあります。しかし、これがリカバリシナリオを複雑にしすぎないよう注意が必要です。
  • タイムアウト設定:
    補償アクションが外部サービスを呼び出す場合など、予期せず長時間応答がないケースに備え、適切なタイムアウト値を設定します。
  • ビジネス的な許容範囲の確認:
    補償アクションの遅延や一時的なデータ不整合が、ビジネス的にどの程度許容されるのかを事前にステークホルダーと合意しておくことが重要です。これにより、リトライ戦略の厳格さや、手動介入が必要となるまでの猶予期間などを判断する基準となります。

まとめ

SAGAパターンにおける補償アクションの失敗は、分散システムにおけるデータ一貫性を脅かす重大な課題です。
この課題に対処するためには、DLQと継続的なリトライ戦略が有効な手段となります。

しかし、それだけに頼るのではなく、

  • 堅牢なリトライメカニズムの段階的導入
  • DLQを活用した永続的なエラー処理
  • 問題の早期発見のための監視とアラート
  • 最終手段としての手動介入プロセスの整備
  • そして何よりも、冪等性や簡潔性を考慮した補償アクション自体の設計

これらの対策を組み合わせることで、SAGAパターンを用いたシステムの信頼性と堅牢性を大幅に向上させることができるでしょう。
分散トランザクションの難しさに立ち向かい、より安定したシステム運用を目指しましょう。

さらなる深淵：DLQへのメッセージ送信すら失敗する場合

補償アクションの失敗に備え、DLQとリトライ戦略を検討しました。
しかし、もし補償アクションの失敗を記録しようとしたDLQへのメッセージ送信自体が失敗したらどうなるのでしょうか？これは「失敗の失敗」とも言える、より深刻な状況です。

このレベルの障害が発生した場合、システムはデータ不整合のリスクが極めて高い状態にあることを意味します。
考えられる対策は以下の通りです。

  1. ローカルフォールバックストレージへの記録試行:
    • DLQ（通常はリモートのメッセージブローカー）への送信が失敗した場合、補償が必要であるという情報（どのトランザクションの、どの補償アクションかなど）を、まずは実行元のサービスインスタンスのローカルストレージ（ローカルディスク上のファイル、ローカルデータベースの専用テーブルなど）に書き出すことを試みます。
    • これは、ネットワーク障害などで一時的にDLQにアクセスできないが、ローカルリソースは生きている場合に有効です。
    • ローカルに保存されたメッセージは、定期的なバックグラウンドプロセスによってDLQへの再送信を試みるか、あるいは直接補償アクションの再試行を試みる必要があります。
  2. 徹底的なローカルロギングと即時アラート:
    • ローカルフォールバックストレージへの書き込みすら失敗する（例：ディスクフル、ローカルDBダウン）場合、これはアプリケーションにとって致命的な状況です。
    • この状況では、できる限り詳細なエラー情報をローカルのログファイルに記録し（可能な限り永続化される場所へ）、即座に最高レベルの緊急アラートを発報するべきです。
    • このアラートは、システム全体、あるいは少なくとも当該サービスが重大な機能不全に陥っていることを示し、即時の人手による調査と介入が不可欠であることを意味します。
  3. Sagaインスタンスの凍結と手動調整フラグ:
    • 補償アクションの記録に完全に失敗したSagaインスタンスは、もはや自動復旧が期待できない「危険な状態」にあると見なすべきです。
    • 該当のトランザクションIDや関連データを特定し、システム上で「手動調整要」といったフラグを立て、それ以上の自動処理が進まないように（あるいは特定の警告を表示するように）マークすることを検討します。
  4. インフラストラクチャの健全性確認:
    • DLQへの送信失敗は、メッセージング基盤自体の広範な障害や、ネットワーク全体の深刻な問題を示唆している可能性があります。個別のアプリケーションレベルの問題だけでなく、インフラ全体の健全性確認が急務となります。
  5. DLQ自体の高可用性設計:
    • そもそも論として、DLQとして利用するメッセージングシステム自体も、他の本番システムコンポーネントと同様に、高い可用性と耐障害性を持つように設計・運用されていることが大前提となります。

このレベルの障害への対応は複雑性を増す

DLQへの送信失敗まで考慮したフォールバック戦略は、システムの複雑性を確実に増大させます。
どこまでの障害シナリオに備えるかは、システムのビジネス上の重要性、許容されるダウンタイムやデータ不整合のリスク、そして開発・運用コストとのトレードオフになります。

しかし、少なくとも「DLQへの送信失敗時には、ローカルにログを最大限残し、最高レベルのアラートを発する」という最低限の対策は、多くのシステムで検討すべき重要なポイントと言えるでしょう。

GitHubで編集を提案

Discussion