Azure Key Vault のスロットル ガイダンスAzure Key Vault throttling guidance

スロットルは、Azure サービスに対する同時呼び出し数を制限し、リソースの過剰使用を防止することを目的に開始されるプロセスです。Throttling is a process you initiate that limits the number of concurrent calls to the Azure service to prevent overuse of resources. Azure Key Vault (AKV) は、大量の要求を処理できるように設計されていますが、Azure Key Vault (AKV) is designed to handle a high volume of requests. 処理しきれない数の要求が発生した場合、クライアントの要求をスロットルすることで、AKV サービスのパフォーマンスと信頼性を最適な状態に保つことができます。If an overwhelming number of requests occurs, throttling your client's requests helps maintain optimal performance and reliability of the AKV service.

スロットルの制限は、シナリオによって異なります。Throttling limits vary based on the scenario. たとえば大量の書き込みを実行している場合、読み取りだけを実行している場合と比べて、スロットルの余地は大きくなります。For example, if you are performing a large volume of writes, the possibility for throttling is higher than if you are only performing reads.

Key Vault における制限の扱いHow does Key Vault handle its limits?

Key Vault のサービス制限は、リソースの乱用を防ぎ、Key Vault の全クライアントのサービス品質を確保します。Service limits in Key Vault prevent misuse of resources and ensure quality of service for all of Key Vault's clients. サービスのしきい値を超えた場合、Key Vault によってそのクライアントからの要求が一定期間制限され、HTTP 状態コード 429 (要求が多すぎます) が返され、要求は失敗します。When a service threshold is exceeded, Key Vault limits any further requests from that client for a period of time, returns HTTP status code 429 (Too many requests), and the request fails. 429 が返されて失敗した要求は、Key Vault によって追跡されているスロットル制限に加算されます。Failed requests that return a 429 count towards the throttle limits tracked by Key Vault.

Key Vault は本来、デプロイ時にシークレットを格納および取得するために使用するように設計されました。Key Vault was originally designed to be used to store and retrieve your secrets at deployment time. 世界が進化し、実行時にシークレットを格納および取得するために Key Vault が使用されています。そして多くの場合、アプリやサービスは Key Vault をデータベースのように使用することを希望しています。The world has evolved, and Key Vault is being used at run-time to store and retrieve secrets, and often apps and services want to use Key Vault like a database. 現在の制限は、高いスループット率をサポートしていません。Current limits do not support high throughput rates.

