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. Les requêtes sont initialement limitées par ID de principal et par instance Azure Resource Manager dans la région de l’utilisateur qui envoie la requête. 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.
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
15,000
Subscription
écritures
1,200
Locataire
lectures
12 000
Locataire
écritures
1,200
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. Différentes instances d’Azure Resource Manager gèrent généralement les requêtes de l’utilisateur.
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 rencontrez de nouvelles limites de limitation. 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 requêtes sont limitées si les limites générales ou celles propres au principal de service ou au locataire sont dépassées.
Les limites peuvent être plus basses pour les clients de 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.
La lecture de métriques en utilisant l’API */providers/microsoft.insights/metrics contribue considérablement au trafic global d’Azure Resource Manager et elle est la cause courante des événements de limitation des abonnements. Si vous utilisez fortement cette API, nous vous recommandons de basculer vers l’API getBatch. Vous pouvez interroger plusieurs ressources dans une seule requête REST, ce qui permet d’améliorer les performances et de réduire la limitation. Pour découvrir plus d’informations sur la conversion de vos opérations, consultez Migrer de l’API de métriques vers l’API getBatch.
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 si vous effectuez des opérations de gestion en utilisant Azure Resource Manager avec le Stockage Azure et le Fournisseur de ressources de stockage. Les limites s’appliquent par abonnement et 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 :
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 la limitation du calcul fournit des informations complètes sur les stratégies de limitation et les limites des machines virtuelles, les groupes de machines virtuelles identiques et les machines virtuelles d’un groupe identique.
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 :
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 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.
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 due à votre requête. Il peut également 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 retourne le message 429 avec le code d’erreur RetryableErrorDueToAnotherOperation lorsqu’une autre opération verrouille la ressource cible. 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.
Requêtes de type de ressource délimitées à l’abonnement restantes.
Cette valeur d’en-tête est retourné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.
Requêtes de collecte de type de ressource délimitées à l’abonnement restantes.
Cette valeur d’en-tête est retourné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 délimitées au locataire restantes.
Cet en-tête est ajouté pour les requêtes au niveau du locataire, et ce uniquement si un service écrase la limite par défaut. Resource Manager ajoute cette valeur au lieu des requêtes de lecture ou d’écriture du locataire.
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 ce 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 :
Azure HPC est une fonctionnalité cloud conçue spécialement pour les charges de travail HPC et IA, qui utilise des processeurs de pointe et une interconnexion InfiniBand de classe HPC pour offrir les meilleures performances, scalabilité et valeur aux applications. Azure HPC permet aux utilisateurs de laisser libre cours à l’innovation, la productivité et l’agilité métier grâce à une gamme de technologies HPC et IA hautement disponibles qui peuvent être allouées dynamiquement à mesure que vos besoins technico
Découvrez comment résoudre les problèmes liés à l’erreur SubscriptionRequestsThrottled (état 429) lorsque vous essayez de créer et de déployer un cluster Azure Kubernetes Service (AKS).
Découvrez comment analyser, diagnostiquer et réduire les problèmes de performances qui provoquent la latence et la limitation dans Azure Time Series Insights.
Découvrez comment résoudre les problèmes d’erreur TooManyRequestsReceived ou SubscriptionRequestsThrottled lorsque vous essayez de supprimer un cluster Azure Kubernetes Service (AKS).