429 要求エラーが多すぎます

この記事では、Microsoft Azure Kubernetes Service (AKS) クラスター (または Azure で別の Kubernetes 実装を使用するクラスター) で "429 要求が多すぎる" エラーが原因で発生したエラーのトラブルシューティング方法について説明します。

現象

次のテキストのようなエラーが表示されます。

サービスからエラーが返されました。

Status=429

Code="OperationNotAllowed"

Message="このサブスクリプションに対して受信した要求が多すぎるため、サーバーは要求を拒否しました。

Details=[{
"code":"TooManyRequests",
"message":"{
\"operationGroup\":\"HighCostGetVMScaleSet30Min\",
\"startTime\":\"2020-09-20T07:13:55.2177346+00:00\",
\"endTime\":\"2020-09-20T07:28:55.2177346+00:00\",
\"allowedRequestCount\":1800,
\"measuredRequestCount\":2208
}",
"target":"HighCostGetVMScaleSet30Min"
}]

InnerError={"internalErrorCode":"TooManyRequestsReceived"}"}

原因: 呼び出しボリュームが多すぎると、Azure がサブスクリプションを調整する

Azure 上の Kubernetes クラスター (AKS の有無にかかわらず) で、頻繁にスケールアップまたはスケール ダウンを行ったり、クラスター オートスケーラーを使用したりすると、大量の HTTP 呼び出しが発生する可能性があります。 この呼び出しボリュームは、Azure サブスクリプションに割り当てられたクォータを超えるため、エラーが発生する可能性があります。

これらのエラーの詳細については、「Azure Resource Manager 要求の調整」および「API 調整エラーのトラブルシューティング」を参照してください。 これらのエラーの原因を分析して特定し、それらを解決するための推奨事項を取得する方法については、「 AKS の診断と問題の解決を使用したエラーの分析と特定」を参照してください。

解決策 1: Kubernetes の新しいバージョンにアップグレードする

Kubernetes 1.18 を実行します。x 以降。 これらのバージョンには、「AKS 調整/429 エラー」および「調整なしで大規模なクラスターをサポートする」で説明されている多くの機能強化が含まれています。 ただし、(サブスクリプション内のクライアントの実際の負荷または数が原因で) 調整が引き続き発生する場合は、次の解決策を試すことができます。

解決策 2: 自動スケーラーのスキャン間隔を長くする

"クラスターオートスケーラーの調整が検出されました" という診断レポートがクラスター オートスケーラーによって発生した調整を報告する場合は、自動スケーラー スキャン間隔を増やして、クラスター オートスケーラーからの仮想マシン スケール セット (VMSS) への呼び出しの数を減らすことができます。

解決策 3: より少ない呼び出しを行うためにサード パーティ製アプリケーションを再構成する

"要求率とスロットルの詳細の表示" 診断でユーザー エージェントによってフィルター処理する場合、GET 要求の数が多すぎるサード パーティ製アプリケーション (監視アプリケーションなど) が見つかる場合は、GET 呼び出しの頻度を減らすためにこれらのアプリケーションの設定を変更します。 さらに、アプリケーション クライアントが Azure API を呼び出すときに指数バックオフを使用していることを確認します。

解決策 4: クラスターを異なるサブスクリプションまたはリージョンに分割する

仮想マシン スケール セットを使用する多数のクラスターとノード プールがある場合は、クラスターを異なるサブスクリプションまたはリージョン (同じサブスクリプション内) に分割してみてください。 ほとんどの Azure API の制限は、サブスクリプション リージョン レベルでの共有制限です。 たとえば、サブ 1 と米国東部リージョン内のすべてのクラスターとクライアントは、仮想マシン スケール セット GET API の制限を共有します。 そのため、新しいリージョンで新しい AKS クラスターを移動またはスケーリングし、Azure API の調整でブロックを解除できます。 この手法は、クラスターのアクティビティが高い (アクティブなクラスター オートスケーラーがある場合など) 場合に役立ちます。 また、多数のクライアント (Rancher、Terraform など) がある場合にも役立ちます。 すべてのクラスターは弾力性と Azure API をポーリングするクライアントの数が異なるため、サブスクリプション リージョン レベルごとに実行できるクラスターの数に関する一般的なガイドラインはありません。 具体的なガイダンスについては、サポート チケットを作成できます。

AKS の問題の診断と解決を使用してエラーを分析して特定する