Key Vault は、最初は Azure Key Vault サービスの制限で指定された制限を使用して作成されました。Key Vault was originally created with the limits specified in Azure Key Vault service limits. Key Vault のスループット率を最大化するための、いくつかの推奨ガイドライン/ベスト プラクティスを次に示します。To maximize your Key Vault through put rates, here are some recommended guidelines/best practices for maximizing your throughput:

  1. スロットルが機能していることを確認します。Ensure you have throttling in place. クライアントは、429 に対してのエクスポネンシャル バックオフ ポリシーを遵守し、以下のガイダンスに従って再試行を行う必要があります。Client must honor exponential back-off policies for 429's and ensure you are doing retries as per the guidance below.
  2. Key Vault トラフィックを複数のコンテナーと異なるリージョンに分割します。Divide your Key Vault traffic amongst multiple vaults and different regions. セキュリティ/可用性ドメインごとに個別のコンテナーを使用します。Use a separate vault for each security/availability domain. 5 つのアプリが、2 つのリージョンのそれぞれにある場合は、アプリおよびリージョンに固有のシークレットを格納する 10 個のコンテナーを使用することをお勧めします。If you have five apps, each in two regions, then we recommend 10 vaults each containing the secrets unique to app and region. すべてのトランザクションの種類に適用されるサブスクリプション全体の制限は、個々のキー コンテナーの制限の 5 倍です。A subscription-wide limit for all transaction types is five times the individual key vault limit. たとえば、1 つのサブスクリプションで許可される HSM - その他のトランザクションの最大数は、10 秒間に 5,000 トランザクションです。For example, HSM-other transactions per subscription are limited to 5,000 transactions in 10 seconds per subscription. サービスまたはアプリ内にシークレットをキャッシュして、キー コンテナーへの直接の RPS を減らしたり、バースト ベースのトラフィックに対処したりすることを検討してください。Consider caching the secret within your service or app to also reduce the RPS directly to key vault and/or handle burst based traffic. また、トラフィックを異なるリージョンに分割して待機時間を最小限にしたり、別のサブスクリプション/コンテナーを使用したりすることもできます。You can also divide your traffic amongst different regions to minimize latency and use a different subscription/vault. 単一の Azure リージョンの Key Vault サービスには、サブスクリプションの制限を超えて送信しないでください。Do not send more than the subscription limit to the Key Vault service in a single Azure region.
  3. Azure Key Vault から取得したシークレットをメモリにキャッシュし、可能な限りメモリから再利用してください。Cache the secrets you retrieve from Azure Key Vault in memory, and reuse from memory whenever possible. キャッシュされたコピーが動作しなくなった場合 (たとえば、ソースでローテーションされたため) にだけ、Azure Key Vault から再度読み取りしてください。Re-read from Azure Key Vault only when the cached copy stops working (e.g. because it got rotated at the source).
  4. Key Vault は、自身のサービス シークレット向けに設計されています。Key Vault is designed for your own services secrets. 顧客のシークレットを格納する場合 (特に、高スループットの主要なストレージ シナリオの場合) は、データベースまたはストレージ アカウントに暗号化した状態でキーを配置し、マスター キーだけを Azure Key Vault に格納することを検討してください。If you are storing your customers' secrets (especially for high-throughput key storage scenarios), consider putting the keys in a database or storage account with encryption, and storing just the master key in Azure Key Vault.
  5. 公開キーの操作の暗号化、ラップおよび確認は、Key Vault にアクセスせずに実行できます。これにより、スロットルのリスクが軽減されるだけでなく、信頼性も向上します (公開キー マテリアルを適切にキャッシュしている場合)。Encrypt, wrap, and verify public-key operations can be performed with no access to Key Vault, which not only reduces risk of throttling, but also improves reliability (as long as you properly cache the public key material).
  6. サービスの資格情報を格納するために Key Vault を使用する場合は、直接認証するために、そのサービスが Azure AD Authentication をサポートしているかどうかを確認します。If you use Key Vault to store credentials for a service, check if that service supports Azure AD Authentication to authenticate directly. これにより、Key Vault は Azure AD トークンを使用できるようになるため、Key Vault の負荷が軽減され、信頼性が向上してコードが簡素化されます。This reduces the load on Key Vault, improves reliability and simplifies your code since Key Vault can now use the Azure AD token. 多くのサービスは、Azure AD 認証の使用に移行しました。「Azure リソースのマネージド ID をサポートするサービス」の現在の一覧を参照してください。Many services have moved to using Azure AD Auth. See the current list at Services that support managed identities for Azure resources.
  7. 現在の RPS 制限を維持するために、より長い期間にわたって負荷/デプロイを分散させることを検討してください。Consider staggering your load/deployment over a longer period of time to stay under the current RPS limits.
  8. アプリが同じシークレットを読み取る必要がある複数のノードで構成されている場合は、1 つのエンティティが Key Vault からシークレットを読み取ってすべてのノードに展開する、ファンアウト パターンを使用することを検討してください。If your app comprises multiple nodes that need to read the same secret(s), then consider using a fan out pattern, where one entity reads the secret from Key Vault, and fans out to all nodes. 取得したシークレットをメモリだけにキャッシュします。Cache the retrieved secrets only in memory. 上記の内容が依然としてニーズに合わない場合は、追加できる容量を決定するために以下の表に記入して、お問い合わせください (説明のみを目的として、以下に例を記載します)。If you find that the above still does not meet your needs, please fill out the below table and contact us to determine what additional capacity can be added (example put below for illustrative purposes only).
コンテナー名Vault name コンテナーのリージョンVault Region オブジェクトの種類 (シークレット、キー、または証明書)Object type (Secret, Key, or Cert) 操作*Operation(s)* キーの種類Key Type キーの長さまたは曲線Key Length or Curve HSM キーかどうか?HSM key? 安定状態の RPS が必要Steady state RPS needed 必要なピークの RPSPeak RPS needed
https://mykeyvault.vault.azure.net/ KeyKey 署名Sign ECEC P-256P-256 いいえNo 200200 10001000

* 使用可能な値の完全な一覧については、「Azure Key Vault の操作」を参照してください。* For a full list of possible values, see Azure Key Vault operations.

