Sagaパターン（分散トランザクションの代替）

なぜマイクロサービスは2PCを嫌うのか

2相コミット（2PC）は、複数DBを原子的にそろえる素直な解ですが、prepare で YES を返した参加者がコーディネータの決定を待つ間ロックを保持したまま固まるブロッキング問題を抱えます。単一データセンター内の少数DBならまだ許容できても、マイクロサービスでは事情が悪化します。

• 参加者が別チームが運用する別サービスであり、コーディネータへの信頼や可用性要件が揃わない。
• 処理が注文確定→在庫引当→配送手配のように数秒〜数日かかることがあり、その間ロックを握り続けるのは現実的でない。
• サービスごとにスケール・デプロイが独立しており、1つの障害が他全部をブロックする設計は可用性目標と相容れない。

Saga パターンはこの前提を覆します。「全部を1つの原子的トランザクションにする」のを諦め、代わりに各サービスのローカルトランザクションの連鎖として処理を組み、途中で失敗したらそれまでに成功した分を逆順に打ち消すという設計です。

ローカルトランザクションの連鎖と補償

Saga は T1, T2, ..., Tn という一連のローカルトランザクションで構成されます。各 Ti は単一サービス内で完結し、コミットした瞬間にその結果は他から可視になります（2PC の in-doubt 状態は存在しません）。

ある Tk が失敗したら、それより前に成功していた Tk-1, ..., T1 を、補償トランザクション Ck-1, ..., C1 で逆順に実行して打ち消します。

正常系: T1 -> T2 -> T3 -> T4 (すべて成功、Saga完了)

異常系: T1 -> T2 -> T3 -> T4(失敗)
補償:                C3 -> C2 -> C1  (逆順に打ち消す)

補償トランザクションは「元に戻す」というより「業務的に打ち消す」処理です。たとえば在庫引当の補償は行を物理削除するのではなく、在庫を+1戻す という別の正のトランザクションとして実行されます。

補償トランザクションには実務上、べき等性（リトライで二重に走っても結果が変わらない）、可換性の制御（実行時点で後続の別トランザクションが同じデータを触っている可能性への配慮）、リトライ可能性（補償自体の失敗に備え成功するまで諦めず再試行する forward recovery）が求められます。

コレオグラフィ型: 自律分散でつなぐ

コレオグラフィ（choreography）型は中央の管理者を置きません。各サービスがイベントを発行し、他サービスがそれを購読して自分の番のローカルトランザクションを実行、また次のイベントを発行する、というリレー形式です。

注文サービス --(注文作成イベント)--> 在庫サービス
在庫サービス --(引当完了イベント)--> 配送サービス
配送サービス --(手配失敗イベント)--> 在庫サービス（補償: 引当解除）
在庫サービス --(補償完了イベント)--> 注文サービス（補償: 注文キャンセル）

各サービスは「自分の前後に何がいるか」だけ知っていればよく、サービス間の結合度が低いのが利点です。一方で欠点もはっきりしています。

オーケストレーション型: 中央集権でつなぐ

オーケストレーション（orchestration）型は、Saga 専用のオーケストレータ（司令塔サービスやワークフローエンジン）が手順を一元管理します。オーケストレータが各サービスへコマンドを送り、応答を見て次のステップか補償かを判断します。

Orchestrator -> 在庫サービス: 引当コマンド
Orchestrator <- 在庫サービス: 成功
Orchestrator -> 配送サービス: 手配コマンド
Orchestrator <- 配送サービス: 失敗
Orchestrator -> 在庫サービス: 補償コマンド（引当解除）
Orchestrator -> 注文サービス: 補償コマンド（注文キャンセル）

手順・補償の対応関係が1か所（オーケストレータの状態機械）にまとまるため、フローの可視性とテスト容易性が高まります。代償はオーケストレータ自体が新たな結合点になることと、そのサービスの可用性・実装負荷が増すことです。

結果整合性の受容とISOLATIONの喪失

Saga で最も見落とされがちなのが、ACID の I（分離性）を実質的に失う点です。Sagaが受け入れるのは一貫性モデルの階層でいう最も弱い部類の結果整合性であり、途中経過を隠す強い保証は最初から放棄されています。T1 がコミットした瞬間から補償 C1 が完了するまでの間、他のトランザクションはまだ確定していないSagaの中間状態を読み取れてしまいます。これは典型的な分離性違反であり、Sagaは原子性を結果整合性で置き換える代わりに、この中間可視性という代償を払います。

この中間可視性を抑える代表的な対策が、意味論的ロック（「Saga処理中」フラグで競合更新を業務ロジックでブロック）、可換な更新への設計（加減算のように順序に依存しない更新にし途中状態が見えても数値が破綻しないようにする）、べき等なイベント配送（少なくとも1回配送やメッセージ重複を前提に各ステップと補償を実装する）です。

2PCとの対比で押さえる選択基準

2PCは「原子性を犠牲にしない代わりにブロッキングと可用性を犠牲にする」設計であり、Sagaは「ブロッキングを避ける代わりに原子性と分離性をアプリケーションの責務に押し戻す」設計です。マイクロサービスで2PCが避けられがちなのは、サービスの独立デプロイ・スケール性という前提そのものが、参加者を長時間ブロックする方式と根本的に相性が悪いからです。

Saga は決して「2PCの簡易版」ではなく、保証するものの種類を意図的に変える設計判断です。ステップ数が少なく単純ならコレオグラフィ、業務フローが複雑で可視性やテスト容易性を重視するならオーケストレーション。どちらを選んでも、補償トランザクションのべき等性設計と中間状態の可視性対策は避けて通れません。