アーキテクチャパターン

Sagaパターンさがぱたーん

Saga分散トランザクション補償トランザクションマイクロサービス結果整合性

Sagaパターンについて教えて

簡単に言うとこんな感じ！

複数のサービスをまたぐ処理が途中で失敗したとき、「やり直し手順（補償トランザクション）」を順番に実行してなかったことにする仕組みだよ！

Sagaパターンとは

Sagaパターンとは、マイクロサービス環境で複数のサービスにまたがるビジネストランザクションを、一連のローカルトランザクションと補償トランザクションで実現するパターンです。

従来のモノリシックなシステムでは、DBのACIDトランザクションで「全部成功か全部失敗」を保証できました。しかしマイクロサービスでは各サービスが独自のDBを持つため、複数サービスをまたぐ「2フェーズコミット」は現実的でありません。Sagaはこれを「各ステップを個別に実行し、失敗したら打ち消す（補償トランザクション）」という方法で解決します。

2つの実装方式

コレオグラフィー（Choreography）方式

各サービスがイベントを発行・購読し合い、中央のコントローラーなしに全体の流れを進める方式です。

注文サービス → OrderPlaced イベント → 在庫サービス
在庫サービス → InventoryReserved イベント → 決済サービス
決済サービス → PaymentFailed イベント → 在庫サービス（補償）

メリット: 疎結合、シンプルな場合は実装が楽 デメリット: ステップが増えると全体の流れが把握しにくい

オーケストレーター（Orchestrator）方式

中央のSagaオーケストレーターが各サービスへ命令し、全体の流れを管理する方式です。

Sagaオーケストレーター
  → 在庫確保(注文サービス)
  → 決済処理(決済サービス) ← 失敗
  → 在庫解放(注文サービス) ← 補償

メリット: 全体の流れが一か所で把握でき、デバッグが容易 デメリット: オーケストレーターがボトルネックになりうる

補償トランザクションの例

ステップ	処理	失敗時の補償処理
1	注文を作成	注文をキャンセル
2	在庫を確保	在庫を解放
3	決済を実行	返金処理
4	配送を依頼	配送をキャンセル

歴史と背景

Sagaという名称は1987年にHector Garcia-MolinaとKenneth Salemが発表した論文「Sagas」に由来します。もともとは長時間トランザクション（Long-Lived Transaction）問題への解法として提案されました。2010年代のマイクロサービスブームとともに再発見され、Chris Richardsonの書籍「Microservices Patterns」（2018年）によって広く認知されるようになりました。AWS Step Functionsなどマネージドなワークフローサービスがオーケストレーター方式の実装を容易にしています。