追加の容量が承認された場合は、容量が増加したため、次の点に注意してください。If additional capacity is approved, please note the following as result of the capacity increases:

  1. データ整合性モデルが変更になります。Data consistency model changes. 追加のスループット容量でコンテナーが許可されると、Key Vault サービスのデータの整合性が保証されます (基になる Azure Storage サービスが維持できなくなるため、より高い量の RPS を満たすために必要です)。Once a vault is allow listed with additional throughput capacity, the Key Vault service data consistency guarantee changes (necessary to meet higher volume RPS since the underlying Azure Storage service cannot keep up). 簡単に言うと、In a nutshell:
  2. 許可リストを使用しない場合:Key Vault サービスは、書き込み操作 (例えば、Without allow listing: The Key Vault service will reflect the results of a write operation (eg. SecretSet、CreateKey) の結果を、それに続く呼び出しに即座に反映させます。(呼び出しとは例えば、SecretSet, CreateKey) immediately in subsequent calls (eg. SecretGet、KeySign です)。SecretGet, KeySign).
  3. 許可リストを使用する場合:Key Vault サービスは、書き込み操作 (例えば、With allow listing: The Key Vault service will reflect the results of a write operation (eg. SecretSet、CreateKey) の結果を、それに続く呼び出しに 60 秒以内に反映させます。(呼び出しとは例えば、SecretSet, CreateKey) within 60 seconds in subsequent calls (eg. SecretGet、KeySign です)。SecretGet, KeySign).
  4. クライアント コードは 429 に対する再試行に関して、バックオフ ポリシーを遵守する必要があります。Client code must honor back-off policy for 429 retries. 429 応答コードを受信したときには、Key Vault サービスを呼び出すクライアント コードは Key Vault 要求をすぐに再試行することはできません。The client code calling the Key Vault service must not immediately retry Key Vault requests when it receives a 429 response code. ここで公開されている Azure Key Vault スロットル ガイダンスでは、429 HTTP 応答コードを受け取った場合にエクスポネンシャル バックオフを適用することをお勧めしています。The Azure Key Vault throttling guidance published here recommends applying exponential backoff when receiving a 429 Http response code.

業務上の正当な理由でスロットル制限の引き上げを希望される場合は、Microsoft にお問い合わせください。If you have a valid business case for higher throttle limits, please contact us.

サービス制限に対応してアプリをスロットルする方法How to throttle your app in response to service limits

サービスがスロットルされているときに実践すべきベスト プラクティスを次に示します。The following are best practices you should implement when your service is throttled:

  • 要求あたりの操作の数を減らす。Reduce the number of operations per request.
  • 要求の頻度を減らす。Reduce the frequency of requests.
  • すぐに再試行しない。Avoid immediate retries.
    • すべての要求が使用制限のカウント対象になります。All requests accrue against your usage limits.

アプリのエラー処理を実装するときに、HTTP エラー コード 429 を使って、クライアント側でのスロットルの必要性を検出してください。When you implement your app's error handling, use the HTTP error code 429 to detect the need for client-side throttling. HTTP 429 エラー コードで再び要求が失敗すれば、Azure のサービス制限が引き続き適用されます。If the request fails again with an HTTP 429 error code, you are still encountering an Azure service limit. それ以降は、推奨されているクライアント側のスロットル手法を使用して、成功するまで要求を再試行してください。Continue to use the recommended client-side throttling method, retrying the request until it succeeds.

エクスポネンシャル バックオフを実装するコードを次に示します。Code that implements exponential backoff is shown below.

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# アプリケーションで使用するのが簡単です。Using this code in a client C# application is straightforward.

HTTP エラー コード 429 が発生したら、次のように指数関数的バックオフ手法を使ってクライアントのスロットルを開始します。On HTTP error code 429, begin throttling your client using an exponential backoff approach:

  1. 1 秒待って要求を再試行Wait 1 second, retry request
  2. 引き続きスロットルされる場合は 2 秒待って要求を再試行If still throttled wait 2 seconds, retry request
  3. 引き続きスロットルされる場合は 4 秒待って要求を再試行If still throttled wait 4 seconds, retry request
  4. 引き続きスロットルされる場合は 8 秒待って要求を再試行If still throttled wait 8 seconds, retry request
  5. 引き続きスロットルされる場合は 16 秒待って要求を再試行If still throttled wait 16 seconds, retry request

通常は、この時点で HTTP 429 応答コードは発生しなくなります。At this point, you should not be getting HTTP 429 response codes.

関連項目See also

Microsoft Cloud のスロットルに関するさらに詳しい情報については、「Throttling Pattern (スロットル パターン)」を参照してください。For a deeper orientation of throttling on the Microsoft Cloud, see Throttling Pattern.