REL05-BP03 Contrôler et limiter les appels de nouvelle tentative
Utilisez le backoff exponentiel pour relancer les demandes à des intervalles de plus en plus longs entre chaque nouvelle tentative. Introduisez un décalage entre les tentatives afin de randomiser les intervalles entre les tentatives. Limitez le nombre maximal de tentatives.
Résultat souhaité : les composants types d’un système logiciel distribué incluent les serveurs, les équilibreurs de charge, les bases de données et les serveurs DNS. Pendant le fonctionnement normal, ces composants peuvent répondre aux demandes par des erreurs temporaires ou limitées, ainsi que par des erreurs qui persisteraient indépendamment des nouvelles tentatives. Lorsque des clients adressent des demandes à des services, celles-ci consomment des ressources, notamment de la mémoire, des threads, des connexions, des ports ou toute autre ressource limitée. Le contrôle et la limitation des nouvelles tentatives constituent une stratégie visant à libérer et à minimiser la consommation de ressources afin que les composants du système soumis à des contraintes ne soient pas surchargés.
Lorsque le client demande une expiration du délai ou reçoit des réponses d’erreur, il doit décider de réessayer ou non. S’il recommence, il le fait avec un backoff exponentiel avec une instabilité et une valeur de nouvelle tentative maximale. Par conséquent, les services et processus back-end sont moins sollicités et le temps nécessaire pour s’autoréparer est réduit, ce qui se traduit par une récupération plus rapide et un traitement efficace des demandes.
Anti-modèles courants :
-
Implémentation de nouvelles tentatives sans ajouter de valeurs de backoff exponentiel, d’instabilité et de nouvelles tentatives maximales. Le backoff et l’instabilité permettent d’éviter les pics de trafic artificiels dus à des tentatives involontaires coordonnées à intervalles réguliers.
-
Implémentation de nouvelles tentatives sans tester leurs effets ou en supposant que les nouvelles tentatives sont déjà intégrées dans un kit SDK sans tester de scénarios de nouvelles tentatives.
-
Incapacité à comprendre les codes d’erreur publiés à partir des dépendances, ce qui entraîne une nouvelle tentative pour toutes les erreurs, y compris celles dont la cause claire indique un manque d’autorisation, une erreur de configuration ou toute autre condition qui, comme on pouvait s’y attendre, ne sera pas résolue sans intervention manuelle.
-
Ne pas aborder les pratiques d’observabilité, notamment la surveillance et l’envoi d’alertes en cas de pannes de service répétées afin que les problèmes sous-jacents soient connus et puissent être résolus.
-
Développement de mécanismes de nouvelle tentative personnalisés lorsque des fonctionnalités de nouvelle tentative intégrées ou tierces suffisent.
-
Réessayer à plusieurs couches de votre pile d’applications d’une manière qui complique les nouvelles tentatives et augmente la consommation de ressources lors d’une tempête de nouvelles tentatives. Assurez-vous de comprendre comment ces erreurs affectent votre application et les dépendances sur lesquelles vous vous appuyez, puis implémentez les nouvelles tentatives à un seul niveau.
-
Réessayer les appels de service qui ne sont pas idempotents, ce qui peut entraîner des effets secondaires inattendus tels que des résultats dupliqués.
Avantages du respect de cette bonne pratique : les nouvelles tentatives aident les clients à obtenir les résultats souhaités lorsque les requêtes échouent, mais elles font également perdre plus de temps au serveur pour obtenir les réponses souhaitées. Lorsque les défaillances sont rares ou transitoires, les nouvelles tentatives fonctionnent bien. Lorsque les défaillances sont causées par une surcharge de ressources, les nouvelles tentatives peuvent aggraver la situation. L’ajout d’un backoff exponentiel avec instabilité aux nouvelles tentatives des clients permet aux serveurs de se rétablir en cas de défaillance provoquée par une surcharge de ressources. L’instabilité permet d’éviter l’alignement des demandes en pics, tandis que le backoff réduit l’escalade de charge provoquée par l’ajout de nouvelles tentatives au chargement normal des demandes. Enfin, il est important de configurer un nombre maximal de nouvelles tentatives ou un temps écoulé afin d’éviter de créer des backlogs susceptibles d’entraîner des échecs métastables.
Niveau d’exposition au risque si cette bonne pratique n’est pas respectée : élevé
Directives d’implémentation
Contrôler et limiter les appels de nouvelle tentative. Utilisez le backoff exponentiel pour réessayer après des intervalles progressivement plus longs. Introduisez l’instabilité pour randomiser les intervalles de nouvelle tentative et limiter le nombre maximal de nouvelles tentatives.
Les kits AWS SDK implémentent les nouvelles tentatives et le backoff exponentiel par défaut. Utilisez ces implémentations AWS intégrées là où cela s’avère nécessaire dans votre charge de travail. Implémentez une logique similaire dans votre charge de travail lorsque vous appelez des services qui sont idempotents et où les nouvelles tentatives améliorent la disponibilité de vos clients. Déterminez quels sont les délais d’expiration et quand les nouvelles tentatives doivent s’arrêter en fonction de votre cas d’utilisation. Créez et mettez en pratique des scénarios de test pour ces cas d’utilisation impliquant de nouvelles tentatives.
Étapes d’implémentation
-
Déterminez la couche optimale de votre pile d’applications pour implémenter de nouvelles tentatives pour les services sur lesquels repose votre application.
-
Soyez conscient des SDK existants qui mettent en œuvre des stratégies de nouvelle tentative éprouvées avec un backoff exponentiel et une instabilité pour la langue de votre choix, et privilégiez-les par rapport à l’écriture de vos propres implémentations de nouvelles tentatives.
-
Vérifiez que les services sont idempotents
avant d’implémenter de nouvelles tentatives. Une fois les nouvelles tentatives mises en œuvre, assurez-vous qu’elles sont à la fois testées et régulièrement mises en œuvre en production. -
Lorsque vous appelez des API de service AWS, utilisez les AWSSDK et AWS CLI et comprenez les options de configuration de nouvelle tentative. Déterminez si les valeurs par défaut conviennent à votre cas d’utilisation, testez-les et ajustez-les si nécessaire.
Ressources
Bonnes pratiques associées :
Documents connexes :
Exemples associés :
Vidéos connexes :
Outils associés :
