SAA弾力性に優れたアーキテクチャの設計
あるフィンテック企業が Amazon API Gateway と AWS Lambda（Python、メモリ 512MB）を使用した決済 API を運用しています。平日の毎朝9時に業務開始とともに急激なリクエスト増加が発生し、Lambda のコールドスタートにより P99 レイテンシが SLA（500ms 以内）を超過しています。深夜〜早朝はリクエストがほぼゼロです。最もコスト効率よく SLA を達成する方法はどれですか？
ALambda のプロビジョニング済み同時実行数（Provisioned Concurrency）を設定し、EventBridge Scheduler でピーク開始前後に自動的にスケールアップ・ダウンするよう構成する。
✓ 正解
Provisioned Concurrency は Lambda インスタンスを初期化済み状態で保持しコールドスタートを完全に排除します。EventBridge Scheduler で業務時間帯のみスケールアップ・ダウンすることで、SLA 達成とコスト最適化を両立できます。
BLambda 関数を常時起動の EC2 インスタンス（m5.large・1年リザーブドインスタンス）に置き換え、Application Load Balancer でリクエストを分散してコールドスタートを根本的に排除する。
EC2 リザーブドインスタンスへの置き換えは24時間365日の課金が発生します。深夜〜早朝のゼロトラフィック時間帯も含めて固定コストが発生し、Lambda のピーク時間帯課金より大幅にコストが増加します。
CLambda のリザーブドコンカレンシー（Reserved Concurrency）を最大値に設定してスロットリングを防止し、コンカレンシー枯渇によるコールドスタートの影響が出ないようにする。
リザーブドコンカレンシーはアカウントの同時実行数を特定の Lambda 関数に予約する機能であり、インスタンスの事前初期化は行いません。コールドスタートは依然として発生するため P99 レイテンシの SLA 超過は解消されません。
DLambda 関数のメモリを 3GB に増やして CPU パフォーマンスを向上させ、コールドスタートの初期化時間を短縮することで P99 レイテンシを SLA 範囲内に収める。
Lambda のメモリ増量は割り当て CPU が増え初期化時間が若干短縮されますが、コールドスタート自体を排除する機能ではありません。急激なスパイク時の P99 レイテンシ 500ms 以内を確実に保証する手段として不十分です。
解説
Lambda のプロビジョニング済み同時実行数（Provisioned Concurrency）を設定すると、指定した数の Lambda インスタンスが初期化済み状態で待機し、リクエスト受信時のコールドスタートが発生しなくなります。EventBridge Scheduler を使用して業務時間帯（9時〜18時）のみ Provisioned Concurrency をスケールアップし、深夜〜早朝はスケールダウンすることで、必要な時間帯だけコストを発生させるコスト効率の高い構成になります。
選択肢BのEC2インスタンスへの置き換えは24時間課金が発生し、深夜〜早朝のゼロトラフィック時間帯も含めて固定コストがかかるため、ピーク時間帯のみ課金する Lambda + Provisioned Concurrency よりも大幅にコスト効率が悪化します。
選択肢CのリザーブドコンカレンシーはLambdaの最大同時実行数を予約する設定ですが、インスタンスの事前初期化は行わないためコールドスタートを防ぐことはできません。スロットリング防止にはなるものの SLA 問題は解消されません。
選択肢Dのメモリ増加はLambda に割り当てる CPU リソースを増やし初期化時間を若干短縮しますが、コールドスタート自体をなくすことはできず、急激なスパイク時に P99 レイテンシ 500ms 以内を確実に保証する手段として不十分です。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →