2.1標準
注文処理のタイムアウト後、ワークフローが再試行される。
同じ注文IDの副作用を二重に発生させない。
最も適切な設計はどれか。
× 不正解
注文IDなどを冪等キーとして扱い、再試行時に既存結果を返す設計にする。
詳細解説
誤りタイムアウトするたびに新しい注文IDを発行する
再試行ごとに別注文が作成され、二重処理になる。
再試行ごとに別注文が作成され、二重処理になる。
正しい注文IDを冪等キーとして保存し、同じIDの処理結果を再利用する
同じ要求を再実行しても副作用を一度に抑え、結果を返せる。
同じ要求を再実行しても副作用を一度に抑え、結果を返せる。
誤り失敗した状態を無条件に最初から実行する
完了済みステップを再実行し、副作用を重ねる可能性がある。
完了済みステップを再実行し、副作用を重ねる可能性がある。
誤りRoute 53のTTLで注文重複を防ぐ
DNS TTLはアプリケーションの冪等性を提供しない。
DNS TTLはアプリケーションの冪等性を提供しない。
実際に確かめる
一時的な検証環境で実行できる例です。
AWS Step Functions retryと冪等性設計の公式説明を確認する。期待される結果
再試行と冪等性を組み合わせて副作用の重複を防げる。理解のポイント
- 冪等キー
- 再試行
- 注文ID
確認時の注意
- 確認環境: AWS公式Step Functions・Well-Architectedドキュメントの確認
- AWS公式SAA-C03 Domain 2と各サービスの公式ドキュメントを確認する。
基礎のおさらい
判断のポイント
障害ドメイン、データの復旧点、処理の重複、切り替え時間を分けて評価する。
設計の確認
正常系だけでなく、キュー滞留・AZ障害・リージョン障害・依存サービス停止時の動作を確認する。
問題IDAWS-SAA-140
確認環境AWS公式Step Functions・Well-Architectedドキュメントの確認
最終技術確認2026-08-20
誤り・権利侵害を報告