# Lambda SnapStart による起動パフォーマンスの向上
Lambda SnapStart は通常、関数コードを変更することなく、わずか 1 秒未満の起動パフォーマンスを提供できます。SnapStart を使用すると、リソースをプロビジョニングしたり、複雑なパフォーマンス最適化を実装したりすることなく、応答性が高くスケーラブルなアプリケーションを簡単にビルドできます。
起動時のレイテンシー (多くの場合、コールドスタート時間と呼ばれます) の最大の原因は、Lambda が関数の初期化に費やす時間で、これには関数のコードのロード、ランタイムの開始、および関数コードの初期化が含まれます。SnapStart を使用すると、Lambda は関数バージョンを発行するときに関数を初期化します。Lambda は、初期化された[実行環境](lambda-runtime-environment.md)のメモリとディスク状態の [Firecracker microVM](https://aws.amazon.com/blogs/opensource/firecracker-open-source-secure-fast-microvm-serverless/) スナップショットを作成し、そのスナップショットを暗号化し、インテリジェントにキャッシュして、取得レイテンシーを最適化します。
回復性を確保するために、Lambda は各スナップショットのコピーを複数保持します。Lambda は、最新のランタイムとセキュリティ更新を使用して、スナップショットとそのコピーにパッチを自動的に適用します。関数バージョンを初めて呼び出し、呼び出しがスケールアップすると、Lambda はそれらをゼロから初期化するのではなく、キャッシュされたスナップショットから新しい実行環境を再開するので、起動時のレイテンシーが短縮されます。
**重要**
アプリケーションが状態の一意性に依存する場合は、関数コードを評価して、スナップショット操作に対する耐性があることを確認する必要があります。詳細については、「[Lambda SnapStart での一意性の取り扱い](snapstart-uniqueness.md)」を参照してください。
**Topics**
+ [SnapStart を使用するタイミング](#snapstart-use-cases)
+ [サポートされている機能と制限事項](#snapstart-runtimes)
+ [サポート対象のリージョン](#snapstart-supported-regions)
+ [互換性に関する考慮事項](#snapstart-compatibility)
+ [SnapStart の料金](#snapstart-pricing)
+ [Lambda SnapStart のアクティブ化と管理](snapstart-activate.md)
+ [Lambda SnapStart での一意性の取り扱い](snapstart-uniqueness.md)
+ [Lambda 関数スナップショットの前後のコード実装](snapstart-runtime-hooks.md)
+ [Lambda SnapStart のモニタリング](snapstart-monitoring.md)
+ [Lambda SnapStart のセキュリティモデル](snapstart-security.md)
+ [Lambda SnapStart パフォーマンスの最大化](snapstart-best-practices.md)
+ [Lambda 関数の SnapStart エラーのトラブルシューティング](snapstart-troubleshooting.md)
## SnapStart を使用するタイミング
Lambda SnapStart は、モジュールの依存関係やフレームワークのロードなど、1 回限りの初期化コードによって生じるレイテンシーの変動に対処するように設計されています。これらのオペレーションの最初の呼び出し時は、完了に数秒かかることがあります。最適なシナリオでは、SnapStart を使用すると、このレイテンシーが数秒から 1 秒未満に短縮されます。SnapStart は、大規模な関数呼び出しで使用すると最も効果的です。頻繁に呼び出されない関数では、パフォーマンスが同じように向上されない場合があります。
SnapStart は、次の主要な 2 種類のアプリケーションで特に役立ちます。
+ **レイテンシーの影響を受けやすい API とユーザーフロー:** 重要な API エンドポイントまたはユーザー向けフローの一部である関数では、SnapStart によってレイテンシーが短縮され、応答時間が向上します。
+ **レイテンシーの影響を受けやすいデータ処理ワークフロー:** Lambda 関数を使用する時間制限付きデータ処理ワークフローでは、外れ値関数の初期化レイテンシーを短縮することで、スループットの向上が可能になります。
[プロビジョニングされた同時実行](provisioned-concurrency.md)は、関数を、初期化され、2 桁ミリ秒台で応答できる状態に維持します。アプリケーションに SnapStart で適切に対処できない厳格なコールドスタートレイテンシー要件がある場合は、プロビジョニングされた同時実行を使用します。
## サポートされている機能と制限事項
SnapStart は、次の [Lambda マネージドランタイム](lambda-runtimes.md)で使用できます。
+ Java 11 以降
+ Python 3.12 以降
+ .NET 8 以降。[Lambda Annotations framework for .NET](csharp-handler.md#csharp-handler-annotations) を使用している場合は、[Amazon.Lambda.Annotations](https://www.nuget.org/packages/Amazon.Lambda.Annotations) バージョン 1.6.0 以降にアップグレードして、SnapStart との互換性を確保してください。
他のマネージドランタイム (`nodejs24.x` や `ruby3.4` など)、[OS 専用ランタイム](runtimes-provided.md)、および[コンテナイメージ](images-create.md)はサポートされていません。
SnapStart は、[プロビジョニングされた同時実行](provisioned-concurrency.md)、[Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/accessing-fs.html)、または 512 MB を超えるエフェメラルストレージをサポートしません。
**注記**
SnapStart を使用できるのは、[発行済みの関数バージョン](configuration-versions.md#configuration-versions-config)と、バージョンをポイントする[エイリアス](configuration-aliases.md)のみです。関数の未発行バージョン (\$1LATEST) で SnapStart を使用することはできません。
## サポート対象のリージョン
Lambda SnapStart は、アジアパシフィック (ニュージーランド) とアジアパシフィック (台湾) を除くすべての[商用リージョン](https://docs.aws.amazon.com/general/latest/gr/glos-chap.html#region)で利用できます。
## 互換性に関する考慮事項
SnapStart では、Lambda が複数の実行環境の初期状態として単一のスナップショットを使用します。関数が[初期化フェーズ](lambda-runtime-environment.md#runtimes-lifecycle-ib)で以下のいずれかを使用する場合は、SnapStart を使用する前にいくつかの変更を行う必要がある場合があります。
**一意性**
スナップショットに包含される一意のコンテンツを初期化コードが生成する場合、そのコンテンツは、複数の実行環境で再利用されるときに一意にならない可能性があります。SnapStart の使用時に一意性を維持するには、初期化後に一意のコンテンツを生成する必要があります。これには、一意の ID、一意のシークレット、および疑似ランダム性を生成するために使用されるエントロピーが含まれます。一意性を回復する方法については、「[Lambda SnapStart での一意性の取り扱い](snapstart-uniqueness.md)」を参照してください。
**ネットワーク接続**
Lambda がスナップショットから関数を再開するときは、関数が初期化フェーズ中に確立する接続の状態が保証されません。ネットワーク接続の状態を検証し、必要に応じて再確立してください。ほとんどの場合、AWS SDK が確立するネットワーク接続は、自動的に再開されます。その他の接続については、[ベストプラクティス](snapstart-best-practices.md)を確認してください。
**一時的なデータ**
関数には、初期化フェーズ中に一時的な認証情報やキャッシュされたタイムスタンプなどのエフェメラルデータをダウンロード、または初期化するものがあります。SnapStart を使用しない場合でも、エフェメラルデータは関数ハンドラーで更新してから使用してください。
## SnapStart の料金
**注記**
Java マネージドランタイムの場合、SnapStart に追加コストはかかりません。料金は、関数に対するリクエストの数、コードの実行に要する時間、および関数用に設定されたメモリの量に基づいて請求されます。
SnapStart の使用コストには以下が含まれます。
+ **キャッシュ:** SnapStart を有効にしてパブリッシュする関数バージョンごとに、スナップショットのキャッシュと保守のコストがかかります。料金は、関数に割り当てる[メモリ](configuration-memory.md)の量によって異なります。最低でも 3 時間分の料金が発生します。関数が[アクティブ](snapstart-activate.md#snapstart-active)である限り、引き続き課金されます。[ListVersionsByFunction](https://docs.aws.amazon.com/lambda/latest/api/API_ListVersionsByFunction.html) の API アクションを使用して関数バージョンを識別し、[DeleteFunction](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html) を使用して未使用のバージョンを削除します。未使用の関数バージョンを自動的に削除する場合は、Serverless Land の [Lambda Version Cleanup](https://serverlessland.com/workflows/step-functions-lambda-version-cleanup) パターンを参照してください。
+ **復元:** 関数インスタンスがスナップショットから復元されるたびに、復元料金が発生します。料金は、関数に割り当てるメモリの量によって異なります。
すべての Lambda 関数で、時間料金は関数ハンドラーで実行されるコードに適用されます。SnapStart 関数の時間料金は、ハンドラー外で宣言される初期化コード、ランタイムのロードにかかる時間、および[ランタイムフック](snapstart-runtime-hooks.md)で実行されるすべてのコードにも適用されます。所要時間は、コードの実行が開始されてから、それが戻る、または終了するまでの時間 (1 ミリ秒単位で切り上げ) で算出されます。Lambda は、回復性のためにスナップショットのキャッシュされたコピーを維持し、ランタイムアップグレードやセキュリティパッチなどのソフトウェア更新を自動的に適用します。Lambda がソフトウェア更新を適用するために初期化コードを再実行すると、そのたびに料金が発生します。
SnapStart の使用料金に関しては、「[AWS Lambda 料金](https://aws.amazon.com/lambda/pricing/#SnapStart_Pricing)」を参照してください。