DVAAWSのサービスを使用した開発
注文管理システムでは、SQS標準キューに複数種類のメッセージ（`{"eventType": "ORDER_CREATED"}`, `{"eventType": "ORDER_UPDATED"}`, `{"eventType": "ORDER_CANCELLED"}` など）が混在して送信されます。現在、Lambda関数はすべてのメッセージを受け取り、関数内部でeventTypeを確認して `ORDER_CREATED` のみを処理し、他のメッセージは何もせずに正常終了（削除）しています。既存のメッセージ送信側のコードを変更せずに、Lambda呼び出し回数とコストを削減しながら `ORDER_CREATED` メッセージのみを処理する最も効率的な方法はどれですか？
ASQS標準キューを `ORDER_CREATED` 専用キューとその他のキューに分割し、専用キューにのみLambdaイベントソースマッピングを設定する
キュー分割が有効なアーキテクチャですが、メッセージ送信側のコードを変更（送信先キューを変更）する必要があり、「送信側の変更なし」という条件に反します。
BLambda関数のイベントソースマッピングにFilterCriteria（フィルター条件）を設定し、`{"body": {"eventType": ["ORDER_CREATED"]}}` のパターンでメッセージをフィルタリングする
✓ 正解
Lambda Event Source MappingのFilterCriteriaを使用すると、SQS・DynamoDB Streams・Kinesis Streams等のイベントソースに対してフィルター条件を設定でき、条件に一致するメッセージのみLambdaが呼び出されます。SQSの場合、フィルターに一致しないメッセージは自動的にキューから削除され、Lambda呼び出し料金が発生しません。送信側の変更も不要で最小限の変更で実現できます。
CSQSキューの前段にSNSトピックを配置し、SNSサブスクリプションフィルターポリシーで `ORDER_CREATED` のみをキューに送信するよう構成する
SNS+SQSファンアウト構成は有効なアーキテクチャパターンですが、送信側をSQS直接送信からSNS経由に変更する大規模な構成変更が必要です。
DSQSキューのメッセージ属性（Message Attributes）を使用してeventTypeを設定し、受信側Lambdaで属性値を確認して処理する（現在とほぼ同じだが属性読み取りの方が高速）
Lambda呼び出し回数の削減にはならず、コストも変わりません。引き続き全メッセージでLambdaが呼び出されます。
解説
Lambda Event Source MappingのFilterCriteriaを使用すると、SQS・DynamoDB Streams・Kinesis Streams等のイベントソースに対してフィルター条件を設定でき、条件に一致するメッセージのみLambdaが呼び出されます。SQSの場合、フィルターに一致しないメッセージは自動的にキューから削除され、Lambda呼び出し料金が発生しません。送信側の変更も不要で最小限の変更で実現できます。
選択肢Aはキュー分割が有効なアーキテクチャですが、メッセージ送信側のコードを変更（送信先キューを変更）する必要があり、「送信側の変更なし」という条件に反します。
選択肢CのSNS+SQSファンアウト構成は有効なアーキテクチャパターンですが、送信側をSQS直接送信からSNS経由に変更する大規模な構成変更が必要です。
選択肢DのLambda呼び出し回数の削減にはならず、コストも変わりません。引き続き全メッセージでLambdaが呼び出されます。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDVAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →