概要
AWSは、Lambda関数のコールドスタートを高速化する「SnapStart」機能をコンテナイメージでパッケージされた関数にも拡張したと発表した。これまでSnapStartはZipアーカイブ形式でパッケージされたPython、.NET、Javaの関数でのみ利用可能で、開発者はデプロイパッケージのサイズと起動性能のどちらかを選ばざるを得ない構造になっていた。今回の対応により、コンテナイメージを使いながらSnapStartの恩恵を受けられるようになり、起動時間を数秒から1秒未満へと短縮できる。
これまでの制約と背景
Lambdaのデプロイパッケージには、Zipアーカイブ（解凍後最大250MB）とコンテナイメージ（最大10GB）という2つの選択肢がある。依存関係が大きいアプリケーション、特にデータ処理用にpandasやnumpyといったライブラリを組み込むPythonの関数は、250MBの制限にすぐ達してしまう。Redditのスレッドではある開発者が、この制限に直面しコメントの削除などでファイル容量を切り詰めて対応していたと報告されており、現場での実際の悩みとなっていたことがうかがえる。制限を回避するためにコンテナイメージへ移行すると、今度はSnapStartが使えなくなり起動時間が増加するというトレードオフが生じ、開発者はアーキテクチャの再設計を迫られる場合もあった。
技術的な詳細と対応範囲
SnapStartは、デプロイ時に初期化済みのスナップショットを作成しておき、呼び出し時にはそのスナップショットを再開することで初期化オーバーヘッドを削減する仕組みである。コンテナイメージへの対応拡大により、Java 11以降、Python 3.12以降、.NET 8以降をベースイメージとして使う場合は追加設定なしで機能が利用できる。一方、Node.jsやRuby、カスタムイメージなどそれ以外の環境では、Dockerfile内にcom.amazonaws.lambda.feature.snapstart="Allow"ラベルを追加するか、SnapStartランタイムフックを自前で実装する必要がある。なお、コンテナイメージを使う場合のランタイムパッチ適用は引き続き利用者側の責任であり、この点はSnapStart対応後も変わらない。対応リージョンはニュージーランドと台北を除く全商用AWSリージョンとなっている。
影響と今後の展望
今回の変更により、依存関係の大きいPythonプロジェクトなどでコンテナイメージを選んだ際に生じていた起動性能面のペナルティが実質的に解消され、パッケージ形式の選択だけを理由にアーキテクチャを再設計する必要性は薄れる。エコシステム側の対応も早く、Serverless Framework は1週間以内にバージョン4.42.0でサポートを実装し、512MB以上のストレージ設定とSnapStartの併用を事前に検知して拒否する機能も同時に追加した。大容量の依存関係を抱えるサーバーレスアプリケーションにとって、パッケージ形式に縛られずに性能を最適化できる選択肢が広がったことになる。