正確には、Azure Functions 従量課金プランで HTTP トリガーを使用する場合に、プログラム実行されるインスタンスのライフタイム。
まず前提として、Azure Functions 従量課金プランでは、プログラムが実行されるインスタンスは常に実行可能な状態になっているわけではない。 プログラムの待機時間が続くと、Azure 側のリソース管理の一環で、それまで呼び出し待機していたインスタンスが落とされてしまう。 この状態で関数が呼ばれた場合、関数を実行する為のインスタンスがない為、インスタンスを新たに起動して、プログラムや必要なモジュールをロードして実行準備が整ってから、実行されることになる（所謂コールドスタート問題）。
コールドスタート状態の挙動について一言で言えば、「HTTP トリガーの呼び出しに時間がかかる (通常の呼び出し＋5～20 秒前後)」となるが、具体的にその裏で何が起こって遅くなっているのか、Application Insights に記録されるログから一部確認できる。
ざっとしたフローは以下
Application Insights で確認した結果は以下。並びは発生時間の降順。但し、Application Insights へのイベント送信がバッチ送信される為か、完全に発生順に並んでいるわけではなさそうなので、その点は注意。
下の赤枠が、インスタンス生成から関数実行までに発生しているイベントを示している。記録されている時間からは分からないが、URI 叩いてから結果が返るまで、大体 16 秒程かかっている。 上の青枠が、一度関数実行してから数分後に再度実行した時に発生したイベント。インスタンスは既に待機状態なので、関数実行のイベントしか記録されていない。この時は、URI 叩いた直後に結果が得られている。
上記の実行後、20 分以上経ってから再度 HTTP トリガーを呼び出した結果が以下。
下の赤枠が、前回関数実行後に 20 分以上未実行状態が続き、インスタンスが終了した際に発生したイベント。 上の青枠は、インスタンス生成から再度処理が行われている様子を現している。
補足
タイマートリガーの場合は予め実行する時間が分かっているからか、スケジュールしている予定時刻の 1 分ほど前にインスタンスの準備が行われるようで、コールドスタート問題で実行時間が遅れるような事は発生しない様子。
参考ドキュメント
