料金と使用制限
Azure DevOps Services
Azure DevOps Services では、マルチテナントを使用してコストを削減し、パフォーマンスを向上させます。 この設計により、ユーザーは、共有リソースの他のユーザーの消費が急増した場合に、パフォーマンスの問題や停止に対して脆弱になります。 そのため、Azure DevOps では、個人が使用できるリソースと、特定のコマンドに対して行うことができる要求の量が制限されます。 これらの制限を超えると、今後の要求が遅延またはブロックされる可能性があります。
詳細については、 レート制限に達しないようにするための Git の 制限と ベスト プラクティスに関するページを参照してください。
グローバル消費制限
現在、Azure DevOps にはグローバル消費制限があり、共有リソースが圧倒される危険性がある場合に、個々のユーザーからの要求がしきい値を超えて遅延します。 この制限は、共有リソースが圧倒されそうになったときの停止を回避することに専念しています。 通常、個々のユーザーは、次のいずれかのインシデントが発生した場合にのみ、遅延要求を受け取ります。
- 共有リソースの 1 つは、圧倒されるリスクがあります
- 個人の使用は、(スライディング) 5 分の期間内の一般的なユーザーの消費量の 200 倍を超えています
遅延の量は、ユーザーの持続的な消費レベルによって異なります。 遅延の範囲は、要求ごとに数ミリ秒から最大 30 秒です。 消費がゼロになったり、リソースが過剰に消費されなくなったりすると、遅延は 5 分以内に停止します。 使用量が再メイン高い場合、リソースを保護するために遅延が無期限に続く可能性があります。
ユーザー要求が大幅に遅れると、そのユーザーは Web で電子メールと警告バナーを受け取ります。 メール アドレスのないビルド サービス アカウントおよびその他のユーザーの場合、Project Collection 管理istrators グループのメンバーは電子メールを受け取ります。 詳細については、「使用量の監視」を参照してください。
個々のユーザーの要求がブロックされると、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 スループット ユニット (TSTU)
Azure DevOps ユーザーは多くの共有リソースを使用し、使用量は次の要因によって異なります。
- 多数のファイルをバージョン管理にアップロードすると、データベースとストレージ アカウントに大量の負荷が生まれます
- 複雑な作業項目追跡クエリは、検索する作業項目の数に基づいてデータベースの負荷を作成します
- バージョン管理からファイルをダウンロードし、ログ出力を生成してドライブの負荷をビルドする
- すべての操作は、サービスのさまざまな部分で CPU とメモリを消費します
これに対応するために、Azure DevOps リソースの消費量は、Azure DevOps スループット ユニット (TSTU) と呼ばれる抽象単位で表されます。 TSTU には、最終的に次の項目のブレンドが組み込まれます。
- データベース使用量のメジャーとしての Azure SQL Database DTU
- コンピューティング消費量のメジャーとしてのアプリケーション層とジョブ エージェントの CPU、メモリ、および I/O
- ストレージ使用量の測定値としての Azure Storage 帯域幅
現時点では、TSTU は主に Azure SQL Database DTU に焦点を当てています。これは、Azure SQL Database は、過剰な消費によって最も一般的に圧倒される共有リソースであるためです。 1 つの TSTU は、Azure DevOps の 1 人の通常ユーザーが 5 分あたりに生成することが予想される平均負荷です。 また、通常のユーザーは負荷の急増も発生します。 これらのスパイクは、通常、5 分あたり 10 個以下の TSTU です。 スパイクの頻度は 100 TSTU ほど高くなります。
グローバル消費制限は、スライディング 5 分間で 200 TSTU です。
少なくともヘッダーに Retry-After 応答することをお勧めします。 応答でヘッダーを検出した Retry-After 場合は、しばらく待ってから別の要求を送信します。 これにより、クライアント アプリケーションの強制遅延が少なくなります。 応答は 200 であるため、要求に再試行ロジックを適用する必要はありません。
可能であれば、監視 X-RateLimit-Remaining と X-RateLimit-Limit ヘッダーを使用することをお勧めします。 これにより、遅延しきい値に近づいている時間を概算できます。 クライアントは、時間の経過と同時にインテリジェントに対応し、要求を分散させることができます。
Note
Azure DevOps と統合するためにツールやアプリケーションによって使用される ID には、許可されている消費制限を超える高いレートと使用制限が必要になる場合があります。 Basic + Test Plans アクセス レベルをアプリケーションで使用する目的の ID に割り当てることで、追加のレートと使用制限を取得できます。 より高いレート制限の必要性が満たされたら、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
通常のリポジトリの制限に加えて、プロジェクトに定義されている Wiki は、1 つのファイルあたり 25 MB (メガバイト)に制限されます。
サービス接続
サービス接続の作成にプロジェクトごとの制限はありません。 ただし、Microsoft Entra ID によって適用される制限がある場合があります。 追加情報については、次の記事を参照してください。