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

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

リージョンごとのスロットリングとトークン バケット アルゴリズム

Microsoft は、2024 年の時点で、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 に移行する方法」を参照してください。

制限されたリクエストをどのように確認できますか？

調整された要求とその他の Resource Manager メトリックを表示するには、「 Azure Resource Manager メトリックへのアクセス」を参照してください。

なぜインスタンスごとではなくリージョンごとにスロットリングが行われるのですか?

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

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

送信できる要求数も増加します。 書き込み要求は 30 倍に増加します。 削除要求は 2.4 倍に増加します。 読み取り要求は 7.5 倍に増加します。

バックグラウンド ジョブの調整

Azure Resource Manager (ARM) のバックグラウンド ジョブは、リソースのデプロイ、診断、システムメンテナンスなどの操作をサポートするためにバックグラウンドで実行される自動化されたタスクです。 これらのジョブは、ユーザー要求の処理とサービス機能の確保に不可欠です。 プラットフォームの安定性と信頼性を維持するために、ARM ではバックグラウンド ジョブ調整を使用して、これらのタスクからの負荷を管理します。

次のエラー メッセージが表示された場合、バックグラウンド ジョブの調整が発生するタイミングを特定できます。

The request for subscription '{0}' could not be processed due to an excessive volume of traffic. Please try again later.

お客様は、高頻度の操作またはシステム全体のアクティビティによってトリガーされる可能性がある過剰なバックグラウンド ジョブが原因で調整が発生する可能性があります。 お客様はこれらのタスクの作成または実行を直接制御することはできませんが、潜在的な制限についての理解は重要です。

非パブリック クラウドの調整

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

要求は最初に、プリンシパル ID ごと、および要求を送信するユーザーのリージョン内の Azure Resource Manager インスタンスごとに調整されます。 リージョン内の Azure Resource Manager インスタンスへの要求も、プリンシパル ユーザー ID と 1 時間ごとに調整されます。 リソース プロバイダーに転送された要求は、ユーザーのリージョン内の Azure Resource Manager インスタンスごとではなく、リソースのリージョンごとに調整されます。

次の図は、要求がユーザーから Azure Resource Manager とリソース プロバイダーに送信されるときに調整がどのように適用されるかを示しています。

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

サブスクリプションレベルとテナントレベルのすべての操作には、調整制限が適用されます。 サブスクリプション要求 (サブスクリプション内のリソース グループの取得など) では、サブスクリプション 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 にスコープされます。 複数のセキュリティ プリンシパルから要求が発信されると、サブスクリプションまたはテナント全体の制限数は 12,000 件を超え、一時間あたり 1,200 件におよびます。

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

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

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

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

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

ストレージの調整

次の制限は、Azure Storage およびストレージ リソース プロバイダーで Azure Resource Manager を使用して管理操作を実行する場合にのみ適用されます。 この制限は、要求内のリソースの各リージョンのサブスクリプションごとに適用されます。

ネットワーク制限

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

これら以外の一般的な制限については、「Azure DNS の使用量の制限」を参照してください。

コンピューティング調整

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

Azure Resource Graph の調整

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

Azure Resource Graph には、既存の Azure Resource Manager コントロール プレーン GET および LIST API とシームレスに統合することで、リソース プロバイダーの調整制限に達したときにリソース データを取得するための追加のメカニズムを有効にするソリューションもあります。これにより、リソース データ アクセスのための強力でスケーラブルなソリューションが提供されます。 詳細については、「 ARG GET/LIST API」を参照してください。

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

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

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

エラー コード

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

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

一部のリソース プロバイダーでは、一時的な問題を報告するために 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 の完全な例については、「特定のサブスクリプションの ARM 制限を確認する」を参照してください。

デバッグのために残りの要求数を確認するには、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 要求の処理の詳細については、「非同期の Azure 操作の追跡」を参照してください。