API の調整エラーのトラブルシューティング

[アーティクル]
04/18/2024

Azure コンピューティング要求は、サービスの全体的なパフォーマンスを向上させるために、サブスクリプションとリージョンベースで調整される場合があります。 Microsoft.Compute 名前空間でリソースを管理する Azure コンピューティングリソースプロバイダー (CRP) に対するすべての呼び出しは、許容されている最大の API 要求レートを超えないことが保証されています。このドキュメントでは、API の調整、調整に関する問題をトラブルシューティングする方法の詳細、および調整を回避するためのベストプラクティスについて説明します。

Azure Resource Manager による調整とリソースプロバイダーによる調整

Azure への入口として、Azure Resource Manager は、認証と最初の検証を行って、すべての受信 API 要求を調整します。 Azure Resource Manager の呼び出しレート制限と、関連する診断応答 HTTP ヘッダーについてはこちらを参照してください。

Azure API クライアントで調整エラーが取得された場合、HTTP ステータスは "429 要求が多すぎます" になります。要求の調整が Azure Resource Manager に行われているか CRP などの基になるリソースプロバイダーによって行われているかを判断するには、GET 要求の x-ms-ratelimit-remaining-subscription-reads と GET 以外の要求の x-ms-ratelimit-remaining-subscription-writes 応答ヘッダーを調べます。残りの呼び出し回数が 0 に近づいていれば、Azure Resource Manager によって定義されているサブスクリプションの一般的な呼び出し制限に達しています。すべてのサブスクリプションクライアントによるアクティビティがまとめてカウントされます。それ以外の場合、調整はターゲットリソースプロバイダー (要求 URL の /providers/<RP> セグメントによってアドレス指定されているもの) によって行なわれています。

呼び出しレートの情報提供応答ヘッダー

ヘッダー	値の書式	例	説明
x-ms-ratelimit-remaining-resource	`<source RP>/<policy or bucket>;<count>`	Microsoft.Compute/HighCostGet;159	この要求のターゲットを含むリソースバケットまたは操作グループを対象とする調整ポリシーの残りの API 呼び出し数
x-ms-request-charge	`<count>`	1	適用可能なポリシーの制限でのこの HTTP 要求に対して "課金" される呼び出しカウントの数。これは、ほとんどの場合 1 になります。バッチ要求 (仮想マシンスケールセットのスケーリングなど) では、複数のカウントが課金される可能性があります。

API 要求は複数の調整ポリシーの対象になる可能性があることに注意してください。ポリシーごとに個別の x-ms-ratelimit-remaining-resource ヘッダーが存在します。

仮想マシンスケールセット要求の削除に対する応答の例を次に示します。

x-ms-ratelimit-remaining-resource: Microsoft.Compute/DeleteVMScaleSet;107 
x-ms-ratelimit-remaining-resource: Microsoft.Compute/DeleteVMScaleSet;587 
x-ms-ratelimit-remaining-resource: Microsoft.Compute/VMScaleSetBatchedVMRequests;3704 
x-ms-ratelimit-remaining-resource: Microsoft.Compute/VmssQueuedVMOperations;4720

調整エラーの詳細

HTTP ステータス 429 は、通常は呼び出しレートの制限に達したという理由で要求を拒否するために使用されます。コンピューティングリソースプロバイダーからの一般的な調整エラー応答は次の例のようになります (関係のあるヘッダーのみが示されています)。

HTTP/1.1 429 Too Many Requests
x-ms-ratelimit-remaining-resource: Microsoft.Compute/HighCostGet;0
Retry-After: 1200
Content-Type: application/json; charset=utf-8
{
  "code": "OperationNotAllowed",
  "message": "The server rejected the request because too many requests have been received for this subscription.",
  "details": [
    {
      "code": "TooManyRequests",
      "target": "HighCostGet",
      "message": "{\"operationGroup\":\"HighCostGet\",\"startTime\":\"2018-06-29T19:54:21.0914017+00:00\",\"endTime\":\"2018-06-29T20:14:21.0914017+00:00\",\"allowedRequestCount\":300,\"measuredRequestCount\":1238}"
    }
  ]
}

