Azure Resource Manager が要求を調整する方法の概要

この記事では、Azure Resource Manager を使って要求を調整する方法について説明します。 制限に達する前に残っている要求の数を追跡する方法と、制限に達したときに対応する方法を示します。

調整は 2 つのレベルで行われます。 Azure Resource Manager を使って、サブスクリプションとテナントの要求を調整します。 要求がサブスクリプションとテナントの調整制限内に収まる場合、Resource Manager によって要求はリソース プロバイダーにルーティングされます。 リソース プロバイダーでは、その操作に合わせた調整制限が適用されます。

次の図は、要求がユーザーから Azure Resource Manager とリソース プロバイダーに送信されるときに調整がどのように適用されるかを示しています。 この図は、要求が最初にプリンシパル ID ごと、および要求を送信するユーザーのリージョン内の Azure Resource Manager インスタンスごとに調整されることを示しています。 要求は 1 時間ごとに調整されます。 要求は、リソース プロバイダーに転送されると、ユーザーのリージョン内の Azure Resource Manager インスタンスごとではなく、リソースのリージョンごとに調整されます。 また、リソース プロバイダーの要求は、プリンシパル ユーザー ID ごと、および 1 時間ごとに調整されます。

サブスクリプションとテナントの制限

すべてのサブスクリプションレベルとテナントレベルの操作には、調整制限が適用されます。 サブスクリプション要求 (サブスクリプション内のリソース グループの取得など) では、サブスクリプション ID を渡す必要があります。 たとえば、https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups?api-version=2022-01-01 への要求の送信はサブスクリプション レベルの操作です。 テナント要求 (有効な Azure の場所の取得など) には、サブスクリプション ID は含まれません。 たとえば、https://management.azure.com/tenants?api-version=2022-01-01 への要求の送信はテナント レベルの操作です。

次の表は、1 時間あたりの既定の調整制限を示しています。

これらの制限は、要求を行うセキュリティ プリンシパル (ユーザーまたはアプリケーション) と、サブスクリプション ID またはテナント ID の範囲に設定されます。 複数のセキュリティ プリンシパルから要求が発信されると、サブスクリプションまたはテナント全体の制限は、1 時間あたり 12,000 件および 1,200 件を超えます。

これらの制限は、各 Azure Resource Manager インスタンスに適用されます。 すべての Azure リージョンに複数のインスタンスがあり、Azure Resource Manager はすべての Azure リージョンにデプロイされます。 したがって、実際の制限はこれらの制限よりも高くなります。 通常、ユーザーからの要求は、Azure Resource Manager の異なるインスタンスによって処理されます。

残りの要求は、応答ヘッダー値で返されます。

リージョン調整とトークン バケット アルゴリズムへの移行

2024 年から、Microsoft は Azure サブスクリプションを新しい調整アーキテクチャに移行します。 この変更により、新しい調整制限が適用されます。 新しい調整制限は、Azure Resource Manager のインスタンスごとではなく、リージョンごとに適用されます。 新しいアーキテクチャでは、トークン バケット アルゴリズムを使って API 調整を管理します。

トークン バケットは、1 秒あたりに送信できる要求の最大数を表します。 要求の最大数に達すると、リフィル レートによって、バケット内でトークンが使用可能になるまでの時間が決まります。

これらの更新された制限により、クォータの更新と管理が容易になります。

新しい制限は次のとおりです。

サブスクリプションの制限は、サブスクリプションごと、サービス プリンシパルごと、操作の種類ごとに適用されます。 また、操作の種類ごとに、個別のサービス プリンシパル制限の 15 倍に相当するグローバル サブスクリプション制限もあります。 グローバル制限はすべてのサービス プリンシパルに適用されます。 グローバル、サービス プリンシパル、またはテナント固有の制限を超えると、要求は調整されます。

無料または試用版のお客様の場合、制限はより小さくなる場合があります。

たとえば、読み取り要求用のバケット サイズが 250 トークンで、リフィル レートが 1 秒あたり 25 トークンであるとします。 1 秒間に 250 件の読み取り要求を送信すると、バケットは空になり、要求は調整されます。 バケットが最大容量の 250 トークンに達するまで、毎秒 25 個のトークンが使用可能になります。 トークンが使用可能になったら、それを使用できます。

