Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
REL05-BP02 Demandes d'accélérateur
Limitez les demandes pour atténuer l’épuisement des ressources en cas d’augmentation imprévue de la demande. Les demandes inférieures aux taux de limitation sont traitées tandis que celles dépassant la limite définie sont rejetées avec un message de retour indiquant que la demande a été limitée.
Résultat souhaité : les pics de volume importants, qu’ils soient dus à une augmentation soudaine du trafic client, à des inondations ou à des tempêtes de nouvelles tentatives, sont atténués par la limitation des demandes, ce qui permet aux charges de travail de poursuivre le traitement normal du volume de demandes pris en charge.
Anti-modèles courants :
-
APIles limites des points de terminaison ne sont pas implémentées ou sont laissées aux valeurs par défaut sans tenir compte des volumes attendus.
-
APIles points de terminaison ne sont pas testés en charge ou les limites d'étranglement ne sont pas testées.
-
Limiter les taux de demandes sans tenir compte de la taille ou de la complexité des demandes.
-
Tester les taux de demande maximaux ou la taille maximale des demandes, mais pas les deux simultanément.
-
Les ressources ne sont pas provisionnées selon les mêmes limites établies lors des tests.
-
Les plans d'utilisation n'ont pas été configurés ou pris en compte pour les API consommateurs d'application à application (A2A).
-
Les utilisateurs de files d’attente qui mettent à l’échelle horizontalement ne disposent pas de paramètres de simultanéité maximaux configurés.
-
La limitation du débit par adresse IP n’a pas été mise en œuvre.
Avantages du respect de cette bonne pratique : les charges de travail qui fixent des limites peuvent fonctionner normalement et traiter correctement le chargement des demandes acceptées en cas de pics de volume inattendus. Les pics soudains ou soutenus de demandes et de files d'attente sont limités APIs et n'épuisent pas les ressources de traitement des demandes. Les limites de débit limitent les demandes individuelles, de sorte que les volumes élevés de trafic provenant d'une seule adresse IP ou d'un seul API consommateur n'épuisent pas les ressources d'autres consommateurs.
Niveau d’exposition au risque si cette bonne pratique n’est pas respectée : élevé
Directives d’implémentation
Les services doivent être conçus pour traiter une capacité connue de demandes ; cette capacité peut être établie par des tests de charge. Si les taux d’arrivée des demandes dépassent les limites, la réponse appropriée indique qu’une demande a été limitée. Cela permet au consommateur de gérer l’erreur et de réessayer ultérieurement.
Lorsque votre service nécessite une implémentation de limitation, pensez à implémenter l’algorithme du compartiment à jetons, dans lequel un jeton compte pour une demande. Les jetons sont rechargés à une vitesse limitée par seconde et vidés de manière asynchrone à raison d’un jeton par demande.
Amazon API Gateway
Étapes d’implémentation
Vous pouvez configurer API Gateway avec des limites de limitation pour vos erreurs APIs et renvoyer des 429 Too Many Requests
erreurs lorsque les limites sont dépassées. Vous pouvez l'utiliser AWS WAF avec vos points de terminaison AWS AppSync et API Gateway pour activer la limitation du débit par adresse IP. En outre, lorsque votre système peut tolérer un traitement asynchrone, vous pouvez placer les messages dans une file d’attente ou un flux pour accélérer les réponses aux clients du service, ce qui vous permet d’atteindre des taux de limitation plus élevés.
Avec le traitement asynchrone, lorsque vous avez configuré Amazon SQS comme source d'événements pour AWS Lambda, vous pouvez configurer une simultanéité maximale afin d'éviter que des taux d'événements élevés ne consomment le quota d'exécution simultanée du compte disponible nécessaire pour les autres services de votre charge de travail ou de votre compte.
Bien que API Gateway fournisse une implémentation gérée du bucket de jetons, dans les cas où vous ne pouvez pas utiliser API Gateway, vous pouvez tirer parti des implémentations open source spécifiques au langage (voir les exemples connexes dans Ressources) du bucket de jetons pour vos services.
-
Comprenez et configurez les limites de limitation de API Gateway au niveau du compte, par région, par étape, et API par API clé par niveau de plan d'utilisation.
-
Appliquez des règles AWS WAF de limitation de débit
à API Gateway et aux AWS AppSync terminaux pour vous protéger contre les inondations et bloquer les programmes malveillantsIPs. Les règles de limitation du débit peuvent également être configurées sur AWS AppSync API les clés pour les consommateurs A2A. -
Déterminez si vous avez besoin de plus de contrôle de la régulation que de la limitation du débit et AWS AppSync APIs, dans l'affirmative, configurez une API passerelle devant votre AWS AppSync terminal.
-
Lorsque les SQS files d'attente Amazon sont configurées comme déclencheurs pour les consommateurs de files d'attente Lambda, définissez la simultanéité maximale sur une valeur qui traite suffisamment pour atteindre vos objectifs de niveau de service mais qui ne respecte pas les limites de simultanéité ayant un impact sur les autres fonctions Lambda. Envisagez de définir une simultanéité réservée pour d’autres fonctions Lambda du même compte et de la même région lorsque vous utilisez des files d’attente avec Lambda.
-
Utilisez API Gateway avec des intégrations de services natives à Amazon SQS ou Kinesis pour mettre en mémoire tampon les demandes.
-
Si vous ne pouvez pas utiliser API Gateway, consultez les bibliothèques spécifiques au langage pour implémenter l'algorithme Token bucket adapté à votre charge de travail. Consultez la section des exemples et faites vos propres recherches pour trouver une bibliothèque appropriée.
-
Testez les limites que vous envisagez de définir ou d’autoriser à augmenter, et documentez les limites testées.
-
N’augmentez pas les limites au-delà de ce que vous avez établi lors des tests. Lorsque vous augmentez une limite, vérifiez que les ressources provisionnées sont déjà équivalentes ou supérieures à celles des scénarios de test avant d’appliquer l’augmentation.
Ressources
Bonnes pratiques associées :
Documents connexes :
Exemples connexes :
Vidéos connexes :
Outils associés :