# Conception des interactions dans un système distribué pour résister aux défaillances ou les atténuer
Les systèmes distribués s’appuient sur des réseaux de communication pour interconnecter des composants (tels que des serveurs ou des services). Votre charge de travail doit fonctionner de manière fiable malgré la perte de données ou la latence sur ces réseaux. Les composants du système distribué doivent fonctionner de manière à ne pas avoir d’impact négatif sur les autres composants ou sur la charge de travail. Ces bonnes pratiques permettent aux charges de travail de résister aux contraintes ou aux défaillances, de s’en remettre plus rapidement et d’atténuer l’impact de ces altérations. Il en résulte une amélioration du temps moyen de récupération (MTTR).
Ces bonnes pratiques permettent d’éviter les défaillances et d’améliorer le temps moyen entre défaillances (MTBF).
**Topics**
+ [REL05-BP01 Implémenter une dégradation appropriée pour transformer les dépendances matérielles applicables en dépendances logicielles](rel_mitigate_interaction_failure_graceful_degradation.md)
+ [REL05-BP02 Limiter les demandes](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Contrôler et limiter les appels de nouvelle tentative](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Procéder à une interruption immédiate et limiter les files d’attente](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Définir les délais d'expiration des clients](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 Rendre les systèmes apatrides dans la mesure du possible](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 Mettre en œuvre des leviers de secours](rel_mitigate_interaction_failure_emergency_levers.md)
# REL05-BP01 Implémenter une dégradation appropriée pour transformer les dépendances matérielles applicables en dépendances logicielles
Les composants de l’application doivent continuer à exécuter leur fonction principale même si les dépendances deviennent indisponibles. Ils peuvent fournir des données légèrement obsolètes, des données alternatives ou même aucune donnée. Cela garantit que le fonctionnement global du système n’est que très peu entravé par des défaillances localisées tout en fournissant une valeur commerciale centrale.
**Résultat escompté :** lorsque les dépendances d’un composant ne sont pas en bon état, le composant lui-même peut continuer de fonctionner, mais de manière dégradée. Les modes de défaillance des composants doivent être considérés comme un fonctionnement normal. Les flux de travail doivent être conçus de manière à ce que ces défaillances n’aboutissent pas à une défaillance complète ou qu’elles aboutissent au moins à des états prévisibles et récupérables.
**Anti-modèles courants :**
+ Ne pas identifier les fonctionnalités métier essentielles nécessaires. Ne pas tester le fonctionnement des composants, même en cas de défaillance des dépendances.
+ Aucune donnée n’est diffusée en cas d’erreur ou lorsqu’une seule dépendance parmi plusieurs n’est pas disponible et que des résultats partiels peuvent toujours être renvoyés.
+ Création d’un état incohérent lorsqu’une transaction échoue partiellement.
+ Ne pas disposer d’un autre moyen d’accéder à un magasin de paramètres central.
+ Invalider ou vider l’état local à la suite d’un échec d’actualisation sans prendre en compte les conséquences d’une telle opération.
**Avantages du respect de cette bonne pratique :** une dégradation progressive améliore la disponibilité du système dans son ensemble et maintient la fonctionnalité des fonctions les plus importantes même en cas de panne.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
La mise en œuvre d’une dégradation progressive permet de minimiser l’impact des défaillances de dépendance sur le fonctionnement des composants. Idéalement, un composant détecte les défaillances liées aux dépendances et les contourne de manière à avoir un impact minimal sur les autres composants ou les clients.
L’architecture permettant une dégradation progressive implique de prendre en compte les modes de défaillance potentiels lors de la conception des dépendances. Pour chaque mode de défaillance, déterminez un moyen de fournir la plupart des fonctionnalités, ou les plus critiques d’entre elles, du composant aux appelants ou aux clients. Ces considérations peuvent devenir des exigences supplémentaires qui peuvent être testées et vérifiées. Idéalement, un composant est capable d’exécuter sa fonction principale de manière acceptable, même en cas de défaillance d’une ou de plusieurs dépendances.
Il s’agit tout autant d’une discussion commerciale que technique. Toutes les exigences commerciales sont importantes et doivent être satisfaites dans la mesure du possible. Cependant, il est tout de même logique de se demander ce qui doit se passer lorsque toutes les exigences ne peuvent pas être satisfaites. Un système peut être conçu pour être disponible et cohérent, mais lorsqu’une exigence doit être supprimée, laquelle est la plus importante ? Pour le traitement des paiements, il peut s’agir de la cohérence. Pour une application en temps réel, il peut s’agir de la disponibilité. Pour un site Web orienté client, la réponse peut dépendre des attentes du client.
Ce que cela signifie dépend des exigences du composant et de ce qui doit être considéré comme sa fonction principale. Par exemple :
+ un site Web d’e-commerce peut afficher des données provenant de plusieurs systèmes différents, par exemple des recommandations personnalisées, les produits les mieux classés et l’état des commandes des clients sur la page de destination. Lorsqu’un système en amont est défaillant, il est tout de même judicieux d’afficher tout le reste au lieu d’afficher une page d’erreur à un client.
+ Un composant effectuant des écritures par lots peut toujours continuer à traiter un lot si l’une des opérations individuelles échoue. La mise en œuvre d’un mécanisme de nouvelle tentative doit être simple. Cela peut être fait en renvoyant à l’appelant des informations indiquant quelles opérations ont réussi, lesquelles ont échoué et pourquoi elles ont échoué, ou en plaçant les demandes ayant échoué dans une file d’attente de lettres mortes pour implémenter des tentatives asynchrones. Les informations relatives aux opérations ayant échoué doivent également être consignées.
+ Un système qui traite les transactions doit vérifier que toutes les mises à jour individuelles sont exécutées ou qu’aucune d’entre elles ne l’est. Pour les transactions distribuées, le modèle Saga peut être utilisé pour annuler les opérations précédentes en cas d’échec d’une opération ultérieure de la même transaction. Ici, la fonction principale est de maintenir la cohérence.
+ Les systèmes soumis à des contraintes de temps doivent être en mesure de gérer les dépendances qui ne répondent pas en temps voulu. Dans ces cas de figure, le modèle du disjoncteur peut être utilisé. Lorsque les réponses d’une dépendance commencent à expirer, le système peut passer à un état fermé où aucun appel supplémentaire n’est effectué.
+ Une application peut lire des paramètres à partir d’un magasin de paramètres. Il peut être utile de créer des images de conteneur avec un ensemble de paramètres par défaut et de les utiliser si le magasin de paramètres n’est pas disponible.
Notez que les chemins empruntés en cas de défaillance d’un composant doivent être testés et doivent être nettement plus simples que le chemin principal. Généralement, [les stratégies de repli doivent être évitées](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/).
## Étapes d’implémentation
Identifiez les dépendances externes et internes. Déterminez quels types de défaillances peuvent y survenir. Réfléchissez à des moyens de minimiser l’impact négatif sur les systèmes en amont et en aval, ainsi que sur les clients lors de ces défaillances.
Vous trouverez ci-dessous une liste des dépendances et la manière de les dégrader de façon appropriée en cas d’échec :
1. **Défaillance partielle des dépendances :** un composant peut adresser plusieurs demandes à des systèmes en aval, soit sous la forme de demandes multiples adressées à un système, soit sous celle d’une demande adressée à plusieurs systèmes. Selon le contexte métier, différentes méthodes de gestion peuvent être appropriées (pour plus de détails, voir les exemples précédents dans le guide de mise en œuvre).
1. **Un système en aval est incapable de traiter les demandes en raison d’une charge élevée :** si les demandes adressées à un système en aval échouent régulièrement, il n’est pas logique de continuer à réessayer. Cela peut créer une charge supplémentaire sur un système déjà surchargé et rendre la récupération plus difficile. Le modèle du disjoncteur peut être utilisé ici afin de surveiller les appels en échec vers un système en aval. Si un grand nombre d’appels échouent, il cessera d’envoyer d’autres demandes au système en aval et n’autorisera les appels qu’occasionnellement pour vérifier si le système en aval est à nouveau disponible.
1. **Aucun magasin de paramètres n’est disponible :** pour transformer un magasin de paramètres, vous pouvez utiliser la mise en cache des dépendances souples ou des valeurs par défaut saines incluses dans les images de conteneur ou de machine. Notez que ces valeurs par défaut doivent être tenues à jour et incluses dans les suites de tests.
1. **Aucun service de surveillance ou autre dépendance non fonctionnelle n’est disponible :** si un composant ne peut pas envoyer par intermittence des journaux, des métriques ou des traces à un service de surveillance central, il est souvent préférable de continuer à exécuter les fonctions métier comme d’habitude. Il est souvent inacceptable de ne pas enregistrer ni de pousser des métriques pendant une longue période. En outre, certains cas d’utilisation peuvent nécessiter des entrées d’audit complètes pour répondre aux exigences de conformité.
1. **Il est possible qu’une instance principale d’une base de données relationnelle ne soit pas disponible :** Amazon Relational Database Service, comme presque toutes les bases de données relationnelles, ne peut avoir qu’une seule instance de rédacteur principal. Cela crée un point de défaillance unique pour les charges de travail d’écriture et complique la mise à l’échelle. Ce problème peut être partiellement atténué en utilisant une configuration multi-AZ pour une haute disponibilité ou Amazon Aurora sans serveur pour une meilleure mise à l’échelle. Pour des exigences de très haute disponibilité, il peut être judicieux de ne pas se fier du tout au rédacteur principal. Pour les requêtes qui se limitent à la lecture, des répliques de lecture peuvent être utilisées, ce qui assure la redondance et la possibilité d’une augmentation horizontale, et pas seulement d’une augmentation verticale. Les écritures peuvent être mises en mémoire tampon, par exemple dans une file d’attente Amazon Simple Queue Service, afin que les demandes d’écriture des clients puissent toujours être acceptées même si le serveur principal est temporairement indisponible.
## Ressources
**Documents connexes :**
+ [Amazon API Gateway : Limitation des demandes d’API pour améliorer le débit](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Coupe-circuit (présentation du coupe-circuit, ouvrage « Release It\$1 »)](https://martinfowler.com/bliki/CircuitBreaker.html)
+ [Nouvelles tentatives après erreur et backoff exponentiel dans AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Michael Nygard « Release It\$1 Design and Deploy Production-Ready Software »](https://pragprog.com/titles/mnee2/release-it-second-edition/)
+ [L’Amazon Builders’ Library : éviter le basculement dans les systèmes distribués](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [L’Amazon Builders’ Library : éviter les retards de file d’attente insurmontables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [L’Amazon Builders’ Library : défis et stratégies de mise en cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Amazon Builders’ Library : délais d’attente, nouvelles tentatives et backoff avec instabilité](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Vidéos connexes :**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP02 Limiter les demandes
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 dépassé la limite.
**Résultat escompté :** 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 :**
+ Les limitations des points de terminaison de l’API ne sont pas implémentées ou leurs valeurs par défaut sont conservées sans tenir compte des volumes attendus.
+ Les points de terminaison de l’API ne sont pas testés en termes de charge ou les limites de régulation 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.
+ Aucun plan d’utilisation n’a été configuré ni envisagé pour les utilisateurs d’API 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 adressées aux API et aux files d’attente sont limités et n’épuisent pas les ressources de traitement des demandes. Les limites de débit limitent les requêtes individuelles afin que les volumes élevés de trafic provenant d’une seule adresse IP ou d’un seul utilisateur d’API n’épuisent pas les ressources et n’aient pas d’impact sur les 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.
![\[Schéma décrivant l’algorithme du compartiment à jetons.\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/reliability-pillar/images/token-bucket-algorithm.png)
[Amazon API Gateway](https://aws.amazon.com/api-gateway/) implémente l’algorithme du compartiment à jetons en fonction des limites du compte et de la région et il peut être configuré par client avec des plans d’utilisation. En outre, [Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/) et [Amazon Kinesis](https://aws.amazon.com/kinesis/) peuvent mettre en mémoire tampon les demandes afin de réduire le taux de demandes et de permettre des taux de limitation plus élevés pour les demandes pouvant être traitées. Enfin, vous pouvez implémenter une limitation de débit avec [AWS WAF](https://aws.amazon.com/waf/) pour limiter les consommateurs d’API spécifiques qui génèrent une charge anormalement élevée.
## Étapes d’implémentation
Vous pouvez configurer API Gateway avec des limites de régulation pour vos API et renvoyer des erreurs `429 Too Many Requests` lorsque les limites sont dépassées. Vous pouvez utiliser AWS WAF avec votre AWS AppSync et vos points de terminaison 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](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) 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 qu’API Gateway propose une implémentation gérée du compartiment à jetons, lorsque vous ne pouvez pas utiliser API Gateway, vous pouvez tirer parti des implémentations open source spécifiques à la langue (voir les exemples associés dans Ressources) du compartiment à jetons pour vos services.
+ Comprenez et configurez les [limites de limitation d’API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) au niveau du compte par région, de l’API par étape et de la clé d’API par niveau de plan d’utilisation.
+ Appliquez des [règles de limitation de débit AWS WAF](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/) à API Gateway et aux points de terminaison AWS AppSync pour vous protéger contre les inondations et bloquer les adresses IP malveillantes. Les règles de limitation de débit peuvent également être configurées sur les clés d’API AWS AppSync pour les consommateurs A2A.
+ Déterminez si vous avez besoin d’un contrôle plus limitant qu’une limitation du débit pour les API AWS AppSync et, si c’est le cas, configurez un API Gateway devant votre point de terminaison AWS AppSync.
+ Lorsque les files d’attente Amazon SQS sont configurées comme déclencheurs pour les consommateurs de files d’attente Lambda, définissez la [simultanéité maximale](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) 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 vers Amazon SQS ou Kinesis pour mettre des demandes en mémoire tampon.
+ Si vous ne pouvez pas utiliser API Gateway, examinez les bibliothèques spécifiques à la langue pour implémenter l’algorithme de compartiment à jetons 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 :**
+ [REL04-BP03 Faire un travail constant](rel_prevent_interaction_failure_constant_work.md)
+ [REL05-BP03 Contrôler et limiter les appels de nouvelle tentative](rel_mitigate_interaction_failure_limit_retries.md)
**Documents connexes :**
+ [Amazon API Gateway : Limitation des demandes d’API pour améliorer le débit](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [AWS WAF : instruction de règle fréquentielle ](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based.html)
+ [ Introduction d’une simultanéité maximale de AWS Lambda en utilisant Amazon SQS comme source d’événements ](https://aws.amazon.com/blogs/compute/introducing-maximum-concurrency-of-aws-lambda-functions-when-using-amazon-sqs-as-an-event-source/)
+ [AWS Lambda : simultanéité maximale ](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency)
**Exemples connexes :**
+ [ Les trois principales règles AWS WAF basées sur le débit ](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/)
+ [ Bucket4j Java ](https://github.com/bucket4j/bucket4j)
+ [ Jeton-compartiment Python ](https://pypi.org/project/token-bucket/)
+ [ Nœud jeton-compartiment ](https://www.npmjs.com/package/tokenbucket)
+ [ Limitation du débit de threading du système .NET ](https://www.nuget.org/packages/System.Threading.RateLimiting)
**Vidéos connexes :**
+ [ Implementing GraphQL API security best practices with AWS AppSync](https://www.youtube.com/watch?v=1ASMLeJ_15U)
**Outils associés :**
+ [ Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [ Amazon Kinesis ](https://aws.amazon.com/kinesis/)
+ [AWS WAF](https://aws.amazon.com/waf/)
+ [ Salle d’attente virtuelle sur AWS](https://aws.amazon.com/solutions/implementations/virtual-waiting-room-on-aws/)
# 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 escompté :** Les composants typiques d'un système logiciel distribué incluent les serveurs, les équilibreurs de charge, les bases de données et DNS les serveurs. 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 ou SDK sans test de scénarios de nouvelle tentative.
+ 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.
Certains AWS SDKs implémentent les nouvelles tentatives et le recul exponentiel par défaut. Utilisez ces AWS implémentations intégrées, le cas échéant, 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.
+ Tenez compte des stratégies de relance éprouvées SDKs qui mettent en œuvre des stratégies de relance éprouvées avec un retard et une instabilité exponentiels dans la langue de votre choix, et privilégiez ces stratégies par rapport à l'écriture de vos propres implémentations de nouvelle tentative.
+ Vérifiez que les [services sont idempotents](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/) 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 le AWS serviceAPIs, utilisez les options de configuration [AWS SDKs[AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-retries.html)](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html)et et comprenez la 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 :**
+ [REL04-BP04 Rendre les opérations de mutation idempotentes](rel_prevent_interaction_failure_idempotent.md)
+ [REL05-BP02 Limiter les demandes](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP04 Procéder à une interruption immédiate et limiter les files d’attente](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Définir les délais d'expiration des clients](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL11-BP01 Surveiller tous les composants de la charge de travail pour détecter les défaillances](rel_withstand_component_failures_monitoring_health.md)
**Documents connexes :**
+ [Rétentatives d'erreur et retard exponentiel dans AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Amazon Builders’ Library : délais d’attente, nouvelles tentatives et backoff avec instabilité](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [ Instabilité et backoff exponentiel ](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/)
+ [Sécuriser les nouvelles tentatives avec idempotent APIs](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)
**Exemples connexes :**
+ [ Nouvelle tentative Spring ](https://github.com/spring-projects/spring-retry)
+ [ Nouvelle tentative Resilience4j ](https://resilience4j.readme.io/docs/retry)
**Vidéos connexes :**
+ [Réessayez, attendez et agitez : AWS re:Invent 2019 : Introducing The Amazon Builders' Library () DOP328](https://youtu.be/sKRdemSirDM?t=1884)
**Outils associés :**
+ [AWS SDKset outils : comportement des nouvelles tentatives](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html)
+ [AWS Command Line Interface: nouvelles AWS CLI tentatives](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-retries.html)
# REL05-BP04 Procéder à une interruption immédiate et limiter les files d’attente
Lorsqu’un service n’est pas en mesure de répondre correctement à une demande, procédez à son interruption immédiate. Cela permet la libération des ressources associées à une demande et donne la possibilité au service de récupérer s’il lui manque des ressources. L’interruption immédiate est un modèle de conception logicielle bien établi qui peut être exploité pour créer des charges de travail hautement fiables dans le cloud. La mise en file d’attente est également un modèle d’intégration d’entreprise bien établi qui permet de faciliter le chargement et de permettre aux clients de libérer des ressources lorsque le traitement asynchrone peut être toléré. Lorsqu’un service est capable de répondre correctement dans des conditions normales, mais échoue lorsque le taux de demandes est trop élevé, utilisez une file d’attente pour mettre les demandes en mémoire tampon. Toutefois, ne permettez pas l’accumulation de longs backlogs de files d’attente susceptibles d’entraîner le traitement de demandes obsolètes auxquelles un client a déjà renoncé.
**Résultat escompté :** lorsque les systèmes sont confrontés à des problèmes de ressources, à des dépassements de délai, à des exceptions ou à des pannes grises qui rendent les objectifs de niveau de service irréalisables, les stratégies d’interruption immédiate permettent d’accélérer la récupération du système. Les systèmes qui doivent absorber les pics de trafic et peuvent prendre en charge le traitement asynchrone peuvent améliorer la fiabilité en permettant aux clients de lancer rapidement des demandes grâce à l’utilisation des files d’attente pour mettre en mémoire tampon les demandes envoyées aux services back-end. Lors de la mise en mémoire tampon des demandes dans des files d’attente, des stratégies de gestion des files d’attente sont mises en œuvre pour éviter des backlogs insurmontables.
**Anti-modèles courants :**
+ Mise en œuvre de files de messages sans configurer de files d’attente de lettres mortes (DLQ) ni d’alarmes sur les volumes DLQ pour détecter les défaillances d’un système.
+ Il ne s’agit pas de mesurer l’ancienneté des messages dans une file d’attente, mais de mesurer la latence pour comprendre quand les utilisateurs prennent du retard ou si des erreurs entraînent de nouvelles tentatives.
+ Conservation des messages en attente dans une file d’attente, alors qu’il n’est plus utile de traiter ces messages si l’entreprise n’en a plus besoin.
+ La configuration de files d’attente du premier entré, premier sorti (FIFO) au moment du dernier entré, premier sorti (LIFO) permettrait de mieux répondre aux besoins des clients, par exemple lorsqu’un ordre strict n’est pas requis et que le traitement du backlog retarde toutes les nouvelles demandes urgentes, ce qui entraîne une violation des niveaux de service pour tous les clients.
+ Exposition des files d’attente internes aux clients au lieu d’exposer les API qui gèrent la prise de travail et placent les demandes dans les files d’attente internes.
+ La combinaison d’un trop grand nombre de types de demandes de travail dans une seule file d’attente peut aggraver les problèmes de backlog en répartissant la demande de ressources entre les types de demandes.
+ Traitement de demandes complexes et simples dans la même file d’attente, malgré la nécessité d’une surveillance, de délais d’expiration et d’allocations de ressources différents.
+ Absence de validation des entrées ou utilisation des assertions pour implémenter des mécanismes d’interruption immédiate dans les logiciels qui génèrent des exceptions vers des composants de niveau supérieur capables de gérer les erreurs de façon appropriée.
+ Absence de suppression des ressources défectueuses du routage des requêtes, en particulier lorsque les défaillances sont grises, ce qui indique à la fois des réussites et des échecs en raison d’un plantage et d’un redémarrage, d’une panne de dépendance intermittente, d’une capacité réduite ou d’une perte de paquets réseau.
**Avantages du respect de cette bonne pratique :** les systèmes avec interruption immédiate sont plus faciles à déboguer et à corriger, et présentent souvent des problèmes de codage et de configuration avant la publication des versions en production. Les systèmes qui intègrent des stratégies de mise en file d’attente efficaces offrent une résilience et une fiabilité accrues face aux pics de trafic et aux pannes intermittentes du système.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Les stratégies d’interruption immédiate peuvent être codées dans des solutions logicielles ou configurées dans l’infrastructure. En plus de leur capacité d’interruption immédiate, les files d’attente constituent une technique architecturale simple mais puissante qui permet de découpler les composants du système en douceur. [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) fournit des fonctionnalités de surveillance et d’alerte en cas de défaillance. Une fois que l’on sait qu’un système est défaillant, des stratégies d’atténuation peuvent être invoquées, notamment en cas de défaillance de ressources altérées. Quand des systèmes implémentent des files d’attente avec [Amazon SQS](https://aws.amazon.com/sqs/) et d’autres technologies de file d’attente pour faciliter le chargement, ils doivent tenir compte de la gestion des backlogs de files d’attente, ainsi que des défaillances de consommation de messages.
## Étapes d’implémentation
+ Implémentez des assertions programmatiques ou des métriques spécifiques dans votre logiciel et utilisez-les pour signaler explicitement les problèmes du système. Amazon CloudWatch vous aide à créer des métriques et des alarmes reposant sur le modèle de journal des applications et l’instrumentation du SDK.
+ Utilisez les métriques et les alarmes CloudWatch pour éviter les problèmes liés à l’altération des ressources qui ajoutent de la latence au traitement ou qui échouent à plusieurs reprises à traiter les demandes.
+ Utilisez le traitement asynchrone en concevant des API pour accepter les demandes et les ajouter aux files d’attente internes en utilisant Amazon SQS, puis en répondant au client émetteur du message par un message de réussite afin que le client puisse libérer des ressources et passer à autre chose pendant que les utilisateurs de la file d’attente back-end traitent les demandes.
+ Mesurez et surveillez la latence de traitement des files d’attente en produisant une métrique CloudWatch chaque fois que vous retirez un message d’une file d’attente en comparant l’heure actuelle à l’horodatage du message.
+ Lorsque des défaillances empêchent le bon traitement des messages ou que des pics de trafic concernent des volumes qui ne peuvent pas être traités conformément aux contrats de niveau de service, mettez de côté le trafic ancien ou excédentaire vers une file d’attente de débordement. Cela permet de traiter en priorité les nouvelles tâches et les tâches plus anciennes lorsque la capacité est disponible. Cette technique est une approximation du traitement LIFO et permet un traitement normal du système pour toutes les nouvelles tâches.
+ Utilisez des lettres mortes ou réadaptez des files d’attente afin de déplacer les messages qui ne peuvent pas être traités hors du backlog vers un emplacement pouvant faire l’objet de recherches et de résolutions ultérieures.
+ Réessayez ou, si cela est acceptable, supprimez les anciens messages en comparant l’heure actuelle à l’horodatage du message et en supprimant les messages qui ne sont plus pertinents pour le client demandeur.
## Ressources
**Bonnes pratiques associées:**
+ [REL04-BP02 Implémenter des dépendances faiblement couplées](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL05-BP02 Limiter les demandes](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Contrôler et limiter les appels de nouvelle tentative](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL06-BP02 Définir et calculer des métriques (agrégation)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP07 Surveiller la traçabilité complète des demandes via votre système](rel_monitor_aws_resources_end_to_end.md)
**Documents connexes :**
+ [ Éviter les backlogs insurmontables dans les files d’attente ](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs/)
+ [Interruption immédiate](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ [ Comment puis-je empêcher un backlog de messages croissant dans ma file d’attente Amazon SQS ? ](https://repost.aws/knowledge-center/sqs-message-backlog)
+ [Elastic Load Balancing : changement de zone](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/zonal-shift.html)
+ [Amazon Application Recovery Controller : contrôle du routage pour le basculement du trafic](https://docs.aws.amazon.com/r53recovery/latest/dg/getting-started-routing-controls.html)
**Exemples connexes :**
+ [ Modèles d’intégration d’entreprise : canal des lettres mortes ](https://www.enterpriseintegrationpatterns.com/patterns/messaging/DeadLetterChannel.html)
**Vidéos connexes :**
+ [AWS re:Invent 2022 - Operating highly available Multi-AZ applications](https://www.youtube.com/watch?v=mwUV5skJJ0s)
**Outils associés :**
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [ Amazon MQ ](https://aws.amazon.com/amazon-mq/)
+ [AWS IoT Core](https://aws.amazon.com/iot-core/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
# REL05-BP05 Définir les délais d'expiration des clients
Définissez les délais d’expiration de manière appropriée pour les connexions et les demandes, vérifiez-les systématiquement et ne vous fiez pas aux valeurs par défaut, car elles ne tiennent pas compte des spécificités de la charge de travail.
**Résultat souhaité :** les délais d’expiration du client doivent prendre en compte le coût pour le client, le serveur et la charge de travail associés à l’attente des demandes dont le traitement prend un temps anormal. Dans la mesure où il est impossible de connaître la cause exacte d’un délai d’attente, les clients doivent utiliser leur connaissance des services pour établir des attentes relatives aux causes probables et aux délais d’expiration appropriés.
Le délai d’expiration des connexions client dépend des valeurs configurées. Après avoir dépassé le délai imparti, les clients décident de revenir en arrière et de réessayer ou d’ouvrir un [coupe-circuit](https://martinfowler.com/bliki/CircuitBreaker.html). Ces modèles évitent d’émettre des demandes susceptibles d’exacerber un problème d’erreur sous-jacent.
**Anti-modèles courants :**
+ Ne pas connaître les délais d’expiration du système ou les délais d’expiration par défaut.
+ Ne pas connaître le délai normal d’exécution des demandes.
+ Ne pas connaître les raisons pour lesquelles les demandes peuvent prendre un temps anormalement long à traiter, ni les coûts pour le client, le service ou les performances de la charge de travail associés à l’attente de ces traitements.
+ Ne pas connaître la probabilité qu’un réseau défaillant entraîne l’échec d’une requête uniquement lorsque le délai d’expiration est atteint, ainsi que les coûts pour les performances du client et de la charge de travail si l’on n’adopte pas un délai d’expiration plus court.
+ Ne pas tester les scénarios de délai d’expiration à la fois pour les connexions et les demandes.
+ Définir des délais d’expiration trop élevés, ce qui peut entraîner de longs temps d’attente et augmenter l’utilisation des ressources.
+ Définir des délais d’attente trop bas, ce qui entraîne des défaillances artificielles.
+ Oublier les modèles pour gérer les erreurs de temporisation des appels distants, par exemple les disjoncteurs et les nouvelles tentatives.
+ Ne pas envisager de surveiller les taux d’erreur des appels de service, les objectifs de niveau de service en matière de latence et les valeurs aberrantes en matière de latence. Ces métriques peuvent fournir des informations sur les délais d’attente agressifs ou permissifs.
**Avantages du respect de cette bonne pratique :** les délais d’expiration des appels distants sont configurés et les systèmes sont conçus pour gérer les délais d’expiration de façon appropriée afin de préserver les ressources lorsque les appels distants répondent de manière anormalement lente et que les erreurs de délai d’expiration sont gérées de façon appropriée par les clients du service.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Définissez un délai d’expiration de la connexion et un délai d’expiration de la demande pour tout appel de dépendance de service et, plus généralement, pour tout appel entre processus. De nombreux cadres proposent des capacités de délai d’expiration intégrées, mais soyez prudent, car certains ont des valeurs par défaut infinies ou supérieures à ce qui est acceptable pour vos objectifs de service. Une valeur trop élevée réduit l’utilité du délai d’attente, car les ressources continuent d’être consommées pendant que le client attend l’expiration du délai. Une valeur trop faible peut générer un trafic accru sur le back-end et une latence accrue en raison du nombre excessif de demandes réessayées. Dans certains cas, cela peut entraîner des interruptions complètes, car toutes les demandes font l’objet d’une nouvelle tentative.
Tenez compte des points suivants lorsque vous déterminez des stratégies de délai d’expiration :
+ Le traitement des demandes peut prendre plus de temps que d’habitude en raison de leur contenu, de défaillances d’un service cible ou d’une panne de partition réseau.
+ Les demandes dont le contenu est anormalement coûteux peuvent consommer des ressources inutiles du serveur et du client. Dans ce cas, le fait d’avoir un délai d’expiration pour ces demandes et de ne pas réessayer peut préserver les ressources. Les services doivent également se protéger contre les contenus anormalement coûteux avec des limites et des délais d’expiration côté serveur.
+ Les demandes qui prennent anormalement longtemps en raison d’une défaillance du service peuvent être interrompues et réessayées. Il convient de tenir compte des coûts de service liés à la demande et à la nouvelle tentative, mais si la cause est une déficience localisée, une nouvelle tentative ne sera probablement pas coûteuse et réduira la consommation de ressources du client. Le délai d’expiration peut également libérer des ressources du serveur en fonction de la nature de la déficience.
+ Les demandes dont l’exécution prend beaucoup de temps parce que la demande ou la réponse n’a pas été envoyée par le réseau peuvent être interrompues et réessayées. La demande ou la réponse n’ayant pas été envoyée, il en aurait résulté un échec indépendamment de la durée du délai imparti. Dans ce cas, l’expiration du délai ne libérera pas les ressources du serveur, mais des ressources client et cela améliorera les performances de la charge de travail.
Tirez parti de modèles de conception bien établis, tels que les nouvelles tentatives et les disjoncteurs, pour gérer les délais d'attente avec élégance et prendre en charge les approches rapides. [AWS SDKs](https://docs.aws.amazon.com/index.html#sdks)et [AWS CLI](https://aws.amazon.com/cli/)permettent de configurer les délais d'expiration des connexions et des demandes ainsi que les nouvelles tentatives avec un retard et une instabilité exponentiels. [AWS Lambda](https://aws.amazon.com/lambda/)les fonctions prennent en charge la configuration des délais d'attente, et avec [AWS Step Functions](https://aws.amazon.com/step-functions/), vous pouvez créer des disjoncteurs low code qui tirent parti des intégrations prédéfinies avec les services et. AWS SDKs [AWS App Mesh](https://aws.amazon.com/app-mesh/) Envoy fournit des fonctionnalités de délai d’expiration et de disjoncteur.
## Étapes d’implémentation
+ Configurez les délais d’expiration pour les appels de service à distance et profitez des fonctionnalités de délai d’expiration spécifique à la langue intégrées ou des bibliothèques de délai d’expiration open source.
+ Lorsque votre charge de travail passe des appels avec un AWS SDK, consultez la documentation pour connaître la configuration du délai d'expiration spécifique à la langue.
+ [ Python ](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html)
+ [ PHP ](https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.DefaultsMode.Configuration.html)
+ [ .NET ](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [ Ruby ](https://docs.aws.amazon.com/sdk-for-ruby/v3/developer-guide/timeout-duration.html)
+ [ Java ](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/best-practices.html#bestpractice5)
+ [ Go ](https://aws.github.io/aws-sdk-go-v2/docs/configuring-sdk/retries-timeouts/#timeouts)
+ [ Node.js ](https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/Config.html)
+ [ C\$1\$1 ](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/client-config.html)
+ Lorsque vous utilisez des AWS CLI commandes AWS SDKs or dans votre charge de travail, configurez les valeurs de délai d'expiration par défaut en définissant les AWS [valeurs par défaut](https://docs.aws.amazon.com/sdkref/latest/guide/feature-smart-config-defaults.html) pour `connectTimeoutInMillis` et. `tlsNegotiationTimeoutInMillis`
+ Appliquez des [options de ligne de commande](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html) `cli-connect-timeout` et `cli-read-timeout` contrôlez des AWS CLI commandes ponctuelles aux AWS services.
+ Surveillez les appels de service à distance pour détecter les délais d’expiration et définissez des alarmes en cas d’erreurs persistantes afin de pouvoir gérer de manière proactive les scénarios d’erreur.
+ Mettez en œuvre [CloudWatch des mesures](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) et [CloudWatch une détection des anomalies](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) sur les taux d'erreur des appels, les objectifs de niveau de service en matière de latence et les valeurs aberrantes de latence afin de mieux comprendre la gestion des délais d'attente trop agressifs ou trop permissifs.
+ Configurez les délais d’expiration des [fonctions Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html#configuration-timeout-console).
+ APILes clients Gateway doivent implémenter leurs propres tentatives lors de la gestion des délais d'expiration. APIGateway prend en charge un [délai d'intégration de 50 millisecondes à 29 secondes pour les](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html#api-gateway-execution-service-limits-table) intégrations en aval et ne réessaie pas lorsque les demandes d'intégration expirent.
+ Implémentez le modèle de [disjoncteur](https://martinfowler.com/bliki/CircuitBreaker.html) pour éviter de passer des appels à distance lorsque le délai d’expiration est écoulé. Ouvrez le circuit pour éviter les échecs d’appels et fermez-le lorsque les appels répondent normalement.
+ Pour les charges de travail basées sur des conteneurs, consultez les fonctionnalités d’[App Mesh Envoy](https://docs.aws.amazon.com/app-mesh/latest/userguide/envoy.html) pour tirer parti des délais d’attente et des disjoncteurs intégrés.
+ AWS Step Functions À utiliser pour créer des disjoncteurs à faible code pour les appels de service à distance, en particulier lorsque vous faites appel à des intégrations Step Functions AWS natives SDKs et compatibles afin de simplifier votre charge de travail.
## Ressources
**Bonnes pratiques associées :**
+ [REL05-BP03 Contrôler et limiter les appels de nouvelle tentative](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Procéder à une interruption immédiate et limiter les files d’attente](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL06-BP07 Surveiller la traçabilité complète des demandes via votre système](rel_monitor_aws_resources_end_to_end.md)
**Documents connexes :**
+ [AWS SDK: tentatives et délais d'expiration](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [Amazon Builders’ Library : délais d’attente, nouvelles tentatives et backoff avec instabilité](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [Quotas Amazon API Gateway et remarques importantes](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html)
+ [AWS Command Line Interface : options de ligne de commande ](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html)
+ [AWS SDK for Java 2.x: Configurer les API délais](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/best-practices.html#bestpractice5)
+ [AWS Botocore utilisant l'objet de configuration et la référence de configuration](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html#using-the-config-object)
+ [AWS SDK pour .NET : nouvelles tentatives et délais d’expiration ](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [AWS Lambda : configuration des options de fonction Lambda ](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html)
**Exemples connexes :**
+ [Utilisation du schéma du disjoncteur avec AWS Step Functions Amazon DynamoDB](https://aws.amazon.com/blogs/compute/using-the-circuit-breaker-pattern-with-aws-step-functions-and-amazon-dynamodb/)
+ [Martin Fowler : CircuitBreaker](https://martinfowler.com/bliki/CircuitBreaker.html?ref=wellarchitected)
**Outils associés :**
+ [AWS SDKs ](https://docs.aws.amazon.com/index.html#sdks)
+ [AWS Lambda](https://aws.amazon.com/lambda/)
+ [Amazon SQS](https://aws.amazon.com/sqs/)
+ [AWS Step Functions](https://aws.amazon.com/step-functions/)
+ [AWS Command Line Interface](https://aws.amazon.com/cli/)
# REL05-BP06 Rendre les systèmes apatrides dans la mesure du possible
Les systèmes ne doivent pas exiger d’état ou doivent décharger un état de telle sorte qu’entre les différentes demandes client, il n’y ait pas de dépendance vis-à-vis des données stockées localement sur disque et en mémoire. Cela permet le remplacement à volonté des serveurs sans impact sur la disponibilité.
Lorsque des utilisateurs ou des services interagissent avec une application, ils exécutent souvent une série d’interactions qui forment une session. Une session correspond aux données uniques des utilisateurs qui persistent entre les requêtes pendant l’utilisation de l’application. Une application sans état n’a pas besoin de connaître les interactions précédentes et ne stocke pas d’informations de session.
Une fois conçu pour être apatride, vous pouvez ensuite utiliser des services de calcul sans serveur, tels que AWS Lambda ou. AWS Fargate
Outre le remplacement des serveurs, les applications apatrides présentent un autre avantage : elles peuvent évoluer horizontalement, car toutes les ressources informatiques disponibles (telles que les EC2 instances et les AWS Lambda fonctions) peuvent répondre à toutes les demandes.
**Avantages du respect de cette bonne pratique :** les systèmes conçus pour être sans état sont plus adaptables à la mise à l’échelle horizontale, ce qui permet d’ajouter ou de supprimer des capacités en fonction des fluctuations du trafic et de la demande. Ils sont également intrinsèquement résilients aux défaillances et offrent flexibilité et agilité dans le cadre du développement d’applications.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
Rendre vos applications sans état. Les applications sans état permettent une mise à l’échelle horizontale et tolèrent la défaillance d’un nœud individuel. Analysez et comprenez les composants de votre application qui conservent leur état au sein de l’architecture. Cela vous permet d’évaluer l’impact potentiel de la transition vers une conception sans état. Une architecture sans état découple les données utilisateur et décharge les données de session. Cela permet de mettre à l’échelle chaque composant indépendamment pour répondre à des demandes variables de charge de travail et optimiser l’utilisation des ressources.
### Étapes d’implémentation
+ Identifiez et comprenez les composants avec état dans votre application.
+ Découplez les données en séparant et en gérant les données utilisateur de la logique principale de l’application.
+ [Amazon Cognito](https://aws.amazon.com/cognito/) peut découpler les données utilisateur du code de l’application en utilisant des fonctionnalités telles que les [groupes d’identités](https://docs.aws.amazon.com/cognito/latest/developerguide/getting-started-with-identity-pools.html), les [groupes d’utilisateurs](https://docs.aws.amazon.com/cognito/latest/developerguide/getting-started-with-cognito-user-pools.html) et [Amazon Cognito Sync.](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-sync.html)
+ Vous pouvez utiliser [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) pour découpler les données utilisateur en stockant les secrets dans un emplacement sécurisé et centralisé. Cela signifie que le code de l’application n’a pas besoin de stocker de secrets, ce qui le rend plus sécurisé.
+ Envisagez d’utiliser [Amazon S3](https://aws.amazon.com/s3/) pour stocker des données volumineuses non structurées, telles que des images et des documents. Votre application peut récupérer ces données en cas de besoin, évitant ainsi d’avoir à les stocker en mémoire.
+ Utilisez [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) pour stocker des informations telles que les profils utilisateur. Votre application peut interroger ces données en temps quasi réel.
+ Déchargez les données de session dans une base de données, un cache ou des fichiers externes.
+ [Amazon ElastiCache](https://aws.amazon.com/elasticache/), Amazon DynamoDB, Amazon [Elastic File System (Amazon](https://aws.amazon.com/efs/)) et EFS [Amazon](https://aws.amazon.com/memorydb/) MemoryDB sont des exemples de services que vous pouvez utiliser pour AWS décharger des données de session.
+ Concevez une architecture sans état après avoir identifié les données d’état et d’utilisateur qui doivent être conservées avec la solution de stockage de votre choix.
## Ressources
**Bonnes pratiques associées :**
+ [REL11-BP03 Automatiser la guérison sur toutes les couches](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_auto_healing_system.html)
**Documents connexes :**
+ [L’Amazon Builders’ Library : éviter le basculement dans les systèmes distribués](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [L’Amazon Builders’ Library : éviter les retards de file d’attente insurmontables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [L’Amazon Builders’ Library : défis et stratégies de mise en cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Bonnes pratiques pour Stateless Web Tier sur AWS](https://docs.aws.amazon.com/whitepapers/latest/best-practices-wordpress/stateless-web-tier.html)
# REL05-BP07 Mettre en œuvre des leviers de secours
Les leviers d’urgence sont des processus rapides qui peuvent réduire l’impact sur la disponibilité de votre charge de travail.
Les leviers d’urgence fonctionnent en désactivant, en limitant ou en modifiant le comportement des composants ou des dépendances à l’aide de mécanismes connus et testés. Ils permettent d’atténuer les perturbations de la charge de travail causées par l’épuisement des ressources dû à une augmentation inattendue de la demande et de réduire l’impact des défaillances des composants non stratégiques de votre charge de travail.
**Résultat souhaité :** en mettant en œuvre des leviers d’urgence, vous pouvez établir des processus dont le fonctionnement a été vérifié pour maintenir la disponibilité des composants essentiels de votre charge de travail. La charge de travail devrait se dégrader de manière appropriée et continuer à remplir ses fonctions stratégiques durant l’activation d’un levier d’urgence. Pour plus de détails sur la dégradation progressive, voir [REL05-BP01 Implémenter la dégradation progressive pour transformer les dépendances strictes applicables en dépendances souples](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html).
**Anti-modèles courants :**
+ La défaillance des dépendances non stratégiques a un impact sur la disponibilité de votre charge de travail principale.
+ Le comportement des composants stratégiques n’est pas testé ou vérifié lors d’une défaillance d’un composant non stratégique.
+ Aucun critère clair et déterministe n’a été défini pour l’activation ou la désactivation d’un levier d’urgence.
**Avantages du respect de cette bonne pratique :** la mise en œuvre de leviers d’urgence peut améliorer la disponibilité des composants critiques de votre charge de travail en fournissant à vos résolveurs des processus établis pour répondre aux pics de demande inattendus ou aux défaillances liées à des dépendances non critiques.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
+ Identifier les composants stratégiques de votre charge de travail.
+ Concevoir et construire les composants stratégiques de votre charge de travail de manière à ce qu’ils résistent aux défaillances des composants non stratégiques.
+ Effectuer des tests pour valider le comportement de vos composants stratégiques en cas de défaillance des composants non stratégiques.
+ Définir et surveiller des métriques ou des déclencheurs pertinents pour lancer des procédures de levier d’urgence.
+ Définir les procédures (manuelles ou automatisées) qui comprennent le levier d’urgence.
### Étapes d’implémentation
+ Identifier les composants stratégiques de votre charge de travail.
+ Chaque composant technique de votre charge de travail doit être associé à la fonction commerciale correspondante et classé comme stratégique ou non stratégique. Pour des exemples de fonctionnalités critiques et non critiques d’Amazon, consultez [Any Day Can Be Prime Day: How Amazon.com Search Uses Chaos Engineering to Handle Over 84K Requests Per Second](https://community.aws/posts/how-search-uses-chaos-engineering).
+ Il s’agit d’une décision à la fois technique et commerciale, qui varie en fonction de l’organisation et de la charge de travail.
+ Concevoir et construire les composants stratégiques de votre charge de travail de manière à ce qu’ils résistent aux défaillances des composants non stratégiques.
+ Lors de l’analyse des dépendances, tenez compte de tous les modes de défaillance potentiels et vérifiez que vos mécanismes de levier d’urgence fournissent les fonctionnalités stratégiques aux composants en aval.
+ Effectuer des tests pour valider le comportement de vos composants stratégiques pendant l’activation de vos leviers d’urgence.
+ Éviter les comportements bimodaux. Pour plus de détails, voir [REL11-BP05 Utiliser la stabilité statique pour empêcher le comportement bimodal](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html).
+ Définir et surveiller des métriques pertinentes pour lancer des procédures de levier d’urgence.
+ La recherche des bonnes métriques à surveiller dépend de votre charge de travail. Parmi les métriques, citons la latence ou le nombre de demandes infructueuses à une dépendance.
+ Définir les procédures (manuelles ou automatisées) qui comprennent le levier d’urgence.
+ Cela peut inclure des mécanismes tels que le [délestage](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/), les [demandes de limitation](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html) ou la mise en œuvre d’une [dégradation appropriée](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html).
## Ressources
**Bonnes pratiques associées :**
+ [REL05-BP01 Implémenter une dégradation progressive pour transformer les dépendances matérielles applicables en dépendances souples](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html)
+ [REL05-BP02 Demandes d'accélérateur](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html)
+ [REL11-BP05 Utiliser la stabilité statique pour empêcher le comportement bimodal](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)
**Documents connexes :**
+ [ Automatiser les déploiements sécurisés et sans intervention ](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
+ [Any Day Can Be Prime Day: How Amazon.com Search Uses Chaos Engineering to Handle Over 84K Requests Per Second](https://community.aws/posts/how-search-uses-chaos-engineering)
**Vidéos connexes :**
+ [AWS re:Invent 2020 : fiabilité, cohérence et confiance grâce à l'immuabilité](https://www.youtube.com/watch?v=jUSYnRztttY)