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 DTUs
- コンピューティング消費量の指標としてのアプリケーション層およびジョブエージェントのCPU、メモリ、I/O
- ストレージ使用量の測定値としての Azure Storage 帯域幅
現時点では、TSTU は主に Azure SQL Database DTU に焦点を当てています。これは、Azure SQL Database は、過剰な消費によって最も一般的に圧倒される共有リソースであるためです。 1 つの TSTU は、Azure DevOps の一般的なユーザーが 5 分ごとに生成することが予想される平均負荷です。 一般的なユーザーは、負荷の急増も発生します。 これらのスパイクは通常、5 分間に 10 TSTU 以下です。 頻度は低いですが、スパイクは 100 TSTU まで上昇します。
グローバル消費制限は、5 分間のスライディング ウィンドウ内で 200 TSTU です。
少なくとも Retry-After ヘッダーに応答することをお勧めします。 応答で Retry-After ヘッダーを検出した場合は、しばらく待ってから別の要求を送信します。 これにより、クライアント アプリケーションの強制遅延が少なくなります。 応答は 200 であるため、要求に再試行ロジックを適用する必要はありません。
可能であれば、 X-RateLimit-Remaining ヘッダーと X-RateLimit-Limit ヘッダーを監視することをお勧めします。 これにより、遅延しきい値に近づいている時間を概算できます。 クライアントは、時間の経過と同時にインテリジェントに対応し、要求を分散させることができます。
注
Azure DevOps と統合するためにツールやアプリケーションによって使用される ID では、許容される消費制限を超える高いレートと使用制限が必要になる場合があります。 Basic + Test Plans アクセス レベルをアプリケーションで使用される目的の ID に割り当てることで、これらの制限を引き上げることができます。 より高いレート制限の必要性が満たされたら、以前のアクセス レベルに戻すことができます。 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-After
RFC 6585 で指定されたヘッダーは、次のリクエストを送信する前に、検知しきい値を超えないようにするためにどれくらい待つべきかを示します。 単位: 秒。
X-RateLimit-Resource
到達したサービスとしきい値の種類を示すカスタム ヘッダー。 しきい値の種類とサービス名は、時間の経過と同時に、警告なしに異なる場合があります。 この文字列は人間に表示することをお勧めしますが、計算には依存しません。
X-RateLimit-Delay
要求が遅延した時間。 単位: 小数点以下 3 桁までの秒 (ミリ秒)。
X-RateLimit-Limit
遅延が課される前に許可される TSTU の合計数。
X-RateLimit-Remaining
遅延する前の残りの TSTU の数。 要求が既に遅延またはブロックされている場合は、0 です。
X-RateLimit-Reset
すべてのリソース消費が直ちに停止した場合、追跡された使用状況は 0 TSTU に戻ります。 Unix エポック時間で表されます。
作業の追跡、プロセス、 & プロジェクトの制限
Azure DevOps では、組織内で使用できるプロジェクトの数と、各プロジェクト内で使用できるチームの数に制限が課されます。 また、作業項目、クエリ、バックログ、ボード、ダッシュボードなどの制限にも注意してください。 詳細については、「 作業の追跡、プロセス、およびプロジェクトの制限」を参照してください。
ウィキ
通常の リポジトリの制限に加えて、プロジェクトに定義されている Wiki は、1 つのファイルあたり 25 MB に制限されます。
サービス接続
サービス接続の作成にプロジェクトごとの制限はありません。 ただし、Microsoft Entra ID によって適用される制限がある場合があります。 詳細については、次の記事を参照してください。