*/providers/microsoft.insights/metrics API を使用したメトリックの読み取りは、Azure Resource Manager トラフィック全体に大きく影響します (サブスクリプション調整イベントの一般的な原因です)。 この API を頻繁に使用する場合は、getBatch API に切り替えることをお勧めします。 1 つの REST 要求で複数のリソースにクエリを実行できるため、パフォーマンスが向上し、調整が減少します。 操作の変換の詳細については、「メトリック API から getBatch API に移行する方法」を参照してください。

自分のサブスクリプションが新しい調整エクスペリエンスを使っているかどうかを確認するにはどうすればよいですか?

サブスクリプションが新しい調整エクスペリエンスに移行されると、応答ヘッダーには、1 時間あたりではなく 1 分あたりの残りの要求が表示されます。 また、Retry-After 値には、5 分ではなく 1 分以下が表示されます。 詳細については、「エラー コード」を参照してください。

調整がインスタンスごとではなくリージョンごとに変更されるのはなぜですか?

リージョンごとに Resource Manager インスタンス数が異なるため、インスタンスごとに調整を行うと、一貫性のない調整のパフォーマンスになります。 リージョンごとに調整を行うと、調整が一貫して予測可能なものになります。

新しい調整エクスペリエンスは制限にどのように影響しますか?

より多くの要求を送信できます。 書き込み要求は 30 倍に増加します。 削除要求は 2.4 倍に増加します。 読み取り要求は 7.5 倍に増加します。

自分のサブスクリプションが新しい調整に移行されないようにすることはできますか?

いいえ。最終的にはすべてのサブスクリプションが移行されます。

リソース プロバイダーの制限

リソース プロバイダーでは、独自の調整制限が適用されます。 各サブスクリプション内では、リソース プロバイダーによって要求内のリソースのリージョンごとに調整されます。 Resource Manager は、Resource Manager のインスタンスごとに調整し、各リージョンには Resource Manager の複数のインスタンスがあるため、リソース プロバイダーは前のセクションの既定の制限よりも多くの要求を受け取る場合があります。

このセクションでは、広く使用されているいくつかのリソース プロバイダーの調整制限について説明します。

ストレージの調整

次の制限は、Azure Resource Manager と Azure Storage を使用して管理操作を実行しているときにのみ適用されます。 この制限は、要求内のリソースのリージョンごとに適用されます。

Network throttling

Microsoft.Network リソース プロバイダーでは、次の調整制限が適用されます。

これらの一般的な制限以外については、Azure DNS の使用量の制限に関するセクションを参照してください。

コンピューティング調整

Microsoft Compute では、仮想マシンと仮想マシン スケール セットのユーザーに最適なエクスペリエンスを提供するために調整を実装します。 「Compute の調整の制限」では、VM、仮想マシン スケール セット、スケール セット VM の調整ポリシーと制限に関する包括的な情報が提供されています。

Azure Resource Graph の調整

Azure Resource Graph では、その操作に対する要求数が制限されます。 この記事内の、残りの要求数を確認する方法と、上限に達したときの対処方法の手順は、Resource Graph にも該当します。 ただし、Resource Graph は独自の制限とリセット レートを設定します。 詳細については、Resource Graph スロットル ヘッダーに関する記事をご覧ください。

他のリソース プロバイダー

他のリソース プロバイダーでの帯域幅調整の詳細については、以下を参照してください。

• Azure Key Vault のスロットル ガイダンス
• AKS のトラブルシューティング
• マネージド ID

エラー コード

上限に達すると、HTTP 状態コード 429 Too many requests が返されます。 応答には Retry-After 値が含まれます。これは、次の要求を送信する前にアプリケーションの待機 (またはスリープ) が必要な秒数を示します。 この再試行値が経過する前に要求を送信した場合、要求は処理されず、新しい再試行値が返されます。

Azure SDK を使用している場合は、SDK に自動再試行構成が含まれている可能性があります。 詳細については、「特定のサービスの再試行ガイダンス」を参照してください。

