DVAAWSのサービスを使用した開発
VPC外で動作するLambda関数がREST APIのバックエンドになっています。トラフィックは平常時は低いものの、特定時刻に一斉アクセスが発生し、その瞬間にコールドスタートによる数百ms〜数秒の遅延が顕著になります。一斉アクセスの時刻は事前に分かっています。コードや実行環境の初期化処理は変更できません。遅延を最小化する最も適切な対策はどれですか。
A関数に予約済みコンカレンシー（Reserved Concurrency）を設定し、同時実行数の上限を引き上げる
予約済みコンカレンシーは関数が使える同時実行数を他関数と分離して確保するものの、実行環境を事前に初期化しないためコールドスタートはそのまま発生します。スロットリング回避には有効ですが遅延対策にはなりません。
Bスケジュールに合わせてProvisioned Concurrencyを有効化し、Application Auto Scalingで一斉アクセス前に必要数を確保する
✓ 正解
Provisioned Concurrencyは初期化済みの実行環境を事前確保しコールドスタートを排除します。アクセス時刻が既知なので、Application Auto Scalingのスケジュールドスケーリングでピーク前に必要数を確保すれば遅延を最小化でき、常時確保よりコストも抑えられます。
C関数のメモリ割り当てを最大の10,240MBに引き上げてCPUを増やす
メモリ増加はCPU比例で初期化処理をやや高速化しますが、新規実行環境の起動と初期化自体は依然発生します。一斉アクセスで多数の環境が同時に立ち上がる状況のコールドスタートは解消されません。
DEventBridgeで5分ごとに関数を呼び出すウォーマーを実装し、常に1インスタンスを温める
定期ウォーマーは1つの実行環境を温める程度で、一斉アクセス時には多数の新規環境が同時に必要になります。温まっていない大半のリクエストがコールドスタートとなり、根本的な対策になりません。
解説
Provisioned Concurrencyは指定した数の実行環境を初期化済みの状態で事前に確保するため、コールドスタートを排除できます。一斉アクセスの時刻が分かっている場合、Application Auto Scalingのスケジュールドスケーリングを使い、アクセス前に必要数のProvisioned Concurrencyを確保しておけば、ピーク時も初期化遅延なしで応答できます。
選択肢Aの予約済みコンカレンシーは同時実行数を確保（上限設定）するだけで、実行環境を事前初期化しないためコールドスタートは解消されない。
選択肢Cのメモリ増加は初期化と実行を多少速くするがコールドスタート自体は残り、多数の同時新規起動には無力。
選択肢Dの定期ウォーマーは1インスタンスしか温まらず、一斉アクセスで多数の新規環境が必要になる場面では大半がコールドスタートになる。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDVAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →