ある企業の AWS 環境で、開発チームが Lambda 関数を頻繁にデプロイしています。最近、デプロイ後に特定のリージョンでコールドスタートが急増し、エンドユーザーへのレイテンシーが悪化するという問題が発生しています。調査の結果、コールドスタートは最初のリクエストで最大 3 秒かかることが判明しました。アプリケーションは Java で実装されており、メモリサイズは 512MB です。最小限のコスト増加でコールドスタートを最も効果的に削減するには、どの方法が適切ですか？
- A. Lambda のプロビジョニングドコンカレンシーを設定し、常に一定数の実行環境を事前にウォームアップしておく。Application Auto Scaling でピーク時間帯に合わせてプロビジョニングドコンカレンシーをスケジュールし、オフピーク時はゼロに設定してコストを節約する
- B. CloudWatch Events（EventBridge）でウォーマー関数を 5 分ごとに実行し、Lambda 関数を定期的に呼び出してウォームな状態を維持する
- C. Lambda のランタイムを Java から Node.js または Python に変更し、コールドスタート時間を短縮する
- D. Lambda のメモリサイズを 3,008MB に増やし、CPU 性能を向上させてコールドスタート時間を短縮する
解答と解説を見る
正解: A
プロビジョニングドコンカレンシーは指定した数の Lambda 実行環境を常に初期化済み状態に保ち、コールドスタートをほぼゼロにします。Application Auto Scaling でスケジュールを設定することで、ピーク時間帯のみプロビジョニングドコンカレンシーを確保し、オフピーク時はゼロにすることでコストを最小化できます。 D: メモリ増加は CPU リソースが増えコールドスタートが若干改善される場合がありますが、Java のコールドスタートの主な原因はJVMの起動とクラスローディングであり、メモリ増加だけでは根本的な解決にはなりません。また 3,008MB への増加はコストが約 6 倍になります。 C: Java から Python/Node.js への変更は確かにコールドスタートを短縮できますが、アプリケーション全体の書き直しが必要で、「最小限のコスト増加」の前に大きな開発コストが生じます。 B: 定期的な呼び出しによるウォームアップは一般的な手法ですが、Lambda はアイドル後に実行環境が廃棄されるため、5 分より短い間隔でもコールドスタートが発生する可能性があります。プロビジョニングドコンカレンシーほど確実ではありません。
📚 関連サービスの解説: AWS Lambda