リソース プロバイダーによっては、一時的な問題を報告するために 429 を返します。 この問題は、要求が直接の原因ではないオーバーロード条件の可能性があります。 または、ターゲット リソースまたは依存リソースの状態に関する一時的なエラーを表す可能性があります。 たとえば、ターゲット リソースが別の操作によってロックされている場合、ネットワーク リソース プロバイダーからは RetryableErrorDueToAnotherOperation エラー コードと共に 429 が返されます。 調整と一時的な状態のどちらによるエラーかを判断するには、応答のエラーの詳細を確認します。

残りの要求数

残りの要求数を確認するには、応答ヘッダーを調べます。 読み取り要求では、残りの読み取り要求数の値がヘッダーに返されます。 書き込み要求には、残りの書き込み要求数の値が含まれます。 これらの値を確認できる応答ヘッダーを次の表に示します。

リソース プロバイダーからは、残りの要求に関する情報と共に応答ヘッダーが返されることもあります。 コンピューティング リソース プロバイダーから返される応答ヘッダーの詳細については、「呼び出しレートの情報提供応答ヘッダー」を参照してください。

ヘッダー値の取得

コードまたはスクリプトでこれらのヘッダー値を取得する方法は、任意のヘッダー値を取得する方法と変わりはありません。

たとえば、C# では、次のコードを使用して response という名前の HttpWebResponse オブジェクトからヘッダー値を取得します。

response.Headers.GetValues("x-ms-ratelimit-remaining-subscription-reads").GetValue(0)

PowerShell では、Invoke-WebRequest 操作からヘッダー値を取得します。

$r = Invoke-WebRequest -Uri https://management.azure.com/subscriptions/{guid}/resourcegroups?api-version=2016-09-01 -Method GET -Headers $authHeaders
$r.Headers["x-ms-ratelimit-remaining-subscription-reads"]

詳細な PowerShell の例については、サブスクリプションの Resource Manager の制限を確認する方法に関するページを参照してください。

デバッグのために残りの要求数を確認する場合は、PowerShell コマンドレットで -Debug パラメーターを指定します。

Get-AzResourceGroup -Debug

次の応答値を含む多くの値が返されます。

DEBUG: ============================ HTTP RESPONSE ============================

Status Code:
OK

Headers:
Pragma                        : no-cache
x-ms-ratelimit-remaining-subscription-reads: 11999

書き込み制限数を取得するには、書き込み操作を使用します。

New-AzResourceGroup -Name myresourcegroup -Location westus -Debug

次の値を含む多くの値が返されます。

DEBUG: ============================ HTTP RESPONSE ============================

Status Code:
Created

Headers:
Pragma                        : no-cache
x-ms-ratelimit-remaining-subscription-writes: 1199

Azure CLI では、より詳細なオプションを使用してヘッダー値を取得します。

az group list --verbose --debug

次の値を含む多くの値が返されます。

msrest.http_logger : Response status: 200
msrest.http_logger : Response headers:
msrest.http_logger :     'Cache-Control': 'no-cache'
msrest.http_logger :     'Pragma': 'no-cache'
msrest.http_logger :     'Content-Type': 'application/json; charset=utf-8'
msrest.http_logger :     'Content-Encoding': 'gzip'
msrest.http_logger :     'Expires': '-1'
msrest.http_logger :     'Vary': 'Accept-Encoding'
msrest.http_logger :     'x-ms-ratelimit-remaining-subscription-reads': '11998'

書き込み制限数を取得するには、書き込み操作を使用します。

az group create -n myresourcegroup --location westus --verbose --debug

次の値を含む多くの値が返されます。

msrest.http_logger : Response status: 201
msrest.http_logger : Response headers:
msrest.http_logger :     'Cache-Control': 'no-cache'
msrest.http_logger :     'Pragma': 'no-cache'
msrest.http_logger :     'Content-Length': '163'
msrest.http_logger :     'Content-Type': 'application/json; charset=utf-8'
msrest.http_logger :     'Expires': '-1'
msrest.http_logger :     'x-ms-ratelimit-remaining-subscription-writes': '1199'

次のステップ

• 制限とクォータの詳細については、「Azure サブスクリプションとサービスの制限、クォータ、制約」を参照してください。
• 非同期の REST 要求の処理の詳細については、「Track asynchronous Azure operations (非同期の Azure 操作の追跡)」を参照してください。