メインコンテンツまでスキップ

🧩 Saga パターン（分散トランザクション調整）

✅ このスタイルの概要​

複数サービスにまたがる一連の処理を、「ローカルトランザクション＋補償アクション」の組み合わせとして調整するパターン。

2PC（2 フェーズコミット）のような強い分散トランザクションではなく、
最終的な一貫性（Eventual Consistency）を前提とするアプローチである。

✅ 解決しようとした問題​

マイクロサービス化により、1 つのビジネス操作が：

  • 複数のサービス
  • 複数のデータストア

にまたがるようになった。その結果：

  • どこか 1 箇所が失敗したときのロールバックが難しい
  • 分散トランザクション（XA, 2PC）は重く、クラウド・マイクロサービスと相性が悪い

Saga はこれに対して：

「各サービスは自分の DB に対してローカルトランザクションを行い、
失敗したら補償トランザクションで取り消す」

という考え方で整合性を保とうとする。

✅ 基本思想・ルール​

● ローカルトランザクション​

  • 各サービスは、自身の DB に対して ACID トランザクションを実行
  • グローバルトランザクションは張らない

● 補償トランザクション​

  • 失敗時に「既に成功したステップ」を取り消すための処理
    • 例：予約を取り消す、在庫引き当てを戻す、支払いを返金する

● オーケストレーション vs コレオグラフィ​

  • オーケストレーション型

    • Saga を制御する「オーケストレーター」が存在し、各ステップを順に呼び出す

  • コレオグラフィ型

    • 各サービスがイベントを購読し、自律的に次のステップを進める

✅ 得意なアプリケーション​

  • EC の注文処理（決済・在庫・配送・ポイントなどの連携）
  • 予約システム（座席・支払い・通知）
  • 複数サービス連携が前提の B2B プロセス

特徴：

  • 強い分散トランザクションを使わずに、一貫性をある程度保てる
  • 失敗パターン（補償シナリオ）を明示的に設計できる

❌ 不向きなケース​

  • 絶対に中途半端な状態を許容できない処理（金融の一部領域など）
  • 処理フローが短く、単一サービス内で完結する場合

また、Saga の設計を誤ると：

  • 補償ロジックが複雑化
  • 障害時のシナリオが読みにくくなる

ため、ドメイン理解と失敗パターンの洗い出しが不可欠である。

✅ 歴史（系譜・親スタイル）​

  • 元々はデータベースのトランザクション管理に関する論文から登場
  • マイクロサービス時代に再注目され、分散トランザクションの現実解として扱われるように
  • EDA / CQRS / Event Sourcing などと組み合わせて使われることも多い

✅ 関連スタイル​

  • Event-driven Architecture：コレオグラフィ型 Saga は EDA 上に構築される
  • REST / gRPC：オーケストレーション型でのステップ呼び出しに使われる
  • CQRS / Event Sourcing：状態遷移の追跡や補償ロジックの実装と相性が良い

✅ 代表的なフレームワーク​

Saga はパターンだが、実装を支援するフレームワークや基盤も存在する。

  • Camunda / Zeebe / JBPM などのワークフローエンジン
    BPMN ベースで長時間実行のビジネスプロセスをオーケストレーションできる。

  • Temporal / Cadence
    コードでワークフローを記述し、リトライ／補償／タイムアウトを管理するプラットフォーム。

  • AWS Step Functions
    分散処理のオーケストレーション基盤として、Saga 的なフローを構築できる。

  • Kafka + カスタム Orchestrator
    Kafka 上のイベントを使いながら、アプリケーションコードで Saga を制御する実装も多い。

✅ このスタイルを支えるデザインパターン​

Saga はそれ自体がアーキテクチャパターンですが、内部では複数のデザインパターンが活躍する。

  • Command
    各ステップの処理（予約・課金・在庫引き当てなど）を操作オブジェクトとして表現する。

  • Memento
    どこまで処理が進んだか、どの状態に戻すべきかを記録・復元する際の考え方として現れる。

  • State
    Saga 全体の状態（進行中／成功／補償中／失敗など）を明示的に表現する。

  • Chain of Responsibility
    ステップを順に辿り、途中で失敗したら補償フローに切り替える構造。

  • Mediator
    オーケストレーション型 Saga では、オーケストレーター自体が各サービス間の調停役となる。

✅ まとめ​

Saga パターンは、

  • マイクロサービス時代の分散トランザクション問題に対する実践的な解決策
  • 「強い一貫性」ではなく「最終的な一貫性」を前提にした設計

として重要な位置づけを持つ。

導入する際は、
「どのステップで失敗しうるか」「どう補償するか」 を丁寧に設計することが鍵になる。