In-depth demystification of function computing asynchronous task capabilities

タスクスケジューリング

タスクスケジューリングとは、システムが現在の負荷状況に基づいて、異なるタスクを適切なコンピューティングリソースに配置して実行する一連の操作を指します。完全なスケジューリングシステムは、異なる特性を持つタスク間の分離と最適な効率という 2 つの要件をバランスよく満たす必要があります。Function Compute では、非同期タスクに対して独立キューモデルと自動負荷分散戦略を採用しており、処理性能を低下させることなくマルチテナント分離を実現する機能を提供します。

Serverless Task スケジューリングモデル

ユーザーがタスクを送信すると、システムはそのタスクをメッセージに変換し、非同期配信によって内部キューに投入します。メッセージの処理フローは以下の通りです。

システム全体では、タスクスケジューリング、マルチテナント分離、メッセージバックログ制御の観点から、主にスケジューラによるキューの消費と制御に依存しています。各ユーザーに対してあらかじめアカウントレベルのキューを割り当てており、そのユーザーの全関数への非同期呼び出し（タスク呼び出しを含む）はこのキューを共有します。

このモデル構造により、各ユーザーの非同期実行リクエスト（タスク呼び出しを含む）は他のユーザーの呼び出し状況に影響を受けません。ただし、大規模なアプリケーションシナリオでは、たとえば 1 人のユーザーに関数が多く、各関数の呼び出し量が多い場合、すべての非同期メッセージが 1 つのキューを共有することで呼び出し間の相互影響が生じることを避けられません。一部のロングテール呼び出しがキュー内のリソースを過剰に消費し、他の関数の実行がリソース不足に陥る可能性があります。

こうした状況が重要な関数の実行に影響を与えることを防ぐため、Function Compute ではより粒度の細かいキュー、関数レベルキューを提供しています。関数ごとに個別のキューを設定でき、高優先度関数の消費が同一アカウント内の他の関数の実行に影響を受けないようにできます。キュー間の関係は以下の通りです。

ユーザー A に 2 つの異なるタスク関数があるとします。1 つのタスク A は下流サービスの制約によりメッセージごとに 1 つずつ実行する必要があります。もう 1 つのタスク B は大量の同時実行を伴うタスクで、できるだけ早く完了させたいと考えています。デフォルトモードでは、タスク A とタスク B は同じユーザーキューを共有します。この場合、次のような状況が発生します。タスク A の同時実行数の制限により、Function Compute 側はタスクキュー全体の送信レートを制御します。その結果、タスク B のタスクが遅延し、キューから取り出せなくなります。タスク A の実行が完了した後、タスク B はキューから取り出される機会を得ます。この時点で同時実行数が増加し、タスク B のメッセージが実行用のリソースプールを占有します。タスク A はキューから取り出されにくくなり、長時間実行を開始できません。結果として、A と B の両方が相手のビジネスに深刻な影響を受けます。

キューを調整した後、タスク A とタスク B はそれぞれ排他的にキューを占有します。この場合、タスク A とタスク B の消費速度は互いに影響を受けず、両方とも各自の要件を満たすことができます。

現在、Serverless Task では大規模なタスクバックログのキャパシティを備えています。タスクインターフェイスで既にバックログされているタスク数を取得し、関数の排他キューを有効にする必要があるかどうかを総合的に分析できます。

Serverless Task タスクキュー負荷分散モデル

前述のセクションでは、関数レベルキューによる「ノイジーネイバー」問題の回避方法を説明しました。ただし、シナリオによっては、タスクの同時実行レベルが高すぎる場合、タスクを単一のキューに分離してもバックログが発生する可能性があります。この問題を解決するには、Serverless Task の負荷分散戦略を導入する必要があります。

Function Compute のタスク処理モジュールにはパーティションの概念があります。各ユーザーはデフォルトで 1 つのパーティションに属し、そのパーティションを担当するスケジューラがユーザーの対応するタスクキューをリッスンします。深刻なバックログが発生した場合、負荷状況に基づいてユーザーに複数のパーティションを割り当て、異なるスケジューラに分配して消費させることで、タスクの全体的な消費速度を向上させます。

図 3

以上の通り、Alibaba Cloud Function Compute はタスクキュー管理においてマルチテナンシーと分離を実現する機能をデフォルトで備えており、ほとんどのシナリオに適用できます。高負荷、長時間実行、高い同時実行数を伴うシナリオでは、Function Compute は水平スケーリングによる消費の高速化もサポートしています。タスク分離の面では、異なる優先度の関数を個別に分離し、ノイジーネイバー問題を回避することをサポートしています。

可観測性

タスクの可観測性は、タスクシステムに不可欠な機能の 1 つです。強力な可観測性は、タスク実行の各段階で必要となる追加作業を軽減するのに役立ちます。

1. 開発段階：タスクのオンラインデバッグ機能と実行結果のデバッグ機能は、ビジネスの立ち上げ進捗に直接影響します。

2. 定常運用段階：各種モニタリング、トラフィック統計、ランタイムログにより、ユーザーはビジネスの変化を迅速に把握し、障害の特定と対応を素早く行えます。

定期的な監査：タスクの履歴記録の保存と保持により、ユーザーに優れたトレーサビリティを提供し、履歴情報に基づく後續のビジネス計画を可能にします。

ServerlessTask の可観測性サポート - 開発テストフェーズ

ビジネスの開発段階での主な要件は、迅速なデバッグと課題の特定です。このフェーズのサポートとして、ServerlessTask はインスタンスへのログイン機能とリアルタイムログ機能を提供しています。コード開発後のテスト、デバッグ、コード修正、再テストのプロセスはすべてコンソール上で完結でき、開発効率が大幅に向上します。性能デバッグが必要な場合や、FFmpeg などのサードパーティバイナリのデバッグ（音声・映像処理分野など）も、インスタンスログイン機能を利用して完了できます。操作手順は以下の通りです。

インスタンスにログインする対象のタスクを選択し、インスタンスリンクをクリックします。

インスタンス監視ページに入り、右上のインスタンスログイン機能をクリックして対応するインスタンスにログインします。

ServerlessTask の可観測性サポート - 本番運用開始後の運用フェーズ

ビジネスが本番環境に移行すると、キャパシティ見積もりの不足により下流システムが負荷に耐えられず、障害が発生しやすくなります。そこで、ServerlessTask はランタイム指標を提供しています。すなわち、一定期間内に送信されたタスク数、完了したタスク数、実行中のタスク数です。ユーザーはこの指標チャートから現在のビジネス負荷を迅速に把握できます。ユーザーのタスクの下流消費が遅い場合、タスクのバックログが発生する可能性がありますが、これも指標チャートに明確に反映されるため、迅速に対応できます。現在、ServerlessTask が提供する関連指標は以下の通りです。

タスクモニタリングダッシュボードでは、以下のタスクモニタリングデータを提供しています。

問題の迅速な特定に関しては、Function Compute は関数ログとインスタンス指標のリアルタイム表示をサポートしています。タスクリストページに入り、実際に実行に失敗したタスクを見つけ、ログページとインスタンスページから問題を特定できます。

ServerlessTask の可観測性サポート - フェーズ監査

オンラインタスクを一定期間運用した後、前週の総タスク実行数、失敗タスク数、失敗した実行の時刻など、一連の定期的な監査が必要になることがよくあります。現在、Function Compute ではコンソールに加えて、タスク監査用の豊富な API 機能を提供しています。主に以下の機能が含まれます。

1. ステータスによるフィルタリング：特定のステータスの実行のみをクエリします。

2. トリガー時間に基づくフィルタリング：過去のある期間内に開始されたタスクをクエリするなどです。

3. タスク名によるクエリ：タスクの上下游に TraceID がある場合、タスクのトリガー時に有意義なタスク ID を指定できます。その後、ID プレフィックスに基づいて範囲をクエリできます。

上記のフィルタリング方法は組み合わせて使用でき、より柔軟な要件を実現できます。コンソールでサポートされているフィルタ条件は以下の通りです。

ServerlessTask の可観測性サポート - デッドレターキューとサービス補償

メッセージングの分野には非常に重要な概念であるデッドレターキューがあります。一部のメッセージを消費できない場合、未処理によるビジネス上の損失を避けるため、後続の人的介入に備えて保存しておく場所が必要です。Serverless Task もこの機能をサポートしています。Serverless Task のターゲット関数を設定できます。タスクの実行が失敗した場合、Function Compute は実行失敗のコンテキスト情報を自動的に Message Queuing などのメッセージサービスに送信し、後続の処理を行えます。処理ロジックが自動化に対応している場合、Function Compute は失敗したタスクのコンテキスト情報を関数計算に再度送信し、カスタムビジネスロジックを実行してビジネス補償を実現することもサポートしています。

非同期呼び出し設定ページで成功時と失敗時のターゲットを設定できます。

以上のように、Serverless Task が提供する可観測性機能は、タスクライフサイクル全体のモニタリング要件を効果的にサポートします。すべてのコンソール機能はオープン API を使用してカスタマイズでき、より多くの要件に対応できます。Serverless Task のターゲット関数は、タスク失敗の補償だけでなく、イベント駆動モードのデータソースとしても機能し、後処理されたイベントを下流サービスに自動送信できます。