次の方法で共有


スケーリングを構成する

スケーリング設定を構成することで、Managed DevOps Pools インスタンスのパフォーマンスとコストを管理できます。 価格とパフォーマンスの詳細については、「コストとパフォーマンスを管理する」をご覧ください。

エージェントの状態

プールは次のように構成できます。

  • ステートレス: すべてのジョブに新しいエージェントを提供します。
  • ステートフル: 複数のジョブ間でのエージェントの共有を許可します。

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

セキュリティ エージェントでは、ユーザーがサプライ チェーン攻撃に対する防御としてステートレス プールを使用することをお勧めします。 毎回新しいエージェントを使用するエージェント状態設定を適用します。

ステートレス プール

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

ステートレス エージェントのライフサイクルと Azure Pipelines での使用方法の詳細については、「 エージェントのライフサイクルと割り当ての潜在的な遅延 」セクションを参照してください。

ステートレス エージェントを示すスクリーンショット。

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

ステートフル プール

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

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

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

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

    重要

    スタンバイ エージェントの最大有効期間が切れたときにジョブが実行されている場合、ジョブの実行に 2 日以上かかる場合を除き、エージェントはジョブが完了するまでシャットダウンしません。 Managed DevOps プール内の個々のジョブは、スタンバイ エージェントの最大 有効期間が 2 日を超えてスタンバイ エージェントで実行されている場合でも、最大 2 日間実行できます。 ワークフローで、完了までに 2 日以上かかる 1 つのジョブを実行する必要がある場合は、サポートにお問い合わせください。

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

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

ステートフル プールで実行されているエージェントは、前の条件が満たされている場合でも、 スタンバイ エージェントの最大有効期間で指定された期間継続的に実行される場合、シャットダウンおよび破棄されます。 たとえば、 スタンバイ エージェントの最大有効期間 が 3 日間構成されていて、 スタンバイ エージェント モード手動、すべての週のスキーム (24 時間 365 日利用可能なマシン) に設定されている場合、エージェントは 3 日間の連続アップタイム後に再起動します。

重要

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

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

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

プールを作成すると、 スタンバイ エージェント モード は既定でオフになります。 スタンバイ エージェント モードがオフの場合、パイプラインにすぐに割り当てるスタンバイ エージェントはありません。 パイプラインは、エージェントがオンデマンドでプロビジョニングされるまで、数分から15分の間待たなければならないことがあります。 パフォーマンスを向上させるには、スタンバイ エージェント モードを有効にして、ワークロード用にキャパシティを提供するスタンバイ エージェント スケジュールを構成します。

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

重要

スキームのプロビジョニング数は、プール設定で構成した最大エージェントの値を超えることはできません。

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

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

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

手動

手動モードは、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインの使用パターンを知っているチームに最適です。 手動オプションを使用する場合は、事前プロビジョニング スキームを定義する必要があります。 使用される可能性が最も高いプール内のエージェントと、使用される可能性の高いエージェントの数を理解した上で、スキームを定義します。 予想される需要を満たすエージェントのプロビジョニング数を指定します。

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

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

プロビジョニング前の各クイック スタートには、(そのクイックスタートに固有の設定に加えて) 次の共通設定があります。

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

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

最初から行う

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

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

プロビジョニング期間を作成した後、事前 プロビジョニングスキーム の一覧から期間を削除または編集できます。

次の例は、月曜日の朝 12:00 AM から 5:00 AM EST にプロビジョニングされた 1 つのエージェントを使用して手動スキームを構成する方法を示しています。

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

平日のスキーム

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

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

次の例では、東部標準時 (UTC-5) を使用して、勤務時間中に 4 つのエージェントを使用し、非稼働時間と週末にはエージェントを使用しないように構成します。

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

全週のスキーム

週単位のスキームを選択した場合は、常に使用可能にするエージェントの数を指定できます。

全週のスキームを示すスクリーンショット。

自動

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

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

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

エージェントのライフサイクルと割り当ての潜在的な遅延

ステートレス スキームを使用してスタンバイ エージェントを有効にする場合は、準備完了状態から割り当て済み状態に移行してパイプラインを実行する前に、Azure Pipelines エージェントをインストールして構成する必要があります。

Managed DevOps Pools は、新しいエージェントをプロビジョニングするときに、準備完了状態に移行する前にスタンバイ エージェントに既にダウンロードされるように、最新の Azure Pipelines エージェントのダウンロードを試みます。 ジョブの起動、接続、開始には、プールの SKU 速度、使用されるイメージ、ネットワークの負荷に応じて、10 秒から 1 分かかります。 さらに、パイプライン ジョブで特定の設定を指定すると、別のエージェントの再ダウンロードと実行が発生する可能性があります。 エージェントの回帰とロールバックによって、エージェントの再ダウンロードが発生する可能性もあります。

常に開始可能なエージェント は常に遅延が発生する可能性があるのは、マネージド DevOps プールがこのエージェントをエフェメラルな方法で使用するためです。つまり、タスクエージェントはジョブごとに1回起動して実行されます。 準備完了エージェントが Azure DevOps からジョブを取得する際に遅延が発生する場合は、次の質問を検討してください。

  • エージェントの準備は完了していますか? 最も一般的な問題は、エージェントを事前にプロビジョニングする必要がある場合の誤解です。 次の条件が満たされた場合は、マシンをゼロからスピンアップする必要があります。
    • キューに入っているジョブの数が、プールのスタンバイエージェントの数を上回っています。
    • ジョブは、事前プロビジョニング スケジュール外にキューに入れられます。
    • スタンバイ エージェントの数が空に設定されています。
  • 複数のイメージを持つスタンバイ エージェントを適切に構成していますか? ImageOverride 要求を使用してパイプラインで使用するイメージを指定しない場合、ジョブは最初のイメージを対象とします。 スケーリングの設定によっては、他のイメージに割り当てられているエージェントがあるため、予想どおりの数のエージェントが使用できない場合があります。
  • パイプラインでImageVersionOverrideの需要を利用していますか? ImageVersionOverride要求を使用してプール設定で構成されているものとは異なるイメージ バージョンを指定すると、各エージェントは、指定されたイメージ バージョンを使用してオンデマンドで開始されます。 スタンバイ エージェントは、 プールの構成で指定されたイメージ バージョンを使用してプロビジョニングされます。 ImageVersionOverrideを使用すると、スタンバイ エージェントはそのバージョンと一致せず、新しいエージェントが起動します。
  • プロキシ、仮想ネットワーク、またはファイアウォールの設定によってプールの速度が低下していますか? ネットワーク設定が遅くなる可能性があるため、エージェントの起動と Azure DevOps への接続に時間がかかります。
  • エージェントのバージョンをオーバーライドしていますか? 既定では、Managed DevOps プールは最新の Azure DevOps タスク エージェント バージョンで実行されます。 パイプライン YAML の設定 ( Agent.Version 需要など) と Azure DevOps 組織の設定により、パイプラインで古いバージョンのタスク エージェントを使用するように強制できます。これには、マシンの割り当て後に再ダウンロードが必要になります。