すべてのプロダクト
Search
ドキュメントセンター

Function Compute:コールドスタートの待ち時間を短縮するためのベストプラクティス

最終更新日:Sep 09, 2024

このトピックでは、function Computeでプロビジョニングされたインスタンスを使用して、オンデマンドインスタンスのコールドスタートと関数パフォーマンスを最適化する方法について説明します。

コールドスタートとは何ですか?

Function Computeは、オンデマンドインスタンスとプロビジョニングインスタンスの2種類のインスタンスをサポートしています。 オンデマンドインスタンスは、Function Computeによって自動的に割り当てられ、リリースされます。 インスタンスがリクエストを処理するために使用した実際の時間に基づいて課金されます。 オンデマンドインスタンスを使用すると、リソースの管理と割り当ての手間を省くことができます。 ただし、オンデマンドモードではコールドスタートが発生し、呼び出し待ち時間が長くなり、関数のパフォーマンスに悪影響を及ぼします。

コールドスタートとは、コードのダウンロード、コンテナーの開始、ランタイムの初期化、コードの初期化など、実行環境とコードを準備するプロセスを指します。 コールドスタートが完了すると、関数インスタンスは後続のリクエストを処理する準備が整います。

image

オンデマンドインスタンスの最適化されたコールドスタート

コールドスタートは、システム側とユーザー側で最適化できます。 システム側では、Function Computeがコールドスタートの最適化に関して多くの改善を行っています。 ユーザー側では、次の方法を使用してコールドスタートを最適化することを推奨します。

  • 軽量コードパッケージの使用

    軽量コードパッケージを使用し、不要な依存関係を削除します。 たとえば、Node.jsランタイムでnpm pruneを実行したり、Pythonランタイムでautoflakeを実行したりできます。 さらに、テストソースコードや無効なバイナリファイル、データファイルなどの冗長ファイルをサードパーティのライブラリから削除して、コードのダウンロードと解凍の時間を短縮できます。

  • 軽量プログラミング言語を使用する

    Javaなどの一部の言語は、他の言語よりもコールドスタートが長くなります。 コールドスタートに敏感なアプリケーションの場合、Pythonなどの軽量プログラミング言語を使用すると、ウォームスタートのレイテンシに大きな違いがなければ、ロングテールのレイテンシを大幅に削減できます。

  • 適切なメモリの設定

    同時実行設定が固定された関数の場合、より大きなメモリが構成されている場合、より多くのCPUリソースが関数の実行に使用できます。

  • コールドスタートの頻度を減らす

    • タイムトリガーを使用してインスタンスをウォームアップします。

    • Initializerフックを使用します。 この場合、Function Computeは初期化子を非同期で呼び出し、コードの初期化に費やされる時間をなくします。 コールドスタートは、function Computeのシステムおよび関数のアップグレード中にユーザーに気付かれません。

ハイブリッドモード

ほとんどの場合、ユーザー側のコールドスタートを排除することは困難です。 たとえば、ディープラーニングの推論シナリオでは、初期化に時間がかかるクライアントを使用して、多数のモデルファイルをロードする必要がある場合、または関数がレガシーシステムと対話する必要がある場合、コールドスタートは避けられません。 これらのシナリオでは、プロビジョニングされたインスタンスを構成したり、機能がレイテンシーに敏感な場合は、プロビジョニングされたインスタンスとオンデマンドインスタンスの両方を使用したりできます。

プロビジョニングされたインスタンスは、ユーザーによって割り当てられ、リリースされます。 インスタンスの実行期間に基づいて課金されます。 プロビジョニングされたインスタンスのリソースがワークロードの要件を満たすのに十分でない場合、システムは自動的にオンデマンドインスタンスを割り当てます。 これにより、パフォーマンスとリソース使用率の最適なバランスを実現できます。 プロビジョニングされたインスタンスでは、ワークロードの変動に基づいて事前にコンピューティングリソースを割り当てることができます。 オンデマンドインスタンスが割り当てられている場合、システムはプロビジョニングされたインスタンスを使用してリクエストを処理します。 これにより、コールドスタートによる待ち時間がなくなります。

プロビジョニング済みインスタンスとオンデマンドインスタンスの両方を設定する場合は、プロビジョニング済みインスタンスが優先的に使用されます。 たとえば、10個のインスタンスがプロビジョニングされているとします。 リクエストを処理するために1秒あたり10を超えるインスタンスが必要な場合、Function Computeはオンデマンドインスタンスを割り当ててリクエストを処理します。 インスタンスが完全にロードされているかどうかは、インスタンスの同時実行設定によって決まります。 システムは、各インスタンスで処理されているリクエストの数を追跡します。 インスタンスの同時リクエスト数が指定された上限に達すると、システムは別のインスタンスを割り当てます。 すべてのインスタンスのリクエスト数が上限に達すると、新しいインスタンスが作成されます。 プロビジョニングされたインスタンスはお客様によって管理されます。 リクエストを処理していない場合でも、プロビジョニングされたインスタンスに対して課金されます。 オンデマンドインスタンスはFunction Computeによって管理されます。 システムは、一定期間アイドル状態のオンデマンドインスタンスを再要求します。 オンデマンドインスタンスがリクエストを処理する実際の期間に基づいてのみ課金されます。 課金ルールの詳細については、「課金の概要」をご参照ください。 オンデマンドインスタンスの使用量の上限を設定して、リソース使用量が予想範囲内に収まるようにすることができます。