ある企業が AWS 上でサーバーレスアプリケーションを構築しており、Lambda 関数が複数のダウンストリームサービス（外部 API、データベース、メッセージキュー）と連携します。ある Lambda 関数が外部 API の呼び出しに失敗した場合、他の Lambda 関数の呼び出しやデータベースへの書き込みが部分的に成功してしまい、データの整合性が失われる問題が発生しています。分散トランザクションの整合性を確保するには、どのアーキテクチャが最も適切ですか？
- A. Lambda 関数のタイムアウトを延ばして外部 API の応答を長時間待機し、失敗した場合は Lambda を手動で再実行する
- B. Amazon SQS の FIFO キューを使って全操作をシリアル化し、一つの操作が完了してから次の操作を実行する
- C. AWS Step Functions を使ってワークフローを定義し、各ステップの成功/失敗を State Machine で管理する。外部 API 呼び出しの失敗時はステートマシンが自動的にリトライロジックを実行し、最終的な失敗時には補償トランザクション（ロールバック用の Step）を実行してデータベースへの書き込みを取り消す（Saga パターン）
- D. すべての Lambda 関数を単一の大きな Lambda 関数に統合し、コード内でトランザクション管理を実装する
解答と解説を見る
正解: C
Step Functions の Saga パターンは分散システムでの整合性確保のベストプラクティスです。各ステップが Step Function のステートとして定義され、失敗時に自動リトライを実行します。すべてのリトライが失敗した場合、補償トランザクション（既に成功したステップを取り消す逆操作）を実行してシステムを一貫した状態に戻します。 A: タイムアウトの延長は根本的な解決にならず、長時間の待機はコスト増加とリソースの無駄遣いです。手動再実行は自動化されておらず、部分的な成功の問題も解決しません。 D: 単一の大きな Lambda 関数への統合はサーバーレスの分散設計原則に反し、テスタビリティとスケーラビリティが低下します。 B: SQS FIFO のシリアル化は順序付きメッセージ配信を保証しますが、複数のダウンストリームサービス間のトランザクション整合性（成功/失敗の補償）には対応していません。
📚 関連サービスの解説: AWS Step Functions