アーキテクチャパターン

Sagaパターンさがぱたーん

マイクロサービス分散トランザクション補償トランザクションイベント駆動結果整合性オーケストレーション

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

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

旅行の予約をイメージして！航空券・ホテル・レンタカーを順番に予約して、途中でホテルが取れなかったら、すでに押さえた航空券をキャンセルする…そのルールを決めておく仕組みがSagaパターンだよ。複数のシステムにまたがる処理を「失敗したら元に戻す手順ごと設計する」って発想なんだ！

Sagaパターンとは

Sagaパターンとは、複数のマイクロサービスにまたがる一連の処理（分散トランザクション）を、ひとつながりの小さなトランザクションの連鎖として設計するアーキテクチャパターンです。各ステップが成功すれば次へ進み、どこかで失敗したときは補償トランザクション（Compensating Transaction）と呼ばれる「取り消し処理」を逆順に実行して、データの整合性を保ちます。

従来のリレーショナルデータベースでは、複数の操作をひとまとめにするACIDトランザクション（原子性・一貫性・分離性・永続性を保証する仕組み）が使われていました。しかし、マイクロサービスアーキテクチャではサービスごとにデータベースが分かれているため、複数サービスをまたぐ「全部成功か全部失敗か」という保証が技術的に難しくなります。Sagaパターンはこの問題を解決するための代表的な設計手法です。

「Saga」という名前は、1987年にHector Garcia-MolinaとKenneth Salemが発表した論文に由来します。長大な叙事詩（サガ）になぞらえ、長い処理をひとつの物語のように連続した章（ステップ）で構成するイメージから命名されました。

Sagaパターンの2つの実装スタイル

Sagaパターンには、処理の制御をどこが担うかによって大きく2種類の実装スタイルがあります。

項目	コレオグラフィ型	オーケストレーション型
制御の場所	各サービスが自律的に動く	中央の司令塔（Orchestrator）が指示
通信方式	イベント（メッセージ）を発行・購読	指示を直接送受信
疎結合度	高い（互いを知らない）	やや低い（Orchestratorに依存）
全体把握のしやすさ	難しい（処理が分散）	しやすい（一箇所で管理）
向いている規模	シンプルなフロー	複雑な業務フロー
障害箇所の特定	難しい	比較的簡単

補償トランザクションの考え方

通常のデータベースの「ロールバック」と異なり、補償トランザクションはすでにコミット（確定）済みの操作を論理的に打ち消す別の操作を実行します。たとえば「在庫を10個減らした」を取り消すには「在庫を10個増やす」という補償処理を実行します。

正常フロー:
  [注文作成] → [在庫確保] → [決済処理] → [配送手配] ✅

失敗時のフロー（決済で失敗した場合）:
  [注文作成] → [在庫確保] → [決済処理❌]
                                    ↓ 補償トランザクション
               [在庫を戻す] ← [注文キャンセル] ✅

結果整合性（Eventual Consistency）とは

Sagaパターンでは、処理の途中では一時的にデータがバラバラな状態になることを許容します。最終的にすべての補償処理が完了したとき、全体として整合が取れた状態になる考え方を結果整合性と呼びます。「今この瞬間は完璧じゃなくていい、最後には合う」という割り切りが設計の前提です。

歴史と背景

1987年 — Garcia-MolinaとSalemが論文「Sagas」を発表。長時間トランザクションの分割手法として提唱
2000年代 — SOA（サービス指向アーキテクチャ）の普及とともに分散トランザクションの課題が顕在化
2010年代前半 — マイクロサービスアーキテクチャの台頭により、サービスごとのDBが一般的になる
2015年頃 — Netflixなどの大規模サービスがマイクロサービスの実運用ノウハウを公開。Sagaパターンへの注目が高まる
2018年 — Chris Richardsonが著書「Microservices Patterns」でSagaパターンを体系的に解説。業界での共通認識が形成される
2020年代 — KubernetesやイベントバスサービスApache Kafkaの普及に伴い、Sagaパターンの実装が容易になり広く採用される

コレオグラフィ型 vs オーケストレーション型の構造

2つのスタイルがどのように処理を進めるか、構造を図解します。

ACIDトランザクションとの比較

比較軸	ACIDトランザクション	Sagaパターン
適用範囲	単一DB内	複数サービス・DB
失敗時の対処	自動ロールバック	補償トランザクションを手動設計
整合性のタイミング	即時（強整合性）	最終的に（結果整合性）
パフォーマンス	ロック競合が起きやすい	高スループットを維持しやすい
実装の複雑さ	DB任せでシンプル	設計コストが高い

参考資料	内容
microservices.io – Saga pattern	Chris Richardsonによるパターン定義サイト
CloudEvents v1.0	イベント駆動連携の標準フォーマット仕様