ジョブスケジューリングにおいて、アプリケーションレベルの速度制限を実装するには、次の 2 つの戦略が利用できます：速度制限を有効にして適切なキュー サイズを設定する、またはプリエンプティブ（横取り型）の優先度付きキューを構成する。これらの戦略により、スケジューリングシステムの安定性と重要なジョブのタイムリーな実行を確保できます。本トピックでは、アプリケーションレベルのリソースを効果的に管理し、優先度に基づいてジョブをスケジュールする方法について説明します。
ユースケース
ジョブスケジューリングシステムは、突発的なトラフィックスパイク時に大きな負荷にさらされることがあります。たとえば、多数の日次ジョブが同時に開始されるようにスケジュールされている場合、適切な制御が行われなければ同時ロードによってバックエンドシステムがクラッシュする可能性があります。この問題に対処するため、SchedulerX はアプリケーション内で同時に実行できるタスクインスタンスの最大数を制御するキュー機構を導入しています。ジョブをキューに格納して順次ディスパッチすることにより、この機構はアプリケーションの安定性を維持し、リソースを効率的に使用します。
設定
速度制限を有効にしてキュー サイズを設定する
-
アプリケーショングループを作成または編集する際、詳細設定セクションで Flow Control スイッチを有効にします。このスイッチはデフォルトで無効になっています。アプリケーショングループの作成方法の詳細については、「アプリケーショングループの作成」をご参照ください。
フロー コントロールを有効にすると、Number of concurrent task instances を設定できます。このパラメーターは、アプリケーションで同時に実行できるタスクインスタンスの最大値を定義します。送信されたタスクインスタンス数がこの上限を超えた場合、超過分のインスタンスは後続の実行のためにキューに格納されます。
-
アプリケーショングループ内に 3 つのジョブを作成し、それぞれのジョブについて **[操作]** 列の Run once をクリックします。
-
左側のナビゲーションウィンドウで Execution List をクリックします。Task instance List タブで、最初にトリガーされた hello_jobA が実行中であり、hello_jobB および hello_jobC がキューで待機していることを確認できます。
-
hello_jobA の実行が正常に完了すると、次に hello_jobB が実行を開始します。
プリエンプティブな優先度付きキューを構成する
YARN (Yet Another Resource Negotiator) のようなリソース管理システムでは、優先度付きキューを使用して、異なる優先度を持つジョブのリソースを分離します。
以下のプロシージャでは、SchedulerX がアプリケーションレベルの速度制限とジョブの優先度を組み合わせて、プリエンプション（横取り）をサポートする優先度付きキューを実装する方法を示します。
-
SchedulerX では、各ジョブに優先度を割り当てることができます。同一アプリケーション内で複数のジョブが同じ時刻にスケジュールされている場合、SchedulerX は優先度の高いジョブから順にスケジュールします。
ジョブの 基本設定 ページで、ドロップダウンリストから 優先度 を選択できます：低、中、高、または 非常に高。
-
これを実証するために、
dts-all.hxmアプリケーショングループに対してフロー コントロールを有効にし、わかりやすくするために Number of concurrent task instances を 1 に設定します。優先度が高、中、低の 3 つのジョブを作成し、この順序で一度だけトリガーします：中 → 低 → 高。 -
左側のナビゲーションウィンドウで Execution List をクリックします。Task instance List タブで、中優先度のジョブがトリガーされた時点で実行キューが空であるため、そのジョブが即座に実行されることを確認できます。
-
中優先度のジョブが完了すると、実行スロットが空きます。その後、高優先度のジョブが低優先度のジョブを横取りして、次に実行されます。
よくある質問
-
すべてのジョブの優先度を「非常に高」に設定した場合、他のユーザーのジョブより前にスケジュールされますか？
ジョブの優先度はアプリケーションレベルの設定です。これは同一アプリケーション内のジョブのスケジュール順序にのみ影響し、他のアプリケーションには影響しません。
-
1 分ごとに実行されるジョブに対してキューに基づく速度制限を使用できますか？
この機能は、突発的なトラフィックスパイクが発生するシナリオに最適です。1 分ごとに大量のジョブがスケジュールされている場合は、キューが無限に増加する可能性があるため、この機能の使用は推奨されません。このようなケースでは、クライアント側でビジネスレベルの速度制限を実装するか、クライアントのリソースをスケールアップすることを検討してください。