Limitation de requêtes avancée avec Gestion des API Azure
S’APPLIQUE À : Tous les niveaux de Gestion des API
La possibilité de limiter les requêtes entrantes est un rôle clé du service Gestion des API Azure. En contrôlant la fréquence des requêtes ou le nombre total de requêtes/données transférées, 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 produits API.
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 la protection contre les pics de volume brefs et intenses. Par exemple, si vous savez qu'un goulot d'étranglement se forme au niveau de la base de données de votre service back-end lorsque le volume d'appels est élevé, vous pouvez définir une stratégie rate-limit-by-key pour ne pas autoriser un volume d'appels élevé à l'aide de ce paramètre.
Attention
En raison de la nature distribuée de l’architecture de limitation, la limitation du débit n’est jamais totalement exacte. La différence entre le nombre configuré et le nombre réel de requêtes autorisées varie en fonction du volume et du débit des requêtes, de la latence du back-end et d’autres facteurs.
Quotas
Les quotas sont généralement utilisés pour contrôler les débits d'appels sur une longue période. Par exemple, ils peuvent définir le nombre total d'appels qu'un abonné particulier est autorisé à passer au cours d'un mois donné. Pour monétiser votre API, les quotas peuvent également être définis différemment pour les abonnements reposant sur des niveaux. Par exemple, un abonnement de niveau De base ne pourra pas passer plus de 10 000 appels par mois, tandis qu'un niveau Premium pourra passer jusqu'à 100 000 000 d'appels par mois.
Dans Gestion des API Azure, les limites de débit sont généralement propagées plus rapidement sur les nœuds pour se protéger contre les pics. Les informations relatives aux quotas d'utilisation, quant à elles, sont utilisées à plus long terme ; leur implémentation est donc différente.
Notes
Quand les ressources de calcul sous-jacentes redémarrent dans la plateforme de service, Gestion des API peut continuer à gérer les requêtes pendant une courte période après qu’un quota est atteint.
Limitation basée sur le produit
Les capacités de limitation du débit qui portent sur un abonnement particulier sont utiles au fournisseur d’API pour appliquer des limites aux développeurs qui se sont inscrits pour utiliser leur API. Cependant, cela ne permet pas, par exemple, de limiter les utilisateurs finaux de l’API. Il est possible pour un utilisateur de l’application du développeur de consommer le quota entier et d’empêcher d’autres clients du développeur de pouvoir utiliser l’application. De la même façon, plusieurs clients générant un volume élevé de requêtes peuvent limiter l'accès aux utilisateurs occasionnels.
Limitation basée sur une clé personnalisée
Notes
Les stratégies rate-limit-by-key et quota-by-key ne sont pas disponibles dans le niveau Consommation de Gestion des API Azure. La stratégie quota-by-key n’est pas disponible actuellement dans les niveaux v2.
Les rate-limit-by-key et quota-by-key fournissent une solution plus souple pour le contrôle du trafic. Ces stratégies vous permettent de définir des expressions pour identifier les clés qui servent à effectuer le suivi de l’utilisation du trafic. Il est plus facile d’en comprendre le fonctionnement avec un exemple.
Limitation par adresse IP
Les stratégies suivantes limitent l’adresse IP d’un client à 10 appels par minute, avec un total d’un million d’appels et 10 000 Ko 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 utilisent une adresse IP unique, cela peut être un moyen efficace de limiter l'utilisation par utilisateur. Toutefois, il est probable que plusieurs utilisateurs partagent une même adresse IP publique, parce qu’ils accèdent à Internet via un périphérique NAT. En dépit de cela, le IpAddress peut être la meilleure option pour les API qui autorisent l’accès non authentifié.
Limitation par identité d'utilisateur
Si un utilisateur final est authentifié, une clé de limitation de la clé peut être générée en fonction d’informations qui identifient cet utilisateur de façon unique.
<rate-limit-by-key calls="10"
renewal-period="60"
counter-key="@(context.Request.Headers.GetValueOrDefault("Authorization","").AsJwt()?.Subject)" />
Cet exemple montre l’en-tête d’autorisation, pour le convertir en objet JWT et utiliser le sujet du jeton pour identifier l’utilisateur et l’utiliser comme la clé de limitation du 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 offrent davantage de contrôle que les stratégies de limitation basées sur l’abonnement, il est toujours utile de combiner les deux capacités. La limitation par clé d’abonnement produit (Limiter la fréquence des appels par abonnement et Définir le quota d’utilisation par abonnement) constitue un excellent moyen de permettre la monétisation d’une API en facturant en fonction des niveaux d’utilisation. Le contrôle plus fin 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 en utilisant une expression de stratégie, le fournisseur d'API est celui qui choisit comment définir la limitation. Toutefois, un développeur peut souhaiter contrôler la limitation de débit de leurs propres clients. Cela peut être possible si le fournisseur de l'API introduit un en-tête personnalisé afin de permettre à l'application client 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",""))"/>
Cela permet à l'application client du développeur de laisser le choix de la création de la clé de limitation de la fréquence. Un développeur client peut créer ses propres niveaux de fréquence en allouant des jeux de clés aux utilisateurs et en effectuant la rotation de l’utilisation des clés.
Résumé
Gestion des API Azure permet la limitation du débit et du quota pour à la fois protéger et valoriser votre service API. Les nouvelles stratégies de limitation avec les règles de portée personnalisées vous permettent un contrôle plus fin sur les stratégies afin de permettre à vos clients de créer de meilleures applications. Les exemples de cet article illustrent l'utilisation de ces nouvelles stratégies avec la création de clés de limitation appliquées aux adresses IP clientes, à l’identité de l'utilisateur et les valeurs générées par le client. Toutefois, il existe de nombreuses autres parties du message qui peuvent être utilisées telles que l’agent utilisateur, les fragments de chemin d'URL, ou la taille des messages.
Étapes suivantes
Faites-nous part de vos commentaires en tant que problème GitHub pour cette rubrique. Il serait intéressant d’en savoir davantage sur les autres valeurs de clé potentielles qui se sont avérées être un choix judicieux dans vos scénarios.