Aide sur la limitation de requêtes Azure Key VaultAzure Key Vault throttling guidance

La limitation de requêtes est le processus permettant de réduire le nombre d’appels simultanés au service Azure afin d’empêcher toute surexploitation des ressources.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) est conçu pour gérer un volume élevé de requêtes.Azure Key Vault (AKV) is designed to handle a high volume of requests. En cas d’affluence, la limitation des requêtes du client permet de maintenir des performances et une fiabilité optimales pour le service AKV.If an overwhelming number of requests occurs, throttling your client's requests helps maintain optimal performance and reliability of the AKV service.

Les limites varient selon les scénarios.Throttling limits vary based on the scenario. Par exemple, si vous réalisez un volume important d’écritures, la possibilité de limitation est plus élevée que si vous effectuez uniquement des lectures.For example, if you are performing a large volume of writes, the possibility for throttling is higher than if you are only performing reads.

Comment Key Vault gère-t-il ses limites ?How does Key Vault handle its limits?

Les limites de service dans Key Vault empêchent l’usage abusif des ressources et garantissent la qualité du service pour tous les clients de Key Vault.Service limits in Key Vault prevent misuse of resources and ensure quality of service for all of Key Vault's clients. En cas de dépassement d’un seuil de service, Key Vault limite toutes les autres requêtes de ce client sur une période donnée et retourne le code d’état HTTP 429 (Trop de requêtes), indiquant l’échec de la requête.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. Les requêtes qui ont échoué et retourné une erreur 429 sont comptabilisées dans les limites appliquées par Key Vault.Failed requests that return a 429 count towards the throttle limits tracked by Key Vault.

Key Vault a été conçu à l’origine pour stocker et récupérer vos secrets au moment du déploiement.Key Vault was originally designed to be used to store and retrieve your secrets at deployment time. Le monde a évolué et Key Vault est maintenant utilisé au moment de l’exécution pour stocker et récupérer les secrets ; par ailleurs, les applications et les services cherchent souvent à utiliser Key Vault comme une base de données.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. Les limites actuelles ne sont pas adaptées aux débits élevés.Current limits do not support high throughput rates.

