# Architecture de charge de travail
**Topics**
+ [REL 3 Comment concevoir l'architecture de service de votre charge de travail ?](w2aac19b9b7b5.md)
+ [REL 4 Comment concevoir des interactions dans un système distribué pour éviter les défaillances ?](w2aac19b9b7b7.md)
+ [REL 5 Comment concevoir des interactions dans un système distribué pour atténuer ou résister aux défaillances ?](w2aac19b9b7b9.md)
# REL 3 Comment concevoir l'architecture de service de votre charge de travail ?
Créez des charges de travail hautement évolutives et fiables à l'aide d'une architecture orientée service (SOA) ou d'une architecture de microservices. La SOA consiste à rendre les composants logiciels réutilisables via les interfaces de service. L'architecture des microservices va plus loin, en particulier en rendant les composants plus petits et plus simples.
**Topics**
+ [REL03-BP01 Choisir comment segmenter votre charge de travail](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Créer des services axés sur des domaines d'activité et la fonctionnalité](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Fournir des contrats de service par API](rel_service_architecture_api_contracts.md)
# REL03-BP01 Choisir comment segmenter votre charge de travail
La segmentation de la charge de travail est importante lorsqu'il s'agit de déterminer les exigences de résilience de votre application. L'architecture monolithique doit être évitée dans la mesure du possible. À la place, réfléchissez bien aux composants de l'application capables d'être divisés en microservices. Selon les exigences de votre application, il peut s'agir d'une combinaison d'une architecture orientée services et de microservices dans la mesure du possible. Les charges de travail capables d'absence d'état sont davantage en mesure d'être déployées en tant que microservices.
**Résultat souhaité :** Les charges de travail doivent être supportables, évolutives et aussi faiblement couplées que possible.
Lorsque vous choisissez comment segmenter votre charge de travail, comparez les avantages aux complexités. Ce qui convient pour un nouveau produit en course pour un premier lancement est différent de ce dont a besoin une charge de travail conçue pour augmenter d'échelle. Lors de la refactorisation d'une architecture monolithique existante, vous devez évaluer comment l'application prendra en charge une décomposition vers l'absence d'état. La division de services en microservices permet aux petites équipes bien définies de les développer et les gérer. Toutefois, les services plus petits peuvent créer des complexités dont une latence supérieure, un débogage plus complexe et une charge opérationnelle accrue.
**Anti-modèles courants :**
+ La version [microservice *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) est une situation dans laquelle les composants atomiques deviennent si interdépendants que l'échec de l'un d'entre eux résulte en un échec encore plus important, ce qui rend les composants aussi rigides et fragiles qu'une architecture monolithique.
**Avantages liés au respect de cette pratique :**
+ L'utilisation de segments plus petits permet une plus grande agilité, une plus grande flexibilité organisationnelle et une évolutivité.
+ L'impact réduit des interruptions de service.
+ Les composants de l'application peuvent avoir différentes exigences de disponibilité, pouvant être pris en charge par une segmentation plus atomique.
+ Des responsabilités bien définies pour les équipes prenant en charge la charge de travail.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Élevé
## Directives d'implémentation
Choisissez votre type d'architecture en fonction de la façon dont vous segmenterez votre charge de travail. Choisissez une architecture orientée service (SOA) ou une architecture de microservices (ou, dans de rares cas, une architecture monolithique). Même si vous choisissez de commencer avec une architecture monolithe, vous devez vous assurer qu'elle est modulaire et peut évoluer vers une SOA ou vers des microservices à mesure que votre produit se développe avec son adoption par les utilisateurs. Une SOA et une architecture de microservices offrent une segmentation plus petite. Si elle est préférable en tant qu'architecture moderne évolutive et fiable, il faut prendre en compte des compromis, notamment lors du déploiement d'une architecture de microservices.
Le principal compromis est que vous avez maintenant une architecture pour le calcul distribué qui peut compliquer le respect des exigences en matière de latence des utilisateurs et qui complexifie le suivi et le débogage des interactions des utilisateurs. AWS X-Ray peut vous aider à résoudre ce problème. Un autre effet à prendre en compte est la hausse de la complexité opérationnelle à mesure que vous augmentez le nombre d'applications que vous gérez, ce qui nécessite le déploiement de plusieurs composants indépendants.
![\[Schéma comparant les architectures monolithique, orientée services et de microservices\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/monolith-soa-microservices-comparison.png)
## Étapes d'implémentation
+ Déterminer l'architecture adaptée pour refactoriser ou créer votre application. SOA et les microservices offrent respectivement une segmentation plus petite, ce qui est préférable pour une architecture moderne évolutive et fiable. SOA peut constituer un bon compromis pour parvenir à une segmentation plus réduite tout en évitant certaines des complexités des microservices. Pour en savoir plus, voir [Compromis des microservices](https://martinfowler.com/articles/microservice-trade-offs.html).
+ Si votre charge de travail est appropriée et que votre organisation peut la prendre en charge, vous devez utiliser une architecture de microservices pour obtenir la meilleure agilité et la meilleure fiabilité. Pour en savoir plus, voir [Implémentation des microservices sur AWS.](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Tenir compte du modèle [*Figuier étrangleur* pour](https://martinfowler.com/bliki/StranglerFigApplication.html) refactoriser une architecture monolithique en composants plus petits. Cela implique de remplacer petit à petit des composants d'une application spécifique par de nouveaux services et applications. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) agit comme le point de départ de la refactorisation incrémentielle. Pour en savoir plus, voir [Migrer sans interruption vers des charges de travail existantes sur site à l'aide d'un modèle Figuier étrangleur](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ L'implémentation d'une architecture de microservices peut exiger un mécanisme de découverte de service pour permettre à ces services distribués de communiquer entre eux. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) peut être utilisé avec des architectures orientées service afin de fournir une découverte et un accès fiables aux services. [AWS Cloud Map](https://aws.amazon.com/cloud-map/) peut également être utilisé pour la découverte dynamique de service basée sur un DNS.
+ Si vous migrez d'une architecture monolithique vers une architecture orientée service, [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) peut combler le fossé en tant que bus de services lors de la reconception des applications existantes dans le cloud.
+ Pour les architectures monolithiques existantes avec une base de données partagée unique, choisissez comment réorganiser les données en segments plus petits. Vous pouvez les réorganiser par unité commerciale, modèle d'accès ou structure de données. À ce stade du processus de refactorisation, vous devez choisir d'utiliser un type de base de données relationnelle ou non relationnelle. Pour en savoir plus, voir [De SQL à NoSQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html).
**Niveau d'effort du plan d'implémentation :** Élevé
## Ressources
**Bonnes pratiques associées :**
+ [REL03-BP02 Créer des services axés sur des domaines d'activité et la fonctionnalité](rel_service_architecture_business_domains.md)
**Documents connexes :**
+ [Amazon API Gateway : configuration d'une API REST à l'aide d'OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Qu'est-ce que l'architecture orientée service ?](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [Contexte délimité (modèle central dans la conception pilotée par domaine)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implémentation des microservices sur AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Compromis des microservices](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices : une définition de ce nouveau terme architectural](https://www.martinfowler.com/articles/microservices.html)
+ [Microservices sur AWS](https://aws.amazon.com/microservices/)
+ [Qu'est-ce qu'AWS App Mesh ?](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**Exemples connexes :**
+ [Atelier sur la modernisation itérative des applications](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**Vidéos connexes :**
+ [Offrir l'excellence avec l'architecture de microservices sur AWS](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 Créer des services axés sur des domaines d'activité et la fonctionnalité
Une architecture orientée services (SOA) crée des services avec des fonctions bien définies dictées par les besoins métier. Les microservices utilisent des modèles de domaine et un contexte délimité pour limiter ces éléments de façon à ce que chaque service fasse une seule chose. En vous concentrant sur des fonctionnalités spécifiques, vous pouvez différencier les exigences de fiabilité des différents services et cibler les investissements avec plus de précision. Un problème commercial concis et une petite équipe associée à chaque service permettent également une mise à l'échelle organisationnelle plus facile.
Lors de la conception d'une architecture de microservices, il est intéressant d'utiliser la conception pilotée par le domaine (DDD) pour modéliser le problème métier à l'aide d'entités. Par exemple, pour le site Amazon.com, les entités peuvent inclure le colis, la livraison, le calendrier, le prix, la remise et la devise. Ensuite, le modèle est subdivisé en modèles plus petits à l'aide du [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html)dans lequel les entités qui partagent des fonctions et des attributs similaires sont regroupées. Par conséquent, si nous reprenons l'exemple Amazon.com, le colis, la livraison et le calendrier feraient partie du contexte d'expédition, tandis que le prix, la remise et la devise appartiendraient au contexte de tarification. La divisison en contextes permet de faire émerger un modèle de délimitation des microservices.
![\[Modèle expliquant comment délimiter les microservices\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/building-services.png)
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Concevez votre charge de travail en fonction de vos domaines d'activité et de leurs fonctionnalités respectives. En vous concentrant sur des fonctionnalités spécifiques, vous pouvez différencier les exigences de fiabilité des différents services et cibler les investissements avec plus de précision. Un problème commercial concis et une petite équipe associée à chaque service permet également une mise à l'échelle organisationnelle plus facile.
+ Effectuez une analyse de domaine pour définir une conception orientée domaine (DDD) pour votre charge de travail. Ensuite, vous pouvez choisir un type d'architecture pour répondre aux besoins de votre charge de travail.
+ [Comment convertir un monolithe en microservices](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Premiers pas avec DDD en présence de systèmes hérités](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Eric Evans « Domain-Driven Design: Tackling Complexity in the Heart of Software »](https://www.amazon.com/gp/product/0321125215)
+ [Implémentation des microservices sur AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Décomposez vos services en composants aussi petits que possible. Avec l'architecture de microservices, vous pouvez séparer votre charge de travail en composants ayant la fonctionnalité minimale favorisant une mise à l'échelle organisationnelle et l'agilité.
+ Définissez l'API pour la charge de travail ainsi que ses objectifs de conception, ses limites et toutes autres considérations liées à son utilisation.
+ Définissez l'API
+ La définition de l'API doit tenir compte de la croissance et prévoir des paramètres supplémentaires.
+ Définissez les disponibilités conçues.
+ Votre API peut avoir plusieurs objectifs de conception pour différentes fonctions.
+ Établir des limites
+ Utilisez des tests pour définir les limites des capacités de votre charge de travail.
## Ressources
**Documents connexes :**
+ [Amazon API Gateway : configuration d'une API REST à l'aide d'OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Contexte délimité (modèle central dans la conception pilotée par domaine)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Eric Evans « Domain-Driven Design: Tackling Complexity in the Heart of Software »](https://www.amazon.com/gp/product/0321125215)
+ [Premiers pas avec DDD en présence de systèmes hérités](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Comment convertir un monolithe en microservices](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Implémentation des microservices sur AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Compromis des microservices](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices : une définition de ce nouveau terme architectural](https://www.martinfowler.com/articles/microservices.html)
+ [Microservices sur AWS](https://aws.amazon.com/microservices/)
# REL03-BP03 Fournir des contrats de service par API
Les contrats de service sont des accords documentés entre les équipes sur l'intégration de service et incluent une définition d'API lisible par la machine, des limites de taux et des attentes en matière de performance. Une stratégie de gestion des versions permet aux clients de continuer à utiliser l'API existante et de procéder à la migration de leurs applications vers la nouvelle API lorsqu'ils sont prêts. Le déploiement peut se produire à tout moment, tant que le contrat n'est pas enfreint. L'équipe du fournisseur de services peut utiliser la pile technologique de son choix pour satisfaire aux clauses du contrat d'API. De même, le consommateur du service peut utiliser sa propre technologie.
Les microservices s'appuient sur le concept d'architecture orientée service (SOA) pour créer des services offrant un ensemble minimal de fonctionnalités. Chaque service publie une API et des objectifs de conception, des limites et d'autres considérations pour l'utilisation du service. L'ensemble forme un *contrat* avec les applications appelantes. Ce système permet d'obtenir trois principaux avantages :
+ Le service fait face à un problème commercial concis devant être géré et une petite équipe doit y remédier. Cela permet un meilleur scaling-up organisationnel.
+ L'équipe peut déployer à tout moment, tant qu'elle respecte les exigences de son API et de son autre contrat.
+ Elle peut utiliser la pile technologique de son choix, dès lors qu'elle respecte les exigences de son API et de son autre contrat.
Amazon API Gateway est un service totalement géré qui permet aux développeurs de créer, de publier, de gérer, de surveiller et de sécuriser facilement des API à n'importe quelle échelle. Il gère toutes les tâches liées à l'acceptation et au traitement de plusieurs centaines de milliers d'appels d'API simultanés, notamment la gestion du trafic, le contrôle des autorisations et des accès, la surveillance et la gestion de la version de l'API. Grâce à OpenAPI Specification (OAS), anciennement appelé Swagger Specification, vous pouvez définir votre contrat d'API et l'importer dans API Gateway. Avec API Gateway, vous pouvez ensuite gérer les versions et déployer les API.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Faible
## Directives d'implémentation
+ Fournir des contrats de service par API : les contrats de service sont des accords documentés entre les équipes sur l'intégration de service et incluent une définition d'API lisible par machine, des limites de taux et des attentes en termes de performances.
+ [Amazon API Gateway : configuration d'une API REST à l'aide d'OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ Une stratégie de gestion des versions permet aux clients de continuer à utiliser l'API existante et de procéder à la migration de leurs applications vers la nouvelle API lorsqu'ils sont prêts.
+ Amazon API Gateway est un service entièrement géré qui permet aux développeurs de créer facilement des API à n'importe quelle échelle. Grâce à OpenAPI Specification (OAS), anciennement appelé Swagger Specification, vous pouvez définir votre contrat d'API et l'importer dans API Gateway. Avec API Gateway, vous pouvez ensuite gérer les versions et déployer les API.
## Ressources
**Documents connexes :**
+ [Amazon API Gateway : configuration d'une API REST à l'aide d'OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Contexte délimité (modèle central dans la conception pilotée par domaine)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implémentation des microservices sur AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Compromis des microservices](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices : une définition de ce nouveau terme architectural](https://www.martinfowler.com/articles/microservices.html)
+ [Microservices sur AWS](https://aws.amazon.com/microservices/)
# 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)
# 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