AKS クラスターの場合は、 AKS の診断と問題の解決 を使用して、これらのエラーの原因を分析して特定し、それらを解決するための推奨事項を取得できます。 Azure portalでクラスターに移動し、左側のナビゲーションで [問題の診断と解決] を選択して、AKS の [問題の診断と解決] を開きます。 Azure リソース要求の調整をSearchして開きます。ここでは、一連の診断を含むレポートを取得できます。 これらの診断は、クラスターで Azure Resource Manager (ARM) またはリソース プロバイダー (RP) の要求レート調整 (429 応答) が発生したかどうか、および調整の発生元を示すことができます。 以下に例を示します。

• クラスターに対して要求レート調整が検出されました:この診断では、現在の AKS クラスターで調整が検出された場合に一般的な推奨事項が提供されます。

• クラスター自動スケーラーの調整が検出されました:この診断は、調整が検出され、クラスター オートスケーラーから発生した場合に表示されます。

  クラスター オートスケーラーからの要求の量を減らすには、次の方法を使用します。

  • 自動スケーラーのスキャン間隔を長くして、クラスター オートスケーラーから仮想マシン スケール セットへの呼び出しの数を減らします。 この方法は、クラスター の自動スケーラーが新しい仮想マシンに対して Azure Compute Resource Provider (CRP) を呼び出す前に待機時間が長くなるため、スケールアップにかかる時間に悪影響を及ぼす可能性があります。
  • クラスターが 1.18 の Kubernetes の最小バージョンにあることを確認します。 Kubernetes バージョン 1.18 以降のバージョンでは、429 の調整応答が受信されると、要求レートのバックオフが処理されます。 セキュリティ パッチを受け取るために、サポートされている Kubernetes バージョン内に留まることを強くお勧めします。

• 調整 - Azure Resource Manager: この診断では、AKS クラスター内の指定した時間範囲の調整された要求の数が表示されます。

• 要求レート - Azure Resource Manager: この診断では、AKS クラスター内の指定した時間範囲の要求の合計数が表示されます。

• 要求レートとスロットルの詳細を表示する: この診断には、調整された要求や合計要求など、調整の詳細を決定する複数の図があります。 次のディメンションを使用して結果をフィルター処理することもできます。

  • ホスト: HTTP 状態 429 応答が検出されたホスト。 Azure Resource Managerスロットルは、次のものからmanagement.azure.com取得されます。それ以外の場合は、下位層のリソース プロバイダーです。
  • ユーザー エージェント: 調整された指定されたユーザー エージェントを使用した要求。
  • 操作: HTTP 状態 429 応答が検出された操作。
  • クライアント IP: 調整された要求を送信したクライアント IP アドレス。

要求の調整は、このクラスターの要求率だけでなく、このサブスクリプション内の任意のクラスターの組み合わせによって発生する可能性があります。

例 1: クラスターの自動スケーラー調整

この例では、クラスター オートスケーラーによって発生する調整の分析について説明します。

AKS の診断と解決の問題>の既知の問題、可用性とパフォーマンス>の Azure リソース要求の調整でクラスター自動スケーラーの調整が検出された診断が検出された場合は、クラスター 自動スケーラーによって発行された要求が調整されたことを示します。

調整された要求の数と、要求が調整されたときは、調整 - Azure Resource Manager診断で確認できます。

すべての ARM 要求の数は、同じ期間内に確認できます。

[要求レートの表示] と [スロットルの詳細] 診断をチェックして、調整の詳細を見つけることができます。 [フィルターの選択] ドロップダウン リストから [ユーザー エージェント別 429s ] を選択 すると、自動スケーラー要求が 15:00 から 16:00 に調整されていることがわかります。

クラスター オートスケーラーとその他のユーザー エージェントに対する調整された要求の合計数も確認できます。

操作でスロットルをフィルター処理することもできます。 この場合、VMSS VM の削除操作は調整されます。

調整された要求の数と、操作別にグループ化されたすべての要求を確認できます。

次に、 推奨アクション の提案に従ってスロットルを減らすことができます。

例 2: クラウド プロバイダーの調整

この例では、クラウド プロバイダーによって発生するスロットルについて説明します。 多くの場合、大規模なクラスターでリソースを操作する場合 (たとえば、ノード数が 500 を超えるクラスター内のAzure Load Balancerをプロビジョニングする場合など) に発生します。

クラスターで調整が見つかると、[ 要求率の表示] と [スロットルの詳細 ] 診断に調整の詳細が表示されます。 [フィルターの選択] ドロップダウン リストから [429s by User Agent ] を選択 すると、クラウド プロバイダーの要求が 03:00 から 06:00 に調整されたことがわかります。

また、操作でフィルター処理して、調整された操作が "Network/loadBalancers/read" であることを確認することもできます。

AKS プレビュー機能 Node IP ベースのLoad Balancerを使用して、このスロットルを減らすことができます。

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

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