DVAトラブルシューティングと最適化
ECサイトのバックエンドで動作するLambda関数`ProcessOrderFunction`には、コスト制御のために予約済み同時実行数（Reserved Concurrency）が50に設定されています。セール期間中はトラフィックが急増し、同時実行数が50を超えたリクエストには`TooManyRequestsException`（HTTP 429）が返されてリクエストが失われています。リクエストを失わずにすべて処理できるアーキテクチャに変更したいと考えています。最も適切な変更はどれですか？
A予約済み同時実行数の上限を50から500に引き上げ、セール期間中の急増トラフィックに対応してスロットリングを回避する
予約済み同時実行数の増加はコスト制御の目的を損ない、他のLambda関数が使用できる同時実行プールを圧迫する。さらに大きなトラフィック急増に対しても根本的な解決にはならない。
BProcessOrderFunctionの前にAmazon SQSキューを配置してリクエストをバッファリングし、LambdaをSQSのイベントソースとして設定する
✓ 正解
SQSキューはリクエストをバッファリングし、LambdaはReserved Concurrency（50）の範囲内でキューのメッセージを消費する。急増時もリクエストがキューに蓄積されデータロストが防止され、Reserved Concurrencyの上限を維持しながらスケーラビリティを確保できる。
Cプロビジョニングされた同時実行数（Provisioned Concurrency）を50に設定してコールドスタートを排除し、処理速度を向上させる
Provisioned Concurrencyはウォーム状態のLambda実行環境を事前確保してコールドスタートを排除する機能であり、Reserved Concurrencyの上限は変わらない。スロットリングによるリクエストロストの問題は解消しない。
DAPI Gatewayのスロットリング設定でバースト制限を調整し、Lambdaへの過剰なリクエストを抑制して429エラーを回避する
API Gatewayのスロットリングは超過リクエストに対してHTTP 429を即座に返却するものであり、リクエストをキューに保持して後続処理する機能は持たない。リクエストロストの問題を解消しない。
解説
Amazon SQSキューをLambdaの前段に配置することで、急増したリクエストをキューでバッファリングし、LambdaはReserved Concurrency 50の範囲内でキューからメッセージを順次消費できます。SQSはLambdaのイベントソースマッピングとして機能し、同時実行数の制限内でスケーリングされます。リクエストはキューに保持されるため、429エラーによるデータロストが発生しません。
選択肢Aの予約済み同時実行数増加は他のLambdaリソースを圧迫し、コスト制御の目的に反する。さらなる急増には根本的な解決にならない。
選択肢CのProvisioned Concurrencyはコールドスタートを排除するが、Reserved Concurrencyの上限は変わらず、リクエストロストの問題は解消しない。
選択肢DのAPI Gatewayスロットリングは超過リクエストを即座に429で拒否するものであり、リクエストを保持して後処理する機能はない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDVAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →