Q98 — AWS DVA-C02 第3章
第 98/100 問 | ← 第3章
開発者は、AWS Lambda 関数を非同期で呼び出すアプリケーションを持っています。開発者は、Lambda 関数の呼び出しが失敗した原因となるメッセージを保存し、アプリケーションが後で再試行できるようにしたいと考えています。 開発者は、この目的を最小限の運用コストで実現するには、どうすればよいでしょうか?
- A. Amazon CloudWatch Logs のロググループを設定し、メッセージをフィルタリングして Amazon S3 バケットに保存します。Lambda 内でメッセージをインポートし、Lambda 関数を再実行します。
- B. Amazon EventBridge (Amazon CloudWatch Events) を設定し、メッセージを Amazon Simple Notification Service (Amazon SNS) に送信して Lambda 関数を再起動します。
- C. 破棄されたメッセージ用のデッドレターキュー (DLQ) を実装します。デッドレターキューを Lambda 関数のイベントソースとして設定します。 ✓
- D. Amazon EventBridge (Amazon CloudWatch Events) イベントを Amazon Simple Queue Service (Amazon SQS) キューに送信します。Lambda 関数を SQS キューからメッセージを取得するように設定し、Lambda 関数を再実行します。
正解: C. 破棄されたメッセージ用のデッドレターキュー (DLQ) を実装します。デッドレターキューを Lambda 関数のイベントソースとして設定します。
解説
この状況において、デッドレターキュー (DLQ) の実装は効果的な手法です。DLQ は、Lambda 関数の呼び出しが失敗したメッセージを保存でき、複雑な設定や追加のインポート操作を必要としません。選択肢 A は、ロググループの設定、メッセージのフィルタリング、S3 バケットへの保存といった手順が必要であり、運用コストが高く、操作も複雑です。選択肢 B は、EventBridge を介して SNS にメッセージを送信し、そこから Lambda 関数を再起動するものですが、DLQ ほど直接的かつ簡便ではありません。選択肢 D は、イベントを SQS キューに送信し、Lambda 関数がキューからメッセージを取得するように設定するものですが、これも処理フローを複雑化させます。以上より、選択肢 C は、失敗したメッセージを保存して後続の再試行を可能にするという要件を、最小限の運用コストで実現するための最適な選択です。