# REL 4 Comment concevoir des interactions dans un système distribué pour éviter les défaillances ?
Les systèmes distribués s'appuient sur des réseaux de communication pour interconnecter des composants comme des serveurs ou des services. Votre charge de travail doit fonctionner de manière fiable malgré la perte de données ou la latence dans 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 empêchent les défaillances et améliorent le temps moyen entre les défaillances (MTBF).
**Topics**
+ [REL04-BP01 Identifier le type de système distribué requis](rel_prevent_interaction_failure_identify.md)
+ [REL04-BP02 Implémenter des dépendances couplées faiblement](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL04-BP03 Effectuer un travail constant](rel_prevent_interaction_failure_constant_work.md)
+ [REL04-BP04 Rendre toutes les réponses idempotentes](rel_prevent_interaction_failure_idempotent.md)
# REL04-BP01 Identifier le type de système distribué requis
Les systèmes matériels distribués en temps réel exigent la fourniture des réponses de manière synchrone et rapide, alors que les systèmes en temps réel souples disposent d'une fenêtre de temps plus importante (en minutes ou plus). Les systèmes hors connexion gèrent les réponses via un traitement par lots ou asynchrone. Les systèmes matériels distribués en temps réel ont les exigences de fiabilité les plus strictes.
Les [problèmes les plus complexes inhérents aux systèmes distribués](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) concernent les systèmes distribués en temps réel stricts, également appelés services de requête/réponse. Ce qui les rend difficiles, c'est que les requêtes arrivent de façon imprévisible et que les réponses doivent être données rapidement (par exemple, le client attend activement la réponse). Les serveurs web front-end, le pipeline de commandes, les transactions par carte de crédit, chaque API AWS et la téléphonie en sont des exemples.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Identifiez le type de système distribué requis. Les défis posés par les systèmes distribués sont la latence, la mise à l'échelle, la compréhension des API de réseau, le regroupement et le dégroupement des données et la complexité des algorithmes tels que Paxos. Des cas jadis marginaux et théoriques deviennent monnaie courante au fur et à mesure que les systèmes deviennent de plus en plus grands et distribués.
+ [L'Amazon Builders' Library : défis liés aux systèmes distribués](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ Des réponses données de manière synchrone et rapide sont nécessaires pour les systèmes matériels distribués en temps.
+ Les systèmes logiciels en temps réel ont un créneau de temps plus généreux de plusieurs minutes ou plus pour la réponse.
+ Les systèmes hors connexion gèrent les réponses via un traitement par lots ou asynchrone.
+ Les systèmes matériels distribués en temps réel ont les exigences de fiabilité les plus strictes.
## Ressources
**Documents connexes :**
+ [Amazon EC2 : garantir l'idempotence](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [L'Amazon Builders' Library : défis liés aux systèmes distribués](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [L'Amazon Builders' Library : fiabilité, travail constant et une bonne tasse de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [Qu'est-ce qu'Amazon EventBridge ?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Qu'est-ce que Amazon Simple Queue Service ?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**Vidéos connexes :**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (inclut un couplage faible, un travail constant et une stabilité statique)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP02 Implémenter des dépendances couplées faiblement
Des dépendances telles que des systèmes de file d'attente, des systèmes de streaming, des flux de travail et des équilibreurs de charge sont couplées faiblement. Le couplage faible permet d'isoler le comportement d'un composant des autres composants qui en dépendent, ce qui augmente la résilience et l'agilité.
Si les modifications apportées à un composant forcent également d'autres composants qui s'appuient sur lui à changer *couplés* lâchement. *Le couplage lâche* rompt cette dépendance de sorte que les composants dépendants n'ont besoin que de connaître l'interface publiée et sa version. La mise en œuvre d'un couplage lâche entre les dépendances permet d'isoler une défaillance dans l'une afin de ne pas en impacter une autre.
Le couplage lâche permet également d'ajouter du code ou des fonctions supplémentaires à un composant tout en minimisant les risques pour les composants qui en dépendent. La capacité de mise à l'échelle est également améliorée, car vous pouvez augmenter ou même modifier l'implémentation sous-jacente de la dépendance.
Pour améliorer encore la résilience par un couplage lâche, dans la mesure du possible, rendez asynchrones les interactions des composants. Ce modèle convient à toute interaction qui ne nécessite pas besoin une réponse immédiate et pour laquelle une confirmation de l’enregistrement d'une requête suffira. Il implique un composant qui génère des événements et un autre qui les consomme. Les deux composants ne s'intègrent pas via une interaction directe point à point, mais généralement via une couche de stockage durable intermédiaire, telle qu'une file d'attente SQS ou une plateforme de données de streaming comme Amazon Kinesis ou AWS Step Functions.
![\[Diagramme affichant les dépendances telles que des systèmes de file d'attente et des équilibreurs de charge couplés faiblement\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/loosely-coupled-dependencies.png)
Les files d'attente Amazon SQS et les programmes Elastic Load Balancer ne sont que deux façons d'ajouter une couche intermédiaire pour un couplage lâche. Les architectures guidées par les événements peuvent également être conçues dans le AWS Cloud à l'aide d'Amazon EventBridge, qui peut extraire des clients (producteurs d'événements) des services sur lesquels ils s'appuient (clients d'événements). Amazon Simple Notification Service (Amazon SNS) est une solution efficace lorsque vous avez besoin d'une messagerie de type « many-to-many », à haut débit et en mode push. Grâce aux rubriques Amazon SNS, vos systèmes d'édition peuvent diffuser des messages vers un grand nombre de points de terminaison abonnés pour un traitement parallèle.
Bien que les files d'attente offrent plusieurs avantages, dans la plupart des systèmes en temps réel stricts, les requêtes antérieures à un seuil (souvent en secondes) sont considérées comme obsolètes (le client a abandonné et n'attend plus de réponse). En conséquence, elles ne sont pas traitées. De cette façon, les requêtes plus récentes (et probablement toujours valides) peuvent être traitées à la place.
**Anti-modèles courants :**
+ Déploiement d'un singleton dans le cadre d'une charge de travail.
+ Appel direct d'API entre les niveaux de charge de travail sans possibilité de basculement ou de traitement asynchrone de la demande.
**Avantages liés au respect de cette bonne pratique :** Le couplage faible permet d'isoler le comportement d'un composant des autres composants qui en dépendent, ce qui augmente la résilience et l'agilité. La défaillance d'un composant est isolée des autres.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Implémentez des dépendances couplées faiblement. Des dépendances telles que des systèmes de file d'attente, des systèmes de streaming, des flux de travail et des équilibreurs de charge sont couplées faiblement. Le couplage faible permet d'isoler le comportement d'un composant des autres composants qui en dépendent, ce qui augmente la résilience et l'agilité.
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Qu'est-ce qu'Amazon EventBridge ?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Qu'est-ce que Amazon Simple Queue Service ?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
+ Amazon EventBridge vous permet de créer des architectures pilotées par les événements, qui sont faiblement couplées et distribuées.
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ Si les changements apportés à un composant obligent les autres composants qui en dépendent à changer également, c'est qu'ils sont étroitement liés. Le couplage faible rompt cette dépendance de sorte que les composants de dépendance n'ont besoin que de connaître l'interface publiée et déclinée en version.
+ Rendez les interactions des composants aussi asynchrones que possible. Ce modèle convient à toute interaction qui n'a pas besoin d'une réponse immédiate et pour laquelle un accusé de réception indiquant qu'une demande a été enregistrée suffira.
+ [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (API304)](https://youtu.be/2rikdPIFc_Q)
## Ressources
**Documents connexes :**
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon EC2 : garantir l'idempotence](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [L'Amazon Builders' Library : défis liés aux systèmes distribués](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [L'Amazon Builders' Library : fiabilité, travail constant et une bonne tasse de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [Qu'est-ce qu'Amazon EventBridge ?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Qu'est-ce que Amazon Simple Queue Service ?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**Vidéos connexes :**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (inclut un couplage faible, un travail constant et une stabilité statique)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
+ [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (API304)](https://youtu.be/2rikdPIFc_Q)
# REL04-BP03 Effectuer un travail constant
Les systèmes peuvent échouer en cas de modifications importantes et rapides de la charge. Par exemple, si votre charge de travail effectue une surveillance de l'état de milliers de serveurs, elle doit envoyer chaque fois une charge utile de la même taille (un instantané complet de l'état actuel). Qu'aucun des serveurs ne présente de problème ou qu’ils en connaissent tous, le système de surveillance de l'état effectue un travail constant sans modifications importantes ni rapides.
Par exemple, si le système de vérification de l'état surveille 100 000 serveurs, la charge sur celui-ci est nominale sous le taux de défaillance normalement faible du serveur. En revanche, si un événement majeur rendait la moitié de ces serveurs défectueux, le système de vérification de l'état serait submergé en tentant de mettre à jour les systèmes de notification et de communiquer l'état à ses clients. Le système de vérification de l'état doit donc plutôt envoyer à chaque fois l'instantané complet de l'état actuel. 100 000 états d'intégrité du serveur, chacun représenté par un bit, ne seraient qu'une charge utile de 12,5 Ko. Qu'aucun des serveurs ne présente de problème ou qu'ils en connaissent tous, le système de vérification de l'état effectue un travail constant, et les modifications importantes et rapides ne menacent pas la stabilité du système. C'est ainsi qu'Amazon Route 53 gère les vérifications de l'état des points de terminaison (tels que les adresses IP) pour déterminer comment les utilisateurs finaux sont acheminés vers eux.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Faible
## Directives d'implémentation
+ Effectuer un travail constant : les systèmes peuvent échouer lorsque la charge connaît des changements rapides et importants.
+ Implémentez des dépendances couplées faiblement. Des dépendances telles que des systèmes de file d'attente, des systèmes de streaming, des flux de travail et des équilibreurs de charge sont couplées faiblement. Le couplage faible permet d'isoler le comportement d'un composant des autres composants qui en dépendent, ce qui augmente la résilience et l'agilité.
+ [L'Amazon Builders' Library : fiabilité, travail constant et une bonne tasse de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes constant work)](https://youtu.be/O8xLxNje30M?t=2482)
+ Pour l'exemple d'un système de vérification de l'état surveillant 100 000 serveurs, concevez les charges de travail de manière à ce que les tailles de charge utile restent constantes, quel que soit le nombre de réussites ou d'échecs.
## Ressources
**Documents connexes :**
+ [Amazon EC2 : garantir l'idempotence](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [L'Amazon Builders' Library : défis liés aux systèmes distribués](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [L'Amazon Builders' Library : fiabilité, travail constant et une bonne tasse de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Vidéos connexes :**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes constant work)](https://youtu.be/O8xLxNje30M?t=2482)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (inclut un couplage faible, un travail constant et une stabilité statique)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP04 Rendre toutes les réponses idempotentes
Un service idempotent promet que chaque demande est traitée une seule fois et exactement de la même façon, de sorte que l'exécution de plusieurs demandes identiques ait le même effet qu'une seule demande. Un service idempotent permet à un client d'implémenter plus facilement les nouvelles tentatives sans craindre qu'une demande soit traitée plusieurs fois par erreur. Pour ce faire, les clients peuvent émettre des demandes d'API avec un jeton d'idempotence. Le même jeton est utilisé chaque fois que la demande est répétée. Une API de service idempotente utilise le jeton pour renvoyer une réponse identique à la réponse qui a été renvoyée la première fois que la demande a été traitée.
Dans un système distribué, il est facile d'effectuer une action au maximum une fois (le client n'effectue qu'une seule demande) ou au moins une fois (continuer à demander jusqu'à ce que le client reçoive la confirmation de la réussite). En revanche, il est difficile de garantir qu'une action est idempotente, c'est-à-dire exécutée une *seule* fois, de sorte que l'exécution de plusieurs demandes identiques a le même effet qu'une seule demande. En utilisant des jetons d'idempotence dans les API, les services peuvent recevoir une demande de mutation une ou plusieurs fois sans créer d'enregistrements dupliqués ou induire des effets secondaires.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Rendez toutes les réponses idempotentes. Un service idempotent promet que chaque demande est traitée une seule fois et exactement de la même façon, de sorte que l'exécution de plusieurs demandes identiques ait le même effet qu'une seule demande.
+ Les clients peuvent émettre des demandes d'API avec un jeton d'idempotence. Le même jeton est utilisé chaque fois que la demande est répétée. Une API de service idempotente utilise le jeton pour renvoyer une réponse identique à la réponse qui a été renvoyée la première fois que la demande a été traitée.
+ [Garantir l'idempotence Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
## Ressources
**Documents connexes :**
+ [Garantir l'idempotence Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [L'Amazon Builders' Library : défis liés aux systèmes distribués](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [L'Amazon Builders' Library : fiabilité, travail constant et une bonne tasse de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Vidéos connexes :**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (inclut un couplage faible, un travail constant et une stabilité statique)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)