次の方法で共有


レートと使用量の制限

Azure DevOps Services

Azure DevOps Services では、マルチテナントを使用してコストを削減し、パフォーマンスを向上させます。 この設計により、共有リソースの他のユーザーの消費が急増した場合に、パフォーマンスの問題や停止が発生する可能性があります。 これを防ぐために、Azure DevOps では、各ユーザーが使用できるリソースと、特定のコマンドに対して行うことができる要求の数が制限されます。 これらの制限を超えると、今後の要求が遅延またはブロックされる可能性があります。

レート制限に達しないようにするためのGit の制限とベスト プラクティスの詳細について説明します。

グローバル消費制限

Azure DevOps には、共有リソースが圧倒されるリスクがある場合に個々のユーザーからの要求を遅延するグローバル消費制限があります。 この制限は、共有リソースが過剰な負荷に近い場合の停止を回避するのに役立ちます。 個々のユーザーは、通常、次のいずれかのインシデントが発生した場合にのみ、要求の遅延が発生します。

  • 共有リソースの 1 つは、圧倒されるリスクがあります。
  • 彼らの個人使用は、一般的なユーザーが5分間に消費する量の200倍を超えています。

遅延は、ユーザーの持続的な消費レベルによって異なります。 遅延の範囲は、要求ごとに数ミリ秒から最大 30 秒です。 消費がゼロに低下するか、リソースが過剰に消費されない場合、遅延は 5 分以内に停止します。 消費が高いままの場合、リソースを保護するために遅延が無期限に続く可能性があります。

ユーザー要求が大幅に遅れると、ユーザーは Web で電子メールと警告バナーを受け取ります。 メール アドレスのないビルド サービス アカウントおよびその他のユーザーの場合、Project Collection Administrators グループのメンバーは電子メールを受信します。 詳細については、「使用量の監視」を参照してください。

個々のユーザーの要求がブロックされると、ユーザーは HTTP コード 429 (要求が多すぎます) と次のようなメッセージを含む応答を受け取ります。

TF400733: The request has been canceled: Request was blocked due to exceeding usage of resource <resource name> in namespace <namespace ID>.

Azure DevOps スループット ユニット

Azure DevOps ユーザーは多くの共有リソースを使用し、消費レベルは次のような要因によって異なります。

  • 多数のファイルをバージョン管理にアップロードすると、データベースとストレージ アカウントに負荷がかけられます。
  • 複雑な作業項目クエリを実行すると、検索する作業項目の数に基づいてデータベースの負荷が増加します。
  • ビルドの実行。バージョン管理からファイルをダウンロードし、ログ出力を生成します。
  • サービスのさまざまな部分で CPU とメモリを消費する一般的な操作。

このアクティビティを測定するために、Azure DevOps は Azure DevOps スループット ユニット (TSTU) でリソース消費量を表します。 TSTU は、次のようなさまざまなリソースのブレンドを表す負荷の抽象単位です。

  • データベースの使用状況:主に Azure SQL Database DTU を使用して測定されます。
  • コンピューティング使用量 : アプリケーション層とジョブ エージェントからの CPU、メモリ、I/O。
  • ストレージの使用量 - Azure Storage の帯域幅。

TSTU は意図的に抽象的です。 分散インフラストラクチャ内のコンピューティング、ストレージ、およびデータベース レイヤー全体のリソース消費量を集計します。 基になるメトリック (CPU、メモリ、I/O、DTU) は、単独で直接公開されたり意味を持ったりすることはありません。 TSTU は、負荷を表す統一された方法を提供し、個々のリソース コンポーネントの完全な複雑さを公開することなく、使用状況の管理と監視を容易にします。 数式を使用してアクションの TSTU の使用量を計算することはできませんが、 使用状況の監視 ページで操作が消費する TSTU の数を確認できます。 作業項目クエリなどの一部の操作は、組織の成長や変化に応じて消費量が異なるため、正確な状態を保つには定期的にベンチマークが必要になる場合があります。

