次の方法で共有


スケーリングを構成する

マネージド DevOps プールのパフォーマンスとコストを管理するようにスケーリング設定を構成します。 価格とパフォーマンスの詳細については、「 管理のコストとパフォーマンスを参照してください。

エージェントの状態

マネージド DevOps プールは、ステートレスまたはステートフルとして構成できます。

Managed DevOps プールの既定の設定はステートレス (毎回 Fresh エージェント) ですが、場合によっては、チームは前のパイプラインの実行中に作成されたパッケージまたはファイルを再利用するためにエージェントを再利用したい場合があります。 ビルド ワークロードは、チームが状態を保持してエージェントを再利用する一般的なシナリオです。 マネージド DevOps プールを使用してステートフル プールを実現しながら、セキュリティのベスト プラクティスとバランスを取ることができます。 既定では、エージェントは最大 7 日間再利用できますが、より早くリサイクルされるように構成できます。

Note

ステートレス プールまたはエージェントの状態設定 毎回Fresh エージェントを使用する は、サプライ チェーン攻撃に対する防御としてセキュリティ専門家によって推奨されます。

ステートレス プール

ステートレス エージェントを構成すると、ジョブごとに新しいエージェントが調達され、ジョブの完了後に破棄されます。

ステートレス エージェントのスクリーンショット。

Agent 状態毎回 Fresh エージェントに設定するとジョブごとに新しいエージェントが調達され、ジョブの完了後に破棄されます。

ステートフル プール

ステートフル エージェントのスクリーンショット。

Same エージェントを複数のビルドで使用できる場合 (リソース テンプレートの"kind": "stateful"または Azure CLI の{ "stateful": {...} }) が有効になっていると、プール内のエージェントはステートフルと見なされます。 ステートフル プールは、次の設定を使用して構成されます。

  • スタンバイ エージェントの最大有効期間 (maxAgentLifetime) は、ステートフル プール内のエージェントがシャットダウンおよび破棄されるまでの最大実行時間を構成します。 スタンバイ エージェントの 最大有効期間 の形式は dd.hh:mm:ss。 スタンバイ エージェントの最大有効期間 既定値は 7 日間 (7.00:00:00) の最大許容期間に設定されます。

  • 猶予期間 (gracePeriodTimeSpan) は、ステートフル プール内のエージェントが新しいジョブを待機してから、現在のジョブとキューに登録されているすべてのジョブが完了した後にシャットダウンするまでの時間を構成します。 Grace Period の形式はdd.hh:mm:ssであり、既定値は猶予期間がありません。

ステートレス プール内のエージェントはシャットダウンされ、すべてのジョブの後に破棄されますが、ステートフル プール内のエージェントは、次のいずれかの条件が満たされた場合でも実行を続行します。

  • 最初のジョブが完了したときに別のジョブがキューに登録されている場合、Managed DevOps Pools はそのジョブをシャットダウンするのではなく、最初のジョブを実行したエージェントに送信します。
  • プールに対して猶予期間が構成されている場合、エージェントは猶予期間で指定された期間、新しいジョブを待機してからシャットダウンします。
  • standby エージェントが有効になっていてエージェント イメージがアクティブなプロビジョニング期間の条件を満たしている場合、エージェントは引き続き実行され、ジョブを待機します。

ステートフル プール内の実行中のエージェントは、前の条件が満たされている場合でもMax のスタンバイ エージェントの有効期間中に継続的に実行される場合は、シャットダウンされ、破棄されます。 たとえば、スタンバイ エージェント 最大有効期間 が 3 日間構成され、 Standby エージェント モードManual、All Week Scheme (Machines available 24/7)に設定されている場合、エージェントは 3 日間の継続的なアップタイム後に再起動されます。

重要

猶予期間がなく、スタンバイ エージェントのアクティブなプロビジョニング期間がなく、エージェントと一致するキューに登録されたジョブがない場合、ジョブの完了後も、ステートフル プール内のエージェントをシャットダウンおよび破棄できます。 エージェントが破棄されると、すべての状態が失われます。

猶予期間により、一貫した負荷でパイプラインのステートフル プールを実行する最もコスト効率の高い方法が可能になり、エージェントをオンラインに保ち、ジョブを受け入れる準備をするためにスタンバイ エージェント モードを使用する必要はありません。

スタンバイ エージェント モード

プールを作成する場合、 スタンバイ エージェント モード は既定でオフになっています。また、パイプラインにすぐに割り当てるスタンバイ エージェントはありません。これは、エージェントをオンデマンドでプロビジョニングするために、しばらく (最大 15 分) 待機する必要がある場合があります。 パフォーマンスを向上させるには、 スタンバイ エージェント モードを有効にし ワークロードの容量を提供するスタンバイ エージェント スケジュールを構成します。

スタンバイ エージェント のスケジュールを構成すると、Managed DevOps プールは、プロビジョニングされたエージェントの数と現在のプロビジョニング スキームで指定されたスタンバイ エージェント数を定期的に比較し、スタンバイ エージェント数を維持するために必要に応じて新しいエージェントを開始します。 エージェント ペインを使用して、プール内のエージェントの現在の状態と数を表示できます。

重要

スキームのプロビジョニング数は、Pool 設定で構成された Maximum エージェントより大きくすることはできません。

