← AWSサービスの内部原理 コース
18. コールドスタートの解剖 — 何に時間がかかっているのか
「コールドスタート」は一つの遅延ではなく、ハンドラが動く前の3つの作業(環境作り+初期化)の合計です — 分解して見れば、どの時間をどう削ればよいかが図で追えます。
① コールドスタートの正体 = Init フェーズの3作業
リクエスト到着実行環境がまだない
Init 完了後にはじめて
(1) コードDL + microVM起動隔離環境の立ち上げ
(2) ランタイム起動言語ランタイムのブートストラップ
(3) 初期化コード実行ハンドラの外側の静的初期化
3つ合わせて上限10秒ハンドラ実行(Invoke)ここからが本来の処理
- Init は課金対象で、そのぶん呼び出し全体の所要時間に上乗せされる
- 10秒以内に3つの作業が終わらないと、最初の呼び出し時に Init をやり直す
Lambda はハンドラ(Invoke)を動かす前に、必ず Init フェーズで3つの作業を済ませます。この「環境作りと初期化」の時間がコールドスタートで、課金対象として呼び出し全体の所要時間に上乗せされます。
② 正体は OS のプロセス起動と同じ構造
実行ファイルを読込ディスクから
共有ライブラリを動的リンク
グローバル変数・接続を初期化
main() が動き出す
OS のプロセス起動コードDL + microVM起動
ランタイム起動
静的初期化import・設定読込・DB等への接続確立
Init で最も遅延に効くハンドラ実行
- パッケージが大きいほど・import するライブラリが多いほど・接続確立が遅いほど Init は伸びる
普通のプログラムの起動手順と Lambda の Init は一対一で対応します。Lambda はこれをクラウド側で毎回やり直しているだけで、なかでも静的初期化が最も遅延に効きます。
③ ウォームスタート = Init を丸ごとスキップするキャッシュ
1回目の呼び出しコールドスタート(Init あり)
同じ関数に次のリクエスト
環境を凍結(フリーズ)して保持初期化済みメモリ・開いたままのDB接続・/tmp の中身
解凍して再利用Init を丸ごとスキップ = 速い
- ハンドラの外で宣言したオブジェクトは初期化済みのまま残る
- /tmp(512MB〜10GB)の内容も凍結中は保持される
- 公式ではコールドスタートは全呼び出しの1%未満、遅延は100ms未満〜1秒超まで幅がある
- 開発・テスト環境で目立つのは、呼び出し頻度が低く環境が温まりにくいから
ハンドラが返っても環境はすぐ捨てられず、凍結して保持されます。次のリクエストで解凍・再利用するので、ダウンロードもランタイム起動も初期化もやり直し不要 — キャッシュの原理そのものです。
④ 対策1: 初期化コードを軽くして Init を直接縮める
使わないライブラリを import しない
SDK 全体ではなく必要なクライアントだけ読む
めったに使わない重い初期化は遅延ロードlazy load
Init の時間を直接短縮
最も遅延に効くのは (3) の初期化コードなので、そこを軽くすれば Init の時間を直接削れます。
⑤ 対策2: プロビジョンド同時実行 — 先に Init を済ませて温めておく
リクエストが来る前
リクエスト到着
初期化済みの実行環境を常に確保常に温まった状態
事前 Init なので10秒制限が外れ、最大15分まで使えるウォームスタートと同じ速さで応答
指定した数の実行環境を呼び出しの前にあらかじめ初期化して常に温めておくので、リクエスト時にはウォームスタートと同じ速さで応答できます。
⑥ 対策3: SnapStart — 初期化済み状態のスナップショットを貼り付ける
関数バージョンを発行(publish)
以後の呼び出し
初期化済み環境をスナップショット化Firecracker microVM のメモリ+ディスク状態を暗号化してキャッシュ
スナップショットから復元(Restore フェーズ)ゼロからの初期化なし → サブ秒起動も可能
- 対応ランタイム: Java 11 以降 / Python 3.12 以降 / .NET 8 以降
- スナップショットは複数の環境で使い回される → 一意であるべき値(ユニークID・シークレット・乱数の種)はハンドラ側で作り直す
- 初期化時に張ったネットワーク接続は復元後に生きている保証がない → 必要なら張り直す
OS の古典技法チェックポイント/リストアの応用で、Init はバージョン発行時に一度だけ実行。以後は初期化をやり直すのではなく「初期化が終わった瞬間の状態」を復元して起動します。