Partage via

Comprendre comment Azure Resource Manager limite les demandes

  • Article

Cet article explique comment Azure Resource Manager limite les requêtes. Il vous montre comment suivre le nombre de demandes qui restent avant d’atteindre la limite et comment réagir quand vous avez atteint la limite.

La limitation se produit à deux niveaux. Azure Resource Manager limite les demandes pour l’abonnement et le locataire. Si la demande se trouve sous les limites de limitation pour l’abonnement et le locataire, le Gestionnaire des ressources achemine la requête vers le fournisseur de ressources. Le fournisseur de ressources applique des limites de limitation adaptées à ses opérations.

L’illustration suivante montre la façon dont la limitation est appliquée lorsqu’une demande passe de l’utilisateur à Azure Resource Manager et au fournisseur de ressources. L’image montre que les requêtes sont initialement limitées par ID principal et par instance Azure Resource Manager dans la région de l’utilisateur qui envoie la demande. Les requêtes sont limitées par heure. Lorsque la demande est transférée au fournisseur de ressources, les requêtes sont limitées par région de la ressource plutôt que par instance Azure Resource Manager dans la région de l’utilisateur. Les demandes du fournisseur de ressources sont également limitées par ID utilisateur principal et par heure.

Diagramme montrant la façon dont la limitation est appliquée quand une requête passe de l’utilisateur à Azure Resource Manager et au fournisseur de ressources.

Limites de locataire et d’abonnement

Chaque opération au niveau de l’abonnement et du client est soumise à des limites de limitation. Les requêtes appliquées à l’abonnement sont celles qui impliquent la transmission de votre ID d’abonnement, par exemple pour récupérer les groupes de ressources dans votre abonnement. Par exemple, l’envoi d’une demande à https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups?api-version=2022-01-01 est une opération au niveau de l’abonnement. Les requêtes appliquées au locataire n’incluent pas votre ID d’abonnement, notamment pour la récupération des emplacements Azure valides. Par exemple, l’envoi d’une demande à https://management.azure.com/tenants?api-version=2022-01-01 est une opération au niveau du locataire.

Les limites de limitation par heure par défaut sont indiquées dans le tableau suivant.

Étendue Opérations Limite
Subscription lectures 12 000
Subscription suppressions 15000
Subscription écritures 1200
Locataire lectures 12 000
Locataire écritures 1200

Ces limites sont définies d’après le principal de sécurité (utilisateur ou application) qui effectue les requêtes et l’ID d’abonnement ou l’ID du locataire. Si vos requêtes proviennent de plusieurs principaux de sécurité, votre limite dans l’abonnement ou le locataire est supérieure à 12 000 et 1200 par heure.

Ces limites s’appliquent à chaque instance Azure Resource Manager. Chaque région Azure comporte plusieurs instances, et Azure Resource Manager est déployé dans toutes les régions Azure. Par conséquent, dans la pratique, les limites sont supérieures à ces limites. Les demandes d’un utilisateur sont généralement gérées par des instances différentes d’Azure Resource Manager.

Les demandes restantes sont renvoyées dans les valeurs d’en-tête de réponse.

Migration vers une limitation régionale et l’algorithme de compartiment de jetons

À compter de 2024, Microsoft migre les abonnements Azure vers une nouvelle architecture de limitation. Avec ce changement, vous allez rencontrer de nouvelles limitations. Les nouvelles limitations sont appliquées par région plutôt que par instance d’Azure Resource Manager. La nouvelle architecture utilise un algorithme de compartiment de jetons pour gérer la limitation des API.

Le compartiment de jetons représente le nombre maximal de demandes que vous pouvez envoyer par seconde. Quand vous atteignez le nombre maximal de demandes, le taux de remplissage détermine la vitesse de disponibilité des jetons dans le compartiment.

Ces limites mises à jour facilitent l’actualisation et la gestion de votre quota.

Les nouvelles limites sont les suivantes :

