ある企業が、外部決済APIを呼び出すLambda関数をSQSイベントソースマッピングで起動している。決済APIの仕様として「同一の注文IDで同じリクエストが複数回送られても、決済処理は1度しか実行されない」ことが保証されている。しかし、Lambda関数自体のコードで「SQSから同一メッセージが複数回配信された場合でも、決済処理のトリガーは1度だけ」というべき等性を確保したい。追加インフラを最小化してべき等性を実現するアプローチとして最も適切なものはどれか。
- A. Lambdaのreserved concurrencyを1に設定して、同時に1つの関数インスタンスしか動かないようにする
- B. SQSのvisibility timeoutをLambdaのタイムアウトよりも長く設定し、重複配信が起こらないようにする
- C. Lambda関数内でSQSメッセージのMessageIdをDynamoDBに記録し、既に処理済みの場合はスキップする
- D. SQSのFIFOキューに切り替え、メッセージグループIDとメッセージ重複排除IDを設定する
解答と解説を見る
正解: D
SQS FIFOキューのメッセージ重複排除ID（MessageDeduplicationId）を使うと、5分のデデュプリケーションウィンドウ内に同じIDのメッセージが複数回送られた場合、SQS側で重複を除去してLambdaへの配信を1回に限定できる。これはキューレベルの仕組みであり、Lambda関数のコードを変更せずに実現できる。選択肢AのReserved Concurrency=1は並列実行を制限するが、順次実行の重複には対処できない（同一メッセージが時間をおいて再配信された場合に重複処理が起きる）。選択肢CのDynamoDB記録によるスキップは確実なべき等性を実現できるが「追加インフラを最小化」という要件に反し、DynamoDBのプロビジョニングとコード変更が必要になる。選択肢BのVisibility Timeoutの調整は処理中の重複配信を防ぐことに役立つが、処理完了後のメッセージ再配信（例: 削除前にタイムアウトした場合）への根本的な対策にはならない。
📚 関連サービスの解説: Amazon SQS