優先順位に基づくバッチスケジュール

プラットフォーム アップデート 31 では、機能管理 の バッチ優先順位に基づくスケジューリング 機能を有効にすることができます。 優先順位に基づくスケジューリングではバッチ グループをバッチ サーバーから切り離し、バッチ グループの優先順位を定義できます。 バッチ ジョブをバッチ サーバーに割り当てる必要はなくなりました。 代わりに、使用可能なバッチサーバー間でタスクが実行される順序を決定するために、業務要件に基づく相対的なスケジューリング優先順位が使用されます。

スケジューリング優先順位はバッチ グループに対して定義されますが、特定のバッチ ジョブに対して上書きすることができます。 スケジュール設定の優先順位の分類は、相対的な優先順位を宣言し、ジョブとビジネスプロセスの処理順序の決定に使用されます。 スケジューリング優先順位に使用できる値は、低、通常、高、重大、予約済みキャパシティ です。

標準は規定値で、これが有効化されると、すべての既存のバッチ グループに適用されます。 予約済キャパシティ は、最も高い優先順位を表します。 プラットフォーム更新プログラム 32 または それ以降のバージョンでは、これをジョブ専用のキャパシティとして使用できます。 詳細については、 この記事後半の バッチ専用のキャパシティ レベルを設定 セクションを参照してください。

たとえば、処理するバッチ タスクが 100 あるとします。 予約キューから 40、クリティカル キューから 30、ハイ キューから 15、ノーマル キューから 10、ロー キューから 5 のタスクが処理されます。 これは、処理に対して選択された優先順位に基づく実行順序ではありません。 その代わり、各優先順位からのバッチ タスクの重量です。

プラットフォーム更新プログラム 32 には、既存のバッチジョブに対する更新サポートが含まれています。 詳細については、 この記事後半のバッチ ジョブをバッチ グループへと自動移行する セクションを参照してください。

優先順位に基づくバッチ スケジューリングの利点は次のとおりです。

• 優先順位は、バッチ ジョブ レベルまで導入されます。
• これは、ダウンタイムがほぼゼロのサービスの前提条件として機能します。
• バッチ ジョブは特定のサーバーに関連付けされません。

次の手順では、優先順位に基づくバッチ スケジューリング機能が有効になっている場合に、バッチ グループ、ジョブ、およびタスクと作業する方法について説明します。

1. 識別 – 既存のバッチ ジョブの優先順位を識別します。
2. 有効化 – 機能管理における優先順位に基づくスケジューリングを有効にします。 既定では、既存のすべてのバッチ ジョブは通常の優先順位に設定されます。
3. 更新 – 通常の優先順位ではないジョブの優先順位を選択して更新します (専用キャパシティ、重大、高、低など)。
4. 適用 – 優先順位を超えて一部のジョブの容量を割り当てる必要がある場合は、専用キャパシティを適用します。

バッチ グループ

バッチ グループは、ジョブを論理的にグループ化し、既定のスケジューリング優先順位を設定するためにのみ使用されるようになりました。 バッチ グループの例を次に示します:

• 特定の業務プロセスに属するジョブ
• 同じ実行の繰り返しが設定されているジョブ (たとえば、毎晩、毎週、毎月など)
• 優先順位が同じジョブ

バッチ グループの作成

1. システム管理>設定>バッチ グループの順に移動します。
2. 新規 を選択して、新しいバッチ グループを作成します。
3. グループ フィールドで、そのバッチ グループに対して固有の名前を入力します。
4. 説明フィールドで値を入力します。
5. スケジューリング優先順位 フィールドで、バッチ グループ内のバッチ ジョブの既定のスケジューリング優先順位を選択します。
6. 保存 を選択します。

バッチ ジョブ

バッチ ジョブは、自動処理のために送信されるタスクのグループです。 バッチ ジョブは、実行者 フィールドで選択されたユーザーのセキュリティ資格情報を使用して実行されます。 バッチ ジョブを作成するには、次の手順に従います。

バッチ ジョブの作成