スタンバイ エージェント モードは、次の設定を使用して構成されます。

  • オフ - スタンバイ エージェント モードがオフになり、ジョブがキューに登録されると、エージェントがオンデマンドでプロビジョニングされます。
  • 手動 - 手動スタンバイ スケジュールを構成します。
  • 自動 - エージェントの使用履歴に基づいて自動スタンバイ スケジュールを使用し、コストとパフォーマンスのために構成できます。

スタンバイ エージェント モードの選択のスクリーンショット。

手動

手動モードは、CI/CD パイプラインの使用パターンに関する知識を持つチームに最適です。 手動オプションを選択する場合は、プール内のエージェントが使用される可能性が最も高い時期と使用される可能性の高いエージェントの数を把握し、予測される需要を満たすエージェントのプロビジョニング数を指定して、事前プロビジョニングスキームを定義する必要があります。

独自のプロビジョニング スケジュールを作成することも、定義済みのスケジュールから選択することもできます。また、スケジュールの指定に使用するタイム ゾーンを構成することもできます。 Pre-provisioning TimeZone の既定値は (UTC) 協定世界時です。

手動スタンバイ エージェントの構成は、次の 3 つの方法のいずれかで構成できます。

各事前プロビジョニング クイック スタートには、そのクイック スタートの特定の設定に加えて、次の一般的な設定があります。

  • TimeZone を事前プロビジョニングすると、事前プロビジョニング スキームの時刻のタイム ゾーンを構成できます。 Pre-provisioning TimeZone の既定値は (UTC) 協定世界時です。
  • スタンバイ エージェントの割合 は、イメージごとに必要なスタンバイ エージェントの割合を構成します。 すべてのイメージが均等にプロビジョニングされるように * を入力するか、0 から 100 の整数を指定してパーセンテージを表すことができます。 パーセンテージを指定する場合、すべての画像の合計は 100 に等しい必要があります。 1 つのイメージがある場合は、 * または 100 を指定します。 スタンバイ エージェントの割合 は、ARM テンプレートを使用する場合に images セクションで構成されます。 詳細については、「イメージの構成」を参照してください。

手動スタンバイ モードのスクリーンショット。

ゼロから始める

最初から開始する場合は、プロビジョニングスキームとして機能するプロビジョニング期間の一覧を追加できます。 各プロビジョニング期間は、開始日、終了日、タイム ゾーン、開始時刻、終了時刻、カウントで構成されます。 プロビジョニング期間は互いに重複することはできません。

プロパティ 説明
複数の日 オンにすると、プロビジョニング スキームの開始日と終了日の両方を構成できます。
次の期間まで オンにすると、プロビジョニング期間は開始時刻から次のプロビジョニング期間の開始まで実行されます。
開始日 プロビジョニング期間が開始される日。
終了日 プロビジョニング期間が終了する日。 [複数日] がオンの場合は必須。
Start Time プロビジョニング期間が開始される時間。
End Time プロビジョニング期間が終了する時刻。 次の期間までがオンでない限り必須です。
カウント プロビジョニングするスタンバイ エージェントの数。 この数値は 0 より大きく、プール設定で構成されている Maximum agents 値より大きくすることはできません。

プロビジョニング期間を作成した後、 Pre-provisioning scheme 一覧から期間を削除または編集できます。

次の例では、月曜日の午前 12:00 から午前 5:00 EST に 1 つのエージェントがプロビジョニングされた手動スキームを構成します。

手動スケーリング スキームのスクリーンショット。

平日のスキーム

曜日スキームを選択した場合は、開始時刻と終了時刻を指定できます。この開始時刻と終了時刻では、指定した数のスタンバイ エージェントが平日ごとにスタンバイ状態になります。

プロパティ 説明
Start Time プロビジョニング期間が開始される時間。
End Time プロビジョニング期間が終了する時刻。
プロビジョニング数 プロビジョニングするスタンバイ エージェントの数。 この数値は 0 より大きく、プール設定で構成されている Maximum agents 値より大きくすることはできません。

次の例では、東部標準時を使用して、非稼働時間と週末に 0 個のエージェントを使用して、勤務時間中に使用する 4 つのエージェントを構成します。

平日のスキームのスクリーンショット。

すべての週のスキーム

すべての週のスキームを選択した場合は、24 時間 365 日利用可能なエージェントの数を指定できます。

すべての週のスキームのスクリーンショット。

自動

使用パターンがわからない場合に、過去のデータに基づく自動予測に依存する場合は、 自動を選択します。 スライダーと次の 5 つのオプションを使用して、コストとエージェントのパフォーマンスのバランスを取ることができます。 Managed DevOps Pools は、過去 3 週間の履歴データ (使用可能な場合) に対してクエリを実行し、プールのキューに登録されたセッションを 5 分の期間に整理し、指定されたパーセンタイル (スパイクを回避するために) を各時間に割り当てます。

  • 最もコスト効率の高い (MostCostEffective) - 10 パーセンタイル
  • コスト効率 (MoreCostEffective) - 25 パーセンタイル
  • Balanced (既定値) (Balanced) - 50 パーセンタイル
  • パフォーマンスの向上 (MorePerformance) - 75 パーセンタイル
  • 最適なパフォーマンス (BestPerformance) - 90 パーセンタイル

自動スケーリング設定のスクリーンショット。

関連項目