# REL 5 Comment concevoir des interactions dans un système distribué pour atténuer ou résister aux défaillances ?
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 d'une manière qui n'a pas d'impact négatif sur les autres composants ou 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 déficiences. Il en résulte une amélioration du temps moyen de récupération (MTTR).
**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'attente du client](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 Rendre les services sans état dans la mesure du possible](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 Mettre en place des leviers d'urgence](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
Lorsque les dépendances d'un composant ne sont pas saines, le composant lui-même peut continuer de fonctionner, même si de manière dégradée. Par exemple, lorsqu'un appel de dépendance échoue, basculez vers une réponse statique prédéterminée.
Prenons l'exemple d'un service B qui est appelé par le service A et qui, à son tour, appelle le service C.
![\[Schéma affichant le service C qui échoue lorsqu'il est appelé par le service B. Le service B renvoie une réponse dégradée au service A.\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/graceful-degradation.png)
Lorsque le service B appelle le service C, il reçoit une erreur ou une expiration de délai. Le service B, sans réponse du service C (et des données qu'il contient) renvoie ce qu'il peut. Il peut s'agir de la dernière valeur correcte mise en cache, ou le service B peut remplacer une réponse statique prédéterminée par celle qu'il aurait reçue du service C. Il peut ensuite renvoyer une réponse dégradée à son mandataire, le service A. Sans cette réponse statique, la défaillance du service C se répercuterait entre les services B et A, ce qui entraînerait une perte de disponibilité.
Selon le facteur multiplicatif de l'équation de disponibilité des dépendances strictes (voir [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122)), toute diminution de la disponibilité de C a un impact important sur la disponibilité effective de B. En renvoyant la réponse statique, le service B atténue la panne de C et, bien que dégradée, fait en sorte que la disponibilité du service C ressemble à une disponibilité de 100 % (en supposant qu'il renvoie de manière fiable la réponse statique dans des conditions d'erreur). Notez que la réponse statique est une alternative simple au renvoi d'une erreur et n'est pas une tentative de recalcul de la réponse par différents moyens. Ces tentatives reposant sur un mécanisme totalement différent pour tenter d'obtenir le même résultat constituent un comportement de secours et un anti-modèle à éviter.
Un autre exemple de dégradation appropriée est le *modèle de coupe-circuit*. Les stratégies reposant sur de nouvelles tentatives doivent être utilisées lorsque la défaillance est transitoire. Lorsque ce n'est pas le cas et que l'opération est susceptible d'échouer, le modèle de coupe-circuit empêche le client d'exécuter une demande susceptible d'échouer. Lorsque les demandes sont traitées normalement, le disjoncteur est fermé et ne les bloque pas. Lorsque le système distant commence à renvoyer des erreurs ou présente une latence élevée, le coupe-circuit s'ouvre et la dépendance est ignorée ou les résultats sont remplacés par des réponses obtenues plus simplement mais moins complètes (il peut simplement s’agir d’un cache de réponse). De temps à autre, le système tente d'appeler la dépendance pour déterminer si elle est à nouveau disponible. Lorsque cela se produit, le disjoncteur est fermé.
![\[Schéma montrant le disjoncteur dans les états ouvert et fermé.\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/circuit-breaker.png)
Outre les états fermés et ouverts affichés dans le diagramme, après une période de temps configurable à l'état ouvert, le coupe-circuit peut passer à l'état semi-ouvert. Dans cet état, il tente régulièrement d'appeler le service à un débit nettement inférieur à la normale. Cette sonde est utilisée pour vérifier l'état du service. Après un certain nombre de succès dans l'état semi-ouvert, le coupe-circuit passe à l’état fermé et les demandes normales reprennent.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Implémentez une dégradation appropriée pour transformer les dépendances matérielles applicables en dépendances logicielles. Lorsque les dépendances d'un composant ne sont pas saines, le composant lui-même peut continuer de fonctionner, même si de manière dégradée. Par exemple, lorsqu'un appel de dépendance échoue, basculez vers une réponse statique prédéterminée.
+ En renvoyant une réponse statique, votre charge de travail atténue les défaillances qui se produisent dans ses dépendances.
+ [Atelier Well-Architected : niveau 300 : implémentation de la surveillance de l'état et gestion des dépendances pour améliorer la fiabilité](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
+ Détectez le moment auquel l'opération de nouvelle tentative est susceptible d'échouer et empêchez votre client d'effectuer des appels en échec avec le modèle de coupe-circuit.
+ [Coupe-circuit](https://martinfowler.com/bliki/CircuitBreaker.html)
## Ressources
**Documents connexes :**
+ [Amazon API Gateway : limiter les demandes d'API pour un meilleur 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 interruptions exponentielles 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/)
+ [L'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)
**Exemples connexes :**
+ [Atelier Well-Architected : niveau 300 : implémentation de la surveillance de l'état et gestion des dépendances pour améliorer la fiabilité](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL05-BP02 Limiter les demandes
Limiter les demandes : il s'agit d'un modèle d'atténuation permettant de répondre à une augmentation inattendue de la demande. Certaines demandes sont honorées, mais celles qui dépassent une limite définie sont rejetées et renvoient un message indiquant qu'elles ont été limitées. On attend des clients qu'ils renoncent à leur demande ou qu'ils essaient à nouveau à un taux plus lent.
Vos services doivent être conçus pour gérer une capacité connue de demandes que chaque nœud ou cellule peut traiter. Cette capacité peut être établie grâce à un test de charge. Vous devez ensuite suivre la fréquence d'arrivée des requêtes et si la fréquence d'arrivée temporaire dépasse cette limite, la réponse appropriée est de signaler que la demande a été limitée. Ceci permet à l'utilisateur de réessayer, potentiellement sur un autre nœud/une autre cellule susceptible d'avoir une capacité disponible. Amazon API Gateway fournit des méthodes pour la limitation des demandes. Amazon SQS et Amazon Kinesis peuvent mettre les demandes en mémoire tampon, lisser le taux de demande et réduire la nécessité de limiter les demandes pouvant être traitées de manière asynchrone.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Limiter les demandes. Il s'agit d'un modèle d'atténuation conçu répondre à une augmentation inattendue de la demande. Certaines demandes sont honorées, mais celles qui dépassent une limite définie sont rejetées et renvoient un message indiquant qu'elles ont été limitées. On attend des clients qu'ils renoncent à leur demande ou qu'ils essaient à nouveau à un taux plus lent.
+ Utilisez Amazon API Gateway
+ [Limiter les demandes d'API pour un meilleur débit](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
## Ressources
**Documents connexes :**
+ [Amazon API Gateway : limiter les demandes d'API pour un meilleur débit](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Nouvelles tentatives après erreur et interruptions exponentielles dans AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [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élais d'attente, nouvelles tentatives et backoff avec instabilité](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [Limiter les demandes d'API pour un meilleur débit](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
**Vidéos connexes :**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP03 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 ces intervalles de nouvelle tentative et limitez le nombre maximal de nouvelles tentatives.
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. Ils peuvent tous commencer à générer des erreurs lorsqu’ils sont en fonctionnement et soumis à des défaillances. La technique par défaut de gestion des erreurs consiste à implémenter les nouvelles tentatives côté client. Cette technique augmente la fiabilité et la disponibilité de l'application. Cependant, à grande échelle (et si les clients tentent de relancer l'opération ayant échoué dès qu'une erreur se produit), le réseau peut rapidement devenir saturé par de nouvelles requêtes et mises hors service, chacune en concurrence pour la bande passante réseau. Cela peut entraîner une *tempête de nouvelles tentatives,* ce qui réduira la disponibilité du service. Ce modèle peut continuer de fonctionner jusqu'à une défaillance système complète.
Pour éviter de tels scénarios, des algorithmes de temporisation, comme une temporisation *exponentielle usuelle,* doivent être utilisés. Les algorithmes de temporisation exponentielle diminuent progressivement la vitesse à laquelle les nouvelles tentatives sont exécutées, ce qui évite la congestion du réseau.
Une multitude de kits SDK et de bibliothèques logicielles, y compris ceux d'AWS, permettent l'implémentation d'une version de ces algorithmes. Cependant, **ne supposez jamais qu'un algorithme de temporisation existe ; testez toujours et vérifiez que c'est le cas.**
Une temporisation simple ne suffit pas à elle seule, car dans les systèmes distribués, tous les clients peuvent s'interrompre simultanément, ce qui crée des clusters de rappels. Dans son billet de blog [Backoff exponentiel et instabilité](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-italics%0djitter/)Marc Brooker explique comment modifier la fonction wait() dans la temporisation exponentielle pour empêcher les clusters de rappels. La solution consiste à ajouter de l' *instabilité* dans la fonction wait(). Pour éviter qu’une nouvelle tentative soit trop longue, les implémentations doivent limiter la temporisation à une valeur maximale.
Enfin, il est important de configurer un *nombre maximal de nouvelles tentatives* ou la durée après laquelle les nouvelles tentatives échoueront tout simplement. Les kits de développement logiciel (SDK) AWS mettent en œuvre cette approche par défaut et peuvent être configurés. Pour les services inférieurs dans la pile, une limite maximale de nouvelles tentatives définie sur zéro ou un limite le risque tout en étant efficace lors de la délégation des nouvelles tentatives aux services supérieurs dans la pile.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## 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 ces intervalles de nouvelle tentative et limitez le nombre maximal de nouvelles tentatives.
+ [Nouvelles tentatives après erreur et interruptions exponentielles dans AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ Les kits SDK Amazon implémentent les nouvelles tentatives et le backoff exponentiel par défaut. Mettez en place une logique similaire dans votre couche de dépendance lors de l'appel de vos propres services dépendants. 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.
## Ressources
**Documents connexes :**
+ [Amazon API Gateway : limiter les demandes d'API pour un meilleur débit](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Nouvelles tentatives après erreur et interruptions exponentielles dans AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [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/)
+ [L'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-BP04 Procéder à une interruption immédiate et limiter les files d'attente
Si la charge de travail n'est pas en mesure de répondre avec succès à une demande, procédez à son interruption immédiate. Cela permet la libération des ressources associées à une demande et permet au service de récupérer s'il manque de ressources. Si la charge de travail est en mesure de répondre avec succès, mais que le taux de requêtes est trop élevé, utilisez plutôt une file d'attente pour mettre les requêtes en mémoire tampon. N'autorisez toutefois pas les files d'attente longues qui peuvent entraîner le traitement de requêtes obsolètes que le client a déjà abandonnées.
Cette bonne pratique s'applique côté serveur, ou récepteur, de la requête.
Sachez qu'il est possible de créer des files d'attente à différents niveaux d'un système. Elles peuvent également considérablement entraver la capacité de récupération rapide lorsque des demandes obsolètes (qui n'ont plus besoin d'une réponse) sont traitées avant d'apporter une réponse à des demandes plus récentes. Déterminez bien les endroits où se trouvent les files d'attente. Elles se cachent souvent dans les flux de travail ou dans les tâches enregistrées dans une base de données.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Procéder à une interruption immédiate et limiter les files d'attente. Si la charge de travail n'est pas en mesure de répondre avec succès à une demande, procédez à son interruption immédiate. Cela permet la libération des ressources associées à une demande et permet au service de récupérer s'il manque de ressources. Si la charge de travail est en mesure de répondre avec succès, mais que le taux de requêtes est trop élevé, utilisez plutôt une file d'attente pour mettre les requêtes en mémoire tampon. N'autorisez toutefois pas les files d'attente longues qui peuvent entraîner le traitement de requêtes obsolètes que le client a déjà abandonnées.
+ Procéder à une interruption immédiate lorsque le service est sous pression.
+ [Interruption immédiate](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ Limiter les files d'attente. Dans un système basé sur les files d'attente, la charge du message peut s'accumuler dans une longue file d'attente lorsque le traitement s'arrête mais que les messages continuent d'arriver, ce qui augmente le temps de traitement. Le travail peut être achevé trop tard pour que les résultats soient utiles, provoquant ainsi le problème de disponibilité que la file d'attente était censée permettre d'éviter.
+ [L'Amazon Builders' Library : éviter les retards de file d'attente insurmontables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
## Ressources
**Documents connexes :**
+ [Nouvelles tentatives après erreur et interruptions exponentielles dans AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Interruption immédiate](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ [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/)
+ [L'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-BP05 Définir les délais d'attente du client
Définissez les délais d'expiration de manière appropriée, vérifiez-les systématiquement et ne comptez pas sur les valeurs par défaut, car elles sont généralement trop élevées.
Cette bonne pratique s'applique coté client, ou expéditeur, de la requête.
Définissez un délai de connexion et un délai de demande pour tout appel à distance et, plus généralement, pour tout appel entre processus. De nombreux cadres offrent des fonctionnalités de délai d'expiration intégrées. Toutefois, restez prudent, car beaucoup d'entre elles ont des valeurs par défaut infinies ou trop élevées. 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 backend et une latence accrue en raison du trop grand nombre de demandes relancées. Dans certains cas, cela peut entraîner des interruptions complètes, car toutes les demandes font l'objet d'une nouvelle tentative.
Pour en savoir plus sur l'utilisation par Amazon des délais d'attente, des nouvelles tentatives et de l'interruption avec instabilité, consultez [https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card).
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Définissez un délai de connexion et un délai de demande pour tout appel à distance et, plus généralement, pour tout appel entre processus. De nombreux cadres offrent des fonctionnalités de délai d'expiration intégrées. Toutefois, restez prudent, car beaucoup d'entre elles ont des valeurs par défaut infinies ou trop élevées. 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 backend et une latence accrue en raison du trop grand nombre de demandes relancées. Dans certains cas, cela peut entraîner des interruptions complètes, car toutes les demandes font l'objet d'une nouvelle tentative.
+ [Kits SDK AWS : nouvelles tentatives et délais d'attente](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
## Ressources
**Documents connexes :**
+ [Kits SDK AWS : nouvelles tentatives et délais d'attente](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [Amazon API Gateway : limiter les demandes d'API pour un meilleur débit](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Nouvelles tentatives après erreur et interruptions exponentielles dans AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [L'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-BP06 Rendre les services sans état dans la mesure du possible
Les services 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 aux serveurs d'être remplacés à volonté sans avoir d'impact sur la disponibilité. Amazon ElastiCache ou Amazon DynamoDB sont de bonnes destinations pour l'état déchargé.
![\[Dans cette application Web sans état, l'état de la session est déchargé vers Amazon ElastiCache.\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/stateless-webapp.png)
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.
Lorsqu'une application est conçue pour être sans état, vous pouvez utiliser des services de calcul sans serveur, comme AWS Lambda ou AWS Fargate.
Outre le remplacement du serveur, les applications sans état ont également pour avantage de pouvoir être mises à l'échelle horizontalement, car toutes les ressources de calcul disponibles (telles que les instances EC2 et les fonctions AWS Lambda) peuvent répondre à n'importe quelle requête.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## 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.
+ Supprimez les états qui peuvent être stockés dans les paramètres de demande.
+ Après avoir vérifié si l'état est requis, déplacez n'importe quel suivi d'état vers un cache ou un magasin de données multizone résistant comme Amazon ElastiCache, Amazon RDS, Amazon DynamoDB ou une autre solution de données distribuée. Enregistrez un état qui n'a pas pu être déplacés vers des magasins de données résilient.
+ Certaines données (comme les cookies) peuvent être transmises dans les en-têtes ou les paramètres de requête
+ Réfactorisez afin de supprimer l'état qui peut rapidement être transmis dans les requêtes
+ Certaines données ne sont pas forcément nécessaires pour certaines requêtes et peuvent être récupérées à la demande.
+ Supprimez les données qui peuvent être récupérées de manière asynchrone.
+ Choisissez un magasin de donnée qui répond aux exigences relatives à l'état requis.
+ Pensez à avoir une base de données NoSQL pour les données non relationnelles.
## Ressources
**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/)
# REL05-BP07 Mettre en place des leviers d'urgence
Les leviers d'urgence sont des processus rapides qui peuvent réduire l'impact sur la disponibilité de votre charge de travail.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Mettre en place des leviers d'urgence. Il s'agit de processus rapides qui peuvent atténuer l'impact sur la disponibilité de votre charge de travail. Ils peuvent être exploités en l'absence d'une cause racine. Un levier d'urgence idéal réduit à zéro la charge cognitive sur les résolveurs en fournissant des critères d'activation et de désactivation entièrement déterministes. Les leviers sont souvent manuels, mais ils peuvent également être automatisés.
+ Voici quelques exemples de leviers :
+ Bloquer tout le trafic des robots
+ Diffuser des pages statiques au lieu de dynamiques
+ Réduire la fréquence des appels vers une dépendance
+ Limiter les appels à partir des dépendances
+ Conseils pour implémenter et utiliser des leviers d'urgence
+ Lorsque les leviers sont activés, faites MOINS, pas plus.
+ Gardez la tâche simple, évitez les comportements bimodaux.
+ Testez régulièrement vos leviers.
+ Tels sont des exemples d'actions qui NE sont PAS des leviers d'urgence.
+ Ajouter de la capacité
+ Appelez les propriétaires de services des clients qui dépendent de votre service et demandez-leur de réduire les appels.
+ Apporter une modification au code et le diffuser