マイクロサービスのSAGAパターン

SAGA(サガパターン)とは

SAGA（サガ）パターンとは、複数のマイクロサービスにまたがるトランザクション（一連の処理）において、データの一致を保つための設計パターンのことです。

なぜSAGAが必要なのか？

モノリスな開発では、1つのデータベースに対して BEGIN と COMMIT を使えば、失敗時にすべてを簡単にロールバック（元に戻す）できました。しかし、マイクロサービスでは サービスごとにデータベースが分かれている ため、1つのDBトランザクションで全体を管理することができません。

例：ECサイトの注文処理

注文サービス：注文データ作成
在庫サービス：在庫を減らす
決済サービス：カード決済

もし「3. 決済」で失敗したとき、「2. 在庫」や「1. 注文」をどうやって取り消すか？という問題です。

SAGAの仕組み：補償トランザクション

SAGAでは、各ステップを独立したローカルなトランザクションとして実行します。もし途中のステップでエラーが発生した場合、それまでに完了した処理を打ち消すための **「補償トランザクション（Compensating Transaction）」**を順番に実行して、論理的に元の状態に戻します。

2つの実装方式

Spring Cloudなどの環境で実装する場合、主に以下の2つのアプローチがあります。

① オーケストレーション方式 (Orchestration)

中央に「司令塔（オーケストレーター）」を置く方式です。

特徴: 司令塔が「次は在庫サービス、次は決済サービス」と指示を出します。
メリット: 処理の流れが把握しやすい。
デメリット: 司令塔が複雑になりがち。

② コレオグラフィ方式 (Choreography)

中央の司令塔を置かず、各サービスが「イベント」を発行して連携する方式です。

特徴: 在庫サービスが処理を終えたら「在庫確保完了イベント」を投げ、それを検知した決済サービスが動き出します。
メリット: サービス間の結合が非常に緩やか（疎結合）。
デメリット: 全体の流れを把握するのが難しくなる。

Springでの実装イメージ

Spring Boot で SAGA を実装する場合、 メッセージブローカー（RabbitMQ や Apache Kafka） を介したイベント駆動アーキテクチャにするのが一般的です。

状態管理: State Machine を使って各ステップの成功・失敗を管理します。
結果整合性: 「今すぐ完璧に一致させる」のではなく、「最終的に（補償トランザクションを含めて）正しい状態にする」という 結果整合性 の考え方がベースになります。

SAGAの由来

SAGA（サガ）パターンの名前の由来は、北欧やアイスランドの伝承文学である 「サガ（Saga）」 からきています。なぜコンピュータサイエンスの用語に、中世の文学作品の名前がついたのでしょうか？

語源としての「長い物語」

北欧の「サガ」は、一族の歴史や英雄の冒険を、多くの章やエピソードにわたって長く語り継ぐ物語のことです。マイクロサービスにおけるSagaパターンも、 「一つの大きな処理（トランザクション）が、複数のサービスをまたいで長く続く物語（ステップの連続）のようなもの」 であるため、このように名付けられました。

論文での提唱

この用語が現在のIT文脈で初めて登場したのは、 1987年 にプリンストン大学の Hector Garcia-Molina と Kenneth Salem が発表した論文『Sagas』です。

当時の背景: 当時はマイクロサービスではなく、メインフレームなどの巨大なデータベース（LLT: Long Lived Transactions）を想定していました。
論文の主張: 「長時間かかる処理を一つの大きなトランザクションとして抱え込むと、他の処理を止めて（ロックして）しまい効率が悪い。だから、 処理を小さなステップの連続（Saga）に分割し、失敗した時は逆回しの処理（補償）をすればいい 」というアイデアが提唱されました。

なぜ今、注目されているのか

1987年の論文発表から30年以上経ち、 マイクロサービス という考え方が普及したことで、この「古い論文のアイデア」が再注目されました。

DBが物理的に分かれている現代の分散システムにおいて、 「一気にはできないけれど、物語のように順を追って整合性を取っていく」 というSagaの考え方が、技術的な課題を解決するパズルのピースとして完璧にハマったのです。

まとめ

SAGAパターンは、 「分散したDB間で、失敗時に逆戻り処理（補償）を自動で走らせる仕組み」 です。

AWS Cloud Practitioner の試験では、こうした「疎結合なサービス間連携」の重要性が問われます。SQSなどのメッセージングサービスが、このSAGAパターンを実現する基盤としてよく使われます。

SAGAの由来

由来: 北欧の伝承文学「サガ（長い物語）」。
意味: 複数のステップが連なる「長いトランザクション」のこと。
初出: 1987年のデータベース研究論文。

Springでの開発中、もし「一連の処理が長すぎて複雑だな…」と感じたら、それはまさに一族の歴史を紡ぐような「Saga（物語）」を実装している最中かもしれませんね。