コールドスタートとは？

サーバーレスコンピューティングのコンテキストでは、“cold start”とは、長時間呼び出されなかった後に、関数が処理を開始するまでの最初のレイテンシまたは時間を指します。例として、コンピュータがシャットダウン後にオンにされると、完全なパフォーマンスに達するまで時間がかかる場合があります。

コールドスタートは、サーバーレスアーキテクチャを始める人にとって基本です。特に、タイムアウト期間を可能な限り最短で満たす必要があるインタラクションに関して、アプリケーションのパフォーマンスと使い勝手に影響します。

コールドスタートは、次の状況で発生します。

• 最初の呼び出し: 2つのケースがあります。1つ目は、アプリケーションのデプロイ後またはコードの更新後に初めて関数が呼び出された場合です。
• スケーリング ゼロから: 関数が発生せず、しばらく動作していない後に呼び出しを受け取った場合。
• リソースの再割り当て: クラウドプロバイダーが リソースを再割り当てすると または、関数のベースが他のホストに変更されると、コールドファンクションインスタンスが発生する可能性があります。
• タイムアウトまたは有効期限: ファンクションインスタンスが最大実行時間に達するか、アイドル時間を超えると、終了される可能性があります。つまり、再度呼び出された場合は、最初から開始されます。

コールドスタートに関連する主な課題は、追加のレイテンシです。このレイテンシは、次のような形で観察できます。

• 遅延した応答： アプリは通常、迅速な応答を提供しますが、ユーザーはエクスペリエンスに影響を与える遅延に遭遇することがあります。
• スループットの低下: コールドスタートでは、特に使用量の多い期間にアプリケーションの同時リクエスト処理能力を徐々に増やす必要がある場合があります。
• パフォーマンスのばらつき: コールドスタートの時間が経過とともに変化する程度は、アプリケーションの有効性に影響を与える可能性があり、応答時間の合理化と安定性の強化の両方の可能性があります。

Lambda コールドスタートの期間は、次のようなさまざまな要因によって異なります。

• 関数のサイズと依存関係: 関数が大きいほど、関わる依存関係が増え、一般的なコールドスタートにかかる時間が長くなります。
• ランタイム環境: 初期ランタイム環境の選択（例：Node.js、Python、Javaなど）は、初期化とロードプロセスの違いにより、コールドスタート時間などの要因を必然的に決定します。
• クラウドプロバイダーの最適化: 時間の経過とともに、クラウドプロバイダーはコールドスタート時間を可能な限り短縮するための最適化を継続的に提供していますが、固定または予測可能ではありません。

全体として、Lambda のコールドスタートは 0.5 秒から数秒の間で変化する可能性があります。したがって、正確なデータを取得し、コールドスタート時間が機能と環境のニーズをどのように反映しているかを観察して、正確な洞察を得る必要があります。

Lambda のコールドスタートを削減または少なくとも対処するための方法を次に示します。

• 関数の最適化:
  • 未使用のコードと依存関係を削除して、関数のサイズを削減します。
  • 初期化中にロードされるコードの量を減らすには、ツリーシェイキングまたはコード分割メソッドを使用する必要があります。
  • パッケージの配布とパッケージの依存関係解決ワークフローを改善します。

• プロビジョニングされた同時実行:

プロビジョニングされた同時実行を構成して、特定数の関数インスタンスをアクティブに維持し、着信リクエストがそれらのインスタンスのコールドスタートを引き起こさないようにします。

• ウォームアップリクエスト：

場合によっては、実際のユーザーリクエストが到着したときにウォームアップされるように、ダミーリクエストを関数に送信する必要があります。

• 非同期処理：

重要な操作ではない場合は、他の非同期パターンを導入して関数からのユーザーリクエストをリファクタリングし、コールドスタートの影響を最小限に抑える方がよい場合があります。

• キャッシング：

頻繁にアクセスされるデータまたは事前に計算された結果を格納する適切なキャッシュメカニズムを導入して、関数呼び出しの数を減らし、コールドスタートの発生を減らします。