Key Vault a initialement été créé avec les limites décrites dans Limites du service Azure Key Vault.Key Vault was originally created with the limits specified in Azure Key Vault service limits. Pour optimiser votre débit Key Vault, voici quelques conseils et bonnes pratiques :To maximize your Key Vault through put rates, here are some recommended guidelines/best practices for maximizing your throughput:

  1. Assurez-vous que des limitations sont mises en place.Ensure you have throttling in place. Le client doit respecter les stratégies de backoff exponentiel pour les erreurs 429. Veillez à procéder à de nouvelles tentatives conformément aux instructions ci-dessous.Client must honor exponential back-off policies for 429's and ensure you are doing retries as per the guidance below.
  2. Répartissez le trafic de votre Key Vault entre plusieurs coffres et différentes régions.Divide your Key Vault traffic amongst multiple vaults and different regions. Utilisez un coffre distinct pour chaque domaine de sécurité/disponibilité.Use a separate vault for each security/availability domain. Par exemple, si vous avez cinq applications, chacune dans deux régions, nous vous conseillons d’utiliser dix coffres contenant chacun les secrets propres à l’application et à la région.If you have five apps, each in two regions, then we recommend 10 vaults each containing the secrets unique to app and region. La limite d’abonnement pour tous les types de transactions est fixée à cinq fois la limite d’un coffre de clés.A subscription-wide limit for all transaction types is five times the individual key vault limit. Par exemple, le nombre de transactions autres que HSM par abonnement est limité à 5 000 en 10 secondes.For example, HSM-other transactions per subscription are limited to 5,000 transactions in 10 seconds per subscription. Envisagez de mettre en cache le secret dans votre service ou votre application afin de réduire également le RPS directement dans le coffre de clés et/ou de gérer le trafic en rafale.Consider caching the secret within your service or app to also reduce the RPS directly to key vault and/or handle burst based traffic. Vous pouvez également répartir le trafic entre différentes régions pour réduire la latence et utiliser un autre abonnement/coffre.You can also divide your traffic amongst different regions to minimize latency and use a different subscription/vault. N’envoyez pas plus de transactions que la limite d’abonnement au service Key Vault dans une seule région Azure.Do not send more than the subscription limit to the Key Vault service in a single Azure region.
  3. Mettez en cache les secrets que vous récupérez d’Azure Key Vault et réutilisez ces secrets du cache mémoire autant que possible.Cache the secrets you retrieve from Azure Key Vault in memory, and reuse from memory whenever possible. Récupérez-les d’Azure Key Vault uniquement si la copie en cache n’est plus disponible (par exemple, si elle a été changée dans la source).Re-read from Azure Key Vault only when the cached copy stops working (e.g. because it got rotated at the source).
  4. Utilisez Key Vault uniquement pour vos propres secrets de services.Key Vault is designed for your own services secrets. Si vous stockez les secrets de vos clients (surtout dans les scénarios de stockage de clés à haut débit), placez les clés dans un compte de base de données ou de stockage avec chiffrement et stockez seulement la clé principale dans 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. Les opérations de chiffrement, d’inclusion dans un wrapper et de vérification de clé publique peuvent être effectuées sans accès à Key Vault, ce qui non seulement réduit le risque de limitation, mais améliore également la fiabilité (à condition d’avoir bien mis en cache les éléments de clé publique).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. Si vous utilisez Key Vault pour stocker les informations d’identification d’un service, assurez-vous que ce service prend en charge Azure AD Authentication pour s’authentifier directement.If you use Key Vault to store credentials for a service, check if that service supports Azure AD Authentication to authenticate directly. Cela réduit la charge sur Key Vault, améliore la fiabilité et simplifie votre code puisque Key Vault peut maintenant utiliser le jeton Azure AD.This reduces the load on Key Vault, improves reliability and simplifies your code since Key Vault can now use the Azure AD token. De nombreux services ont été mis à jour pour utiliser l’authentification Azure AD. Consultez la liste actualisée des services qui prennent en charge les identités managées pour les ressources Azure.Many services have moved to using Azure AD Auth. See the current list at Services that support managed identities for Azure resources.
  7. Essayez d’échelonner votre charge/déploiement sur une période plus longue pour rester sous les limites RPS actuelles.Consider staggering your load/deployment over a longer period of time to stay under the current RPS limits.
  8. Si votre application comprend plusieurs nœuds devant lire le ou les mêmes secrets, utilisez un modèle de distribution ramifiée, où une seule entité récupère un secret de Key Vault et le distribue ensuite vers tous les nœuds.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. Mettez en cache les secrets récupérés uniquement en mémoire.Cache the retrieved secrets only in memory. Si les conseils ou bonnes pratiques ci-dessus ne vous permettent pas de résoudre votre problème, renseignez ce tableau, puis contactez-nous pour déterminer si une capacité supplémentaire peut être ajoutée (l’exemple ci-dessous est donné à titre indicatif uniquement).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).
Nom du coffreVault name Région du coffreVault Region Type d’objet (secret, clé ou certificat)Object type (Secret, Key, or Cert) Opération(s)*Operation(s)* Type de cléKey Type Courbe ou longueur de cléKey Length or Curve Clé HSM ?HSM key? État stable de RPS requisSteady state RPS needed Pic de RPS requisPeak RPS needed
https://mykeyvault.vault.azure.net/ CléKey Sign (Signer)Sign ECEC P-256P-256 NonNo 200200 1 0001000

* Pour obtenir une liste complète des valeurs possibles, consultez Opérations Azure Key Vault.* For a full list of possible values, see Azure Key Vault operations.

