← AWSサービスの内部原理 コース
17. 実行環境のライフサイクル — Init/Invoke/Shutdownと凍結・解凍
Lambdaの実行環境はInit→Invoke→Shutdownという決まった一生をたどり、呼び出しの合間の「凍結・解凍」がウォームスタートの速さとクセの両方を生み出します。
① 実行環境の一生 — 3フェーズ+凍結の全体像
Init(初期化)実行環境をゼロから準備
起動完了
Invoke(実行)ハンドラ関数を実行
正常終了(すぐには壊さない)
凍結(freeze)環境ごと一時停止して待機
次の呼び出しで解凍(thaw)
Invoke(実行)…繰り返し続きから即再開
役目を終えると
Shutdown(終了)環境の後片付け
- 呼び出しのたびにゼロから環境を作るわけではなく、freeze/thawで使い回す
- OSで学んだ「プロセスの起動・実行・停止」のミニチュアがクラウド上に再現されている
Lambdaの実行環境はOSのプロセスと同じく「起動・実行・停止」のライフサイクルをたどり、呼び出しの合間は環境ごと一時停止される。この一時停止が性能とクセの両方を生む中心の仕組み。
② Initフェーズ — 3つの仕事と10秒制限
1. Extension起動登録された拡張機能すべて
2. ランタイム起動Node.js / Python の処理系
3. static initializationハンドラ外の初期化コード(DB接続・SDKクライアント)
3つ合わせて10秒以内に終わらないと…
初期化を打ち切り最初の呼び出し時にInitをやり直し
やり直し時の制限設定した関数タイムアウトが上限になる
- プロビジョンド同時実行・SnapStartでは10秒制限が外れ、初期化コードは最大15分まで走れる
Initでは拡張機能→ランタイム→ハンドラ外の初期化コードの順に3つの仕事をこなす。DB接続やSDKクライアント作成はこの3番目で行う。
③ Invokeフェーズ — 1環境=同時1リクエスト
ハンドラ実行上限 = 関数タイムアウト
ランタイム+全拡張機能の合計時間で判定同時に3リクエスト来たら…
環境Aリクエスト1
環境Bリクエスト2
環境Cリクエスト3
- OSにおける「1プロセスの実行」に近いモデル(詳細は同時実行のレッスンで)
上限として効くのは関数に設定したタイムアウト値で、ランタイム+全拡張機能の合計時間が超えると呼び出しは打ち切り。1環境が同時に処理できるのは1リクエストだけなので、同時リクエストの数だけ環境が並ぶ。
④ freeze / thaw — ウォームスタートが速い理由
凍結(freeze)メモリ・ディスクの状態を丸ごと保持
次の呼び出しで解凍(thaw)
ウォームスタートDB接続・変数・/tmpをそのまま再利用 → 速い
コールドスタート環境が無く、Initからやり直す場合
- /tmp(512MB〜10GBで設定可能)の中身も凍結中は保持され、呼び出しをまたぐ一時キャッシュに使える
freezeはOSのプロセスサスペンドと同じで、メモリとディスクの状態を丸ごと保ったまま止まる。だからハンドラ外の変数やDB接続は次の呼び出しでも生き残り、張り直さずに再利用できる。
⑤ 失敗すると環境リセット — 状態に寄りかからない
Invoke失敗エラー / タイムアウト
実行環境をリセット(Shutdownと同じ挙動)
ランタイム停止
各拡張機能に停止を通知
次の呼び出しは
Initからやり直し凍結していた状態は消える
- グローバル変数に呼び出し固有の状態を溜め込む設計は危険
エラーやタイムアウトでInvokeに失敗すると、環境はShutdownイベントと同じ振る舞いでリセットされ、次はInitからやり直し。環境が「生き残る前提」にも「消える前提」にも寄りかかりすぎてはいけない。
⑥ Shutdownフェーズ — 猶予時間とSIGKILL
LambdaShutdownイベントを送信
応答を待つ猶予は構成しだい
拡張機能なし0ミリ秒
内部拡張機能あり500ミリ秒
外部拡張機能あり2,000ミリ秒
制限時間内に応答しないと
SIGKILLで強制終了OSのプロセス停止と同じ仕組み
ShutdownではLambdaが各拡張機能にShutdownイベントを送り、構成に応じた猶予時間だけ応答を待つ。間に合わなければOSと同じくSIGKILLで強制終了され、プロセスとシグナルというOSの基礎がそのままLambdaの一生を形づくる。