Function Computeは、従量課金インスタンスとリザーブドインスタンスの2種類のインスタンスをサポートしています。 従量課金インスタンスは、Function Computeによって自動的に割り当てられ、リリースされます。 インスタンスがリクエストを処理するのにかかる時間に基づいて課金されます。 従量課金インスタンスを使用すると、リソースの管理と割り当ての手間を省くことができます。 ただし、コールドスタートの使用を避けることはできません。 これにより、関数の呼び出し待ち時間の問題が発生し、アプリケーションのパフォーマンスに悪影響を及ぼします。

この図に示すように、冷間始動プロセス全体は複数のステップを含む。 コードのダウンロード、コンテナーの起動、ランタイムの初期化、ユーザーコードの初期化には時間がかかります。 コールドスタートでインスタンスが起動されると、要求された関数を呼び出す準備が整います。 コールドスタートレイテンシの最適化は共通の責任であり、開発者とプラットフォームの両方の努力が必要です。 Function Computeは、プラットフォーム側でのコールドスタートの待ち時間を減らすために、多くの最適化を行っています。 ユーザー側の開発者には、次の最適化を行うことをお勧めします。

  1. コードパッケージのサイズを縮小する: 無関係な依存関係を削除します。 これにより、コードパッケージのダウンロードと抽出にかかる時間を短縮できます。 たとえば、npm pruneコマンドを実行してNode.js関数の無関係な依存関係を削除したり、autoflakeコマンドとautoremoveコマンドを実行してPython関数の無関係な依存関係を削除したりします。 一部のサードパーティライブラリには、テストケースのソースコード、無関係なバイナリファイル、またはその他のデータが含まれている場合があります。 これらのファイルを削除することで、コードパッケージのダウンロードと抽出を高速化できます。
  2. 適切なプログラミング言語を選択する: ほとんどの場合、Javaは他のプログラミング言語よりもコールドスタートでランタイムを起動するのにより多くの時間を必要とします。 低レスポンスレイテンシが必要ですが、ホットスタートを使用するとレイテンシをほとんど短縮できないシナリオでは、Pythonなどの軽量プログラミング言語を選択できます。 これは、平均待ち時間と比較して、ロングテール待ち時間を大幅に低減することができる。
  3. より多くのメモリリソースを割り当てる: コールドスタートを高速化するために、より多くのメモリリソースを割り当てることができます。
  4. コールドスタートの時間を減らす:
    • 関数トリガーを使用して、指定された時間に受信するリクエストに対してコンピューティングリソースを準備します。
    • 初期化子を使用して、ユーザーコード初期化のロジックを定義します。 これにより、Function Computeは、インスタンスの起動時に事前定義されたロジックに従ってユーザーコードを初期化できます。 Initializersは、システムのアップグレードまたは機能の更新に適しており、コールドスタートプロセスをユーザーに透過的にします。

リザーブドインスタンスを使用した関数呼び出しの最適化

ほとんどの場合、ユーザー側でコールドスタートを使用することは避けられません。 たとえば、深層学習推論のために数ギガバイトのモデルファイルをロードする必要がある場合があります。 また、初期化プロセスに時間がかかるクライアントからレガシーソフトウェアと対話するために関数を呼び出す必要がある場合もあります。 これらのシナリオで関数呼び出しの待ち時間を短縮するには、リザーブドインスタンスを使用するか、リザーブドインスタンスと従量課金インスタンスの両方を同時に使用します。 リザーブドインスタンスはユーザーによって割り当てられ、リリースされ、インスタンスの稼働時間に基づいて課金されます。 リザーブドインスタンスが相殺できるよりも多くのリソースがワークロードに必要な場合、システムは従量課金インスタンスを追加します。 これにより、パフォーマンスとリソース使用率のバランスを取ることができます。 リザーブドインスタンスはすぐに使用できるコンピューティングリソースであり、従量課金インスタンスと一緒に使用できます。 リザーブドインスタンスがすべてのリクエストを処理できない場合、Function Computeは従量課金インスタンスを追加として自動的に追加します。 このようにして、従量課金インスタンスのみを使用することで、コールドスタートの待ち時間を短縮できます。

デフォルトでは、両方のタイプのインスタンスが関数呼び出しに使用される場合、リザーブドインスタンスは従量課金インスタンスよりも優先されます。 たとえば、関数呼び出しに1秒あたりに必要なオーバーヘッドは、10容量単位 (10インスタンス) に相当します。 Function Computeは、まずリザーブドインスタンスを使用してリソースコストを相殺します。 より多くのインスタンスが必要な場合、Function Computeは自動的に従量課金インスタンスを追加します。 インスタンスの最大負荷は、インスタンスの同時リクエストスロットリング設定に対応します。 Function Computeは、各インスタンスで処理されているリクエストの数を追跡します。 インスタンスで同時に処理されているリクエストの数が指定された上限に達すると、システムは後続のリクエストを別のインスタンスに送信します。 すべてのインスタンスが上限に達すると、Function Computeは従量課金インスタンスの追加を開始します。 リザーブドインスタンスはユーザーによって管理されます。 それらはアイドル状態であっても継続的に充電されます。 従量課金インスタンスはFunction Computeによって管理され、アイドル状態になるとリリースされます。 従量課金インスタンスは、インスタンスがリクエストを処理するのにかかる時間に基づいて課金されます。 料金の詳細については、「課金」をご参照ください。 Function Computeでは、作成できる従量課金インスタンスの最大数を指定することで、コンピューティングリソースにかかるコストを抑えることができます。

要約

Function Computeには、コールドスタートの待ち時間を短縮し、アプリケーションの安定性と全体的なパフォーマンスを向上させるためのさまざまなアプローチとインジケーターが用意されています。