# 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 les composants, comme les serveurs ou les 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 d’éviter les défaillances et d’améliorer le temps moyen entre défaillances (MTBF).
**Topics**
+ [REL04-BP01 Identifier le type de systèmes distribués dont vous dépendez](rel_prevent_interaction_failure_identify.md)
+ [REL04-BP02 Implémenter des dépendances faiblement couplées](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL04-BP03 Faire un travail constant](rel_prevent_interaction_failure_constant_work.md)
+ [REL04-BP04 Rendre les opérations de mutation idempotentes](rel_prevent_interaction_failure_idempotent.md)
# REL04-BP01 Identifier le type de systèmes distribués dont vous dépendez
Les systèmes distribués peuvent être synchrones, asynchrones ou par lots. Les systèmes synchrones doivent traiter les demandes le plus rapidement possible et communiquer entre eux en effectuant des appels de demande et de réponse synchrones à l’aide des protocoles HTTP/S, REST ou RPC (Remote Procedure Call). Les systèmes asynchrones communiquent entre eux en échangeant des données de manière asynchrone via un service intermédiaire sans coupler des systèmes individuels. Les systèmes par lots reçoivent un volume important de données d’entrée, exécutent des processus de données automatisés sans intervention humaine et génèrent des données de sortie.
**Résultat escompté** : concevez une charge de travail qui interagit efficacement avec les dépendances synchrones, asynchrones et par lots.
**Anti-modèles courants** :
+ La charge de travail attend indéfiniment une réponse de la part de ses dépendances, ce qui peut entraîner une expiration des clients de la charge de travail, qui ne savent pas si leur demande a été reçue.
+ La charge de travail utilise une chaîne de systèmes dépendants qui s’appellent les uns les autres de manière synchrone. Cela nécessite que chaque système soit disponible et traite correctement une demande avant que l’ensemble de la chaîne puisse aboutir, ce qui entraîne un comportement et une disponibilité globale potentiellement fragiles.
+ La charge de travail communique avec ses dépendances de manière asynchrone et repose sur le concept de livraison garantie unique des messages, alors qu’il est souvent encore possible de recevoir des messages dupliqués.
+ La charge de travail n’utilise pas les outils de planification par lots appropriés et permet l’exécution simultanée de la même tâche de traitement par lots.
**Avantages du respect de cette bonne pratique** : il est courant qu’une charge de travail donnée implémente un ou plusieurs styles de communication entre synchrone, asynchrone et par lots. Cette bonne pratique vous aide à identifier les différents compromis associés à chaque style de communication afin que votre charge de travail soit capable de tolérer les interruptions liées à toutes ses dépendances.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée** : élevé
## Directives d’implémentation
Les sections suivantes contiennent des instructions de mise en œuvre générales et spécifiques pour chaque type de dépendance.
**General guidance**
+ Assurez-vous que les objectifs de niveau de service (SLO) offerts par vos dépendances en matière de performance et de fiabilité répondent aux exigences de performance et de fiabilité de votre charge de travail.
+ Utilisez les [services d’observabilité AWS](https://aws.amazon.com/cloudops/monitoring-and-observability) pour [surveiller les temps de réponse et les taux d’erreur](https://www.youtube.com/watch?v=or7uFFyHIX0) afin de vous assurer que votre dépendance fournit des services aux niveaux requis par votre charge de travail.
+ Identifiez les défis potentiels auxquels votre charge de travail peut être confrontée lors de la communication avec ses dépendances. Les systèmes distribués [présentent un large éventail de défis](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) susceptibles d’accroître la complexité architecturale, la charge opérationnelle et les coûts. Les défis courants incluent la latence, les perturbations du réseau, la perte de données, la mise à l’échelle et le retard de réplication des données.
+ Mettez en œuvre une gestion des erreurs et une [journalisation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) robustes pour vous aider à résoudre les problèmes lorsque votre dépendance rencontre des problèmes.
**Dépendance synchrone**
Dans les communications synchrones, votre charge de travail envoie une demande à sa dépendance et bloque l’opération en attente de réponse. Lorsque sa dépendance reçoit la demande, elle essaie de la traiter le plus rapidement possible et renvoie une réponse à la charge de travail. L’un des principaux défis liés à la communication synchrone est qu’elle entraîne un couplage temporel, ce qui nécessite que la charge de travail et ses dépendances soient disponibles en même temps. Lorsque la charge de travail doit communiquer de manière synchrone avec ses dépendances, suivez les conseils ci-dessous :
+ Votre charge de travail ne doit pas reposer sur plusieurs dépendances synchrones pour exécuter une seule fonction. Cette chaîne de dépendances augmente la fragilité globale, car toutes les dépendances sur le chemin doivent être disponibles pour que la demande soit traitée correctement.
+ Lorsqu’une dépendance n’est pas saine ou n’est pas disponible, déterminez vos stratégies de gestion des erreurs et de nouvelles tentatives. Évitez d’utiliser un comportement bimodal. On parle de comportement bimodal lorsque la charge de travail présente un comportement différent en mode normal et en mode d’échec. Pour plus de détails sur le comportement bimodal, 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)
+ N’oubliez pas qu’il vaut mieux échouer rapidement que faire attendre la charge de travail. Par exemple, le [Guide du développeur AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/invocation-retries.html) explique comment gérer les tentatives et les échecs lorsque vous invoquez des fonctions Lambda.
+ Définissez des délais d’expiration lorsque la charge de travail appelle sa dépendance. Cette technique permet d’éviter d’attendre trop longtemps ou d’attendre indéfiniment une réponse. Vous trouverez une discussion utile sur ce sujet dans la section [Réglage des paramètres de demande HTTP du SDK Java AWS pour les applications Amazon DynamoDB sensibles à la latence](https://aws.amazon.com/blogs/database/tuning-aws-java-sdk-http-request-settings-for-latency-aware-amazon-dynamodb-applications/).
+ Réduisez le nombre d’appels passés entre la charge de travail et sa dépendance pour répondre à une seule demande. Le fait d’avoir trop d’appels entre elles augmente le couplage et la latence.
**Dépendance asynchrone**
Pour pouvoir découpler temporellement la charge de travail de sa dépendance, elles doivent communiquer de manière asynchrone. En utilisant une approche asynchrone, la charge de travail peut poursuivre tout autre traitement sans avoir à attendre que sa dépendance, ou sa chaîne de dépendances, envoie une réponse.
Lorsque la charge de travail doit communiquer de manière asynchrone avec sa dépendance, suivez les conseils ci-dessous :
+ Déterminez s’il convient d’utiliser la messagerie ou le streaming d’événements en fonction de votre cas d’utilisation et de vos exigences. La [messagerie](https://aws.amazon.com/messaging/) permet à votre charge de travail de communiquer avec ses dépendances en envoyant et en recevant des messages par le biais d’un agent de messages. Le [streaming d’événements](https://aws.amazon.com/streaming-data/) permet à votre charge de travail et à ses dépendances d’utiliser un service de streaming pour publier et s’abonner à des événements, diffusés sous forme de flux de données continus, qui doivent être traités dès que possible.
+ La messagerie et le streaming d’événements traitent les messages différemment. Vous devez donc faire un choix en fonction des éléments suivants :
+ **Priorité des messages :** les agents de messages peuvent traiter les messages prioritaires avant les messages normaux. Dans le cadre du streaming d’événements, tous les messages ont la même priorité.
+ **Consommation de messages** : les agents de messages veillent à ce que les consommateurs reçoivent le message. Les consommateurs qui diffusent des événements doivent suivre le dernier message qu’ils ont lu.
+ **Ordre des messages** : avec la messagerie, la réception des messages dans l’ordre exact dans lequel ils sont envoyés n’est pas garantie, sauf si vous utilisez une approche « premier entré, premier sorti » (FIFO). Le streaming d’événements préserve toujours l’ordre dans lequel les données ont été produites.
+ **Suppression du message** : dans le cas de la messagerie, le consommateur doit supprimer le message après l’avoir traité. Le service de streaming d’événements ajoute le message à un flux et y reste jusqu’à l’expiration de la période de conservation du message. Cette politique de suppression rend le streaming d’événements adapté à la rediffusion de messages.
+ Définissez comment la charge de travail comprend que sa dépendance a mené à bien sa tâche. Par exemple, lorsque votre charge de travail invoque une [fonction Lambda de manière asynchrone](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html), Lambda place l’événement dans une file d’attente, et renvoie une réponse de succès sans plus d’informations. Une fois le traitement terminé, la fonction Lambda peut [envoyer le résultat à une destination](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html#invocation-async-destinations) configurable en fonction du succès ou de l’échec.
+ Augmentez votre charge de travail pour gérer les messages dupliqués en tirant parti de l’idempotence. L’idempotence signifie que les résultats de la charge de travail ne changent pas même si elle est générée plusieurs fois pour le même message. Il est important de souligner que les services de [messagerie](https://aws.amazon.com/sqs/faqs/#FIFO_queues) ou de [streaming](https://docs.aws.amazon.com/streams/latest/dev/kinesis-record-processor-duplicates.html) redistribueront un message en cas de panne du réseau ou en l’absence de réception d’un accusé de réception.
+ Si la charge de travail n’obtient pas de réponse de sa dépendance, elle doit soumettre à nouveau la demande. Envisagez de limiter le nombre de tentatives pour préserver le processeur, la mémoire et les ressources réseau de votre charge de travail afin de gérer d’autres demandes. La [documentation AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html#invocation-async-errors) montre comment gérer les erreurs lors d’une invocation asynchrone.
+ Tirez parti des outils d’observabilité, de débogage et de suivi appropriés pour gérer et exploiter la communication asynchrone de la charge de travail avec ses dépendances. Vous pouvez utiliser [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) pour surveiller les services de [messagerie](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html) et de [streaming d’événements](https://docs.aws.amazon.com/streams/latest/dev/monitoring-with-cloudwatch.html). Vous pouvez également utiliser votre charge de travail avec [AWS X-Ray](https://aws.amazon.com/xray/) pour [obtenir rapidement des informations](https://docs.aws.amazon.com/xray/latest/devguide/xray-concepts.html) permettant de résoudre les problèmes.
**Dépendance par lots**
Les systèmes par lots prennent les données d’entrée, lancent une série de tâches pour les traiter et produisent certaines données de sortie, sans intervention manuelle. En fonction de la taille des données, les tâches peuvent s’exécuter pendant une durée allant de quelques minutes à, dans certains cas, plusieurs jours. Lorsque la charge de travail communique avec sa dépendance par lots, suivez les conseils ci-dessous :
+ Définissez la fenêtre de temps pendant laquelle la charge de travail doit exécuter le traitement par lots. La charge de travail peut configurer un modèle de récurrence pour invoquer un système de traitement par lots (par exemple, toutes les heures ou à la fin de chaque mois).
+ Déterminez l’emplacement de l’entrée des données et de la sortie des données traitées. Choisissez un service de stockage, tel qu’[Amazon Simple Storage Services (Amazon S3)](https://aws.amazon.com/s3/), [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html) et [Amazon FSx pour Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html), qui permet à votre charge de travail de lire et d’écrire des fichiers à l’échelle.
+ Si votre charge de travail doit invoquer plusieurs tâches par lots, vous pouvez en tirer parti de [AWS Step Functions](https://aws.amazon.com/step-functions/?step-functions.sort-by=item.additionalFields.postDateTime&step-functions.sort-order=desc) pour simplifier l’orchestration des tâches par lots exécutées dans AWS ou sur site. Cet [exemple de projet](https://github.com/aws-samples/aws-stepfunction-complex-orchestrator-app) illustre l’orchestration de traitements par lots à l’aide de Step Functions, [AWS Batch](https://aws.amazon.com/batch/) et Lambda.
+ Surveillez les tâches par lots pour détecter d’éventuelles anomalies, telles qu’une tâche qui prend plus de temps que prévu. Vous pouvez utiliser des outils tels que [CloudWatch Container Insights](https://docs.aws.amazon.com/batch/latest/userguide/cloudwatch-container-insights.html) pour surveiller les environnements AWS Batch et les tâches. Dans ce cas, la charge de travail empêcherait le début de la tâche suivante et informerait le personnel concerné de l’exception.
## Ressources
**Documents connexes** :
+ [Opérations : Surveillance et observabilité AWS Cloud](https://aws.amazon.com/cloudops/monitoring-and-observability)
+ [L’Amazon Builders’ Library : défis liés aux systèmes distribués](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [REL11-BP05 Utiliser la stabilité statique pour éviter les comportements bimodaux](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)
+ [Guide du développeur AWS Lambda : Gestion des erreurs et tentatives automatiques dans AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/invocation-retries.html)
+ [Réglage des paramètres de demande HTTP d’AWS SDK Java pour les applications Amazon DynamoDB sensibles à la latence](https://aws.amazon.com/blogs/database/tuning-aws-java-sdk-http-request-settings-for-latency-aware-amazon-dynamodb-applications/)
+ [Messagerie AWS](https://aws.amazon.com/messaging/)
+ [Qu’est-ce que le streaming de données ?](https://aws.amazon.com/streaming-data/)
+ [Guide du développeur AWS Lambda : Invocation asynchrone](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html)
+ [FAQ Amazon Simple Queue Service : Files d’attente FIFO](https://aws.amazon.com/sqs/faqs/#FIFO_queues)
+ [Guide du développeur Amazon Kinesis Data Streams : Gestion des enregistrements en double](https://docs.aws.amazon.com/streams/latest/dev/kinesis-record-processor-duplicates.html)
+ [Guide du développeur Amazon Simple Queue Service : Métriques CloudWatch disponibles pour Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html)
+ [Guide du développeur Amazon Kinesis Data Streams : Surveillance du service Amazon Kinesis Data Streams avec Amazon CloudWatch](https://docs.aws.amazon.com/streams/latest/dev/monitoring-with-cloudwatch.html)
+ [Guide du développeur AWS X-Ray : Concepts AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-concepts.html)
+ [Exemples AWS sur GitHub : Application AWS Step Functions Complex Orchestrator](https://github.com/aws-samples/aws-stepfunction-complex-orchestrator-app)
+ [Guide de l’utilisateur AWS Batch : AWS Batch CloudWatch Container Insights](https://docs.aws.amazon.com/batch/latest/userguide/cloudwatch-container-insights.html)
**Vidéos connexes** :
+ [AWS Summit SF 2022 - Full-stack observability and application monitoring with AWS (COP310)](https://www.youtube.com/watch?v=or7uFFyHIX0)
**Outils associés** :
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html)
+ [Amazon FSx pour Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [AWS Step Functions](https://aws.amazon.com/step-functions/?step-functions.sort-by=item.additionalFields.postDateTime&step-functions.sort-order=desc)
+ [AWS Batch](https://aws.amazon.com/batch/)
# REL04-BP02 Implémenter des dépendances faiblement couplées
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é.
Le découplage des dépendances, telles que les systèmes de file d’attente, les systèmes de streaming et les flux de travail, permet de minimiser l’impact des modifications ou des défaillances sur un système. Cette séparation empêche le comportement d’un composant d’affecter les autres qui en dépendent, améliorant ainsi la résilience et l’agilité.
Dans les systèmes couplés fortement, la modification d’un composant peut nécessiter de modifier d’autres composants qui en dépendent, ce qui entraîne une dégradation des performances de tous les composants. Le couplage *faible* 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 faible entre les dépendances permet d’isoler une défaillance dans l’une afin de ne pas en impacter une autre.
Le couplage faible vous permet de modifier le code ou d’ajouter des fonctionnalités à un composant tout en minimisant les risques pour les autres composants qui en dépendent. Il offre également une résilience granulaire au niveau des composants, ce qui vous permet d’augmenter horizontalement voire de modifier la mise en œuvre sous-jacente de la dépendance.
Pour améliorer encore la résilience par un couplage faible, dans la mesure du possible, rendez asynchrones les interactions des composants. Ce modèle convient à toute interaction qui ne nécessite pas 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 par point-to-point interaction directe, mais généralement par le biais d'une couche de stockage durable intermédiaire, telle qu'une SQS file d'attente Amazon, une plateforme de données de streaming telle qu'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/latest/reliability-pillar/images/dependency-diagram.png)
Amazon fait la SQS queue et ce ne AWS Step Functions sont que deux moyens d'ajouter une couche intermédiaire pour un couplage souple. Des architectures axées sur les événements peuvent également être créées à l'aide d' AWS Cloud Amazon EventBridge, qui peut isoler les clients (producteurs d'événements) des services sur lesquels ils comptent (consommateurs d'événements). Amazon Simple Notification Service (AmazonSNS) est une solution efficace lorsque vous avez besoin d'une messagerie push à haut débit. many-to-many À l'aide d'Amazon SNS Topics, les systèmes de vos éditeurs peuvent diffuser les messages vers un grand nombre de points de terminaison d'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.
**Résultat souhaité :** la mise en œuvre de dépendances faiblement couplées vous permet de minimiser la surface de défaillance au niveau du composant, ce qui permet de diagnostiquer et de résoudre les problèmes. Elle simplifie également les cycles de développement en permettant aux équipes de mettre en œuvre des modifications à un niveau modulaire sans affecter les performances des autres composants qui en dépendent. Avec cette approche, il est possible d’augmenter horizontalement un composant en fonction des besoins en ressources et de l’utilisation de ce composant, ce qui contribue à améliorer la rentabilité.
**Anti-modèles courants :**
+ Déploiement d’une charge de travail monolithique.
+ Invocation directe APIs entre les niveaux de charge de travail sans possibilité de basculement ou de traitement asynchrone de la demande.
+ Couplage fort à l’aide de données partagées. Les systèmes couplés faiblement évitent de partager des données par le biais de bases de données partagées ou d’autres formes de stockage de données couplées fortement, qui peuvent réintroduire un couplage fort et entraver la capacité de mise à l’échelle.
+ Ignorer la contre-pression. Votre charge de travail doit être capable de ralentir ou d’arrêter les données entrantes lorsqu’un composant ne peut pas les traiter au même rythme.
**Avantages du 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 d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Implémentez des dépendances couplées faiblement. Différentes solutions permettent de créer des applications couplées faiblement. Il s'agit notamment de services permettant de mettre en œuvre des files d'attente entièrement gérées, des flux de travail automatisés, de réaction aux événements, etc., qui peuvent aider à isoler le comportement des composants par rapport aux autres composants, augmentant ainsi la résilience et l'agilité. APIs
+ **Créez des architectures pilotées par les événements : [Amazon](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)** vous EventBridge aide à créer des architectures pilotées par les événements faiblement couplées et distribuées.
+ **Implémenter des files d'attente dans les systèmes distribués :** vous pouvez utiliser [Amazon Simple Queue Service (AmazonSQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) pour intégrer et découpler les systèmes distribués.
+ **Conteneuriser les composants sous forme de microservices :** les [microservices](https://aws.amazon.com/microservices/) permettent aux équipes de créer des applications composées de petits composants indépendants qui communiquent via des canaux bien définis. APIs [Amazon Elastic Container Service (AmazonECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) et [Amazon Elastic Kubernetes Service (EKSAmazon](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)) peuvent vous aider à démarrer plus rapidement avec les conteneurs.
+ **Gérez les flux de travail avec Step Functions :** [Step Functions](https://aws.amazon.com/step-functions/getting-started/) vous aide à coordonner plusieurs AWS services dans des flux de travail flexibles.
+ **Tirez parti des architectures de messagerie publish-subscribe (pub/sub) : Amazon** [Simple Notification Service (AmazonSNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) assure la transmission des messages des éditeurs aux abonnés (également appelés producteurs et consommateurs).
### Étapes d’implémentation
+ Les composants d’une architecture basée sur les événements sont initiés par des événements. Les événements sont des actions qui se produisent dans un système (par exemple, un utilisateur ajoute un article à un panier). Lorsque l’action aboutit, un événement est généré et active le composant suivant du système.
+ [Création d'applications basées sur les événements avec Amazon EventBridge](https://aws.amazon.com/blogs/compute/building-an-event-driven-application-with-amazon-eventbridge/)
+ [AWS re:Invent 2022 - Conception d'intégrations pilotées par des événements à l'aide d'Amazon EventBridge](https://www.youtube.com/watch?v=W3Rh70jG-LM)
+ Les systèmes de messagerie distribuée comportent trois parties principales qui doivent être mises en œuvre pour une architecture basée sur des files d’attente. Ils incluent les composants du système distribué, la file d'attente utilisée pour le découplage (distribuée sur les SQS serveurs Amazon) et les messages de la file d'attente. Dans un système classique, les producteurs envoient le message dans la file d’attente et le consommateur reçoit le message de la file d’attente. La file d'attente stocke les messages sur plusieurs SQS serveurs Amazon à des fins de redondance.
+ [SQSArchitecture Amazon de base](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-architecture.html)
+ [ Envoyer des messages entre des applications distribuées avec Amazon Simple Queue Service ](https://aws.amazon.com/getting-started/hands-on/send-messages-distributed-applications/)
+ Lorsqu’ils sont bien utilisés, les microservices améliorent la maintenabilité et la capacité de mise à l’échelle, car les composants couplés faiblement sont gérés par des équipes indépendantes. Ils permettent également d’isoler les comportements d’un composant en cas de changement.
+ [Implémentation de microservices sur AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [ Let’s Architect\$1 Architecting microservices with containers ](https://aws.amazon.com/blogs/architecture/lets-architect-architecting-microservices-with-containers/)
+ AWS Step Functions Vous pouvez notamment créer des applications distribuées, automatiser des processus, orchestrer des microservices. L’orchestration de plusieurs composants dans un flux de travail automatisé vous permet de découpler des dépendances dans votre application.
+ [Créez un flux de travail sans serveur avec et AWS Step FunctionsAWS Lambda](https://aws.amazon.com/tutorials/create-a-serverless-workflow-step-functions-lambda/)
+ [Commencer avec AWS Step Functions](https://aws.amazon.com/step-functions/getting-started/)
## Ressources
**Documents connexes :**
+ [Amazon EC2 : garantir l'impuissance](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 qu’Amazon Simple Queue Service ?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
+ [ Rompre avec votre monolithe ](https://pages.awscloud.com/break-up-your-monolith.html)
+ [Orchestrez des microservices basés sur des files d'attente avec Amazon et Amazon AWS Step Functions SQS](https://aws.amazon.com/tutorials/orchestrate-microservices-with-message-queues-on-step-functions/)
+ [SQSArchitecture Amazon de base](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-architecture.html)
+ [ Architecture basée sur des files d’attente ](https://docs.aws.amazon.com/wellarchitected/latest/high-performance-computing-lens/queue-based-architecture.html)
**Vidéos connexes :**
+ [AWS Sommet de New York 2019 : introduction aux architectures événementielles et à Amazon EventBridge (05) MAD2](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018 : Boucles serrées et ouverture d'esprit : comment prendre le contrôle des systèmes, grands et petits ARC337 (y compris le couplage lâche, le travail constant, la stabilité statique)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019 : Passage à des architectures pilotées par les événements (08) SVS3](https://youtu.be/h46IquqjF3E)
+ [AWS re:Invent 2019 : applications évolutives pilotées par des événements sans serveur utilisant Amazon et Lambda SQS](https://www.youtube.com/watch?v=2rikdPIFc_Q)
+ [AWS re:Invent 2022 - Conception d'intégrations pilotées par des événements à l'aide d'Amazon EventBridge](https://www.youtube.com/watch?v=W3Rh70jG-LM)
+ [AWS re:Invent 2017 : Elastic Load Balancing : analyse approfondie et meilleures pratiques](https://www.youtube.com/watch?v=9TwkMMogojY)
# REL04-BP03 Faire 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 surveillance de l’état surveille 100 000 serveurs, la charge sur celui-ci est nominale avec 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 surveillance 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 surveillance de l’état devrait donc envoyer un instantané complet de l’état actuel à chaque fois. 100 000 états de santé du serveur, chacun représenté par un octet, ne représenteraient 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 surveillance 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 surveillances 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 d’exposition au risque si cette bonne pratique n’est pas respectée :** faible
## Directives d’implémentation
+ Effectuez 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 : Boucles serrées et ouverture d'esprit : comment prendre le contrôle des systèmes, grands et petits ARC337 (y compris un travail constant)](https://youtu.be/O8xLxNje30M?t=2482)
+ Pour l’exemple d’un système de surveillance 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'impuissance](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 Sommet de New York 2019 : introduction aux architectures événementielles et à Amazon EventBridge (05) MAD2](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018 : Boucles serrées et ouverture d'esprit : comment prendre le contrôle des systèmes, grands et petits ARC337 (y compris un travail constant)](https://youtu.be/O8xLxNje30M?t=2482)
+ [AWS re:Invent 2018 : Boucles serrées et ouverture d'esprit : comment prendre le contrôle des systèmes, grands et petits ARC337 (y compris le couplage lâche, le travail constant, la stabilité statique)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019 : Passage à des architectures pilotées par les événements (08) SVS3](https://youtu.be/h46IquqjF3E)
# REL04-BP04 Rendre les opérations de mutation idempotentes
Un service idempotent garantit que chaque demande est traitée une seule fois, de sorte que la soumission de plusieurs demandes identiques ait le même effet que la soumission d’une seule demande. Il est ainsi plus facile pour un client d’implémenter de 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, qui 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, même si l’état sous-jacent du système a changé.
Dans un système distribué, il est relativement simple d’effectuer une action au plus une fois (le client soumet une seule demande) ou au moins une fois (le client continue à soumettre des demandes jusqu’à ce qu’il reçoive une confirmation de succès). Il est plus difficile de garantir qu’une action est exécutée *exactement une fois*, de sorte que la soumission 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 avoir besoin de créer des enregistrements en double ou des effets secondaires.
**Résultat escompté :** vous disposez d’une approche cohérente, bien documentée et largement adoptée pour garantir l’idempotence sur l’ensemble des composants et services.
**Anti-modèles courants :**
+ Vous appliquez l’idempotence sans distinction, même lorsque cela n’est pas nécessaire.
+ Vous introduisez une logique trop complexe pour implémenter l’idempotence.
+ Vous utilisez les horodatages comme des clés pour l’idempotence. Cela peut entraîner des inexactitudes en raison d’un décalage d’horloge ou du fait que plusieurs clients utilisent les mêmes horodatages pour appliquer les modifications.
+ Vous stockez des données utiles complètes à des fins d’idempotence. Dans cette approche, vous enregistrez des données utiles complètes pour chaque demande et vous les remplacez à chaque nouvelle demande. Cela peut dégrader les performances et affecter la capacité de mise à l’échelle.
+ Vous générez des clés de manière incohérente entre les services. En l’absence de clés cohérentes, les services peuvent ne pas reconnaître les demandes en double, ce qui peut conduire à des résultats indésirables.
**Avantages liés au respect de cette bonne pratique :**
+ Capacité de mise à l’échelle accrue : le système peut gérer les nouvelles tentatives et les demandes en double sans avoir à appliquer une logique supplémentaire ni à gérer des états complexes.
+ Fiabilité améliorée : l’idempotence aide les services à traiter plusieurs demandes identiques de manière cohérente, ce qui réduit le risque d’effets secondaires indésirables ou de doublons d’enregistrements. Cela est particulièrement important dans les systèmes distribués, où les défaillances du réseau et les nouvelles tentatives sont communes.
+ Cohérence des données améliorée : étant donné qu’une même demande produit la même réponse, l’idempotence permet de maintenir la cohérence des données dans les systèmes distribués. Cela est essentiel pour maintenir l’intégrité des transactions et des opérations.
+ Gestion des erreurs : les jetons d’idempotence facilitent la gestion des erreurs. Si un client ne reçoit pas de réponse en raison d’un problème, il peut renvoyer la demande en toute sécurité avec le même jeton d’idempotence.
+ Transparence opérationnelle : l’idempotence permet une meilleure surveillance et une meilleure journalisation. Les services peuvent consigner les demandes avec leurs jetons d’idempotence, ce qui facilite le suivi et le débogage des problèmes.
+ Contrat d’API simplifié : il peut simplifier le contrat entre les systèmes côté client et serveur et réduire la crainte d’un traitement erroné des données.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
Dans un système distribué, il est relativement simple d’effectuer une action au plus une fois (le client soumet une seule demande) ou au moins une fois (le client continue à soumettre des demandes jusqu’à ce que le succès soit confirmé). Toutefois, il est difficile de mettre en œuvre un comportement *exactement une fois*. Pour ce faire, vos clients doivent générer et fournir un jeton d’idempotence pour chaque demande.
En utilisant des jetons d’idempotence, un service peut faire la distinction entre de nouvelles demandes et des demandes répétées. Lorsqu’un service reçoit une demande contenant un jeton d’idempotence, il vérifie si le jeton a déjà été utilisé. Si le jeton a été utilisé, le service extrait et retourne la réponse stockée. Si le jeton est nouveau, le service traite la demande, stocke la réponse avec le jeton, puis retourne la réponse. Ce mécanisme rend toutes les réponses idempotentes, ce qui améliore la fiabilité et la cohérence du système distribué.
L’idempotence est également un comportement important des architectures axées sur les événements. Ces architectures s’appuient généralement sur une file d’attente de messages telle qu’Amazon SQS, Amazon MQ, Amazon Kinesis Streams ou Amazon Managed Streaming for Apache Kafka (MSK). Dans certaines circonstances, un message qui n’a été publié qu’une seule fois peut être envoyé accidentellement plusieurs fois. Lorsqu’un diffuseur de publication génère et inclut des jetons d’idempotence dans des messages, il demande que le traitement de tout message reçu en double ne donne pas lieu à une action répétée pour le même message. Les consommateurs doivent suivre chaque jeton reçu et ignorer les messages contenant des jetons dupliqués.
Les services et les consommateurs doivent également transmettre le jeton d’idempotence reçu à tous les services en aval qu’il appelle. Chaque service en aval de la chaîne de traitement est de la même manière responsable de la mise en œuvre de l’idempotence afin d’éviter l’effet secondaire consistant à traiter un message plusieurs fois.
### Étapes d’implémentation
1. **Identification des opérations idempotentes**
Déterminez quelles opérations nécessitent l’idempotence. Il s’agit généralement des méthodes HTTP POST, PUT et DELETE et des opérations d’insertion, de mise à jour ou de suppression de base de données. Les opérations qui n’entraînent pas de mutation d’état, telles que les requêtes en lecture seule, ne nécessitent généralement pas l’idempotence, sauf si elles ont des effets secondaires.
1. **Utilisation d’identifiants uniques**
Incluez un jeton unique dans chaque demande d’opération idempotente envoyée par l’expéditeur, soit directement dans la demande, soit au sein de ses métadonnées (par exemple, un en-tête HTTP). Cela permet au destinataire de reconnaître et de traiter les demandes ou opérations dupliquées. Les identifiants couramment utilisés pour les jetons incluent les [identifiants uniques universels (UUID)](https://datatracker.ietf.org/doc/html/rfc9562) et les [identifiants KSUID (K-Sortable Unique Identifiers)](https://github.com/segmentio/ksuid).
1. **Suivi et gestion de l’état**
Tenez à jour l’état de chaque opération ou demande dans votre charge de travail. Pour ce faire, vous pouvez stocker le jeton d’idempotence et l’état correspondant (en attente, terminé ou échec) dans une base de données, un cache ou un autre stockage permanent. Ces informations d’état permettent à la charge de travail d’identifier et de traiter les demandes ou opérations en double.
Maintenez la cohérence et l’atomicité en utilisant des mécanismes de contrôle de simultanéité appropriés si nécessaire, tels que des verrous, des transactions ou des contrôles de simultanéité optimiste. Cela inclut le processus d’enregistrement du jeton idempotent et d’exécution de toutes les opérations de mutation associées au traitement de la demande. Cela contribue à éviter la survenue de conditions de concurrence et vérifie que les opérations idempotentes se déroulent correctement.
Supprimez régulièrement les anciens jetons d’idempotence de l’entrepôt de données pour gérer le stockage et les performances. Si votre système de stockage les prend en charge, pensez à utiliser des horodatages d’expiration pour les données (souvent appelés « durée de vie » ou valeurs TTL). La probabilité de réutilisation des jetons d’idempotence diminue avec le temps.
Les options de stockage AWS courantes généralement utilisées pour le stockage des jetons d’idempotence et de l’état associé incluent :
+ **Amazon DynamoDB** : DynamoDB est un service de base de données NoSQL qui fournit des performances à faible latence et une haute disponibilité, ce qui le rend parfaitement adapté au stockage de données liées à l’idempotence. Le modèle de données clé-valeur et document de DynamoDB permet de stocker et d’extraire efficacement les jetons d’idempotence et les informations d’état associées. DynamoDB peut également faire expirer automatiquement les jetons d’idempotence si votre application définit une valeur TTL à leur insertion.
+ **Amazon ElastiCache** : ElastiCache peut stocker des jetons d’idempotence à haut débit, à faible latence et à faible coût. ElastiCache (Redis) et ElastiCache (Memcached) peuvent tous les deux également faire expirer automatiquement les jetons d’idempotence si votre application définit une valeur TTL à leur insertion.
+ **Amazon Relational Database Service (RDS) :** vous pouvez utiliser Amazon RDS pour stocker les jetons d’idempotence et les informations d’état associées, en particulier si votre application utilise déjà une base de données relationnelle à d’autres fins.
+ **Amazon Simple Storage Service (S3) :** Amazon S3 est un service de stockage d’objets hautement évolutif et durable qui peut être utilisé pour stocker les jetons d’idempotence et les métadonnées associées. Les capacités de gestion des versions de S3 peuvent être particulièrement utiles pour maintenir l’état des opérations idempotentes. Le choix du service de stockage dépend généralement de facteurs tels que le volume de données liées à l’idempotence, les caractéristiques de performances requises, le besoin de durabilité et de disponibilité, et la manière dont le mécanisme d’idempotence s’intègre dans l’architecture globale de la charge de travail.
1. **Mise en œuvre des opérations idempotentes**
Concevez vos composants d’API et de charge de travail de manière à ce qu’ils soient idempotents. Incorporez des vérifications d’idempotence dans vos composants de charge de travail. Avant de traiter une demande ou d’effectuer une opération, vérifiez si l’identifiant unique a déjà été traité. Si tel est le cas, renvoyez le résultat précédent au lieu de réexécuter l’opération. Par exemple, si un client envoie une demande de création d’utilisateur, vérifiez si un utilisateur possédant le même identifiant unique existe déjà. Si un tel utilisateur existe, ses informations doivent être renvoyées au lieu de créer un nouvel utilisateur. De même, si un consommateur de file d’attente reçoit un message contenant un jeton d’idempotence dupliqué, le consommateur doit ignorer le message.
Créez des suites de tests complètes qui valident l’idempotence des demandes. Elles doivent couvrir un large éventail de scénarios, tels que des demandes réussies, des demandes ayant échoué et des demandes dupliquées.
Si votre charge de travail tire parti des fonctions AWS Lambda, envisagez d’utiliser Powertools for AWS Lambda. Powertools for AWS Lambda est une boîte à outils pour développeurs permettant de mettre en œuvre les bonnes pratiques en matière de technologies sans serveur et d’augmenter la rapidité des développeurs dans le cadre de l’utilisation des fonctions AWS Lambda. En particulier, il fournit un utilitaire pour convertir vos fonctions Lambda en opérations idempotentes qu’il est possible de réessayer en toute sécurité.
1. **Communication claire de l’idempotence**
Documentez vos composants d’API et de charge de travail afin de communiquer clairement la nature idempotente des opérations. Cela permet aux clients de comprendre le comportement attendu et de savoir comment interagir de manière fiable avec votre charge de travail.
1. **Surveillance et audit**
Mettez en œuvre des mécanismes de surveillance et d’audit pour détecter tout problème lié à l’idempotence des réponses, tel que des variations de réponse inattendues ou un traitement excessif des demandes dupliquées. Cela peut vous aider à détecter et à étudier tout problème ou comportement inattendu lié à votre charge de travail.
## Ressources
**Bonnes pratiques associées :**
+ [REL05-BP03 Contrôler et limiter les appels de nouvelle tentative](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_limit_retries.html)
+ [REL06-BP01 Surveiller tous les composants de la charge de travail (génération)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_monitor_resources.html)
+ [REL06-BP03 Envoyer des notifications (traitement et alarmes en temps réel)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_notification_monitor.html)
+ [REL08-BP02 Intégrer les tests fonctionnels dans le cadre de votre déploiement](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_functional_testing.html)
**Documents connexes :**
+ [Amazon Builders’ Library : sécurisation des nouvelles tentatives avec des API idempotentes](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)
+ [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/)
+ [Amazon Elastic Container Service : garantie de l’idempotence](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/ECS_Idempotency.html)
+ [Comment puis-je rendre ma fonction Lambda idempotente ?](https://repost.aws/knowledge-center/lambda-function-idempotent)
+ [Procédure pour garantir l’idempotence dans les demandes d’API Amazon EC2](https://docs.aws.amazon.com/ec2/latest/devguide/ec2-api-idempotency.html)
**Vidéos connexes :**
+ [Création d’applications distribuées avec une architecture axée sur les événements – AWS Online Tech Talks](https://www.youtube.com/watch?v=gA2-eqDVSng&t=1668s)
+ [AWS re:Invent 2023 - Building next-generation applications with event-driven architecture](https://www.youtube.com/watch?v=KXR17uwLEC8)
+ [AWS re:Invent 2023 - Advanced integration patterns & trade-offs for loosely coupled systems](https://www.youtube.com/watch?v=FGKGdUiZKto)
+ [AWS re:Invent 2023 - Advanced event-driven patterns with Amazon EventBridge](https://www.youtube.com/watch?v=6X4lSPkn4ps)
+ [AWS re:Invent 2018 - Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (inclut les concepts de couplage faible, travail constant et stabilité statique)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019 - Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
**Outils associés :**
+ [Idempotence avec Powertools AWS Lambda (Java)](https://docs.powertools.aws.dev/lambda/java/utilities/idempotency/)
+ [Idempotence avec Powertools AWS Lambda (Python)](https://docs.powertools.aws.dev/lambda/python/latest/utilities/idempotency/)
+ [Page GitHub de Powertools AWS Lambda](https://github.com/aws-powertools/)