Q83 — AWS SAA-C03 第15章

第 83/100 問 | ← 第15章

Q1183. ある企業が支払い処理アプリケーションを作成したいと考えています。このアプリケーションは、既存の Amazon S3 バケットに支払いレコードが到着したときに実行される必要があります。また、各支払いレコードを「正確に1回だけ」処理する必要があります。企業は AWS Lambda 関数を用いて支払いを処理したいと考えています。これらの要件を満たすソリューションはどれですか？

正解: A. 既存の S3 バケットを設定し、オブジェクト作成イベントを Amazon EventBridge に送信するようにします。EventBridge を設定して、イベントを Amazon Simple Queue Service (Amazon SQS) FIFO キューにルーティングするようにします。Lambda 関数を、SQS キューに新しいイベントが到着したときに実行されるように設定します。

解説

既存の Amazon S3 バケットに支払いレコードが到着した際に、AWS Lambda 関数を用いて「各支払いレコードを正確に1回だけ」処理するという要件を満たすには、選択肢 A が最適です。すなわち、「既存の S3 バケットを設定し、オブジェクト作成イベントを Amazon EventBridge に送信する。EventBridge を設定して、イベントを Amazon SQS FIFO キューにルーティングする。Lambda 関数を、SQS キューに新しいイベントが到着したときに実行されるように設定する」ことです。 各選択肢の検討： 選択肢 A：Amazon SQS FIFO（先入れ先出し）キューは、メッセージが受信順に、かつ「正確に1回だけ」処理されることを保証します。EventBridge を介して S3 のオブジェクト作成イベントを SQS FIFO キューにルーティングすることで、Lambda 関数による各支払いレコードの重複なし・順序保証付きの処理が実現できます。これは支払い処理アプリケーションに必要な信頼性と順序保証を提供します。 選択肢 B：Amazon SNS はパブリッシュ／サブスクライブ型サービスであり、メッセージの順序保証や正確に1回だけの処理を保証しません。Lambda をトリガーすることは可能ですが、重複処理や順不同処理のリスクがあり、支払い処理のような厳密な整合性が求められる用途には不適切です。 選択肢 C：Amazon SQS 標準キューは Lambda のトリガーとして利用可能ですが、順序保証や正確に1回だけの処理は保証されません。結果として支払いレコードの重複処理や順不同処理が発生し、支払い処理アプリケーションとしては許容できません。 選択肢 D：S3 のオブジェクト作成イベントを Lambda 関数に直接送信することでトリガーは可能ですが、正確に1回だけの処理を保証する仕組みはありません。ネットワークエラーなどによる再試行により、同一イベントに対して Lambda が複数回呼び出される可能性があり、支払いの重複実行につながります。また、メッセージの順序保証もありません。 結論：選択肢 A は、各支払いレコードを「正確に1回だけ」かつ「到着順に」処理することを保証し、支払い処理アプリケーションに必要な信頼性を提供するため、要件を最もよく満たすソリューションです。