Étendue Opérations Taille du compartiment Taux de remplissage par seconde
Abonnement lectures 250 25
Abonnement suppressions 200 10
Abonnement écritures 200 10
Locataire lectures 250 25
Locataire suppressions 200 10
Locataire écritures 200 10

Les limites d’abonnement s’appliquent par abonnement, par principal de service et par type d’opération. Il existe également des limites d’abonnement générales équivalentes à 15 fois les limites d’un principal de service individuel pour chaque type d’opération. Les limites générales s’appliquent à tous les principaux de service. Les demandes sont limitées si les limites générales, du principal de service ou du locataire sont dépassées.

Les limites peuvent être plus basses pour les clients des versions gratuites ou d’essai.

Par exemple, supposons que vous avez une taille de compartiment de 250 jetons pour les demandes de lecture et que le taux de remplissage est de 25 jetons par seconde. Si vous envoyez 250 demandes de lecture en une seconde, le compartiment est vide et vos demandes sont limitées. Chaque seconde, 25 jetons deviennent disponibles jusqu’à ce que le compartiment atteigne sa capacité maximale de 250 jetons. Vous pouvez utiliser des jetons dès qu’ils sont disponibles.

Comment savoir si mon abonnement utilise la nouvelle expérience de limitation ?

Une fois votre abonnement migré vers la nouvelle expérience de limitation, l’en-tête de réponse affiche les demandes qui restent par minute et non par heure. Par ailleurs, la valeur Retry-After affiche une minute ou moins, au lieu de cinq minutes. Pour plus d’informations, consultez Code d’erreur.

Pourquoi la limitation est-elle par région et non par instance ?

Parce que différentes régions ont un nombre différent d’instances Resource Manager, la limitation par instance entraîne des performances de limitation incohérentes. La limitation par région rend la limitation cohérente et prévisible.

Comment la nouvelle expérience de limitation affecte-t-elle mes limites ?

Vous pouvez envoyer plus de demandes. Les demandes d’écriture sont 30 fois supérieures. Les demandes de suppression sont 2,4 fois supérieures. Les demandes de lecture sont 7,5 fois supérieures.

Puis-je empêcher mon abonnement de migrer vers la nouvelle expérience de limitation ?

Non, tous les abonnements finiront par être migrés.

Limites de fournisseur de ressources

Les fournisseurs de ressources appliquent leurs propres limites de limitation. Dans chaque abonnement, le fournisseur de ressources limite par région de la ressource dans la requête. Étant donné que Resource Manager limite par instance de Resource Manager et qu’il existe plusieurs instances de Resource Manager dans chaque région, le fournisseur de ressources peut recevoir plus de demandes que les limites par défaut de la section précédente.

Cette section décrit les limites de limitation de certains fournisseurs de ressources couramment utilisés.

Limitation du stockage

Les limites suivantes s’appliquent seulement quand vous effectuez des opérations de gestion en utilisant Azure Resource Manager avec le stockage Azure. Les limites s’appliquent par région de la ressource dans la requête.

Ressource Limite
Opérations de gestion du compte de stockage (lecture) 800 toutes les 5 minutes
Opérations de gestion du compte de stockage (écriture) 10 par seconde/1 200 par heure
Opérations de gestion du compte de stockage (liste) 100 toutes les 5 minutes

Limitation du réseau

Le fournisseur de ressources Microsoft. Network applique les limites de limitation suivantes :

Opération Limite
écriture / suppression (PUT) 1000 toutes les 5 minutes
lecture (GET) 10000 toutes les 5 minutes

En plus de ces limites générales, consultez les limites d’utilisation pour Azure DNS.

Calculer la limitation

Microsoft Compute implémente la limitation pour offrir une expérience optimale aux utilisateurs de machines virtuelles et de groupes de machines virtuelles identiques. limites de limitation de calcul fournit des informations complètes sur les stratégies de limitation et les limites des machines virtuelles, des groupes de machines virtuelles identiques et des machines virtuelles identiques.

