arch-saga

1 行での概要

複数ステップからなるビジネスワークフローを、それぞれ異なるサービス／アグリゲート内で実行される一連のローカルトランザクションとして実行します。あるステップが失敗した場合は、先行して成功したステップを取り消すための補償アクションを実行します。ロールバックはありません。あるのは前に進む補償だけです。

このスキルを使用する場面

• ビジネスプロセスが複数のサービスまたは複数のアグリゲートにまたがり、単一のトランザクションを共有できない場合。
• 一部のステップが外部（サードパーティー API、決済処理サービス）にあり、トランザクションとして扱えない場合。
• 分散ロックを保持するのが現実的ではない、長時間実行されるワークフローの場合。
• 「ステップ X が失敗したら、取り消すためにステップ X' を実行する」という明確な概念がビジネスにある場合。

このスキルを使用しない場面

• すべてが単一のサービス／単一のアグリゲート内で完結する場合は、ローカルのデータベーストランザクションを使用してください。
• ステップが冪等で、順序に依存しない場合は、サガによる調整自体が不要なことがあります。
• 「アトミックな」ロールバックのセマンティクスが本当に必要な場合（分散システムではまれです）、サガではそれを実現できません。サガが提供するのは、補償による結果整合性です。

主な内容

調整方法の異なる2 つのスタイルがあります。

コレオグラフィ型サガ。 各サービスがイベントを監視し、いつ処理するかを判断します。サービス A がステップ 1 を完了して Step1Completed を発行し、サービス B がそれを受け取ってステップ 2 を完了し、Step2Completed を発行します。以降も同様です。補償もイベント（Step1Compensated）として発行されます。

• 長所：分散型で、単一障害点がなく、水平方向にスケールできます。
• 短所：ワークフロー全体が暗黙的になり、全体を所有する人がいません。停止したサガのデバッグは困難で、新しいステップの追加には複数のサービスへの変更が必要です。

オーケストレーション型サガ（プロセスマネージャー）。 中央のオーケストレーターがワークフローを進行させます。各サービスに順番にコマンドを送り、その応答を待ち、次のステップ（続行または補償）を決定します。

• 長所：ワークフローが明示的に 1 か所にまとまり、把握やテストが容易です。
• 短所：オーケストレーターは高可用性が必要な調整コンポーネントです。集中化には実際のコストが伴います。

ロールバックではなく、補償アクションを使用します。

• ロールバック（データベーストランザクション）は、何も起きなかったかのように状態を復元します。補償アクションはビジネス上の効果を取り消します。支払いの払い戻しは補償ですが、支払いがすでに処理された場合、支払いをロールバックするという方法はありません。
• 補償は冪等であり、一部の処理が完了した後に呼び出しても安全でなければなりません。
• 補償できないアクションもあります（メールの送信、外部の取り消し不能な API の呼び出しなど）。サガの前段階で失敗した場合にそうしたアクションまで到達しないよう、これらのステップは最後に実行するよう設計してください。

冪等性と少なくとも 1 回の配信。 サガはイベント駆動の世界で動作します。メッセージが再配信されることがあります。すべてのステップとすべての補償は冪等でなければなりません。

サガの状態。 オーケストレーター（コレオグラフィ型の場合は各サービスに分散）は、各サガインスタンスの進行状況を追跡します。この状態を永続化してください。サガはクラッシュすることがあるため、再開できる必要があります。

判断のヒューリスティクス

• ステップが 3 つ以下で、参加者が固定されている場合は、コレオグラフィを使用します。
• ステップが 4 つ以上の場合、後からステップが追加される可能性がある場合、または補償ロジックが複雑な場合は、オーケストレーションを使用します。
• 取り消し不能なステップが最後になるように、ステップの順序を決めます。
• すべてのステップに、初日から冪等性を組み込みます。
• オーケストレーターの状態を永続化し、再起動時に読み込みます。
• 複雑さに応じて、独自のオーケストレーターを作る代わりにワークフローエンジン（Temporal、Camunda、Conductor）を使用します。ただし、意図を持って利用してください。これらは実際の依存関係です。

アンチパターン

• 実際には同期 RPC を連鎖させているだけの「Saga」。 サービス A が B を呼び、B が C を呼びますが、イベントブローカーはありません。これは分散呼び出しチェーンであり、Saga ではありません。失敗時に補償するのではなく、単に伝播します。
• 実際には補償になっていない補償アクション。 ユーザーに返金する代わりに、レコードを「キャンセル済み」とマークします。半端に元に戻しているだけです。
• 冪等でないステップ。 同じメッセージが再配信されると、ステップが 2 回実行され、ユーザーに 2 回請求されます。
• 途中にある取り消し不能なステップ。 ステップ 3 で取り消せないメールを送信し、ステップ 4〜5 が失敗すると、そのメールを取り消せません。最後に配置してください。
• 20 ステップの Saga。 手作りの Saga ではなく、ワークフローエンジンを使うべきでしょう。

関連項目

• arch-event-driven — Saga のイベントはブローカーを通じて流れます。
• arch-microservices — サービス間のトランザクションをどう処理するかという問いに対する標準的な答えが Saga です。
• arch-event-sourcing — Saga の状態はイベントソーシングされることがよくあります。
• arch-circuit-breaker — 他のサービスを呼び出す Saga のステップでは、サーキットブレーカーで保護してください。
• ddd-domain-event — Saga のステップはドメインイベントを生成／消費します。

参考資料

• Hector Garcia-Molina と Kenneth Salem、「Sagas」（1987 年）— 原著論文。
• Khononov、『Learning DDD』、マイクロサービス／イベント駆動型の章にある Saga の節。
• Bellemare、『Building Event-Driven Microservices』第 8 章（マイクロサービスでワークフローを構築する）。