要求が1秒に0.2件来る場合、立ち上げに当たった要求は0.0%でした。
0.001件まで下げると71.4%です。同じ設定でも、呼ばれる頻度で結論が変わります。
設定ではなく、呼ばれる頻度が割合を決めます。頻度が下がると急に効いてきます。
AWS Lambdaで立ち上げが起きる頻度について、公式は明確に述べています。
一般に、立ち上げからの開始は、本番の作業負荷よりも、開発や試験の関数のほうで起きやすいという記述です。理由として、そうした関数は呼ばれる頻度が低いことを挙げています。
どれだけ違うのかを数えました。要求の来る割合を変えて、待たされた要求の割合を出します。
300秒来なければ片付けられ、次は立ち上げからになる前提を置きました。6時間ぶんを通しています。
6時間ぶん。300秒来なければ片付けられ、次は立ち上げからになる 立ち上げ 0.001件/秒 0.005件/秒 0.02件/秒 0.2件/秒 （待たされた要求の割合） 50ms 71.4% 26.5% 0.7% 0.0% 300ms 71.4% 26.5% 0.7% 0.0% 1500ms 71.4% 26.5% 0.7% 0.0% 5000ms 71.4% 26.5% 0.7% 0.0%
列がすべて同じ値です。立ち上げの長さは、当たる割合には関係しません。
決めているのは要求の頻度だけです。0.2件/秒で0.0%、0.001件/秒で71.4%になります。
公式は立ち上げからの開始は、呼び出しの1%未満で起きるのが普通であるとも述べています。
この計測では0.02件/秒で0.7%でした。1秒に0.02件は、1分に1.2件です。
つまり1分に1回以上呼ばれていれば、1%未満に収まります。そこを下回る関数だけが、別の話になります。
立ち上げの長さは割合を変えない。効くのは頻度だけ。
In general, cold starts are typically more common in development and test functions than production workloads.原文AWS ドキュメント「Understanding the Lambda execution environment lifecycle」 この内容の有効期限2027-02-18
当たる割合は頻度で決まり、当たったときの重さは準備の記述で決まります。別の要因です。
AWS Lambdaの立ち上げの時間について、公式は原因を1つに絞っています。
関数の実行より前の遅れに最も大きく寄与するのは、準備の記述であるという記述です。処理の外に書いた、読み込みや接続の準備を指します。
その長さが、平均の応答にどう出るかを数えました。
平均の応答（立ち上げの分だけを足したもの） 立ち上げ 0.001件/秒 0.005件/秒 0.02件/秒 0.2件/秒 50ms 35.7ms 13.2ms 0.3ms 0.0ms 300ms 214.3ms 79.4ms 2.1ms 0.1ms 1500ms 1071.4ms 397.1ms 10.3ms 0.3ms 5000ms 3571.4ms 1323.5ms 34.3ms 1.2ms
0.001件/秒の列では、50msと5000msで35.7msと3571.4msです。100倍の差になります。
0.2件/秒の列では0.0msと1.2msです。同じ100倍でも、絶対の値が小さいので気になりません。
公式は幅も示しています。立ち上げからの開始の長さは、100ms未満から1秒超まで幅があるという記述です。
この幅のどこにいるかは、自分の準備の記述で決まります。読み込む書庫の大きさと、接続を作る数です。
つまり手を入れる先が2つあります。頻度を上げて当たる割合を下げるか、準備を減らして当たったときを軽くするかです。
配る量を減らす考え方はwebpackの記事で数えていて、入口の数によって落とせる割合が96.2%から59.7%まで変わりました。
The largest contributor of latency before function execution comes from initialization code.原文AWS ドキュメント「Understanding the Lambda execution environment lifecycle」 この内容の有効期限2027-02-18
凍らせて残すため、次の呼び出しで前回の値が見えます。持ち越す前提で書く必要があります。
AWS Lambdaの環境は、呼び出しが終わっても消えません。公式は呼び出しが完了したあと、実行環境は凍らされると述べています。
凍らせて残すのは、次の呼び出しで使い回すためです。前の節の0.0%という値は、この使い回しが効いた結果でした。
1番目と2番目は利点です。接続を作り直さずに済みます。
3番目と4番目は落とし穴になります。前の呼び出しの残りが見えるので、そこに依存した書き方をすると、環境が変わったときに動きが変わります。
残っていることを前提にも、否定にもしないのが安全です。あれば使い、なければ作る形にします。
1回の呼び出しだけで使う値は、処理の中に置きます。外に置くと、次の呼び出しに漏れます。
要求の来る時刻は一定の割合で引いたもので、実際には時間帯の波があります。波がある場合、静かな時間帯の直後だけ立ち上げに当たりやすくなるため、1日の平均では割合が下がっても、特定の時間帯では上がります。片付けられるまでの300秒という値も置いたものです。ここで見せているのは、当たる割合が頻度だけで決まり、当たったときの重さが準備の記述で決まるという、2つの独立した関係です。
After the invocation completes, the execution environment is frozen.原文AWS ドキュメント「Understanding the Lambda execution environment lifecycle」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る