マイクロサービスアーキテクチャでは、1つの業務トランザクションが複数のサービスにまたがることが一般的です。本記事では、この分散トランザクションをどう整合性を保って処理するかを解説します。

SAA レベル：基礎概念

なぜ分散トランザクションが難しいのか

モノリシックなアプリケーションでは、データベースのACIDトランザクションで整合性を保てる
マイクロサービスでは、各サービスが独自のデータストアを持つため、複数サービスにまたがる単一のトランザクション（2相コミット等）は現実的でないケースが多い

SAA 試験のポイント

マイクロサービス間の連携には、SQS/SNS/EventBridgeのような非同期メッセージングを使い、各サービスが自身のデータストアの整合性のみを担保する「結果整合性 (Eventual Consistency)」の考え方を受け入れる設計が基本になります。

Sagaパターンとは

複数のサービスにまたがる一連の処理を、各サービスのローカルトランザクションの連鎖として実行し、途中で失敗した場合は「補償トランザクション（Compensating Transaction）」で以前の処理を打ち消すパターンです。

SAP レベル：高度な設計シナリオ

ChoreographyとOrchestrationの比較

SAP 試験のポイント

Sagaパターンの実装方式には2種類あります。**Choreography（コレオグラフィ）**は中央の管理者を置かず、各サービスがイベントを発行し合って連鎖的に処理を進める方式です。**Orchestration（オーケストレーション）**は、中央の調整役（オーケストレーター）が各サービスの呼び出し順序とエラーハンドリングを一元的に制御します。

観点	Choreography	Orchestration
実装方式	各サービスがイベントを発行・購読（EventBridge等）	中央のオーケストレーターが制御（Step Functions等）
サービス間の結合度	低い（各サービスは他を意識しない）	やや高い（オーケストレーターが全体を把握）
全体フローの可視性	低い（処理が分散し追跡しづらい）	高い（一箇所でフロー全体を確認できる）
複雑なフローへの対応	ステップが増えると管理が困難になりがち	複雑な分岐・並列処理でも見通しが良い

設計上の落とし穴

「疎結合が正義だから、常にChoreographyを選ぶべき」という単純化はSAP試験では誤りになりがちです。ステップ数が多く、条件分岐やリトライロジックが複雑な業務フローでは、Choreographyはイベントの追跡が困難になり、デバッグ・障害対応のコストが増大します。SAPでは、フローの複雑さに応じてOrchestration（Step Functions）を選ぶ方が適切なケースが多いことが問われます。

Step Functionsによるオーケストレーション実装

Step FunctionsのSagaパターン実装では、各ステップに対応する補償ステップをステートマシン内に定義し、Catchフィールドでエラー発生時に補償ワークフローへ分岐させる
ステートマシンの実行履歴がそのままトランザクション全体の可観測性（何が成功し、どこで失敗し、どう補償されたか）を提供する

べき等性の確保

SAP 試験のポイント

分散システムでは、ネットワーク障害等によりメッセージが重複配信される可能性があります。補償トランザクションを含む全てのステップは、**同じ操作が複数回実行されても結果が変わらない「べき等性 (Idempotency)」**を持つように設計する必要があります。例えば「在庫を1つ減らす」ではなく「注文IDに紐づく在庫引当が存在しなければ1つ減らす」という設計にすることで、重複実行時の不整合を防げます。

まとめ

SAA: マイクロサービス間では結果整合性を前提とした非同期連携が基本であること、Sagaパターンの基本概念を理解する。
SAP: ChoreographyとOrchestrationのトレードオフ、複雑なフローにおけるStep Functionsの優位性、べき等性を確保した補償トランザクション設計ができる。

ここまでで 2-2 疎結合・イベント駆動アーキテクチャ の全4記事が完了しました。次は 2-3 データストレージ・データベース設計 に進みます。