1. システム管理>照会>バッチ ジョブ の順に移動します。
2. 新規 を選択して、新しいバッチ ジョブを作成します。
3. 職務明細書フィールドに値を入力します。
4. 開始予定日時フィールドに、日時を入力します。
5. 実行者 フィールドで、バッチジョブの実行時に使用するセキュリティ資格情報を持つユーザーを選択します。 詳細については、バッチ管理者のセキュリティ ロール を参照してください。
6. オプション: 監視カテゴリ フィールドで、監視中にジョブのタイプを容易に識別できるように値を選択します。
7. オプション: 重要なジョブ　オプションを はい に設定します。 詳細については、ユーザーを一括でインポートする または 重大としてバッチ ジョブを処理するときのワークフロー メッセージを構成する を参照してください。
8. バッチ グループ フィールドで、ジョブのバッチ グループを選択します。
9. オプション: スケジューリング優性順位が上書きされました オプションを はい に設定し、ジョブのスケジューリング優先順位 フィールドを使用可能にします。
10. オプション: ジョブのスケジューリング優先順位 フィールドで、バッチ グループに対して定義されている既定の優先順位とは異なる既定の優先順位を選択します。
11. オプション: 有効な期間 フィールドで、バッチ ジョブを実行できる時間の範囲を選択します。 詳細については、有効なバッチ期間 を参照してください。
12. 保存 を選択します。

バッチ ジョブへのタスクの追加

1. バッチ ジョブ ページの バッチ タスク セクションで、新規 を選択します。

2. タスク明細書フィールドに値を入力します。

3. 会社アカウント フィールドで、タスクが実行される会社を選択します。

4. クラス名 フィールドで、実行するプロセスを選択します。 CanGoBatchJournal プロパティが有効化されていると、クラスがリスト表示されます。

5. 保存 を選択します。

6. バッチ タスクの詳細 クイックタブを展開して、バッチ タスクの設定をさらに追加するか、制約を追加します。

7. 全般 タブで、タスクの失敗を無視する オプションを はい に設定して、タスクの失敗によってジョブが失敗しないように指定します。

8. 最大再試行回数 フィールドで、試行が何回失敗した場合にタスクが失敗したと見なされるかを指定します。

9. そのジョブを作成したユーザーのみがタスクを実行する場合は、プライベート オプションを はい に設定します。 このオプションは、クライアントタスクにのみ適用されます。

10. 選択したタスクの実行がそのジョブの先行タスクのステータスに依存すべき場合は、制約 タブで、新規 を選択します。

11. タスク ID フィールドで、先行タスクを選択します。

12. 予定されたステータス フィールドで、現在のタスクを実行する前に先行タスクが到達する必要があるステータスを選択します。

13. 保存を選択します。

    メモ

    複数の条件 / 制約を入力した場合、依存タスクが実行できる前にすべての条件が満たされている必要がある場合は、条件タイプとして すべて を選択します。 いずれかの条件が満たされた後で依存タスクを実行できる場合は、条件タイプとして 任意 を選択します。

14. バッチ タスクが入力パラメーターに対応している場合は、 パラメーター を選択し、続いてタスク固有のパラメーターを設定します。

15. OK を選択してから、保存を選択します。

バッチに特化したキャパシティ レベルの設定

1. システム管理>設定>システム パラメーターの順に移動します。

