Q21 — AWS SAA-C03 第3章

第 21/65 問 | ← 第3章

Q151. ある企業が、注文をデータベースに書き込み、支払い処理のためのサービスを呼び出すECサイトのチェックアウトワークフローを運用しています。ユーザーはチェックアウト中にタイムアウトを頻繁に経験しており、再送信した際に、同一の取引に対して複数の重複する注文（ユニークな注文IDを持つ）が作成されています。ソリューションアーキテクトは、このワークフローをどのようにリファクタリングすれば、重複注文の作成を防ぐことができますか？

• A. Webアプリケーションを設定して、注文メッセージをAmazon Kinesis Data Firehoseに送信します。支払いサービスをKinesis Data Firehoseからメッセージを取得・処理するように設定します。
• B. AWS CloudTrailにルールを作成し、ログ記録されたアプリケーションパスのリクエストに基づいてAWS Lambda関数を起動します。Lambda関数でデータベースをクエリし、支払いサービスを呼び出し、注文情報を渡します。
• C. 注文をデータベースに保存します。注文番号を含むメッセージをAmazon Simple Notification Service (Amazon SNS)に送信します。支払いサービスをAmazon SNSからメッセージをポーリング・取得・処理するように設定します。
• D. 注文をデータベースに保存します。注文番号を含むメッセージをAmazon Simple Queue Service (Amazon SQS) FIFOキューに送信します。支払いサービスをメッセージを取得・処理し、キューからメッセージを削除するように設定します。 ✓

正解: D. 注文をデータベースに保存します。注文番号を含むメッセージをAmazon Simple Queue Service (Amazon SQS) FIFOキューに送信します。支払いサービスをメッセージを取得・処理し、キューからメッセージを削除するように設定します。

解説

重複注文の問題は、ユーザーによる再送信（リトライ）時に、同じ注文が複数回処理されてしまう「冪等性（idempotency）」の欠如によって引き起こされます。これを解決するには、注文の受付と支払い処理を分離し、かつ処理の順序性・重複防止を保証する仕組みが必要です。Amazon SQS FIFOキューは、メッセージの厳密な順序保証と、重複メッセージの自動除外（Message Deduplication IDによる）を提供し、冪等な処理を実現するのに最適です。オプションDでは、まず注文をデータベースに保存（一意な注文IDを生成済み）した後、その注文番号をFIFOキューに送信し、支払いサービスがキューから1回だけ取得・処理・削除することで、重複処理を確実に防止できます。一方、AはKinesis Data Firehoseは主にストリーミングデータのロードに使用され、メッセージの重複防止や厳密な順序保証は提供せず、BはCloudTrailはAPI呼び出しの監査ログ用であり、アプリケーションレベルのイベント駆動処理には不適、CはSNSはパブリッシュ/サブスクライブ型でメッセージの配信保証や重複防止機能を持たず、ポーリングも非効率です。したがって、正解はDです。