Comment puis-je résoudre une limitation des appels d’API ou de dépassement du débit dans Elastic Beanstalk ?

Lecture de 5 minute(s)
0

Comment puis-je résoudre une limitation des appels d’API ou de dépassement du débit dans AWS Elastic Beanstalk ?

Courte description

Les appels d'API en direction de tout service AWS ne peuvent pas excéder le débit maximal de demandes d’API par seconde. La limite est partagée entre toutes les ressources par compte et par région AWS.

Peu importe que les appels proviennent d'une application, de l'interface de la ligne de commande AWS (AWS CLI) ou de la console de gestion AWS. Si les requêtes d’API dépassent le débit maximal par seconde, le message d’erreur "Dépassement du débit" s’affiche et les appels d’API sont ensuite limités. Certains appels d'API peuvent être effectués des dizaines de fois par seconde, tandis que d'autres sont limités à quelques appels autorisés par seconde.

Remarque : si vous recevez des erreurs lors de l'exécution de commandes depuis l'interface de la ligne de commande AWS (AWS CLI), assurez-vous d'utiliser la version la plus récente d'AWS CLI.

Vous pouvez recevoir des erreurs provenant d'appels d'API effectués directement à Elastic Beanstalk, ainsi que d'autres services AWS gérés par Elastic Beanstalk, tels qu'AWS CloudFormation, Amazon Elastic Compute Cloud (Amazon EC2), Auto Scaling et Load Balancing. Le risque de limitation augmente à mesure que l'utilisation du compte augmente ou que vous ajoutez des ressources supplémentaires au même compte.

Remarque : la limite des appels peut varier selon l'heure de la journée, car nos services s'adaptent en fonction de la charge. Il est recommandé d'ajuster dynamiquement le débit d'utilisation de l'API pour s'adapter au comportement des limites dynamiques.

Solution

Pour éviter que le message "Dépassement du débit" ne s’affiche ou qu’une limitation ne se produise, essayez les procédures suivantes :

Trouver la source des appels d'API les plus importants

1.    Dans votre flux d’événements Elastic Beanstalk, recherchez le message d’erreur concerné. Prenez note de la période à laquelle vous avez reçu l’erreur. Ou, si les appels d'API proviennent d'une application ou d'un script, recherchez la période dans les journaux de votre application.

2.    En cas de requêtes détectées et associées au message d’erreur RequestLimitExceeded, utilisez AWS CloudTrail pour consulter la liste des événements et identifier les éléments suivants : eventName, eventSource et userAgent. Faites correspondre l'horodatage de l'erreur dans les événements Elastic Beanstalk ou dans vos journaux avec les erreurs détectées dans CloudTrail. Cela vous aidera à savoir quelle source de votre compte consomme le plus d'appels d'API.

Remarque : il peut être difficile de compter manuellement les enregistrements CloudTrail. Vous pouvez également utiliser des requêtes Athena via CloudTrail.

Les métriques d'utilisation d'Amazon CloudWatch peuvent vous aider à surveiller votre utilisation des API au fil du temps. Notez que pour le moment tous les services et appels d'API ne sont pas pris en charge dans les métriques d'utilisation.

Les applications tierces peuvent effectuer des appels continus en direction d’Elastic Beanstalk ou d’autres services AWS gérés par Elastic Beanstalk. Si vous accordez à une application tierce le droit d'effectuer des appels d'API sur votre compte, assurez-vous de les surveiller également.

Utilisez les meilleures pratiques pour réduire l'utilisation des API

Les logiques de type nouvelle tentative après erreur, les backoffs exponentiels et l’instabilité permettent de limiter le débit d’appels d’API. Bien que chaque SDK d’AWS implémente une logique de nouvelle tentative automatique et des algorithmes de backoff exponentiel, vous pourriez avoir besoin d’ajuster les paramètres de configuration du SDK pour répondre à vos besoins, si la logique de nouvelle tentative par défaut ne suffit pas.

Remarque : les paramètres du SDK ne sont qu'un élément à prendre en compte. Votre propre code doit également utiliser une logique de backoff, de nouvelle tentative et d’instabilité lors de l'appel du SDK.

Si vous disposez d'un script personnalisé qui effectue des appels d'API toutes les secondes, demandez-vous si cela est nécessaire. Pour les cas d'utilisation avancés, envisagez de créer une couche de mise en cache afin de réduire la consommation d'API. Vous pouvez également envisager une stratégie multi-comptes. Il est recommandé d'éviter qu'un seul compte AWS ne devienne trop important. La séparation des ressources de développement ou de test des ressources de production peut empêcher les ressources de développement de détourner l'utilisation des API des ressources de production.

Demandez une augmentation de votre limite du débit d'appels d'API

Si nécessaire, vous pouvez demander une augmentation de votre limite du débit d'appels d'API. Ces limites sont plus difficiles à augmenter que les limites classiques basées sur les ressources et nécessitent une solide justification de cas d'utilisation. Nos équipes examineront vos API et veilleront à ce que les meilleures pratiques soient suivies. Les demandes doivent être faites bien avant que vous en ayez besoin.

Lorsque vous demandez une augmentation, incluez les informations suivantes :

  • Votre région AWS et la période liée aux problèmes de limitation
  • L'appel d'API que vous utilisez et le débit d'appel dont vous avez besoin
  • Une justification détaillée du cas d'utilisation, telle que le besoin commercial et le besoin technique de l'augmentation

Assurez-vous d'essayer les nouvelles tentatives après erreur, les backoffs exponentiels et l’instabilité avant d'envoyer la demande. Incluez les résultats de ces tentatives dans la demande et toute information relative à ces tentatives.


Informations connexes

Nouvelle tentative après erreur et backoff exponentiel dans AWS

Backoff exponentiel et instabilité

Journalisation des appels d’API d’Elastic Beanstalk avec AWS CloudTrail

Métriques d'utilisation CloudWatch

Avantages liés à l'utilisation de plusieurs comptes AWS

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a 2 ans