Limitation Azure Resource Graph

Azure Resource Graph limite le nombre de demandes à ses opérations. Les étapes décrites dans cet article pour déterminer les requêtes restantes et comment réagir si la limite est atteinte s’appliquent également à Resource Graph. Toutefois, Resource Graph définit ses propres limites et son propre taux de réinitialisation. Pour plus d’informations, voir En-têtes de limitation de Resource Graph.

Autres fournisseurs de ressources

Pour plus d’informations sur la limitation dans d’autres fournisseurs de ressources, consultez :

Code d'erreur

Lorsque vous atteignez la limite, vous recevez le code d’état HTTP 429 Trop de requêtes. La réponse inclut la valeur Retry-After qui spécifie le nombre de secondes pendant lesquelles votre application doit attendre (ou rester en veille) avant d’envoyer la requête suivante. Si vous envoyez une demande avant l’écoulement de la valeur de nouvelles tentatives, votre demande n’est pas traitée et une autre valeur de nouvelles tentatives est renvoyée.

Si vous utilisez un kit de développement logiciel (SDK) Azure, celui-ci peut inclure une configuration de nouvelle tentative automatique. Pour plus d’informations, consultez Guide du mécanisme de nouvelle tentative relatif aux services Azure.

Certains fournisseurs de ressources retournent l’erreur 429 pour signaler un problème temporaire. Le problème peut être une condition de surcharge qui n’est pas directement due à votre demande. Il peut s’agir d’une erreur temporaire concernant l’état de la ressource cible ou de la ressource dépendante. Par exemple, le fournisseur de ressources réseau renvoie le message 429 avec le code d’erreur RetryableErrorDueToAnotherOperation lorsque la ressource cible est verrouillée par une autre opération. Pour déterminer si l’erreur provient d’une limitation ou d’une condition temporaire, affichez les détails de l’erreur dans la réponse.

Requêtes restantes

Vous pouvez déterminer le nombre de requêtes restantes en examinant les en-têtes de réponse. Les requêtes de lecture retournent une valeur dans l’en-tête pour le nombre de requêtes de lecture restantes. Les requêtes d’écriture incluent une valeur pour le nombre de requêtes d’écriture restantes. Le tableau suivant décrit les en-têtes de réponse que vous pouvez examiner pour ces valeurs :

En-tête de réponse Description
x-ms-ratelimit-remaining-subscription-deletes Requêtes de suppression restantes étendues à l’abonnement. Cette valeur est renvoyée pour les opérations de suppression.
x-ms-ratelimit-remaining-subscription-reads Requêtes de lecture restantes étendues à l’abonnement. Cette valeur est renvoyée pour les opérations de lecture.
x-ms-ratelimit-remaining-subscription-writes Requêtes d’écriture restantes étendues à l’abonnement. Cette valeur est renvoyée pour les opérations d’écriture.
x-ms-ratelimit-remaining-tenant-reads Requêtes de lecture restantes étendues au locataire
x-ms-ratelimit-remaining-tenant-writes Requêtes d’écriture restantes étendues au locataire
x-ms-ratelimit-remaining-subscription-resource-requests Requêtes de type de ressource restantes étendues à l’abonnement.

Cette valeur d’en-tête est renvoyée uniquement si un service remplace la limite par défaut. Resource Manager ajoute cette valeur au lieu des requêtes de lecture ou d’écriture de l’abonnement.
x-ms-ratelimit-remaining-subscription-resource-entities-read Requêtes de collecte de type de ressource restantes étendues à l’abonnement.

Cette valeur d’en-tête est renvoyée uniquement si un service remplace la limite par défaut. Cette valeur fournit le nombre de requêtes de collecte restantes (répertorier les ressources).
x-ms-ratelimit-remaining-tenant-resource-requests Requêtes de type de ressource restantes étendues au locataire.

