Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de changer d’annuaire.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer d’annuaire.
S’APPLIQUE À : tous les niveaux de Gestion des API
La possibilité de limiter les requêtes entrantes est un rôle clé de Gestion des API Azure. Gestion des API permet aux fournisseurs d’API de protéger leurs API contre les abus et de créer de la valeur pour différents niveaux de produit d’API en contrôlant le taux de requêtes ou les demandes/données totales transférées. Cet article explique comment créer et appliquer une limitation de quota et de débit.
Limites de débit et quotas
Les limites de débit et les quotas sont utilisés à des fins différentes.
Limites du taux de transfert
Les limites de débit sont généralement utilisées pour se protéger contre les rafales de volume court et intense. Par exemple, si vous savez que votre service principal a un goulot d’étranglement dans sa base de données lorsque les volumes d’appels sont élevés, vous pouvez définir une rate-limit-by-key stratégie pour interdire les volumes d’appels élevés.
Pour les serveurs backend de modèles de langage, vous pouvez définir une stratégie llm-token-limit limitant le nombre de jetons traités par minute par votre backend. Cette stratégie permet de vous protéger contre les pics soudains d’utilisation des jetons qui pourraient entraîner une augmentation des coûts, épuiser les ressources ou dégrader les performances.
Avertissement
En raison de la nature distribuée de l’architecture de limitation, la limitation de débit n’est jamais complètement précise. La différence entre le nombre configuré de requêtes autorisées et le nombre réel varie en fonction du volume et du taux de requête, de la latence du back-end et d’autres facteurs.
Niveaux classiques versus v2
Gestion des API implémente la limitation de débit différemment selon que votre instance se trouve dans l’un des niveaux de service classiques ou v2 :
Les niveaux classiques utilisent un algorithme de fenêtre glissante.
Les niveaux V2 utilisent un algorithme de compartiment de jetons plus efficace et s’aligne sur la limitation de débit dans Azure Resource Manager.
Bien que le comportement global de limitation de débit soit similaire dans les niveaux Gestion des API, les différences d’implémentation affectent certains détails d’utilisation des stratégies de limitation de débit telles que rate-limit-by-key et llm-token-limit.
Contingents
Les quotas sont généralement utilisés pour contrôler les taux d’appel sur une période plus longue. Par exemple, ils peuvent définir le nombre total d'appels qu'un abonné particulier est autorisé à passer au cours d'un mois donné. Si vous monétisez votre API, vous pouvez également définir des quotas différemment pour les abonnements basés sur des niveaux. Par exemple, un abonnement de niveau basique peut être en mesure d’effectuer jusqu'à 10 000 appels par mois, mais un niveau premium peut être en mesure d’effectuer 100 000 000 appels chaque mois.
Dans Gestion des API, les limites de débit sont généralement propagées plus rapidement sur les nœuds pour se protéger contre les pics. En revanche, les informations sur le quota d’utilisation sont utilisées à plus long terme, de sorte que son implémentation est différente.
Remarque
Lorsque les ressources de calcul sous-jacentes redémarrent dans la plateforme de service, gestion des API peut continuer à gérer les demandes pendant une courte période après qu’un quota est atteint.
Limitation basée sur le produit
Les fournisseurs d’API peuvent utiliser des fonctionnalités de limitation de débit qui sont étendues à un abonnement particulier pour appliquer des limites aux développeurs qui se sont inscrits pour utiliser leur API. Cependant, ce type de régulation ne permet pas, par exemple, de contrôler l'utilisation par chaque utilisateur final de l'API. Il est possible qu’un seul utilisateur de l’application du développeur consomme l’intégralité du quota et empêche les autres clients du développeur de pouvoir utiliser l’application. En outre, plusieurs clients qui génèrent un volume élevé de demandes peuvent limiter l’accès aux utilisateurs occasionnels.
Limitation basée sur une clé personnalisée
Remarque
Les stratégies rate-limit-by-key et quota-by-key ne sont pas disponibles dans l'offre Consommation de la Gestion des API Azure.
Les stratégies de débit par clé et de quota par clé fournissent une solution plus flexible pour le contrôle du trafic. Ces stratégies vous permettent de définir des expressions pour identifier les clés utilisées pour suivre l’utilisation du trafic. Cette technique est illustrée dans les exemples suivants.
Limitation par adresse IP
Les stratégies suivantes limitent une seule adresse IP cliente à seulement 10 appels toutes les minutes et appliquent un total de 1 000 000 appels et 10 000 kilo-octets de bande passante par mois :
<rate-limit-by-key calls="10"
renewal-period="60"
counter-key="@(context.Request.IpAddress)" />
<quota-by-key calls="1000000"
bandwidth="10000"
renewal-period="2629800"
counter-key="@(context.Request.IpAddress)" />
Si tous les clients sur Internet utilisaient une adresse IP unique, cela peut être un moyen efficace de limiter l’utilisation par l’utilisateur. Toutefois, il est probable que plusieurs utilisateurs partagent une seule adresse IP publique, car ils accèdent à Internet via un appareil NAT. Toutefois, pour les API qui autorisent l’accès non authentifié, l’utilisation IpAddress peut être la meilleure option.
Limitation par identité d’utilisateur
Si un utilisateur final est authentifié, vous pouvez générer une clé de limitation en fonction des informations qui identifient de manière unique l’utilisateur :
<rate-limit-by-key calls="10"
renewal-period="60"
counter-key="@(context.Request.Headers.GetValueOrDefault("Authorization","").AsJwt()?.Subject)" />
Cet exemple montre comment extraire l’en-tête d’autorisation, le convertir en objet JWT et utiliser l’objet du jeton pour identifier l’utilisateur. Elle utilise ensuite cette valeur comme clé de limitation de débit. Si l’identité de l’utilisateur est stockée dans le JWT comme l’une des autres revendications, cette valeur peut être utilisée à la place.
Stratégies combinées
Bien que les stratégies de limitation basées sur l’utilisateur fournissent plus de contrôle que les stratégies de limitation basées sur l’abonnement, il est toujours important de combiner les deux fonctionnalités. Pour les API monétisées, la limitation par clé d’abonnement de produit (limiter le taux d’appel par abonnement et définir le quota d’utilisation par abonnement) est un excellent moyen d’implémenter des frais basés sur les niveaux d’utilisation. Le contrôle précis sur la limitation de la bande passante par utilisateur est gratuite et empêche que le comportement de certains utilisateurs dégrade l’expérience des autres.
Limitation par client
Lorsque la clé de limitation est définie via une expression de stratégie, le fournisseur d’API choisit la portée de la limitation. Toutefois, un développeur peut vouloir contrôler la façon dont il limite ses propres clients. Le fournisseur d’API peut activer ce type de contrôle en introduisant un en-tête personnalisé pour permettre à l’application cliente du développeur de communiquer la clé à l’API :
<rate-limit-by-key calls="100"
renewal-period="60"
counter-key="@(request.Headers.GetValueOrDefault("Rate-Key",""))"/>
Cette technique permet à l’application cliente du développeur de déterminer comment créer la clé de limitation de débit. Les développeurs clients peuvent créer leurs propres niveaux de débit en allouant des ensembles de clés aux utilisateurs et en faisant pivoter l’utilisation des clés.
Considérations relatives à plusieurs régions ou passerelles
Les stratégies de limitation de débit telles que rate-limit, rate-limit-by-key, azure-openai-token-limitet llm-token-limit utilisent des compteurs au niveau de la passerelle Gestion des API. Par conséquent, dans les déploiements multirégions de Gestion des API, chaque passerelle régionale a un compteur distinct et les limites de débit sont appliquées séparément pour chaque région. De même, dans les instances gestion des API avec des espaces de travail, les limites sont appliquées séparément pour chaque passerelle d’espace de travail.
Les stratégies de quota comme quota et quota-by-key sont globales, ce qui signifie qu’un compteur unique est utilisé au niveau de l’instance Gestion des API.
Résumé
Gestion des API fournit des limites de débit et de quota pour protéger et ajouter de la valeur à votre service d’API. Les politiques de limitation dotées de règles de portée personnalisées offrent un contrôle plus précis, permettant à vos clients de créer des applications encore meilleures. Les exemples de cet article illustrent l’utilisation de ces stratégies en créant des clés de limitation de débit avec des adresses IP clientes, une identité utilisateur et des valeurs générées par le client. Toutefois, vous pouvez utiliser de nombreuses autres parties du message, telles que l’agent utilisateur, les fragments de chemin d’accès d’URL et la taille du message.