Azure Key Vault のスロットリング ガイドライン

調整は、リソースの過剰使用を防ぐために Azure サービスへの同時呼び出しの数を制限する、開始するプロセスです。 Azure Key Vault (AKV) は、大量の要求を処理するように設計されています。 要求の数が多い場合、クライアントの要求を調整すると、AKV サービスの最適なパフォーマンスと信頼性を維持するのに役立ちます。

シナリオに応じてスロットリング制限が異なります。 たとえば大量の書き込みを実行している場合、読み取りだけを実行している場合と比べて、スロットルの余地は大きくなります。

Key Vault では、その制限はどのように処理されますか?

Key Vault のサービス制限により、リソースの誤用が防止され、Key Vault のすべてのクライアントのサービス品質が確保されます。 サービスのしきい値を超えると、Key Vault はそのクライアントからのそれ以上の要求を制限し、HTTP 状態コード 429 (要求が多すぎます) を返し、要求は失敗します。 429 を返す失敗した要求は、Key Vault によって追跡されるスロットル制限にはカウントされません。

Key Vault はもともと、デプロイ時にシークレットを格納および取得するように設計されていました。 テクノロジが進化するにつれて、Key Vault は実行時にシークレットの格納と取得にますます使用されるようになりました。 多くのアプリケーションとサービスでは、データベースと同様に Key Vault が使用されます。 ただし、現在のサービスの制限は、このような高スループットシナリオをサポートするようには設計されていません。

Key Vault は、もともと Azure Key Vault サービスの制限で指定された制限を使用して作成されました。 Key Vault のスループットレートを最大化するために、スループットを最大化するための推奨ガイドライン/ベスト プラクティスを次に示します。

1. スロットリングが設定されていることを確認します。 クライアントは、429 に対してのエクスポネンシャル バックオフ ポリシーを遵守し、ガイダンスに従って再試行を行う必要があります。
2. Key Vault トラフィックを複数のボールトや異なるリージョンに分散します。 セキュリティ/可用性ドメインごとに個別のコンテナーを使用します。 2 つのリージョンにそれぞれ 5 つのアプリがある場合は、アプリとリージョンに固有のシークレットを含む 10 個のボールトを用意することをお勧めします。 すべてのトランザクションの種類に対するサブスクリプション全体の制限は、個々のキー コンテナーの制限の 5 倍です。 たとえば、サブスクリプションあたりの HSM 以外のトランザクションは、サブスクリプションあたり 10 秒で 5,000 トランザクションに制限されます。 サービスまたはアプリ内にシークレットをキャッシュして、キー コンテナーへの直接の RPS を減らしたり、バースト ベースのトラフィックに対処したりすることを検討してください。 また、さまざまなリージョン間でトラフィックを分割して待機時間を最小限に抑え、別のサブスクリプション/コンテナーを使用することもできます。 1 つの Azure リージョンの Key Vault サービスに対して、サブスクリプションの制限を超えて送信しないでください。
3. Azure Key Vault から取得したシークレットをメモリにキャッシュし、可能な限りメモリから再利用します。 キャッシュされたコピーが動作を停止した場合 (たとえば、ソースでローテーションされたため) にのみ、Azure Key Vault から再読み取りします。
4. Key Vault は、独自のサービス シークレット用に設計されています。 顧客のシークレット (特に高スループットのキー ストレージ シナリオの場合) を格納する場合は、暗号化を使用してデータベースまたはストレージ アカウントにキーを配置し、主キーのみを Azure Key Vault に格納することを検討してください。
5. 暗号化、ラップ、検証などの公開キー操作の場合は、公開キーマテリアルをキャッシュして Key Vault にアクセスせずにローカルでこれらの操作を実行します。 この方法により、調整のリスクが軽減されるだけでなく、アプリケーションの信頼性も向上します。
6. Key Vault を使用してサービスの資格情報を格納する場合は、そのサービスが直接認証するための Microsoft Entra 認証をサポートしているかどうかを確認します。 これにより、Key Vault の負荷が軽減され、信頼性が向上し、Key Vault で Microsoft Entra トークンを使用できるようになったため、コードが簡略化されます。 多くのサービスで Microsoft Entra 認証が使用されるようになりました。 Azure リソースのマネージド ID をサポートするサービスの現在の一覧を参照してください。
7. 現在の RPS 制限の下に留まるには、より長い期間にわたって負荷/デプロイを調整することを検討してください。
8. アプリが 1 つ以上の同じシークレットを読み取る必要がある複数のノードで構成されている場合は、ファンアウト パターンを使用することを検討してください。このパターンでは、1 つのエンティティが Key Vault からシークレットを読み取り、すべてのノードにファンアウトします。 取得したシークレットをメモリ内にのみキャッシュします。

サービスの制限に応じてアプリを調整する方法

サービスが調整されたときに実装する必要がある ベスト プラクティス を次に示します。

• 要求あたりの操作の数を減らす。
• 要求の頻度を減らします。
• 即時再試行は避けてください。
  • すべての要求は、使用制限に対して発生します。

アプリのエラー処理を実装するときは、HTTP エラー コード 429 を使用して、クライアント側の調整の必要性を検出します。 HTTP 429 エラー コードで要求が再度失敗した場合でも、Azure サービスの制限が発生しています。 推奨されるクライアント側の調整方法を引き続き使用し、成功するまで要求を再試行します。

指数バックオフを実装するコードを次に示します。

SecretClientOptions options = new SecretClientOptions()
    {
        Retry =
        {
            Delay= TimeSpan.FromSeconds(2),
            MaxDelay = TimeSpan.FromSeconds(16),
            MaxRetries = 5,
            Mode = RetryMode.Exponential
         }
    };
    var client = new SecretClient(new Uri("https://keyVaultName.vault.azure.net"), new DefaultAzureCredential(),options);
                                 
    //Retrieve Secret
    secret = client.GetSecret(secretName);

クライアント C# アプリケーションでこのコードを使用するのは簡単です。

推奨されるクライアント側スロットリング方法

HTTP エラー コード 429 が発生したら、次のように指数関数的バックオフ手法を使ってクライアントのスロットルを開始します。

1. 1 秒待って要求を再試行
2. 引き続きスロットルされる場合は 2 秒待って要求を再試行
3. 引き続きスロットルされる場合は 4 秒待って要求を再試行
4. 引き続きスロットルされる場合は 8 秒待って要求を再試行
5. 引き続きスロットルされる場合は 16 秒待って要求を再試行

通常は、この時点で HTTP 429 応答コードは発生しなくなります。

こちらもご覧ください

Microsoft Cloud での調整のより深い方向については、「 調整パターン」を参照してください。