残りの呼び出し回数が 0 というポリシーは、調整エラーが返されるためのポリシーの 1 つです。ここでは、それは HighCostGetです。応答本文の全体的な形式は、一般的な Azure Resource Manager API エラー形式です (OData に準拠します)。メインのエラーコードである OperationNotAllowed は、コンピューティングリソースプロバイダーが (その他の種類のクライアントエラーと共に) 調整エラーを報告するために使用するものです。内部エラーのmessage プロパティには、シリアル化された JSON 構造体と調整違反の詳細が含まれています。

上に示したように、すべての調整エラーには、クライアントが要求を再試行する前に待機する必要がある最少秒数を指定する Retry-After ヘッダーが含まれています。

API 呼び出しレートと調整エラーアナライザー

プレビューバージョンのトラブルシューティング機能は、コンピューティングリソースプロバイダーの API に使用できます。これらの PowerShell コマンドレットは、操作ごとの時間間隔あたりの API 要求レートと操作グループ (ポリシー) ごとの調整違反に関する統計情報を提供します。

API 呼び出しの統計情報は、サブスクリプションのクライアントの動作に関する優れた洞察を提供でき、調整の原因となる呼び出しパターンを識別しやすくすることができます。

当面のアナライザーの制限は、(マネージドディスクのサポートで) ディスクとスナップショットのリソースの種類に対する要求がカウントされないことです。これは CRP の利用統計情報からデータを収集するため、ARM からの調整エラーの特定にも役立ちません。ただし、既に説明したように、それらは独特の ARM 応答ヘッダーに基づいて簡単に特定できます。

これらの PowerShell コマンドレットは REST サービス API を使用しています。これは、クライアントから簡単に直接呼び出すことができます (まだ正式にはサポートされていません)。 HTTP 要求の形式を確認するには、Fiddler での実行時に -Debug スイッチまたは snoop を指定してコマンドレットを実行します。

ベストプラクティス

Azure サービスの API エラーは、無条件に再試行したり即座に再試行したりしないでください。再試行できないエラーに遭遇したときにクライアントコードで一般的に発生するのは、急速な再試行ループに入ることです。再試行のせいで最終的にターゲットの操作グループで許可される読み出し制限に達することで、サブスクリプションの他のクライアントに影響が出ます。
大量の API の自動化では、ターゲットの操作グループで使用できる呼び出しカウントが下限のしきい値を下回った場合に、クライアント側でプロアクティブな自己調整を実装することを検討してください。
非同期操作を追跡する場合は、Retry-After ヘッダーのヒントに従ってください。
クライアントコードが特定の仮想マシンに関する情報を必要とする場合は、すべての VM をリソースグループまたはサブスクリプション全体に含めた後でクライアント側で必要な VM を選択する代わりに、特定の VM に対するクエリを直接実行します。
クライアントコードに特定の Azure の場所からの VM、ディスク、スナップショットが必要な場合は、すべてのサブスクリプション VM にクエリを実行してから、クライアント側: GET /subscriptions/<subId>/providers/Microsoft.Compute/locations/<location>/virtualMachines?api-version=2017-03-30 クエリで場所でフィルタリングして Compute リソースプロバイダーの地域エンドポイントを取得する代わりに、場所ベースの形式のクエリを使用します。
特定の VM または仮想マシンスケールセットで API リソースの作成または更新を実行する場合は、(provisioningState に基づく) リソース URL そのものをポーリングするよりも、返された非同期操作の完了を追跡するほうがはるかに効率が良くなります。

次の手順

Azure の他のサービスの再試行ガイダンスの詳細については、「特定のサービスの再試行ガイダンス」を参照してください。

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティサポートにお問い合わせください。 Azure フィードバックコミュニティに製品フィードバックを送信することもできます。

API の調整エラーのトラブルシューティング

Azure Resource Manager による調整とリソース プロバイダーによる調整

呼び出しレートの情報提供応答ヘッダー

調整エラーの詳細

API 呼び出しレートと調整エラー アナライザー

ベスト プラクティス