Lambda SnapStart による起動パフォーマンスの向上
Lambda SnapStart for Java は、レイテンシーの影響を受けやすいアプリケーションの起動パフォーマンスを追加のコストなしで最大 10 倍向上させることができ、通常は関数コードの料金もかかりません。起動時のレイテンシー (多くの場合、コールドスタート時間と呼ばれます) の最大の原因は、Lambda が関数の初期化に費やす時間で、これには関数のコードのロード、ランタイムの開始、および関数コードの初期化が含まれます。
SnapStart を使用すると、Lambda は関数バージョンを発行するときに関数を初期化します。Lambda は、初期化された実行環境のメモリとディスク状態の Firecracker MicroVM
重要
アプリケーションが状態の一意性に依存する場合は、関数コードを評価して、スナップショット操作に対する耐性があることを確認する必要があります。詳細については、「Lambda SnapStart での一意性の取り扱い」を参照してください。
トピック
サポートされている機能と制限事項
SnapStart は、Java 11 以降の Java マネージドランタイムをサポートします。他のマネージドランタイム (nodejs20.x や python3.12 など)、OS 専用ランタイム、およびコンテナイメージはサポートされていません。
SnapStart は、プロビジョニングされた同時実行、Amazon Elastic File System (Amazon EFS)、または 512 MB を超えるエフェメラルストレージをサポートしません。
SnapStart を使用する際、Lambda コンソール、AWS Command Line Interface (AWS CLI)、Lambda API、AWS SDK for Java、AWS CloudFormation、AWS Serverless Application Model (AWS SAM)、および AWS Cloud Development Kit (AWS CDK) を使用できます。詳細については、「Lambda SnapStart のアクティブ化と管理」を参照してください。
注記
SnapStart を使用できるのは、発行済みの関数バージョンと、バージョンをポイントするエイリアスのみです。関数の未発行バージョン ($LATEST) で SnapStart を使用することはできません。
サポートされるリージョン
SnapStart は、以下の AWS リージョンで利用できます。
米国東部 (バージニア北部)
米国東部 (オハイオ)
米国西部 (北カリフォルニア)
米国西部 (オレゴン)
アフリカ (ケープタウン)
アジアパシフィック (香港)
アジアパシフィック (ムンバイ)
アジアパシフィック (ハイデラバード)
アジアパシフィック (東京)
アジアパシフィック (ソウル)
アジアパシフィック (大阪)
アジアパシフィック (シンガポール)
アジアパシフィック (シドニー)
アジアパシフィック (ジャカルタ)
アジアパシフィック (メルボルン)
カナダ (中部)
欧州 (ストックホルム)
欧州 (フランクフルト)
欧州 (チューリッヒ)
欧州 (アイルランド)
欧州 (ロンドン)
欧州 (パリ)
欧州 (ミラノ)
欧州 (スペイン)
中東 (アラブ首長国連邦)
中東 (バーレーン)
南米 (サンパウロ)
互換性に関する考慮事項
SnapStart では、Lambda が複数の実行環境の初期状態として単一のスナップショットを使用します。関数が初期化フェーズで以下のいずれかを使用する場合は、SnapStart を使用する前にいくつかの変更を行う必要がある場合があります。
- 一意性
-
スナップショットに包含される一意のコンテンツを初期化コードが生成する場合、そのコンテンツは、複数の実行環境で再利用されるときに一意にならない可能性があります。SnapStart の使用時に一意性を維持するには、初期化後に一意のコンテンツを生成する必要があります。これには、一意の ID、一意のシークレット、および疑似ランダム性を生成するために使用されるエントロピーが含まれます。一意性を回復する方法については、「Lambda SnapStart での一意性の取り扱い」を参照してください。
- ネットワーク接続
-
Lambda がスナップショットから関数を再開するときは、関数が初期化フェーズ中に確立する接続の状態が保証されません。ネットワーク接続の状態を検証し、必要に応じて再確立してください。ほとんどの場合、AWS SDK が確立するネットワーク接続は、自動的に再開されます。その他の接続については、ベストプラクティスを確認してください。
- 一時的なデータ
-
関数には、初期化フェーズ中に一時的な認証情報やキャッシュされたタイムスタンプなどのエフェメラルデータをダウンロード、または初期化するものがあります。SnapStart を使用しない場合でも、エフェメラルデータは関数ハンドラーで更新してから使用してください。
SnapStart の料金
SnapStart の使用に追加のコストは発生しません。料金は、関数に対するリクエストの数、コードの実行に要する時間、および関数用に設定されたメモリの量に基づいて請求されます。所要時間は、コードの実行が開始されてから、それが戻る、または終了するまでの時間 (1 ミリ秒単位で切り上げ) で算出されます。
所要時間の料金は、関数ハンドラーで実行されるコード、ハンドラー外で宣言される初期化コード、ランタイム (JVM) のロードにかかる時間、およびランタイムフックで実行されるすべてのコードに適用されます。Lambda が期間を計算する方法の詳細については、「Lambda SnapStart のモニタリング」を参照してください。
SnapStart で設定された関数の場合、Lambda は実行環境を定期的にリサイクルし、初期化コードを再実行します。耐障害性のため、Lambda はスナップショットを複数のリージョンに作成します。Lambda が別のリージョンで初期化コードを再実行すると、そのたびに料金が発生します。Lambda が料金を計算する方法の詳細については、「AWS Lambda 料金設定
Lambda SnapStart とプロビジョニングされた同時実行の比較
Lambda SnapStart とプロビジョニングされた同時実行は、どちらも関数がスケールアップするときのコールドスタート時間と異常なレイテンシーを削減することができます。SnapStartは、起動パフォーマンスを最大 10 倍向上させるために役立ち、追加のコストはかかりません。プロビジョニングされた同時実行は、関数を、初期化され、2 桁ミリ秒台で応答できる状態に維持します。プロビジョニングされた同時実行を設定すると、AWS アカウントに料金が請求されます。プロビジョニングされた同時実行は、アプリケーションに厳格なコールドスタートレイテンシー要件がある場合に使用してください。SnapStart とプロビジョニングされた同時実行の両方を同じ関数バージョンで使用することはできません。
注記
SnapStart は、大規模な関数呼び出しで使用すると最も効果的です。頻繁に呼び出されない関数では、パフォーマンスが同じように向上されない場合があります。
追加リソース
この章の他のトピックを読むだけでなく、「AWS Lambda SnapStart を使用した起動の高速化