現在、TSTU は主に Azure SQL Database DTU に焦点を当てています。データベースは、過剰な消費に圧倒される可能性が最も高い共有リソースであるためです。

  • 1 つの TSTU は、一般的な Azure DevOps ユーザーが 5 分間にわたって生成した平均負荷を表します。
  • 通常のユーザー アクティビティでは、5 分あたり 10 TSTU 以下のスパイクが発生する可能性があります。
  • スパイクが大きくなるが頻度は低いと、最大 100 TSTU に達する可能性があります。
  • グローバル制限は、どの5分間のスライド期間内でも200 TSTUです。

ベスト プラクティス

  • Retry-After ヘッダーを優先します。応答で受信した場合は、指定した時間待ってから別の要求を送信します。 応答は引き続き HTTP 200 を返すので、再試行ロジックは必要ありません。
  • X-RateLimit ヘッダーを監視する: 使用可能な場合は、 X-RateLimit-RemainingX-RateLimit-Limit を追跡して、しきい値に近づいている速度を概算します。 これにより、クライアントは要求のバーストをスムーズにし、強制遅延を回避できます。

Azure DevOps と統合するためにツールやアプリケーションによって使用される ID では、許容される消費制限を超える高いレートと使用制限が必要な場合があります。 アプリケーションで使用する ID に Basic + Test Plans アクセス レベルを割り当てることで、これらの制限を引き上げます。 より高いレート制限が不要になったら、以前のアクセス レベルに戻します。 Basic + Test Plans アクセス レベルの料金は、ID に割り当てられた期間に対してのみ課金されます。 Visual Studio Enterprise サブスクリプションが既に割り当てられている ID には、サブスクリプションを削除するまで Basic + Test Plans アクセス レベルを割り当てることはできません。

Pipelines

レート制限は、Azure Pipelines でも同じように機能します。 各パイプラインは個々のエンティティであり、そのリソース消費量は個別に追跡されます。 ビルド エージェントがセルフホステッドの場合でも、ログの複製と送信によって負荷が生成されます。

移動する5分間のウィンドウ内では、パイプラインごとに200 TSTUの制限があります。 この制限は、ユーザーのグローバル消費制限と一致します。 レート制限の遅延が発生した場合、またはパイプラインをブロックすると、添付ログにメッセージが表示されます。

API クライアント エクスペリエンス

要求が遅延またはブロックされると、Azure DevOps は応答ヘッダーを返して、API クライアントが対応できるようにします。 完全には標準化されていませんが、これらのヘッダーは 広く他の一般的なサービスに沿います

次の表に、使用可能なヘッダーとその意味を示します。 X-RateLimit-Delayを除き、これらのヘッダーはすべて、要求が遅延を開始する前に送信されます。 この設計により、クライアントは要求の速度を事前に遅くすることができます。

ヘッダー名

説明


'Retry- しきい値に達したサービスと種類を示すカスタム ヘッダー。 しきい値の種類とサービス名は、時間の経過と同時に、警告なしに変化する可能性があります。 この文字列を人間に表示しますが、計算には依存しません。


X-RateLimit-Delay

要求が遅延する時間。 単位: 小数点以下 3 桁までの秒 (ミリ秒)。


X-RateLimit-Limit

遅延が課される前に許可される TSTU の合計数。


X-RateLimit-Remaining

遅延が開始されるまでに残っている TSTU の数。 要求が既に遅延またはブロックされている場合は 0 です。


X-RateLimit-Reset

すべてのリソース消費が直ちに停止した場合、追跡された使用状況が 0 TSTU に戻る時間。 Unix エポック時間で表されます。


作業の追跡、プロセス、 & プロジェクトの制限

Azure DevOps では、組織内に含めることができるプロジェクトの数と、各プロジェクトに含めることができるチームの数が制限されます。 作業項目、クエリ、バックログ、ボード、ダッシュボードなどの制限もあります。 詳細については、「 作業の追跡、プロセス、およびプロジェクトの制限」を参照してください。

ウィキ

通常の リポジトリの制限に加えて、プロジェクト内の Wiki ファイルは最大 25 MB にすることができます。

サービス接続

サービス接続の作成には、プロジェクトごとの制限はありません。 ただし、Microsoft Entra ID によって制限が課される場合があります。 詳細については、次の記事を参照してください。