Si une capacité supplémentaire est approuvée, notez les conséquences suivantes d’une augmentation de la capacité :If additional capacity is approved, please note the following as result of the capacity increases:

  1. Modifications du modèle de cohérence des données.Data consistency model changes. Une fois qu’un coffre est autorisé avec une capacité de débit supplémentaire, la cohérence des données du service Key Vault garantit l’application des modifications (ce qui est nécessaire pour traiter un volume RPS plus élevé qui ne peut pas l’être par le service Stockage Azure sous-jacent).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). En résumé :In a nutshell:
  2. Sans autorisation  : le service Key Vault reflètera les résultats d’une opération d’écriture (par exemple,Without allow listing : The Key Vault service will reflect the results of a write operation (eg. SecretSet, CreateKey) immédiatement dans les appels suivants (par exemple,SecretSet, CreateKey) immediately in subsequent calls (eg. SecretGet, KeySign).SecretGet, KeySign).
  3. Avec autorisation  : le service Key Vault reflètera les résultats d’une opération d’écriture (par exemple,With allow listing : The Key Vault service will reflect the results of a write operation (eg. SecretSet, CreateKey) dans un délai de 60 secondes dans les appels suivants (par exemple,SecretSet, CreateKey) within 60 seconds in subsequent calls (eg. SecretGet, KeySign).SecretGet, KeySign).
  4. Le code client doit respecter la stratégie de backoff entre les nouvelles tentatives (code de réponse 429).Client code must honor back-off policy for 429 retries. Le code client qui appelle le service Key Vault ne doit pas réessayer les requêtes de Key Vault immédiatement après avoir reçu un code de réponse 429.The client code calling the Key Vault service must not immediately retry Key Vault requests when it receives a 429 response code. La présente aide sur la limitation de requêtes Azure Key Vault vous conseille d’appliquer un backoff exponentiel pour les codes de réponse HTTP 429 reçus.The Azure Key Vault throttling guidance published here recommends applying exponential backoff when receiving a 429 Http response code.

Si vous avez un scénario valide justifiant une limitation supérieure, contactez-nous.If you have a valid business case for higher throttle limits, please contact us.

Guide pratique pour limiter une application en réponse à des limites de serviceHow to throttle your app in response to service limits

Les bonnes pratiques suivantes doivent être implémentées lorsque votre service est limité :The following are best practices you should implement when your service is throttled:

  • Réduisez le nombre d’opérations par requête.Reduce the number of operations per request.
  • Réduisez la fréquence des requêtes.Reduce the frequency of requests.
  • Évitez les nouvelles tentatives immédiates.Avoid immediate retries.
    • Toutes les requêtes sont comptabilisées dans le cadre de vos limites d’utilisation.All requests accrue against your usage limits.

Lorsque vous implémentez la gestion des erreurs de votre application, utilisez le code d’erreur HTTP 429 pour détecter si une limitation côté client est nécessaire.When you implement your app's error handling, use the HTTP error code 429 to detect the need for client-side throttling. Si la requête échoue à nouveau avec un code d’erreur HTTP 429, cela signifie que vous rencontrez toujours une limite de service Azure.If the request fails again with an HTTP 429 error code, you are still encountering an Azure service limit. Continuez à utiliser la méthode de limitation côté client recommandée, en réessayant la requête jusqu’à ce qu’elle aboutisse.Continue to use the recommended client-side throttling method, retrying the request until it succeeds.

Le code qui implémente un backoff exponentiel est montré ci-dessous.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);

L'utilisation de ce code dans une application cliente C# est simple.Using this code in a client C# application is straightforward.

En cas de code d’erreur HTTP 429, commencez à limiter votre client suivant une approche d’interruption exponentielle :On HTTP error code 429, begin throttling your client using an exponential backoff approach:

  1. Patientez une seconde, relancez la requête ;Wait 1 second, retry request
  2. Si la limitation persiste, patientez deux secondes, relancez la requête ;If still throttled wait 2 seconds, retry request
  3. Si la limitation persiste, patientez quatre secondes, relancez la requête ;If still throttled wait 4 seconds, retry request
  4. Si la limitation persiste, patientez huit secondes, relancez la requête ;If still throttled wait 8 seconds, retry request
  5. Si la limitation persiste, patientez seize secondes, relancez la requête.If still throttled wait 16 seconds, retry request

À ce stade, vous ne devriez pas recevoir de code de réponse HTTP 429.At this point, you should not be getting HTTP 429 response codes.

Voir aussiSee also

Pour orienter la limitation de façon plus approfondie sur Microsoft Cloud, consultez la page Modèle de limitation.For a deeper orientation of throttling on the Microsoft Cloud, see Throttling Pattern.