SAP新しいソリューションのための設計
ある EC 企業は、注文確定処理を AWS 上で再設計しています。フロントエンドは API Gateway + Lambda で注文を受け付け、在庫引当・決済・出荷指示の 3 つのダウンストリーム処理を順番に呼び出します。要件は、ネットワーク再送やクライアントのリトライによって同一注文が二重に決済されないこと（厳密に一度だけ処理）、各ステップの失敗時に自動リトライと補償処理（決済済みなら返金）を行えること、処理状態を可視化して運用チームが追跡できることです。ピークは秒間数千注文で、急増にも耐える必要があります。これらを満たす最適な構成はどれですか。
A注文を SQS FIFO キュー（メッセージグループ ID = 注文 ID、コンテンツベース重複排除有効）で受け、AWS Step Functions の標準ワークフローで在庫・決済・出荷を順次実行。各ステップに Catch を設定し失敗時は補償用の返金タスクを呼ぶ
✓ 正解
SQS FIFO のコンテンツベース重複排除が二重投入を排除し厳密一度を担保。Step Functions 標準ワークフローが各ステップを状態として可視化し、Catch による返金補償（サーガ）を宣言的に実装できる。FIFO のグループ ID 分散で高スループットにも対応し全要件を満たす。
B注文を SQS 標準キューで受け、Lambda が在庫・決済・出荷を順に同期呼び出し。Lambda 内で DynamoDB に注文 ID をキーに条件付き書き込みして重複を排除し、失敗時は例外で標準キューの再駆動に任せる
SQS 標準キューは少なくとも一度の配信で重複が前提のため、条件付き書き込みだけでは在庫・決済処理の途中重複を完全には防げない。補償処理や状態可視化を Lambda 内に自前実装する必要があり、運用追跡性も弱く要件を満たさない。
C注文を Amazon Kinesis Data Streams に送信し、注文 ID でパーティション。コンシューマー Lambda が在庫・決済・出荷を実行し、失敗時はストリームの再読み取りでリトライ。状態は CloudWatch Logs で追跡する
Kinesis Data Streams はメッセージの重複排除を保証せず再送・リトライ時に二重決済の恐れがある。ストリーム再読み取りによるリトライは補償（返金）処理の表現に向かず、CloudWatch Logs では各ステップの状態追跡が困難で可視化要件に不足する。
DAPI Gateway から直接 Step Functions の Express ワークフローを起動し、在庫・決済・出荷を実行。冪等性は決済サービス側の重複検知に委ね、失敗時はワークフローの自動リトライで再実行する
Express ワークフローは最大 5 分・高スループット用途でリトライ履歴も保持されず、補償を伴う長時間トランザクションに不向き。冪等性を決済サービス任せにすると再送時に二重決済が起き、厳密一度の要件を構成として担保できない。
解説
厳密一度の処理・補償処理・状態可視化・高スループットという複数要件を同時に満たすには、SQS FIFO と Step Functions 標準ワークフローの組み合わせが最適です。
SQS FIFO はコンテンツベース重複排除（5 分間の重複排除ウィンドウ）により、ネットワーク再送やクライアントリトライによる同一注文の二重投入を排除します。メッセージグループ ID に注文 ID を使うことで順序とスループットを両立できます。
Step Functions 標準ワークフローは各ステップを状態として可視化でき、Catch による補償（決済済みなら返金）を含むサーガパターンを宣言的に実装できます。長時間実行と確実なリトライにも標準ワークフローが適します。
選択肢Bの SQS 標準キューは少なくとも一度の配信で重複が前提となり、条件付き書き込みだけでは決済の二重実行を完全には防げず補償と可視化も自前実装が必要です。
選択肢Cの Kinesis は重複排除を保証せず、再読み取りによるリトライは補償処理に向かず状態追跡も弱いです。
選択肢Dの Express ワークフローは最大 5 分・補償より高スループット向けで、冪等性を外部サービス任せにすると二重決済リスクが残ります。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →