How Serverless Task solves task scheduling

1、タスクスケジューリング

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

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

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

図 1

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

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

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

図 2

代表的なアプリケーションシナリオ

ユーザー A が 2 つの異なるタスク関数を持っているとします。タスク A はダウンストリームサービスの制約により一度に 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 は、タスクキュー管理においてマルチテナンシー分離機能を標準で備えており、ほとんどのシナリオに適用できます。負荷が高く、実行時間が長く、同時実行数が多いシナリオでも、水平スケーリングにより消費速度を加速できます。タスク分離では、優先度の異なる関数を個別に分離し、ノイジーネイバー問題を回避できます。

2、可観測性

タスクの可観測性は、タスクシステムの不可欠な機能の 1 つです。強力な可観測性により、タスク運用の各段階で必要な追加作業を削減できます。

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

通常運用段階：各種モニタリング、トラフィック統計、ランタイムログにより、ユーザーはビジネスの発展と変化を迅速に把握でき、障害発生時の迅速な位置特定と対応が可能になります。

フェーズ監査：タスク履歴の保存と保持により、ユーザーに優れたトレーサビリティが提供され、履歴情報に基づいた後続のビジネス計画を立てられます。

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

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

タスクを選択し、インスタンスリンクをクリックします。

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

ServerlessTask の可観測性サポート - ビジネス本番稼働後の運用フェーズ

ビジネスが本番稼働すると、キャパシティ見積もりが不十分なためダウンストリームシステムが負荷に耐えられず、障害が発生しやすくなります。そこで ServerlessTask はランタイム指標、つまり期間別に送信されたタスク数、完了したタスク数、実行中のタスク数を提供します。ユーザーはこの指標チャートに基づいて現在のビジネス負荷を迅速に把握できます。ユーザーのタスクのダウンストリーム消費が遅い場合、タスクバックログが発生する可能性がありますが、これも指標チャートに即座に反映されるため、迅速な対応が可能になります。現在、ServerlessTask が提供する関連指標は以下の通りです。

タスク監視システムは次のタスク監視データを提供します。

監視指標

説明

送信タスク数

過去 1 分間に送信されたタスクの総数。実行中、完了、およびキュー待ちのタスク数を含みます。

完了タスク数

過去 1 分間に送信されたタスクのうち完了したタスク数。成功または失敗したタスクを含みます。

キュー内タスク数

過去 1 分間に送信されたタスクのうち、まだキュー待ち状態のタスク数。この数が 0 でない場合、タスクバックログが発生しています。

実行中タスク数

過去 1 分間に送信されたタスクのうち、実行中のタスク数。

失敗タスク数

過去 1 分間に送信されたタスクのうち、実行に失敗したタスク数。

実行中の占有インスタンス数

過去 1 分間に送信されたタスクのうち、正常に実行中のタスク数。

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

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

オンラインタスクが一定期間稼働すると、先週に実行されたタスクの総数、失敗したタスク数、失敗した実行時刻など、一連のフェーズ監査が必要になることが多いです。現在、Function Compute はコンソールに加えて、タスク監査のための豊富な API 機能を提供しています。主に以下の機能を含みます。

ステータスによるフィルタリングで、特定のステータスの実行のみをクエリできます。

トリガー時間によるフィルタリングで、過去の特定期間内に開始されたタスクなどをクエリできます。

タスク名によるクエリ。タスクにビジネスのアップストリームおよびダウンストリームの TraceID がある場合、タスクの起動時に意味のあるタスク ID を指定できます。後から ID プレフィックスに基づいて範囲をクエリできます。

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

より詳細なパラメータについては、ListStatefulAsyncInvocation を参照してください。

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

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

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

より詳細な設定内容については、PutFunctionAsyncInvokeConfig を参照してください。

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

Serverless の最近のおすすめイベント

Serverless 体験談・記事キャンペーンが開催中です。6 月 28 日から 7 月 31 日までの期間中、製品評価への参加や記事の公開で、Beats ヘッドセット、メカニカルキーボード、1,000 元 Tmall スーパーマーケットカード、Youku メンバーシーズンカードなど、豪華賞品を獲得できるチャンスがあります。

投稿のテーマは以下を参考にしてください（ただしこれらに限定されません）。

・Function Compute の機能に関する体験談や提案。他のユーザーが Serverless サービスを選択する際の参考になります。

・Function Compute を活用したアプリケーションシナリオの評価。たとえば、Function Compute を利用したクラウドブログの構築、弾力的で高可用性な Serverless Web アプリケーションの構築、サーバーレスアーキテクチャに基づく弾力的で高可用性な動画処理システムの構築などです。