このトピックでは、従来の長時間実行アプリケーションに基づいて開発されたFunction Computeのランタイム拡張機能について説明します。
実行時間の長いアプリケーションとFaaS実行環境
従来の長時間実行される仮想マシン (VM) およびマネージドコンテナサービスでは、インスタンスが起動されてから停止されるまでの課金間隔が使用されることがよくあります。 この間隔内にリクエストが実行されない場合でも、課金されます。 Function Computeの課金粒度はミリ秒の精度です。 リクエストが処理された場合にのみ課金されます。 リクエストが処理されない場合、インスタンスは凍結されます。 これにより、イベントによって発生するアイドルコストが基本的になくなります。 フリーズメカニズムは、従来のアーキテクチャでは長時間実行されるプロセスのパフォーマンスを予測することを困難にし、アプリケーションの移行を妨げます。 たとえば、一般的に使用されているオープンソースの分散Managed Service For OpenTelemetry (以前のTracing Analysis) ライブラリまたはサードパーティのアプリケーションパフォーマンス管理 (APM) ソリューションは、Function Computeの実行環境のためにデータを正しく報告できません。
次の問題点は、従来のアプリケーションのサーバーレスアーキテクチャへのスムーズな移行を妨げています。
非同期背景メトリックのデータが遅延または失われます。 データが要求の実行中に送信されない場合、データは、次の要求が送信されるまで遅延され得るか、またはデータポイントが破棄され得る。
メトリクスデータが同期して送信されると、レイテンシが増加します。 各リクエストが完了した後にFlushに似たメソッドを呼び出すと、リクエストのレイテンシが増加し、バックエンドサーバーで過度のワークロードが生成されます。
関数インスタンスのグレースフルアンパブリッシングをサポートするには、アプリケーションは、インスタンスの停止時に接続を閉じ、プロセスを停止し、実行ステータスを報告する必要があります。 開発者は、function Computeで関数インスタンスがいつ公開されないかを知りません。 さらに、関数インスタンスの未公開イベントに関する通知を送信するためのwebhookは提供されません。
プログラミングモデル拡張
Function Computeは、前述の問題点を解決するためのランタイム拡張機能を提供します。 この機能は、PreFreezeおよびPreStop Webhookを既存のHTTPサーバーモデルに追加することで、HTTPサーバーの既存のプログラミングモデルを拡張します。 拡張開発者はHTTPハンドラーを実装して、関数インスタンスのライフサイクルイベントを監視します。
PreFreeze: Function Computeが現在の関数インスタンスをフリーズする前に、function ComputeはHTTP GETリクエストを /pre-freezeパスに送信します。 拡張開発者は特定のロジックを実装して、関数インスタンスが凍結される前に、メトリックの送信待機などの必要な操作が完了するようにします。 PreFreezeフックの実行時間は、InvokeFunctionが呼び出される時間に含まれません。
PreStop: Function Computeが現在の関数インスタンスを停止する前に、function ComputeはHTTP GETリクエストを /pre-stopパスに送信します。 拡張開発者は、関数インスタンスが公開されなくなる前に、データベース接続の終了、データのレポート、実行ステータスの更新などの必要な操作が完了するようにロジックを実装します。
課金の概要
PreFreezeまたはPreStop呼び出しの課金方法は、InvokeFunction呼び出しの課金方法と同じです。 HTTPフックを拡張するために送信されたリクエストの数に対しては課金されません。 拡張機能は、複数の同時リクエストが単一のインスタンスで実行されるシナリオにも適用できます。 このようにして、同じインスタンスで複数の呼び出し要求が同時に実行され、すべての要求が実行されると、インスタンスが凍結される前にPreFreezeフックが呼び出されます。 次の図に示す例では、関数インスタンスの仕様が1 GBであり、PreFreezeが開始されてからリクエスト2が実行されるまでの期間が1秒です。 インスタンスの実行時間は、次の式に基づいて計算されます。t6 - t1。 消費されるリソースは、次の式に基づいて計算されます。1s × 1 GB = 1 CU。