2. バッチ グローバル 設定 タブの バッチ専用のキャパシティ レベル フィールドで、 専用キャパシティ の優先度を持つバッチジョブ 専用のキャパシティ レベルを選択します。

   • 専用キャパシティなし – この値が既定の値となります。
   • 専用キャパシティ低 – 累積するバッチ スレッドの 10 パーセントがバッチ処理に割り当てられます。
   • 専用キャパシティ中 – 累積するバッチスレッドの 15 パーセントがバッチ処理に割り当てられます。
   • 専用キャパシティ高 – 累積するバッチ スレッドの 25 パーセントがバッチ処理に割り当てられます。

   たとえば、バッチ アプリケーション オブジェクト サーバー インスタンスが 10 で、各インスタンスが 12 スレッドで構成されています。 したがって、バッチ スレッドの累計数は 120 になります。 バッチ予約能力レベルを高い予約能力として構成すると、累計スレッドの 25 パーセント (つまり、30 スレッド) が、予約されたキューからのバッチ タスク処理専用になります。 これらの 30 のスレッドは、3 つの AOS インスタンスに割り当てられる必要があります。 したがって、10 の AOS インスタンスの 3 つが、予約されたキューの処理専用になります。 予約された能力で処理するバッチ タスクがない場合、それらの 3 つの AOS インスタンスはアイドル状態になります。

   注記

   サンプルの値は、わかりやすい事例を示しています。 実際に割り当てられるキャパシティは、バッチサーバの設定と、任意時点で使用可能となるバッチスレッドの数によって異なります。 専用の X スレッドは、予約されたカテゴリで実行されるバッチ タスクが一定数にあるユース ケースが無い場合、構成することはできません。

3. 保存を選択します。

期限切れのバッチレコードを削除するシステムジョブ は、新規の内部システム向けのバッチジョブで、新たな BatchHeartbeatTable テーブルを削除します。 このバッチジョブのクラス名は、 SysCleanupBatchHeartbeatTable です。 BatchHeartbeatTable は 内部を監視するテーブルで、使用中のノードのスレッドのキャパシティを決定、設定や分配します。

ベスト プラクティス

• すべてのバッチ ジョブの優先度が同じにならないように、優先度を調整することをお勧めします。 たとえば、すべてのバッチ ジョブの優先度を高または重大に設定しないでください。 次の表は、バッチの優先順位を構成するときに考慮する必要のある配分を示しています。

  優先順位	予約容量 を除くバッチ ジョブの可能な配分の割合
  低	10% ～ 50%
  標準	15% ～ 35%
  高	15% ～ 35%
  重大	10% ～ 30%

• バッチ ジョブは、24 時間体制で優先度の異なるジョブが常に混在するようにスケジュールする必要があります。 たとえば、朝に標準、午後に高、夕方に重大、夜に低の優先度で、すべてのバッチ ジョブをスケジュールしないでください。

• 予約されたキューを予約されたキャパシティ優先で使用すると、バッチジョブ専用のリソースがあるように感じられます。 この動作が不要な場合は、予約容量の優先度にバッチジョブを割り当てないでください。

• 優先順位は、ランク タスクを相互にスタックするためには使用されません。 代わりに、優先順位によって、タスクが実行のために選択される確率が決まります。

• パフォーマンスの低下を防ぐために、サーバー間でスレッドの数を同じに保つことをお勧めします。

• SQL Server の一時的なエラーによる問題を防ぐため、バッチ タスクに BatchRetryable インターフェイスを実装することをお勧めします。 詳細については、SQL 一時接続エラーの再試行を参照してください。

• バッチ タスクは、本質的にべき等である必要があります。 何回実行しても同じ結果になるはずなので、タスクのリトライ回数は 0 (ゼロ) 以上で設定してください。 この設定により、ジョブの実行中に発生する可能性があるどんな一時的なエラーからでもシステムを復旧できます。 詳細については、SQL 一時接続エラーの再試行を参照してください。

• ワークロードが大きい場合は、ワークロードやタスクを小さく分割して、10 分以下で実行および完了できるようお勧めします。

• バッチ タスク内の SQL Server トランザクションは、他のバッチ ジョブやユーザー活動のパフォーマンスに影響を与える SQL Server ブロックを引き起こさないように、できる限り短い期間である必要があります。

• 優先順位ベースのバッチ スケジューリングを活用するために複数のバッチ グループを設定し、バッチグループ レベルで異なる優先順位を使用することをお勧めします。

• 開発コンピュータに接続してユーザー受入テスト (UAT) でバッチをデバッグする場合は、次のスクリプトを実行してバッチ サーバーの残りの部分を無効にする必要があります。 これにより、開発マシンですべてのバッチが実行されている状態を確認できます。

  UPDATE ssc
  SET ssc.enablebatch = 0
  FROM dbo.sysserverconfig ssc
  WHERE ssc.serverid = '<servername Tier2 batch server>'   
  