Cet en-tête est ajouté uniquement pour les demandes au niveau du locataire, et uniquement si un service remplace la limite par défaut. Resource Manager ajoute cette valeur au lieu des requêtes de lecture ou d’écriture du locataire.
x-ms-ratelimit-remaining-tenant-resource-entities-read Requêtes de collecte de type de ressource restantes étendues au locataire.

Cet en-tête est ajouté uniquement pour les demandes au niveau du locataire, et uniquement si un service remplace la limite par défaut.

Le fournisseur de ressources peut également retourner des en-têtes de réponse avec des informations sur les demandes restantes. Pour plus d’informations sur les en-têtes de réponse retournés par le fournisseur de ressources de calcul, consultez En-têtes de réponse d’information de débit d’appels.

Récupération des valeurs d’en-tête

La récupération de ces valeurs d’en-tête dans votre code ou script est similaire à la récupération de n’importe quelle valeur d’en-tête.

Par exemple, en C#, vous récupérez la valeur d’en-tête d’un objet HttpWebResponse nommé response avec le code suivant :

response.Headers.GetValues("x-ms-ratelimit-remaining-subscription-reads").GetValue(0)

Dans PowerShell, vous récupérez la valeur de l’en-tête d’une opération Invoke-WebRequest.

$r = Invoke-WebRequest -Uri https://management.azure.com/subscriptions/{guid}/resourcegroups?api-version=2016-09-01 -Method GET -Headers $authHeaders
$r.Headers["x-ms-ratelimit-remaining-subscription-reads"]

Pour obtenir un exemple PowerShell complet, consultez Vérifier les limites de Resource Manager pour un abonnement.

Si voulez voir les requêtes restantes pour le débogage, vous pouvez définir le paramètre -Debug sur votre cmdlet PowerShell.

Get-AzResourceGroup -Debug

Retourne un grand nombre de valeurs, notamment la valeur de réponse suivante :

DEBUG: ============================ HTTP RESPONSE ============================

Status Code:
OK

Headers:
Pragma                        : no-cache
x-ms-ratelimit-remaining-subscription-reads: 11999

Pour obtenir des limites d’écriture, utilisez une opération d’écriture :

New-AzResourceGroup -Name myresourcegroup -Location westus -Debug

Renvoie un grand nombre de valeurs, notamment celles-ci :

DEBUG: ============================ HTTP RESPONSE ============================

Status Code:
Created

Headers:
Pragma                        : no-cache
x-ms-ratelimit-remaining-subscription-writes: 1199

Dans l’interface de ligne de commande, vous récupérez la valeur d’en-tête à l’aide de l’option plus détaillée.

az group list --verbose --debug

Renvoie un grand nombre de valeurs, notamment celles-ci :

msrest.http_logger : Response status: 200
msrest.http_logger : Response headers:
msrest.http_logger :     'Cache-Control': 'no-cache'
msrest.http_logger :     'Pragma': 'no-cache'
msrest.http_logger :     'Content-Type': 'application/json; charset=utf-8'
msrest.http_logger :     'Content-Encoding': 'gzip'
msrest.http_logger :     'Expires': '-1'
msrest.http_logger :     'Vary': 'Accept-Encoding'
msrest.http_logger :     'x-ms-ratelimit-remaining-subscription-reads': '11998'

Pour obtenir des limites d’écriture, utilisez une opération d’écriture :

az group create -n myresourcegroup --location westus --verbose --debug

Renvoie un grand nombre de valeurs, notamment celles-ci :

msrest.http_logger : Response status: 201
msrest.http_logger : Response headers:
msrest.http_logger :     'Cache-Control': 'no-cache'
msrest.http_logger :     'Pragma': 'no-cache'
msrest.http_logger :     'Content-Length': '163'
msrest.http_logger :     'Content-Type': 'application/json; charset=utf-8'
msrest.http_logger :     'Expires': '-1'
msrest.http_logger :     'x-ms-ratelimit-remaining-subscription-writes': '1199'

Étapes suivantes