次の方法で共有

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 でクラスターに移動し、左側のナビゲーションで Diagnose を選択して問題を解決します AKS の [問題の診断と解決] を開きます。 Azure リソース要求の調整を検索して開きます。ここでは、一連の診断を含むレポートを取得できます。 これらの診断は、クラスターで Azure Resource Manager (ARM) またはリソース プロバイダー (RP) の要求レート調整 (429 応答) が発生したかどうか、および調整の発生元を示すことができます。 例えば次が挙げられます。

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

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

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

    • 自動スケーラーのスキャン間隔を長くして、クラスター オートスケーラーから仮想マシン スケール セットへの呼び出しの数を減らします。 この方法は、クラスター オートスケーラーが新しい仮想マシンに対して Azure コンピューティング リソース プロバイダー (CRP) を呼び出す前に待機する時間が長くなるため、スケールアップにかかる時間に悪影響を及ぼす可能性があります。
    • クラスターが最小 Kubernetes バージョン 1.18 上にあることを確認します。 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 Diagnose および Solve Issues>Known Issues, Availability and Performance>Azure Resource Request Throttling で Cluster Auto-Scaler Throttling が検出された場合はクラスター オートスケーラーによって発行された要求が調整されたことを示します。

クラスターオートスケーラー要求の調整が検出されたことを示す図。

調整された要求の数と、要求が調整されるタイミングは、 Throttling - Azure Resource Manager 診断で確認できます。

クラスター オートスケーラー要求が調整されるタイミングを示す図。

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

すべての ARM 要求の図。

要求レートとスロットルの詳細診断を確認して、調整の詳細を見つけることができます。 選択フィルタードロップダウン リストから 429s by User Agent を選択すると、自動スケーラー要求が 15:00 から 16:00 に調整されていることがわかります。

ユーザー エージェント別のスロットルの図。

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

ユーザー エージェント別のスロットルの合計を示す図。

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

操作ごとのスロットルの図。

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

操作ごとのスロットルの合計を示す図。

次に、 Recommended Action の提案に従ってスロットルを減らすことができます。

クラスターオートスケーラー要求の調整が検出されたことを示す図。

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

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

クラスターで調整が見つかると、 View 要求レートとスロットルの詳細 診断で調整の詳細を確認できます。 選択フィルタードロップダウン リストからユーザー エージェントによって 429s を選択すると、クラウド プロバイダーの要求が 03:00 から 06:00 に調整されたことがわかります。

調整が検出されたことを示す図。

ユーザー エージェント別のスロットルの図。

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

操作別のスロットルの図。

このスロットルを減らすには、AKS プレビュー機能 Node IP ベースのロード バランサー を使用できます。

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

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