バッチジョブをバッチグループへ自動移行する

この機能が有効化されると、タスクのバッチ グループ情報は、使用されるジョブへと複製されます。 ジョブのバッチグループへの割り当ては、ジョブのタスクで最も使用されるバッチグループを基準に決定されます。

新規のバッチジョブ、 バッチ グループの関連付けをバッチ ジョブに設定するシステム ジョブ が移行の管理をします。 このバッチジョブのクラス名は、 SysMigrateBatchGroupsForPriorityBasedScheduling です。

このバッチジョブは毎日 1:00 AM に起動し、 スケジュール設定に基づいたバッチ処理優先度 機能が無効となっていても起動します。 最終実行時以降の、適用可能となるバッチ ジョブの差分を移行します。

この機能を有効にすると、バッチジョブが実行され、最終実行時以降のバッチジョブが移行されます。 この機能を有効にしたユーザーには、移行バッチ ジョブの ID への参照を含む通知が送信されます。

この機能を有効化して移行が完了したら、自動バッチグループへの割り当てを確認することを推奨します。 この確認作業を容易にする目的で、タスクの バッチグループ フィールドは読み取り専用になっています。 下位互換性に対応するため、このフィールドの値は、新たなバッチタスクが追加された際にジョブから反映されます。

ベスト プラクティスとして、すべてのバッチ ジョブに高い優先順位または重大な優先順位を割り当てないことをお勧めします。

バッチの同時実行

プラットフォーム アップデート 58 では、機能管理 の バッチの同時実行制御 機能を有効にすることができます。 この機能により、特定のバッチ ジョブで同時に実行できるタスク数を制限できます。 したがって、バッチ ジョブに優先順位を付け、リソースの利用を最適化することができます。 たとえば、優先順位の低いバッチ ジョブのタスク数を制限することで、システムの過負荷や、優先順位の高い他のバッチ ジョブのパフォーマンスに影響を与えること防ぐことができます。

前提条件

前提条件として、この環境で バッチ優先順位に基づくスケジュール設定 の機能を有効にする必要があります。

バッチの同時実行制御が必要となる理由

バッチ ジョブは、データ処理、レポート、統合などのバックグラウンド タスクを実行する一般的な方法です。 ただし、同時に実行されているバッチ タスクの数が多すぎると、パフォーマンスの問題やリソースのコンテンツが発生する可能性があります。 たとえば、バッチ ジョブの 1 つが時間ごとに実行され、大量のデータが処理されます。 別のバッチ ジョブは 15 分おきに実行され、優先順位が高くなります。 バッチ同時実行制御を行わないと、優先度の高いバッチジョブに十分なリソースを確保して、スムーズかつタイムリーに実行できません。

バッチの同時実行制御とどのように使用するか？

バッチ同時実行制御を使用するには、機能管理で (プレビュー) バッチ同時実行制御 機能を有効にする必要があります。 続いてに バッチ グループ に移動し、同時実行制限を適用するバッチ グループを選択します。 バッチ グループ ページには、最大同時実行 という名前の新しいフィールド があります。 選択したバッチ グループ内の各バッチジョブで同時に実行できるタスクの最大数を表す正の整数を入力できます。 この設定は、バッチ グループに属するすべてのバッチ ジョブに適用されます。

たとえば、バッチグループの 最大同時実行 値を 10 に設定した場合、そのバッチグループ内のバッチジョブのタスクは 10 個しか同時実行できません。 ジョブのタスクが 10 件以上実行を待機している場合、実行中のタスクの一部が完了するまでキューに入れられます。

最大同時実行 値 は、さまざまなバッチ グループにわたって実行できるタスクの数には影響されません。 同じバッチ グループ内のタスクにのみ適用されます。 同時実行制御が必須ではない場合は、既定値である 0 (ゼロ) に設定する必要があります。

バッチ グループ内のすべてのバッチ ジョブを完全に一時停止する場合は、最大同時実行 フィールドを -1 に設定します。 値を -1 に設定する前にシステムによって選択されたタスクは、引き続き実行されます。