一貫性を担保するための分散トランザクションの必要性が整理されているか？¶
Type: DeepDive
Category: データ
Audience: 設計リーダー / SRE / インフラ設計者 / レビュー担当者
背景・概要¶
複数のサービスやデータストアにまたがる処理で、途中失敗するとデータの不整合が発生する場合、分散トランザクションが必要になることがある
これは複雑でコストが高いため、本当に必要か？代替策はないか？ を慎重に判断する必要がある
例¶
- 請求書登録と関連ファイル保存を別サービスで行っており、どちらかが失敗すると業務上の破綻が生じる → Sagaパターンを採用して補償トランザクションを実装する
- 顧客マスタと別サービスの連携時に、Google Cloud Pub/Sub・Amazon SNS/SQS・Azure Service Busの確実な受信処理（2段階登録）を導入して整合性を担保する
よくある失敗例¶
- DB登録後に外部サービスへ通知したが、失敗してデータ整合性が取れない
- メッセージ送信前にDB登録してしまい、送信失敗でロールバックできず、片方だけが残る
- 並列で実行した2つのサービスで、片方だけに成功フラグが残る
FAQ¶
Q. 分散トランザクションの代表的な方式は？
A.
- 2フェーズコミット（2PC）：整合性は強いが重い
- Sagaパターン：一連の処理を小さなトランザクションに分けて補償処理で調整
- Outboxパターン：DBの更新とイベント発行を1トランザクション内で行う
Q. すべてのサービス間で一貫性を担保するべき？
A. 必ずしも必要ではない。多少のズレが許されるケース（結果整合）では、よりシンプルな手段の方が有効。BOでは結果整合が多い印象