# Architecture de charge de travail
Pour garantir la fiabilité d’une charge de travail, il faut commencer par choisir le bon logiciel et la bonne infrastructure. Vos choix d’architecture ont un impact sur le comportement des charges de travail sur les cinq piliers Well-Architected. Pour des raisons de fiabilité, vous devez suivre des modèles spécifiques.
Les sections suivantes expliquent les bonnes pratiques à utiliser avec ces modèles de fiabilité.
**Topics**
+ [Conception de l’architecture de votre service de charge de travail](design-your-workload-service-architecture.md)
+ [Concevoir des interactions dans un système distribué pour éviter les défaillances](design-interactions-in-a-distributed-system-to-prevent-failures.md)
+ [Conception des interactions dans un système distribué pour résister aux défaillances ou les atténuer](design-interactions-in-a-distributed-system-to-mitigate-or-withstand-failures.md)
# Conception de l’architecture de votre service de 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. L’architecture orientée services (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.
Les interfaces d’architecture orientée service (SOA) utilisent des normes de communication communes permettant leur intégration rapide à de nouvelles charges de travail. La SOA a remplacé la pratique consistant à créer des architectures monolithes, composées d’unités interdépendantes et indivisibles.
Chez AWS, nous avons toujours utilisé la SOA. Nous concevons toutefois désormais nos systèmes à l’aide de microservices. Bien que les micro-services présentent plusieurs qualités attractives, l’avantage le plus important pour la disponibilité est le fait que les microservices sont plus légers et plus simples. Ils vous permettent de différencier la disponibilité requise par les différents services, et ainsi de concentrer plus spécifiquement vos investissements sur les microservices qui présentent les besoins les plus importants en disponibilité. Par exemple, pour fournir des pages d’informations produits sur Amazon.com (« pages de détails »), des centaines de microservices sont appelés pour construire des parties distinctes de la page. Tandis que certains services doivent être disponibles pour fournir le prix et les détails des produits, la grande majorité du contenu de la page peut simplement être exclu si le service n’est pas disponible. Même des éléments tels que les photos et commentaires ne sont pas requis pour fournir une expérience permettant à un client d’acheter un produit.
**Topics**
+ [REL03-BP01 Choisissez 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 Choisissez 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 (SOA) avec des 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 désiré :** 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 :**
+ Le [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 capacité de mise à l’échelle.
+ 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 d’exposition au risque 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 SOA ou une architecture de microservices (ou dans de rares cas, une architecture monolithique). Même si vous choisissez de commencer par une architecture monolithe, vous devez vous assurer qu'elle est modulaire et qu'elle puisse finalement évoluer vers des microservices au fur et à SOA mesure que votre produit évolue avec l'adoption par les utilisateurs. SOAet les microservices offrent respectivement une segmentation plus petite, ce qui est préférable en tant qu'architecture moderne, évolutive et fiable, mais certains compromis doivent être pris en compte, en particulier 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/latest/reliability-pillar/images/monolith-soa-microservices-comparison.png)
## Étapes d’implémentation
+ Déterminer l’architecture adaptée pour refactoriser ou créer votre application. SOAet les microservices offrent respectivement une segmentation plus petite, ce qui est préférable en tant qu'architecture moderne, évolutive et fiable. SOApeut être un bon compromis pour réduire la segmentation tout en évitant certaines des complexités des microservices. Pour plus de détails, consultez la section [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 plus de détails, voir [Implémentation de microservices sur AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html).
+ Envisagez de suivre le [modèle *Strangler Fig*](https://martinfowler.com/bliki/StranglerFigApplication.html) pour refactoriser un monolithe en composants plus petits. Cela implique le remplacement progressif de composants spécifiques de l’application par de nouvelles applications et de nouveaux services. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) sert de point de départ à la refactorisation incrémentielle. Pour plus de détails, consulter [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/).
+ La mise en œuvre de microservices peut nécessiter un mécanisme de découverte de services 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 services pour permettre 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 de services dynamique DNS basée sur des données.
+ Si vous passez d'un monolithe à un bus de service, [Amazon SOA MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) peut vous aider à combler cette lacune lors de la refonte d'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 de passer à un type de base de données relationnel ou non relationnel (nonSQL). Pour plus de détails, voir [De SQL à Non SQL](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 application à REST API l'aide d'Open API](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 de 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 que c'est 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 :**
+ [Garantir l'excellence grâce aux 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) définit des services avec des fonctions bien déterminées dictées par les besoins métier. Les microservices utilisent des modèles de domaine et un contexte limité pour définir les limites des services en fonction des limites du contexte métier. En se concentrant sur les domaines d’activité et les fonctionnalités, les équipes peuvent définir des exigences de fiabilité indépendantes pour leurs services. Les contextes limités isolent et encapsulent la logique métier, ce qui permet aux équipes de mieux raisonner sur la manière de gérer les défaillances.
**Résultat escompté :** les ingénieurs et les parties prenantes de l’entreprise définissent conjointement des contextes délimités et les utilisent pour concevoir des systèmes en tant que services remplissant des fonctions commerciales spécifiques. Ces équipes utilisent des pratiques établies telles que l’event storming pour définir les exigences. Les nouvelles applications sont conçues comme des services dont les limites sont bien définies et qui possèdent un couplage faible. Les monolithes existants sont décomposés en [contextes délimités](https://martinfowler.com/bliki/BoundedContext.html) et les conceptions des systèmes évoluent vers des architectures SOA ou de microservices. Lorsque les monolithes sont refactorisés, des approches établies telles que les contextes de bulles et les modèles de décomposition des monolithes sont appliquées.
Les services orientés domaine sont exécutés sous la forme d’un ou de plusieurs processus qui ne partagent pas d’état. Ils répondent de manière indépendante aux fluctuations de la demande et gèrent les scénarios de panne à la lumière des exigences spécifiques du domaine.
**Anti-modèles courants :**
+ Les équipes sont constituées autour de domaines techniques spécifiques tels que l’interface utilisateur et l’expérience utilisateur, les intergiciels ou les bases de données plutôt que de domaines commerciaux spécifiques.
+ Les applications couvrent des responsabilités de domaine. Les services qui couvrent des contextes limités peuvent être plus difficiles à gérer, nécessiter des efforts de test plus importants et nécessiter la participation de plusieurs équipes de domaine aux mises à jour logicielles.
+ Les dépendances de domaine, telles que les bibliothèques d’entités de domaine, sont partagées entre les services de telle sorte que les modifications apportées à un domaine de service nécessitent des modifications apportées à d’autres domaines de service.
+ Les contrats de service et la logique métier n’expriment pas les entités dans un langage de domaine commun et cohérent, ce qui crée des couches de traduction qui compliquent les systèmes et augmentent les efforts de débogage.
**Avantages du respect de cette bonne pratique :** les applications sont conçues comme des services indépendants délimités par domaines d’activité et utilisent un langage métier commun. Les services peuvent être testés et déployés indépendamment. Les services répondent aux exigences de résilience spécifiques au domaine mis en œuvre.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
La conception pilotée par domaine (DDD) est l’approche fondamentale de la conception et de la création de logiciels autour de domaines métier. Il est utile de travailler avec un cadre existant lorsque vous créez des services axés sur des domaines métier. Lorsque vous travaillez avec des applications monolithiques existantes, vous pouvez tirer parti des modèles de décomposition qui fournissent des techniques éprouvées pour moderniser les applications en services.
![\[Organigramme illustrant l’approche de la conception pilotée par domaine.\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/reliability-pillar/images/domain-driven-decision.png)
## Étapes d’implémentation
+ Les équipes peuvent organiser des ateliers [event storming](https://serverlessland.com/event-driven-architecture/visuals/event-storming) pour identifier rapidement les événements, les commandes, les agrégats et les domaines dans un format léger de notes autocollantes.
+ Une fois que les entités et les fonctions de domaine ont été formées dans un contexte de domaine, vous pouvez diviser votre domaine en services à l’aide d’un [contexte délimité](https://martinfowler.com/bliki/BoundedContext.html), dans lequel les entités partageant des caractéristiques et des attributs similaires sont regroupées. La division en contextes permet de faire émerger un modèle de délimitation des microservices.
+ Par exemple, les entités du site Web Amazon.com peuvent inclure le colis, la livraison, le calendrier, le prix, la remise et la devise.
+ Le colis, la livraison et le calendrier sont regroupés dans le contexte d’expédition, tandis que le prix, la remise et la devise sont regroupés dans le contexte de tarification.
+ [Décomposition des monolithes en microservices](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html) décrit les modèles de refactorisation des microservices. L’utilisation de modèles de décomposition par capacité métier, sous-domaine ou transaction s’inscrit parfaitement dans les approches axées sur le domaine.
+ Les techniques tactiques telles que le [contexte à bulles](https://www.domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) vous permettent d’introduire le DDD dans des applications existantes ou héritées sans devoir procéder à des réécritures préalables et sans engagement total envers le DDD. Dans une approche basée sur un contexte à bulles, un petit contexte délimité est établi à l’aide d’une cartographie et d’une coordination des services, ou [couche anticorruption](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context), qui protège le modèle de domaine nouvellement défini des influences extérieures.
Une fois que les équipes ont effectué une analyse du domaine et défini des entités et des contrats de service, elles peuvent tirer parti des services AWS pour mettre en œuvre leur conception axée sur le domaine sous forme de services basés sur le cloud.
+ Commencez votre développement en définissant des tests qui appliquent les règles métier de votre domaine. Le développement piloté par les tests (TDD) et le développement piloté par le comportement (BDD) aident les équipes à concentrer leurs services sur la résolution des problèmes commerciaux.
+ Sélectionnez les [services AWS](https://aws.amazon.com/microservices/) qui répondent le mieux aux exigences de votre domaine d’activité et à votre [architecture de microservices](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html) :
+ [AWS sans serveur](https://aws.amazon.com/serverless/) permet à votre équipe de se concentrer sur une logique de domaine spécifique au lieu de gérer les serveurs et l’infrastructure.
+ [Les conteneurs à AWS](https://aws.amazon.com/containers/) simplifient la gestion de votre infrastructure afin que vous puissiez vous concentrer sur les exigences de votre domaine.
+ [Les bases de données sur mesure](https://aws.amazon.com/products/databases/) vous permettent d’adapter les exigences de votre domaine au type de base de données le mieux adapté.
+ [Création d’architectures hexagonales sur AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html) décrit un cadre permettant d’intégrer une logique métier à des services en procédant de manière rétroactive à partir d’un domaine métier afin de répondre à des exigences fonctionnelles, puis d’associer des adaptateurs d’intégration. Les modèles qui séparent les détails de l’interface de la logique métier avec les services AWS aident les équipes à se concentrer sur les fonctionnalités du domaine et à améliorer la qualité des logiciels.
## Ressources
**Bonnes pratiques associées:**
+ [REL03-BP01 Choisissez comment segmenter votre charge de travail](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP03 Fournir des contrats de service par API](rel_service_architecture_api_contracts.md)
**Documents connexes :**
+ [Microservices AWS](https://aws.amazon.com/microservices/)
+ [Implémentation des microservices sur AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [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)
+ [ Conception axée sur le domaine : aborder la complexité au cœur du logiciel ](https://www.amazon.com/gp/product/0321125215)
+ [ Création d’architectures hexagonales sur AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html)
+ [ Décomposition des monolithes en microservices ](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html)
+ [ Event Storming ](https://serverlessland.com/event-driven-architecture/visuals/event-storming)
+ [ Messages entre contextes limités ](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context)
+ [ Microservices ](https://www.martinfowler.com/articles/microservices.html)
+ [ Développement piloté par les tests ](https://en.wikipedia.org/wiki/Test-driven_development)
+ [ Développement axé sur le comportement ](https://en.wikipedia.org/wiki/Behavior-driven_development)
**Exemples connexes :**
+ [ Conception de microservices natifs cloud sur AWS (extrait de DDD/EventStormingWorkshop) ](https://github.com/aws-samples/designing-cloud-native-microservices-on-aws/tree/main)
**Outils associés :**
+ [AWS CloudBases de données](https://aws.amazon.com/products/databases/)
+ [Sans serveur activé sur AWS](https://aws.amazon.com/serverless/)
+ [ Conteneurs à AWS](https://aws.amazon.com/containers/)
# REL03-BP03 Fournir des contrats de service par API
Les contrats de service sont des accords documentés entre API producteurs et consommateurs définis dans une définition lisible par API machine. Une stratégie de gestion des versions des contrats permet aux consommateurs de continuer à utiliser l'existant API et de migrer leurs applications vers une version plus récente API lorsqu'elles sont prêtes. Le déploiement du producteur peut avoir lieu à tout moment tant que le contrat est respecté. Les équipes de service peuvent utiliser la pile technologique de leur choix pour exécuter le API contrat.
**Résultat escompté :** les applications conçues avec des architectures orientées services ou microservices sont capables de fonctionner de manière indépendante tout en intégrant une dépendance à l'environnement d'exécution. Les modifications apportées à un API consommateur ou à un producteur n'interrompent pas la stabilité de l'ensemble du système lorsque les deux parties suivent un API contrat commun. Les composants qui communiquent via le service APIs peuvent exécuter des versions fonctionnelles indépendantes, mettre à niveau les dépendances d'exécution ou basculer vers un site de reprise après sinistre (DR) avec peu ou pas d'impact les uns sur les autres. En outre, les services discrets sont capables d’évoluer de manière indépendante en absorbant la demande de ressources sans que les autres services soient réduits horizontalement à l’unisson.
**Anti-modèles courants :**
+ Création d'un service APIs sans schémas fortement typés. Il en résulte APIs que cela ne peut pas être utilisé pour générer des API liaisons et des charges utiles qui ne peuvent pas être validées par programmation.
+ Ne pas adopter de stratégie de gestion des versions, qui oblige API les consommateurs à effectuer des mises à jour et à publier ou à échouer lorsque les contrats de service évoluent.
+ Messages d’erreur qui divulguent les détails de l’implémentation du service sous-jacent au lieu de décrire les échecs d’intégration dans le contexte et le langage du domaine.
+ Ne pas utiliser de API contrats pour développer des scénarios de test et API des mises en œuvre fictives afin de permettre des tests indépendants des composants du service.
**Avantages de l'établissement de cette meilleure pratique :** les systèmes distribués composés de composants communiquant par le biais de contrats de API service peuvent améliorer la fiabilité. Les développeurs peuvent détecter les problèmes potentiels dès le début du processus de développement en vérifiant le type lors de la compilation afin de vérifier que les demandes et les réponses respectent le API contrat et que les champs obligatoires sont présents. APIles contrats fournissent une interface autodocumentée claire APIs et fournissent une meilleure interopérabilité entre les différents systèmes et langages de programmation.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
Une fois que vous avez identifié les domaines commerciaux et déterminé la segmentation de votre charge de travail, vous pouvez développer votre serviceAPIs. Définissez d'abord des contrats de service lisibles par machine pourAPIs, puis implémentez une stratégie de gestion des API versions. Lorsque vous êtes prêt à intégrer des services via des protocoles courants tels que REST GraphQL ou des événements asynchrones, vous pouvez intégrer des AWS services dans votre architecture afin d'intégrer vos composants à l'aide de contrats bien typés. API
**AWS services pour les API contrats de service**
Intégrez AWS des services tels qu'[Amazon API Gateway](https://aws.amazon.com/api-gateway/) et [Amazon EventBridge](https://aws.amazon.com/eventbridge/) dans votre architecture pour utiliser des contrats de API service dans votre application. [AWS AppSync](https://aws.amazon.com/appsync/) Amazon API Gateway vous permet d'intégrer directement des AWS services natifs et d'autres services Web. APIGateway prend en charge la [APIspécification Open](https://github.com/OAI/OpenAPI-Specification) et le versionnement. AWS AppSync est un point de terminaison [GraphQL](https://graphql.org/) géré que vous configurez en définissant un schéma GraphQL pour définir une interface de service pour les requêtes, les mutations et les abonnements. Amazon EventBridge utilise des schémas d'événements pour définir des événements et générer des liaisons de code pour vos événements.
## Étapes d’implémentation
+ Tout d'abord, définissez un contrat pour votreAPI. Un contrat exprimera les capacités d'un API et définira des objets de données et des champs fortement typés pour l'APIentrée et la sortie.
+ Lorsque vous configurez APIs dans API Gateway, vous pouvez importer et exporter des API spécifications ouvertes pour vos points de terminaison.
+ [L'importation d'une API définition ouverte](https://docs.aws.amazon.com/apigateway/latest/developerguide/import-edge-optimized-api.html) simplifie la création de votre API et peut être intégrée à AWS l'infrastructure sous forme d'outils de code tels que le [AWS Serverless Application Model](https://aws.amazon.com/serverless/sam/)et [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/).
+ [L'exportation d'une API définition](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-export-api.html) simplifie l'intégration avec API les outils de test et fournit aux consommateurs de services une spécification d'intégration.
+ Vous pouvez définir et gérer GraphQL AWS AppSync en [définissant APIs un fichier de schéma GraphQL](https://docs.aws.amazon.com/appsync/latest/devguide/designing-your-schema.html) pour générer votre interface de contrat et simplifier l'interaction avec des REST modèles complexes, plusieurs tables de base de données ou des services existants.
+ [AWS Amplify](https://aws.amazon.com/amplify/)les projets intégrés AWS AppSync génèrent des fichiers de JavaScript requêtes fortement typés à utiliser dans votre application, ainsi qu'une bibliothèque cliente AWS AppSync GraphQL pour les tables Amazon [DynamoDB](https://aws.amazon.com/dynamodb/).
+ Lorsque vous consommez des événements de service d'Amazon EventBridge, les événements adhèrent aux schémas qui existent déjà dans le registre des schémas ou que vous définissez avec l'Open API Spec. Avec un schéma défini dans le registre, vous pouvez également générer des liaisons client à partir du contrat de schéma afin d’intégrer votre code aux événements.
+ Extension ou version de votreAPI. L'extension d'une API est une option plus simple lorsque vous ajoutez des champs qui peuvent être configurés avec des champs facultatifs ou des valeurs par défaut pour les champs obligatoires.
+ JSONles contrats basés sur des protocoles tels que REST GraphQL peuvent être une bonne solution pour l'extension de contrat.
+ XMLdes contrats basés sur des protocoles tels que SOAP ceux qui devraient être testés auprès des consommateurs de services afin de déterminer la faisabilité d'une prolongation du contrat.
+ Lors du versionnement d'unAPI, envisagez d'implémenter le versionnage par proxy dans le cadre duquel une façade est utilisée pour prendre en charge les versions afin que la logique puisse être maintenue dans une base de code unique.
+ Avec API Gateway, vous pouvez utiliser [les mappages de demandes et de réponses](https://docs.aws.amazon.com/apigateway/latest/developerguide/request-response-data-mappings.html#transforming-request-response-body) pour simplifier l'absorption des modifications de contrat en établissant une façade pour fournir des valeurs par défaut pour les nouveaux champs ou pour supprimer les champs supprimés d'une demande ou d'une réponse. Avec cette approche, le service sous-jacent peut gérer une base de code unique.
## Ressources
**Bonnes pratiques associées :**
+ [REL03-BP01 Choisissez 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)
+ [REL04-BP02 Implémenter des dépendances faiblement couplées](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL05-BP03 Contrôler et limiter les appels de nouvelle tentative](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP05 Définir les délais d'expiration des clients](rel_mitigate_interaction_failure_client_timeouts.md)
**Documents connexes :**
+ [Qu'est-ce qu'une API (interface de programmation d'applications) ?](https://aws.amazon.com/what-is/api/)
+ [Implémentation de microservices sur AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.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/)
+ [Utilisation des extensions de API passerelle pour ouvrir API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-swagger-extensions.html)
+ [Spécification ouverte API](https://github.com/OAI/OpenAPI-Specification)
+ [ GraphQL : schémas et types ](https://graphql.org/learn/schema/)
+ [liaisons EventBridge de code Amazon](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-schema-code-bindings.html)
**Exemples connexes :**
+ [Amazon API Gateway : Configuration d'une application à REST API l'aide d'Open API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Amazon API Gateway vers l'application Amazon CRUD DynamoDB à l'aide d'Open API](https://serverlessland.com/patterns/apigw-ddb-openapi-crud?ref=search)
+ [Modèles modernes d'intégration des applications à l'ère du sans serveur : intégration des services de API passerelle](https://catalog.us-east-1.prod.workshops.aws/workshops/be7e1ee7-b91f-493d-93b0-8f7c5b002479/en-US/labs/asynchronous-request-response-poll/api-gateway-service-integration)
+ [Implémentation du versionnement des API passerelles basé sur les en-têtes avec Amazon CloudFront](https://aws.amazon.com/blogs/compute/implementing-header-based-api-gateway-versioning-with-amazon-cloudfront/)
+ [AWS AppSync : création d’une application client ](https://docs.aws.amazon.com/appsync/latest/devguide/building-a-client-app.html#aws-appsync-building-a-client-app)
**Vidéos connexes :**
+ [Utilisation d'Open API in AWS SAM pour gérer API Gateway](https://www.youtube.com/watch?v=fet3bh0QA80)
**Outils associés :**
+ [APIPasserelle Amazon](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [Amazon EventBridge](https://aws.amazon.com/eventbridge/)
# 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/)
# Conception des interactions dans un système distribué pour résister aux défaillances ou les atténuer
Les systèmes distribués s’appuient sur des réseaux de communication pour interconnecter des composants (tels que des serveurs ou des services). Votre charge de travail doit fonctionner de manière fiable malgré la perte de données ou la latence sur ces réseaux. Les composants du système distribué doivent fonctionner de manière à ne pas avoir d’impact négatif sur les autres composants ou sur la charge de travail. Ces bonnes pratiques permettent aux charges de travail de résister aux contraintes ou aux défaillances, de s’en remettre plus rapidement et d’atténuer l’impact de ces altérations. Il en résulte une amélioration du temps moyen de récupération (MTTR).
Ces bonnes pratiques permettent d’éviter les défaillances et d’améliorer le temps moyen entre défaillances (MTBF).
**Topics**
+ [REL05-BP01 Implémenter une dégradation appropriée pour transformer les dépendances matérielles applicables en dépendances logicielles](rel_mitigate_interaction_failure_graceful_degradation.md)
+ [REL05-BP02 Limiter les demandes](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Contrôler et limiter les appels de nouvelle tentative](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Procéder à une interruption immédiate et limiter les files d’attente](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Définir les délais d'expiration des clients](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 Rendre les systèmes apatrides dans la mesure du possible](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 Mettre en œuvre des leviers de secours](rel_mitigate_interaction_failure_emergency_levers.md)
# REL05-BP01 Implémenter une dégradation appropriée pour transformer les dépendances matérielles applicables en dépendances logicielles
Les composants de l’application doivent continuer à exécuter leur fonction principale même si les dépendances deviennent indisponibles. Ils peuvent fournir des données légèrement obsolètes, des données alternatives ou même aucune donnée. Cela garantit que le fonctionnement global du système n’est que très peu entravé par des défaillances localisées tout en fournissant une valeur commerciale centrale.
**Résultat escompté :** lorsque les dépendances d’un composant ne sont pas en bon état, le composant lui-même peut continuer de fonctionner, mais de manière dégradée. Les modes de défaillance des composants doivent être considérés comme un fonctionnement normal. Les flux de travail doivent être conçus de manière à ce que ces défaillances n’aboutissent pas à une défaillance complète ou qu’elles aboutissent au moins à des états prévisibles et récupérables.
**Anti-modèles courants :**
+ Ne pas identifier les fonctionnalités métier essentielles nécessaires. Ne pas tester le fonctionnement des composants, même en cas de défaillance des dépendances.
+ Aucune donnée n’est diffusée en cas d’erreur ou lorsqu’une seule dépendance parmi plusieurs n’est pas disponible et que des résultats partiels peuvent toujours être renvoyés.
+ Création d’un état incohérent lorsqu’une transaction échoue partiellement.
+ Ne pas disposer d’un autre moyen d’accéder à un magasin de paramètres central.
+ Invalider ou vider l’état local à la suite d’un échec d’actualisation sans prendre en compte les conséquences d’une telle opération.
**Avantages du respect de cette bonne pratique :** une dégradation progressive améliore la disponibilité du système dans son ensemble et maintient la fonctionnalité des fonctions les plus importantes même en cas de panne.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
La mise en œuvre d’une dégradation progressive permet de minimiser l’impact des défaillances de dépendance sur le fonctionnement des composants. Idéalement, un composant détecte les défaillances liées aux dépendances et les contourne de manière à avoir un impact minimal sur les autres composants ou les clients.
L’architecture permettant une dégradation progressive implique de prendre en compte les modes de défaillance potentiels lors de la conception des dépendances. Pour chaque mode de défaillance, déterminez un moyen de fournir la plupart des fonctionnalités, ou les plus critiques d’entre elles, du composant aux appelants ou aux clients. Ces considérations peuvent devenir des exigences supplémentaires qui peuvent être testées et vérifiées. Idéalement, un composant est capable d’exécuter sa fonction principale de manière acceptable, même en cas de défaillance d’une ou de plusieurs dépendances.
Il s’agit tout autant d’une discussion commerciale que technique. Toutes les exigences commerciales sont importantes et doivent être satisfaites dans la mesure du possible. Cependant, il est tout de même logique de se demander ce qui doit se passer lorsque toutes les exigences ne peuvent pas être satisfaites. Un système peut être conçu pour être disponible et cohérent, mais lorsqu’une exigence doit être supprimée, laquelle est la plus importante ? Pour le traitement des paiements, il peut s’agir de la cohérence. Pour une application en temps réel, il peut s’agir de la disponibilité. Pour un site Web orienté client, la réponse peut dépendre des attentes du client.
Ce que cela signifie dépend des exigences du composant et de ce qui doit être considéré comme sa fonction principale. Par exemple :
+ un site Web d’e-commerce peut afficher des données provenant de plusieurs systèmes différents, par exemple des recommandations personnalisées, les produits les mieux classés et l’état des commandes des clients sur la page de destination. Lorsqu’un système en amont est défaillant, il est tout de même judicieux d’afficher tout le reste au lieu d’afficher une page d’erreur à un client.
+ Un composant effectuant des écritures par lots peut toujours continuer à traiter un lot si l’une des opérations individuelles échoue. La mise en œuvre d’un mécanisme de nouvelle tentative doit être simple. Cela peut être fait en renvoyant à l’appelant des informations indiquant quelles opérations ont réussi, lesquelles ont échoué et pourquoi elles ont échoué, ou en plaçant les demandes ayant échoué dans une file d’attente de lettres mortes pour implémenter des tentatives asynchrones. Les informations relatives aux opérations ayant échoué doivent également être consignées.
+ Un système qui traite les transactions doit vérifier que toutes les mises à jour individuelles sont exécutées ou qu’aucune d’entre elles ne l’est. Pour les transactions distribuées, le modèle Saga peut être utilisé pour annuler les opérations précédentes en cas d’échec d’une opération ultérieure de la même transaction. Ici, la fonction principale est de maintenir la cohérence.
+ Les systèmes soumis à des contraintes de temps doivent être en mesure de gérer les dépendances qui ne répondent pas en temps voulu. Dans ces cas de figure, le modèle du disjoncteur peut être utilisé. Lorsque les réponses d’une dépendance commencent à expirer, le système peut passer à un état fermé où aucun appel supplémentaire n’est effectué.
+ Une application peut lire des paramètres à partir d’un magasin de paramètres. Il peut être utile de créer des images de conteneur avec un ensemble de paramètres par défaut et de les utiliser si le magasin de paramètres n’est pas disponible.
Notez que les chemins empruntés en cas de défaillance d’un composant doivent être testés et doivent être nettement plus simples que le chemin principal. Généralement, [les stratégies de repli doivent être évitées](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/).
## Étapes d’implémentation
Identifiez les dépendances externes et internes. Déterminez quels types de défaillances peuvent y survenir. Réfléchissez à des moyens de minimiser l’impact négatif sur les systèmes en amont et en aval, ainsi que sur les clients lors de ces défaillances.
Vous trouverez ci-dessous une liste des dépendances et la manière de les dégrader de façon appropriée en cas d’échec :
1. **Défaillance partielle des dépendances :** un composant peut adresser plusieurs demandes à des systèmes en aval, soit sous la forme de demandes multiples adressées à un système, soit sous celle d’une demande adressée à plusieurs systèmes. Selon le contexte métier, différentes méthodes de gestion peuvent être appropriées (pour plus de détails, voir les exemples précédents dans le guide de mise en œuvre).
1. **Un système en aval est incapable de traiter les demandes en raison d’une charge élevée :** si les demandes adressées à un système en aval échouent régulièrement, il n’est pas logique de continuer à réessayer. Cela peut créer une charge supplémentaire sur un système déjà surchargé et rendre la récupération plus difficile. Le modèle du disjoncteur peut être utilisé ici afin de surveiller les appels en échec vers un système en aval. Si un grand nombre d’appels échouent, il cessera d’envoyer d’autres demandes au système en aval et n’autorisera les appels qu’occasionnellement pour vérifier si le système en aval est à nouveau disponible.
1. **Aucun magasin de paramètres n’est disponible :** pour transformer un magasin de paramètres, vous pouvez utiliser la mise en cache des dépendances souples ou des valeurs par défaut saines incluses dans les images de conteneur ou de machine. Notez que ces valeurs par défaut doivent être tenues à jour et incluses dans les suites de tests.
1. **Aucun service de surveillance ou autre dépendance non fonctionnelle n’est disponible :** si un composant ne peut pas envoyer par intermittence des journaux, des métriques ou des traces à un service de surveillance central, il est souvent préférable de continuer à exécuter les fonctions métier comme d’habitude. Il est souvent inacceptable de ne pas enregistrer ni de pousser des métriques pendant une longue période. En outre, certains cas d’utilisation peuvent nécessiter des entrées d’audit complètes pour répondre aux exigences de conformité.
1. **Il est possible qu’une instance principale d’une base de données relationnelle ne soit pas disponible :** Amazon Relational Database Service, comme presque toutes les bases de données relationnelles, ne peut avoir qu’une seule instance de rédacteur principal. Cela crée un point de défaillance unique pour les charges de travail d’écriture et complique la mise à l’échelle. Ce problème peut être partiellement atténué en utilisant une configuration multi-AZ pour une haute disponibilité ou Amazon Aurora sans serveur pour une meilleure mise à l’échelle. Pour des exigences de très haute disponibilité, il peut être judicieux de ne pas se fier du tout au rédacteur principal. Pour les requêtes qui se limitent à la lecture, des répliques de lecture peuvent être utilisées, ce qui assure la redondance et la possibilité d’une augmentation horizontale, et pas seulement d’une augmentation verticale. Les écritures peuvent être mises en mémoire tampon, par exemple dans une file d’attente Amazon Simple Queue Service, afin que les demandes d’écriture des clients puissent toujours être acceptées même si le serveur principal est temporairement indisponible.
## Ressources
**Documents connexes :**
+ [Amazon API Gateway : Limitation des demandes d’API pour améliorer le débit](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Coupe-circuit (présentation du coupe-circuit, ouvrage « Release It\$1 »)](https://martinfowler.com/bliki/CircuitBreaker.html)
+ [Nouvelles tentatives après erreur et backoff exponentiel dans AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Michael Nygard « Release It\$1 Design and Deploy Production-Ready Software »](https://pragprog.com/titles/mnee2/release-it-second-edition/)
+ [L’Amazon Builders’ Library : éviter le basculement dans les systèmes distribués](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [L’Amazon Builders’ Library : éviter les retards de file d’attente insurmontables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [L’Amazon Builders’ Library : défis et stratégies de mise en cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Amazon Builders’ Library : délais d’attente, nouvelles tentatives et backoff avec instabilité](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Vidéos connexes :**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP02 Limiter les demandes
Limitez les demandes pour atténuer l’épuisement des ressources en cas d’augmentation imprévue de la demande. Les demandes inférieures aux taux de limitation sont traitées tandis que celles dépassant la limite définie sont rejetées avec un message de retour indiquant que la demande a dépassé la limite.
**Résultat escompté :** les pics de volume importants, qu’ils soient dus à une augmentation soudaine du trafic client, à des inondations ou à des tempêtes de nouvelles tentatives, sont atténués par la limitation des demandes, ce qui permet aux charges de travail de poursuivre le traitement normal du volume de demandes pris en charge.
**Anti-modèles courants :**
+ Les limitations des points de terminaison de l’API ne sont pas implémentées ou leurs valeurs par défaut sont conservées sans tenir compte des volumes attendus.
+ Les points de terminaison de l’API ne sont pas testés en termes de charge ou les limites de régulation ne sont pas testées.
+ Limiter les taux de demandes sans tenir compte de la taille ou de la complexité des demandes.
+ Tester les taux de demande maximaux ou la taille maximale des demandes, mais pas les deux simultanément.
+ Les ressources ne sont pas provisionnées selon les mêmes limites établies lors des tests.
+ Aucun plan d’utilisation n’a été configuré ni envisagé pour les utilisateurs d’API d’application à application (A2A).
+ Les utilisateurs de files d’attente qui mettent à l’échelle horizontalement ne disposent pas de paramètres de simultanéité maximaux configurés.
+ La limitation du débit par adresse IP n’a pas été mise en œuvre.
**Avantages du respect de cette bonne pratique :** les charges de travail qui fixent des limites peuvent fonctionner normalement et traiter correctement le chargement des demandes acceptées en cas de pics de volume inattendus. Les pics soudains ou soutenus de demandes adressées aux API et aux files d’attente sont limités et n’épuisent pas les ressources de traitement des demandes. Les limites de débit limitent les requêtes individuelles afin que les volumes élevés de trafic provenant d’une seule adresse IP ou d’un seul utilisateur d’API n’épuisent pas les ressources et n’aient pas d’impact sur les autres consommateurs.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Les services doivent être conçus pour traiter une capacité connue de demandes ; cette capacité peut être établie par des tests de charge. Si les taux d’arrivée des demandes dépassent les limites, la réponse appropriée indique qu’une demande a été limitée. Cela permet au consommateur de gérer l’erreur et de réessayer ultérieurement.
Lorsque votre service nécessite une implémentation de limitation, pensez à implémenter l’algorithme du compartiment à jetons, dans lequel un jeton compte pour une demande. Les jetons sont rechargés à une vitesse limitée par seconde et vidés de manière asynchrone à raison d’un jeton par demande.
![\[Schéma décrivant l’algorithme du compartiment à jetons.\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/reliability-pillar/images/token-bucket-algorithm.png)
[Amazon API Gateway](https://aws.amazon.com/api-gateway/) implémente l’algorithme du compartiment à jetons en fonction des limites du compte et de la région et il peut être configuré par client avec des plans d’utilisation. En outre, [Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/) et [Amazon Kinesis](https://aws.amazon.com/kinesis/) peuvent mettre en mémoire tampon les demandes afin de réduire le taux de demandes et de permettre des taux de limitation plus élevés pour les demandes pouvant être traitées. Enfin, vous pouvez implémenter une limitation de débit avec [AWS WAF](https://aws.amazon.com/waf/) pour limiter les consommateurs d’API spécifiques qui génèrent une charge anormalement élevée.
## Étapes d’implémentation
Vous pouvez configurer API Gateway avec des limites de régulation pour vos API et renvoyer des erreurs `429 Too Many Requests` lorsque les limites sont dépassées. Vous pouvez utiliser AWS WAF avec votre AWS AppSync et vos points de terminaison API Gateway pour activer la limitation du débit par adresse IP. En outre, lorsque votre système peut tolérer un traitement asynchrone, vous pouvez placer les messages dans une file d’attente ou un flux pour accélérer les réponses aux clients du service, ce qui vous permet d’atteindre des taux de limitation plus élevés.
Avec le traitement asynchrone, lorsque vous avez configuré Amazon SQS comme source d’événements pour AWS Lambda, vous pouvez [configurer une simultanéité maximale](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) afin d’éviter que des taux d’événements élevés ne consomment le quota d’exécution simultanée du compte disponible nécessaire pour les autres services de votre charge de travail ou de votre compte.
Bien qu’API Gateway propose une implémentation gérée du compartiment à jetons, lorsque vous ne pouvez pas utiliser API Gateway, vous pouvez tirer parti des implémentations open source spécifiques à la langue (voir les exemples associés dans Ressources) du compartiment à jetons pour vos services.
+ Comprenez et configurez les [limites de limitation d’API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) au niveau du compte par région, de l’API par étape et de la clé d’API par niveau de plan d’utilisation.
+ Appliquez des [règles de limitation de débit AWS WAF](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/) à API Gateway et aux points de terminaison AWS AppSync pour vous protéger contre les inondations et bloquer les adresses IP malveillantes. Les règles de limitation de débit peuvent également être configurées sur les clés d’API AWS AppSync pour les consommateurs A2A.
+ Déterminez si vous avez besoin d’un contrôle plus limitant qu’une limitation du débit pour les API AWS AppSync et, si c’est le cas, configurez un API Gateway devant votre point de terminaison AWS AppSync.
+ Lorsque les files d’attente Amazon SQS sont configurées comme déclencheurs pour les consommateurs de files d’attente Lambda, définissez la [simultanéité maximale](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) sur une valeur qui traite suffisamment pour atteindre vos objectifs de niveau de service, mais qui ne respecte pas les limites de simultanéité ayant un impact sur les autres fonctions Lambda. Envisagez de définir une simultanéité réservée pour d’autres fonctions Lambda du même compte et de la même région lorsque vous utilisez des files d’attente avec Lambda.
+ Utilisez API Gateway avec des intégrations de services natives vers Amazon SQS ou Kinesis pour mettre des demandes en mémoire tampon.
+ Si vous ne pouvez pas utiliser API Gateway, examinez les bibliothèques spécifiques à la langue pour implémenter l’algorithme de compartiment à jetons adapté à votre charge de travail. Consultez la section des exemples et faites vos propres recherches pour trouver une bibliothèque appropriée.
+ Testez les limites que vous envisagez de définir ou d’autoriser à augmenter, et documentez les limites testées.
+ N’augmentez pas les limites au-delà de ce que vous avez établi lors des tests. Lorsque vous augmentez une limite, vérifiez que les ressources provisionnées sont déjà équivalentes ou supérieures à celles des scénarios de test avant d’appliquer l’augmentation.
## Ressources
**Bonnes pratiques associées :**
+ [REL04-BP03 Faire un travail constant](rel_prevent_interaction_failure_constant_work.md)
+ [REL05-BP03 Contrôler et limiter les appels de nouvelle tentative](rel_mitigate_interaction_failure_limit_retries.md)
**Documents connexes :**
+ [Amazon API Gateway : Limitation des demandes d’API pour améliorer le débit](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [AWS WAF : instruction de règle fréquentielle ](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based.html)
+ [ Introduction d’une simultanéité maximale de AWS Lambda en utilisant Amazon SQS comme source d’événements ](https://aws.amazon.com/blogs/compute/introducing-maximum-concurrency-of-aws-lambda-functions-when-using-amazon-sqs-as-an-event-source/)
+ [AWS Lambda : simultanéité maximale ](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency)
**Exemples connexes :**
+ [ Les trois principales règles AWS WAF basées sur le débit ](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/)
+ [ Bucket4j Java ](https://github.com/bucket4j/bucket4j)
+ [ Jeton-compartiment Python ](https://pypi.org/project/token-bucket/)
+ [ Nœud jeton-compartiment ](https://www.npmjs.com/package/tokenbucket)
+ [ Limitation du débit de threading du système .NET ](https://www.nuget.org/packages/System.Threading.RateLimiting)
**Vidéos connexes :**
+ [ Implementing GraphQL API security best practices with AWS AppSync](https://www.youtube.com/watch?v=1ASMLeJ_15U)
**Outils associés :**
+ [ Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [ Amazon Kinesis ](https://aws.amazon.com/kinesis/)
+ [AWS WAF](https://aws.amazon.com/waf/)
+ [ Salle d’attente virtuelle sur AWS](https://aws.amazon.com/solutions/implementations/virtual-waiting-room-on-aws/)
# REL05-BP03 Contrôler et limiter les appels de nouvelle tentative
Utilisez le backoff exponentiel pour relancer les demandes à des intervalles de plus en plus longs entre chaque nouvelle tentative. Introduisez un décalage entre les tentatives afin de randomiser les intervalles entre les tentatives. Limitez le nombre maximal de tentatives.
**Résultat escompté :** Les composants typiques d'un système logiciel distribué incluent les serveurs, les équilibreurs de charge, les bases de données et DNS les serveurs. Pendant le fonctionnement normal, ces composants peuvent répondre aux demandes par des erreurs temporaires ou limitées, ainsi que par des erreurs qui persisteraient indépendamment des nouvelles tentatives. Lorsque des clients adressent des demandes à des services, celles-ci consomment des ressources, notamment de la mémoire, des threads, des connexions, des ports ou toute autre ressource limitée. Le contrôle et la limitation des nouvelles tentatives constituent une stratégie visant à libérer et à minimiser la consommation de ressources afin que les composants du système soumis à des contraintes ne soient pas surchargés.
Lorsque le client demande une expiration du délai ou reçoit des réponses d’erreur, il doit décider de réessayer ou non. S’il recommence, il le fait avec un backoff exponentiel avec une instabilité et une valeur de nouvelle tentative maximale. Par conséquent, les services et processus back-end sont moins sollicités et le temps nécessaire pour s’autoréparer est réduit, ce qui se traduit par une récupération plus rapide et un traitement efficace des demandes.
**Anti-modèles courants :**
+ Implémentation de nouvelles tentatives sans ajouter de valeurs de backoff exponentiel, d’instabilité et de nouvelles tentatives maximales. Le backoff et l’instabilité permettent d’éviter les pics de trafic artificiels dus à des tentatives involontaires coordonnées à intervalles réguliers.
+ Implémentation de nouvelles tentatives sans tester leurs effets ou en supposant que les nouvelles tentatives sont déjà intégrées ou SDK sans test de scénarios de nouvelle tentative.
+ Incapacité à comprendre les codes d’erreur publiés à partir des dépendances, ce qui entraîne une nouvelle tentative pour toutes les erreurs, y compris celles dont la cause claire indique un manque d’autorisation, une erreur de configuration ou toute autre condition qui, comme on pouvait s’y attendre, ne sera pas résolue sans intervention manuelle.
+ Ne pas aborder les pratiques d’observabilité, notamment la surveillance et l’envoi d’alertes en cas de pannes de service répétées afin que les problèmes sous-jacents soient connus et puissent être résolus.
+ Développement de mécanismes de nouvelle tentative personnalisés lorsque des fonctionnalités de nouvelle tentative intégrées ou tierces suffisent.
+ Réessayer à plusieurs couches de votre pile d’applications d’une manière qui complique les nouvelles tentatives et augmente la consommation de ressources lors d’une tempête de nouvelles tentatives. Assurez-vous de comprendre comment ces erreurs affectent votre application et les dépendances sur lesquelles vous vous appuyez, puis implémentez les nouvelles tentatives à un seul niveau.
+ Réessayer les appels de service qui ne sont pas idempotents, ce qui peut entraîner des effets secondaires inattendus tels que des résultats dupliqués.
**Avantages du respect de cette bonne pratique :** les nouvelles tentatives aident les clients à obtenir les résultats souhaités lorsque les requêtes échouent, mais elles font également perdre plus de temps au serveur pour obtenir les réponses souhaitées. Lorsque les défaillances sont rares ou transitoires, les nouvelles tentatives fonctionnent bien. Lorsque les défaillances sont causées par une surcharge de ressources, les nouvelles tentatives peuvent aggraver la situation. L’ajout d’un backoff exponentiel avec instabilité aux nouvelles tentatives des clients permet aux serveurs de se rétablir en cas de défaillance provoquée par une surcharge de ressources. L’instabilité permet d’éviter l’alignement des demandes en pics, tandis que le backoff réduit l’escalade de charge provoquée par l’ajout de nouvelles tentatives au chargement normal des demandes. Enfin, il est important de configurer un nombre maximal de nouvelles tentatives ou un temps écoulé afin d’éviter de créer des backlogs susceptibles d’entraîner des échecs métastables.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Contrôler et limiter les appels de nouvelle tentative. Utilisez le backoff exponentiel pour réessayer après des intervalles progressivement plus longs. Introduisez l’instabilité pour randomiser les intervalles de nouvelle tentative et limiter le nombre maximal de nouvelles tentatives.
Certains AWS SDKs implémentent les nouvelles tentatives et le recul exponentiel par défaut. Utilisez ces AWS implémentations intégrées, le cas échéant, dans votre charge de travail. Implémentez une logique similaire dans votre charge de travail lorsque vous appelez des services qui sont idempotents et où les nouvelles tentatives améliorent la disponibilité de vos clients. Déterminez quels sont les délais d’expiration et quand les nouvelles tentatives doivent s’arrêter en fonction de votre cas d’utilisation. Créez et mettez en pratique des scénarios de test pour ces cas d’utilisation impliquant de nouvelles tentatives.
## Étapes d’implémentation
+ Déterminez la couche optimale de votre pile d’applications pour implémenter de nouvelles tentatives pour les services sur lesquels repose votre application.
+ Tenez compte des stratégies de relance éprouvées SDKs qui mettent en œuvre des stratégies de relance éprouvées avec un retard et une instabilité exponentiels dans la langue de votre choix, et privilégiez ces stratégies par rapport à l'écriture de vos propres implémentations de nouvelle tentative.
+ Vérifiez que les [services sont idempotents](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/) avant d’implémenter de nouvelles tentatives. Une fois les nouvelles tentatives mises en œuvre, assurez-vous qu’elles sont à la fois testées et régulièrement mises en œuvre en production.
+ Lorsque vous appelez le AWS serviceAPIs, utilisez les options de configuration [AWS SDKs[AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-retries.html)](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html)et et comprenez la nouvelle tentative. Déterminez si les valeurs par défaut conviennent à votre cas d’utilisation, testez-les et ajustez-les si nécessaire.
## Ressources
**Bonnes pratiques associées :**
+ [REL04-BP04 Rendre les opérations de mutation idempotentes](rel_prevent_interaction_failure_idempotent.md)
+ [REL05-BP02 Limiter les demandes](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP04 Procéder à une interruption immédiate et limiter les files d’attente](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Définir les délais d'expiration des clients](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL11-BP01 Surveiller tous les composants de la charge de travail pour détecter les défaillances](rel_withstand_component_failures_monitoring_health.md)
**Documents connexes :**
+ [Rétentatives d'erreur et retard exponentiel dans AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Amazon Builders’ Library : délais d’attente, nouvelles tentatives et backoff avec instabilité](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [ Instabilité et backoff exponentiel ](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/)
+ [Sécuriser les nouvelles tentatives avec idempotent APIs](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)
**Exemples connexes :**
+ [ Nouvelle tentative Spring ](https://github.com/spring-projects/spring-retry)
+ [ Nouvelle tentative Resilience4j ](https://resilience4j.readme.io/docs/retry)
**Vidéos connexes :**
+ [Réessayez, attendez et agitez : AWS re:Invent 2019 : Introducing The Amazon Builders' Library () DOP328](https://youtu.be/sKRdemSirDM?t=1884)
**Outils associés :**
+ [AWS SDKset outils : comportement des nouvelles tentatives](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html)
+ [AWS Command Line Interface: nouvelles AWS CLI tentatives](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-retries.html)
# REL05-BP04 Procéder à une interruption immédiate et limiter les files d’attente
Lorsqu’un service n’est pas en mesure de répondre correctement à une demande, procédez à son interruption immédiate. Cela permet la libération des ressources associées à une demande et donne la possibilité au service de récupérer s’il lui manque des ressources. L’interruption immédiate est un modèle de conception logicielle bien établi qui peut être exploité pour créer des charges de travail hautement fiables dans le cloud. La mise en file d’attente est également un modèle d’intégration d’entreprise bien établi qui permet de faciliter le chargement et de permettre aux clients de libérer des ressources lorsque le traitement asynchrone peut être toléré. Lorsqu’un service est capable de répondre correctement dans des conditions normales, mais échoue lorsque le taux de demandes est trop élevé, utilisez une file d’attente pour mettre les demandes en mémoire tampon. Toutefois, ne permettez pas l’accumulation de longs backlogs de files d’attente susceptibles d’entraîner le traitement de demandes obsolètes auxquelles un client a déjà renoncé.
**Résultat escompté :** lorsque les systèmes sont confrontés à des problèmes de ressources, à des dépassements de délai, à des exceptions ou à des pannes grises qui rendent les objectifs de niveau de service irréalisables, les stratégies d’interruption immédiate permettent d’accélérer la récupération du système. Les systèmes qui doivent absorber les pics de trafic et peuvent prendre en charge le traitement asynchrone peuvent améliorer la fiabilité en permettant aux clients de lancer rapidement des demandes grâce à l’utilisation des files d’attente pour mettre en mémoire tampon les demandes envoyées aux services back-end. Lors de la mise en mémoire tampon des demandes dans des files d’attente, des stratégies de gestion des files d’attente sont mises en œuvre pour éviter des backlogs insurmontables.
**Anti-modèles courants :**
+ Mise en œuvre de files de messages sans configurer de files d’attente de lettres mortes (DLQ) ni d’alarmes sur les volumes DLQ pour détecter les défaillances d’un système.
+ Il ne s’agit pas de mesurer l’ancienneté des messages dans une file d’attente, mais de mesurer la latence pour comprendre quand les utilisateurs prennent du retard ou si des erreurs entraînent de nouvelles tentatives.
+ Conservation des messages en attente dans une file d’attente, alors qu’il n’est plus utile de traiter ces messages si l’entreprise n’en a plus besoin.
+ La configuration de files d’attente du premier entré, premier sorti (FIFO) au moment du dernier entré, premier sorti (LIFO) permettrait de mieux répondre aux besoins des clients, par exemple lorsqu’un ordre strict n’est pas requis et que le traitement du backlog retarde toutes les nouvelles demandes urgentes, ce qui entraîne une violation des niveaux de service pour tous les clients.
+ Exposition des files d’attente internes aux clients au lieu d’exposer les API qui gèrent la prise de travail et placent les demandes dans les files d’attente internes.
+ La combinaison d’un trop grand nombre de types de demandes de travail dans une seule file d’attente peut aggraver les problèmes de backlog en répartissant la demande de ressources entre les types de demandes.
+ Traitement de demandes complexes et simples dans la même file d’attente, malgré la nécessité d’une surveillance, de délais d’expiration et d’allocations de ressources différents.
+ Absence de validation des entrées ou utilisation des assertions pour implémenter des mécanismes d’interruption immédiate dans les logiciels qui génèrent des exceptions vers des composants de niveau supérieur capables de gérer les erreurs de façon appropriée.
+ Absence de suppression des ressources défectueuses du routage des requêtes, en particulier lorsque les défaillances sont grises, ce qui indique à la fois des réussites et des échecs en raison d’un plantage et d’un redémarrage, d’une panne de dépendance intermittente, d’une capacité réduite ou d’une perte de paquets réseau.
**Avantages du respect de cette bonne pratique :** les systèmes avec interruption immédiate sont plus faciles à déboguer et à corriger, et présentent souvent des problèmes de codage et de configuration avant la publication des versions en production. Les systèmes qui intègrent des stratégies de mise en file d’attente efficaces offrent une résilience et une fiabilité accrues face aux pics de trafic et aux pannes intermittentes du système.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Les stratégies d’interruption immédiate peuvent être codées dans des solutions logicielles ou configurées dans l’infrastructure. En plus de leur capacité d’interruption immédiate, les files d’attente constituent une technique architecturale simple mais puissante qui permet de découpler les composants du système en douceur. [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) fournit des fonctionnalités de surveillance et d’alerte en cas de défaillance. Une fois que l’on sait qu’un système est défaillant, des stratégies d’atténuation peuvent être invoquées, notamment en cas de défaillance de ressources altérées. Quand des systèmes implémentent des files d’attente avec [Amazon SQS](https://aws.amazon.com/sqs/) et d’autres technologies de file d’attente pour faciliter le chargement, ils doivent tenir compte de la gestion des backlogs de files d’attente, ainsi que des défaillances de consommation de messages.
## Étapes d’implémentation
+ Implémentez des assertions programmatiques ou des métriques spécifiques dans votre logiciel et utilisez-les pour signaler explicitement les problèmes du système. Amazon CloudWatch vous aide à créer des métriques et des alarmes reposant sur le modèle de journal des applications et l’instrumentation du SDK.
+ Utilisez les métriques et les alarmes CloudWatch pour éviter les problèmes liés à l’altération des ressources qui ajoutent de la latence au traitement ou qui échouent à plusieurs reprises à traiter les demandes.
+ Utilisez le traitement asynchrone en concevant des API pour accepter les demandes et les ajouter aux files d’attente internes en utilisant Amazon SQS, puis en répondant au client émetteur du message par un message de réussite afin que le client puisse libérer des ressources et passer à autre chose pendant que les utilisateurs de la file d’attente back-end traitent les demandes.
+ Mesurez et surveillez la latence de traitement des files d’attente en produisant une métrique CloudWatch chaque fois que vous retirez un message d’une file d’attente en comparant l’heure actuelle à l’horodatage du message.
+ Lorsque des défaillances empêchent le bon traitement des messages ou que des pics de trafic concernent des volumes qui ne peuvent pas être traités conformément aux contrats de niveau de service, mettez de côté le trafic ancien ou excédentaire vers une file d’attente de débordement. Cela permet de traiter en priorité les nouvelles tâches et les tâches plus anciennes lorsque la capacité est disponible. Cette technique est une approximation du traitement LIFO et permet un traitement normal du système pour toutes les nouvelles tâches.
+ Utilisez des lettres mortes ou réadaptez des files d’attente afin de déplacer les messages qui ne peuvent pas être traités hors du backlog vers un emplacement pouvant faire l’objet de recherches et de résolutions ultérieures.
+ Réessayez ou, si cela est acceptable, supprimez les anciens messages en comparant l’heure actuelle à l’horodatage du message et en supprimant les messages qui ne sont plus pertinents pour le client demandeur.
## Ressources
**Bonnes pratiques associées:**
+ [REL04-BP02 Implémenter des dépendances faiblement couplées](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL05-BP02 Limiter les demandes](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Contrôler et limiter les appels de nouvelle tentative](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL06-BP02 Définir et calculer des métriques (agrégation)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP07 Surveiller la traçabilité complète des demandes via votre système](rel_monitor_aws_resources_end_to_end.md)
**Documents connexes :**
+ [ Éviter les backlogs insurmontables dans les files d’attente ](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs/)
+ [Interruption immédiate](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ [ Comment puis-je empêcher un backlog de messages croissant dans ma file d’attente Amazon SQS ? ](https://repost.aws/knowledge-center/sqs-message-backlog)
+ [Elastic Load Balancing : changement de zone](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/zonal-shift.html)
+ [Amazon Application Recovery Controller : contrôle du routage pour le basculement du trafic](https://docs.aws.amazon.com/r53recovery/latest/dg/getting-started-routing-controls.html)
**Exemples connexes :**
+ [ Modèles d’intégration d’entreprise : canal des lettres mortes ](https://www.enterpriseintegrationpatterns.com/patterns/messaging/DeadLetterChannel.html)
**Vidéos connexes :**
+ [AWS re:Invent 2022 - Operating highly available Multi-AZ applications](https://www.youtube.com/watch?v=mwUV5skJJ0s)
**Outils associés :**
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [ Amazon MQ ](https://aws.amazon.com/amazon-mq/)
+ [AWS IoT Core](https://aws.amazon.com/iot-core/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
# REL05-BP05 Définir les délais d'expiration des clients
Définissez les délais d’expiration de manière appropriée pour les connexions et les demandes, vérifiez-les systématiquement et ne vous fiez pas aux valeurs par défaut, car elles ne tiennent pas compte des spécificités de la charge de travail.
**Résultat souhaité :** les délais d’expiration du client doivent prendre en compte le coût pour le client, le serveur et la charge de travail associés à l’attente des demandes dont le traitement prend un temps anormal. Dans la mesure où il est impossible de connaître la cause exacte d’un délai d’attente, les clients doivent utiliser leur connaissance des services pour établir des attentes relatives aux causes probables et aux délais d’expiration appropriés.
Le délai d’expiration des connexions client dépend des valeurs configurées. Après avoir dépassé le délai imparti, les clients décident de revenir en arrière et de réessayer ou d’ouvrir un [coupe-circuit](https://martinfowler.com/bliki/CircuitBreaker.html). Ces modèles évitent d’émettre des demandes susceptibles d’exacerber un problème d’erreur sous-jacent.
**Anti-modèles courants :**
+ Ne pas connaître les délais d’expiration du système ou les délais d’expiration par défaut.
+ Ne pas connaître le délai normal d’exécution des demandes.
+ Ne pas connaître les raisons pour lesquelles les demandes peuvent prendre un temps anormalement long à traiter, ni les coûts pour le client, le service ou les performances de la charge de travail associés à l’attente de ces traitements.
+ Ne pas connaître la probabilité qu’un réseau défaillant entraîne l’échec d’une requête uniquement lorsque le délai d’expiration est atteint, ainsi que les coûts pour les performances du client et de la charge de travail si l’on n’adopte pas un délai d’expiration plus court.
+ Ne pas tester les scénarios de délai d’expiration à la fois pour les connexions et les demandes.
+ Définir des délais d’expiration trop élevés, ce qui peut entraîner de longs temps d’attente et augmenter l’utilisation des ressources.
+ Définir des délais d’attente trop bas, ce qui entraîne des défaillances artificielles.
+ Oublier les modèles pour gérer les erreurs de temporisation des appels distants, par exemple les disjoncteurs et les nouvelles tentatives.
+ Ne pas envisager de surveiller les taux d’erreur des appels de service, les objectifs de niveau de service en matière de latence et les valeurs aberrantes en matière de latence. Ces métriques peuvent fournir des informations sur les délais d’attente agressifs ou permissifs.
**Avantages du respect de cette bonne pratique :** les délais d’expiration des appels distants sont configurés et les systèmes sont conçus pour gérer les délais d’expiration de façon appropriée afin de préserver les ressources lorsque les appels distants répondent de manière anormalement lente et que les erreurs de délai d’expiration sont gérées de façon appropriée par les clients du service.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Définissez un délai d’expiration de la connexion et un délai d’expiration de la demande pour tout appel de dépendance de service et, plus généralement, pour tout appel entre processus. De nombreux cadres proposent des capacités de délai d’expiration intégrées, mais soyez prudent, car certains ont des valeurs par défaut infinies ou supérieures à ce qui est acceptable pour vos objectifs de service. Une valeur trop élevée réduit l’utilité du délai d’attente, car les ressources continuent d’être consommées pendant que le client attend l’expiration du délai. Une valeur trop faible peut générer un trafic accru sur le back-end et une latence accrue en raison du nombre excessif de demandes réessayées. Dans certains cas, cela peut entraîner des interruptions complètes, car toutes les demandes font l’objet d’une nouvelle tentative.
Tenez compte des points suivants lorsque vous déterminez des stratégies de délai d’expiration :
+ Le traitement des demandes peut prendre plus de temps que d’habitude en raison de leur contenu, de défaillances d’un service cible ou d’une panne de partition réseau.
+ Les demandes dont le contenu est anormalement coûteux peuvent consommer des ressources inutiles du serveur et du client. Dans ce cas, le fait d’avoir un délai d’expiration pour ces demandes et de ne pas réessayer peut préserver les ressources. Les services doivent également se protéger contre les contenus anormalement coûteux avec des limites et des délais d’expiration côté serveur.
+ Les demandes qui prennent anormalement longtemps en raison d’une défaillance du service peuvent être interrompues et réessayées. Il convient de tenir compte des coûts de service liés à la demande et à la nouvelle tentative, mais si la cause est une déficience localisée, une nouvelle tentative ne sera probablement pas coûteuse et réduira la consommation de ressources du client. Le délai d’expiration peut également libérer des ressources du serveur en fonction de la nature de la déficience.
+ Les demandes dont l’exécution prend beaucoup de temps parce que la demande ou la réponse n’a pas été envoyée par le réseau peuvent être interrompues et réessayées. La demande ou la réponse n’ayant pas été envoyée, il en aurait résulté un échec indépendamment de la durée du délai imparti. Dans ce cas, l’expiration du délai ne libérera pas les ressources du serveur, mais des ressources client et cela améliorera les performances de la charge de travail.
Tirez parti de modèles de conception bien établis, tels que les nouvelles tentatives et les disjoncteurs, pour gérer les délais d'attente avec élégance et prendre en charge les approches rapides. [AWS SDKs](https://docs.aws.amazon.com/index.html#sdks)et [AWS CLI](https://aws.amazon.com/cli/)permettent de configurer les délais d'expiration des connexions et des demandes ainsi que les nouvelles tentatives avec un retard et une instabilité exponentiels. [AWS Lambda](https://aws.amazon.com/lambda/)les fonctions prennent en charge la configuration des délais d'attente, et avec [AWS Step Functions](https://aws.amazon.com/step-functions/), vous pouvez créer des disjoncteurs low code qui tirent parti des intégrations prédéfinies avec les services et. AWS SDKs [AWS App Mesh](https://aws.amazon.com/app-mesh/) Envoy fournit des fonctionnalités de délai d’expiration et de disjoncteur.
## Étapes d’implémentation
+ Configurez les délais d’expiration pour les appels de service à distance et profitez des fonctionnalités de délai d’expiration spécifique à la langue intégrées ou des bibliothèques de délai d’expiration open source.
+ Lorsque votre charge de travail passe des appels avec un AWS SDK, consultez la documentation pour connaître la configuration du délai d'expiration spécifique à la langue.
+ [ Python ](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html)
+ [ PHP ](https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.DefaultsMode.Configuration.html)
+ [ .NET ](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [ Ruby ](https://docs.aws.amazon.com/sdk-for-ruby/v3/developer-guide/timeout-duration.html)
+ [ Java ](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/best-practices.html#bestpractice5)
+ [ Go ](https://aws.github.io/aws-sdk-go-v2/docs/configuring-sdk/retries-timeouts/#timeouts)
+ [ Node.js ](https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/Config.html)
+ [ C\$1\$1 ](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/client-config.html)
+ Lorsque vous utilisez des AWS CLI commandes AWS SDKs or dans votre charge de travail, configurez les valeurs de délai d'expiration par défaut en définissant les AWS [valeurs par défaut](https://docs.aws.amazon.com/sdkref/latest/guide/feature-smart-config-defaults.html) pour `connectTimeoutInMillis` et. `tlsNegotiationTimeoutInMillis`
+ Appliquez des [options de ligne de commande](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html) `cli-connect-timeout` et `cli-read-timeout` contrôlez des AWS CLI commandes ponctuelles aux AWS services.
+ Surveillez les appels de service à distance pour détecter les délais d’expiration et définissez des alarmes en cas d’erreurs persistantes afin de pouvoir gérer de manière proactive les scénarios d’erreur.
+ Mettez en œuvre [CloudWatch des mesures](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) et [CloudWatch une détection des anomalies](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) sur les taux d'erreur des appels, les objectifs de niveau de service en matière de latence et les valeurs aberrantes de latence afin de mieux comprendre la gestion des délais d'attente trop agressifs ou trop permissifs.
+ Configurez les délais d’expiration des [fonctions Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html#configuration-timeout-console).
+ APILes clients Gateway doivent implémenter leurs propres tentatives lors de la gestion des délais d'expiration. APIGateway prend en charge un [délai d'intégration de 50 millisecondes à 29 secondes pour les](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html#api-gateway-execution-service-limits-table) intégrations en aval et ne réessaie pas lorsque les demandes d'intégration expirent.
+ Implémentez le modèle de [disjoncteur](https://martinfowler.com/bliki/CircuitBreaker.html) pour éviter de passer des appels à distance lorsque le délai d’expiration est écoulé. Ouvrez le circuit pour éviter les échecs d’appels et fermez-le lorsque les appels répondent normalement.
+ Pour les charges de travail basées sur des conteneurs, consultez les fonctionnalités d’[App Mesh Envoy](https://docs.aws.amazon.com/app-mesh/latest/userguide/envoy.html) pour tirer parti des délais d’attente et des disjoncteurs intégrés.
+ AWS Step Functions À utiliser pour créer des disjoncteurs à faible code pour les appels de service à distance, en particulier lorsque vous faites appel à des intégrations Step Functions AWS natives SDKs et compatibles afin de simplifier votre charge de travail.
## Ressources
**Bonnes pratiques associées :**
+ [REL05-BP03 Contrôler et limiter les appels de nouvelle tentative](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Procéder à une interruption immédiate et limiter les files d’attente](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL06-BP07 Surveiller la traçabilité complète des demandes via votre système](rel_monitor_aws_resources_end_to_end.md)
**Documents connexes :**
+ [AWS SDK: tentatives et délais d'expiration](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [Amazon Builders’ Library : délais d’attente, nouvelles tentatives et backoff avec instabilité](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [Quotas Amazon API Gateway et remarques importantes](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html)
+ [AWS Command Line Interface : options de ligne de commande ](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html)
+ [AWS SDK for Java 2.x: Configurer les API délais](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/best-practices.html#bestpractice5)
+ [AWS Botocore utilisant l'objet de configuration et la référence de configuration](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html#using-the-config-object)
+ [AWS SDK pour .NET : nouvelles tentatives et délais d’expiration ](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [AWS Lambda : configuration des options de fonction Lambda ](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html)
**Exemples connexes :**
+ [Utilisation du schéma du disjoncteur avec AWS Step Functions Amazon DynamoDB](https://aws.amazon.com/blogs/compute/using-the-circuit-breaker-pattern-with-aws-step-functions-and-amazon-dynamodb/)
+ [Martin Fowler : CircuitBreaker](https://martinfowler.com/bliki/CircuitBreaker.html?ref=wellarchitected)
**Outils associés :**
+ [AWS SDKs ](https://docs.aws.amazon.com/index.html#sdks)
+ [AWS Lambda](https://aws.amazon.com/lambda/)
+ [Amazon SQS](https://aws.amazon.com/sqs/)
+ [AWS Step Functions](https://aws.amazon.com/step-functions/)
+ [AWS Command Line Interface](https://aws.amazon.com/cli/)
# REL05-BP06 Rendre les systèmes apatrides dans la mesure du possible
Les systèmes ne doivent pas exiger d’état ou doivent décharger un état de telle sorte qu’entre les différentes demandes client, il n’y ait pas de dépendance vis-à-vis des données stockées localement sur disque et en mémoire. Cela permet le remplacement à volonté des serveurs sans impact sur la disponibilité.
Lorsque des utilisateurs ou des services interagissent avec une application, ils exécutent souvent une série d’interactions qui forment une session. Une session correspond aux données uniques des utilisateurs qui persistent entre les requêtes pendant l’utilisation de l’application. Une application sans état n’a pas besoin de connaître les interactions précédentes et ne stocke pas d’informations de session.
Une fois conçu pour être apatride, vous pouvez ensuite utiliser des services de calcul sans serveur, tels que AWS Lambda ou. AWS Fargate
Outre le remplacement des serveurs, les applications apatrides présentent un autre avantage : elles peuvent évoluer horizontalement, car toutes les ressources informatiques disponibles (telles que les EC2 instances et les AWS Lambda fonctions) peuvent répondre à toutes les demandes.
**Avantages du respect de cette bonne pratique :** les systèmes conçus pour être sans état sont plus adaptables à la mise à l’échelle horizontale, ce qui permet d’ajouter ou de supprimer des capacités en fonction des fluctuations du trafic et de la demande. Ils sont également intrinsèquement résilients aux défaillances et offrent flexibilité et agilité dans le cadre du développement d’applications.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
Rendre vos applications sans état. Les applications sans état permettent une mise à l’échelle horizontale et tolèrent la défaillance d’un nœud individuel. Analysez et comprenez les composants de votre application qui conservent leur état au sein de l’architecture. Cela vous permet d’évaluer l’impact potentiel de la transition vers une conception sans état. Une architecture sans état découple les données utilisateur et décharge les données de session. Cela permet de mettre à l’échelle chaque composant indépendamment pour répondre à des demandes variables de charge de travail et optimiser l’utilisation des ressources.
### Étapes d’implémentation
+ Identifiez et comprenez les composants avec état dans votre application.
+ Découplez les données en séparant et en gérant les données utilisateur de la logique principale de l’application.
+ [Amazon Cognito](https://aws.amazon.com/cognito/) peut découpler les données utilisateur du code de l’application en utilisant des fonctionnalités telles que les [groupes d’identités](https://docs.aws.amazon.com/cognito/latest/developerguide/getting-started-with-identity-pools.html), les [groupes d’utilisateurs](https://docs.aws.amazon.com/cognito/latest/developerguide/getting-started-with-cognito-user-pools.html) et [Amazon Cognito Sync.](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-sync.html)
+ Vous pouvez utiliser [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) pour découpler les données utilisateur en stockant les secrets dans un emplacement sécurisé et centralisé. Cela signifie que le code de l’application n’a pas besoin de stocker de secrets, ce qui le rend plus sécurisé.
+ Envisagez d’utiliser [Amazon S3](https://aws.amazon.com/s3/) pour stocker des données volumineuses non structurées, telles que des images et des documents. Votre application peut récupérer ces données en cas de besoin, évitant ainsi d’avoir à les stocker en mémoire.
+ Utilisez [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) pour stocker des informations telles que les profils utilisateur. Votre application peut interroger ces données en temps quasi réel.
+ Déchargez les données de session dans une base de données, un cache ou des fichiers externes.
+ [Amazon ElastiCache](https://aws.amazon.com/elasticache/), Amazon DynamoDB, Amazon [Elastic File System (Amazon](https://aws.amazon.com/efs/)) et EFS [Amazon](https://aws.amazon.com/memorydb/) MemoryDB sont des exemples de services que vous pouvez utiliser pour AWS décharger des données de session.
+ Concevez une architecture sans état après avoir identifié les données d’état et d’utilisateur qui doivent être conservées avec la solution de stockage de votre choix.
## Ressources
**Bonnes pratiques associées :**
+ [REL11-BP03 Automatiser la guérison sur toutes les couches](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_auto_healing_system.html)
**Documents connexes :**
+ [L’Amazon Builders’ Library : éviter le basculement dans les systèmes distribués](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [L’Amazon Builders’ Library : éviter les retards de file d’attente insurmontables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [L’Amazon Builders’ Library : défis et stratégies de mise en cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Bonnes pratiques pour Stateless Web Tier sur AWS](https://docs.aws.amazon.com/whitepapers/latest/best-practices-wordpress/stateless-web-tier.html)
# REL05-BP07 Mettre en œuvre des leviers de secours
Les leviers d’urgence sont des processus rapides qui peuvent réduire l’impact sur la disponibilité de votre charge de travail.
Les leviers d’urgence fonctionnent en désactivant, en limitant ou en modifiant le comportement des composants ou des dépendances à l’aide de mécanismes connus et testés. Ils permettent d’atténuer les perturbations de la charge de travail causées par l’épuisement des ressources dû à une augmentation inattendue de la demande et de réduire l’impact des défaillances des composants non stratégiques de votre charge de travail.
**Résultat souhaité :** en mettant en œuvre des leviers d’urgence, vous pouvez établir des processus dont le fonctionnement a été vérifié pour maintenir la disponibilité des composants essentiels de votre charge de travail. La charge de travail devrait se dégrader de manière appropriée et continuer à remplir ses fonctions stratégiques durant l’activation d’un levier d’urgence. Pour plus de détails sur la dégradation progressive, voir [REL05-BP01 Implémenter la dégradation progressive pour transformer les dépendances strictes applicables en dépendances souples](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html).
**Anti-modèles courants :**
+ La défaillance des dépendances non stratégiques a un impact sur la disponibilité de votre charge de travail principale.
+ Le comportement des composants stratégiques n’est pas testé ou vérifié lors d’une défaillance d’un composant non stratégique.
+ Aucun critère clair et déterministe n’a été défini pour l’activation ou la désactivation d’un levier d’urgence.
**Avantages du respect de cette bonne pratique :** la mise en œuvre de leviers d’urgence peut améliorer la disponibilité des composants critiques de votre charge de travail en fournissant à vos résolveurs des processus établis pour répondre aux pics de demande inattendus ou aux défaillances liées à des dépendances non critiques.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
+ Identifier les composants stratégiques de votre charge de travail.
+ Concevoir et construire les composants stratégiques de votre charge de travail de manière à ce qu’ils résistent aux défaillances des composants non stratégiques.
+ Effectuer des tests pour valider le comportement de vos composants stratégiques en cas de défaillance des composants non stratégiques.
+ Définir et surveiller des métriques ou des déclencheurs pertinents pour lancer des procédures de levier d’urgence.
+ Définir les procédures (manuelles ou automatisées) qui comprennent le levier d’urgence.
### Étapes d’implémentation
+ Identifier les composants stratégiques de votre charge de travail.
+ Chaque composant technique de votre charge de travail doit être associé à la fonction commerciale correspondante et classé comme stratégique ou non stratégique. Pour des exemples de fonctionnalités critiques et non critiques d’Amazon, consultez [Any Day Can Be Prime Day: How Amazon.com Search Uses Chaos Engineering to Handle Over 84K Requests Per Second](https://community.aws/posts/how-search-uses-chaos-engineering).
+ Il s’agit d’une décision à la fois technique et commerciale, qui varie en fonction de l’organisation et de la charge de travail.
+ Concevoir et construire les composants stratégiques de votre charge de travail de manière à ce qu’ils résistent aux défaillances des composants non stratégiques.
+ Lors de l’analyse des dépendances, tenez compte de tous les modes de défaillance potentiels et vérifiez que vos mécanismes de levier d’urgence fournissent les fonctionnalités stratégiques aux composants en aval.
+ Effectuer des tests pour valider le comportement de vos composants stratégiques pendant l’activation de vos leviers d’urgence.
+ Éviter les comportements bimodaux. Pour plus de détails, voir [REL11-BP05 Utiliser la stabilité statique pour empêcher le comportement bimodal](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html).
+ Définir et surveiller des métriques pertinentes pour lancer des procédures de levier d’urgence.
+ La recherche des bonnes métriques à surveiller dépend de votre charge de travail. Parmi les métriques, citons la latence ou le nombre de demandes infructueuses à une dépendance.
+ Définir les procédures (manuelles ou automatisées) qui comprennent le levier d’urgence.
+ Cela peut inclure des mécanismes tels que le [délestage](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/), les [demandes de limitation](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html) ou la mise en œuvre d’une [dégradation appropriée](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html).
## Ressources
**Bonnes pratiques associées :**
+ [REL05-BP01 Implémenter une dégradation progressive pour transformer les dépendances matérielles applicables en dépendances souples](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html)
+ [REL05-BP02 Demandes d'accélérateur](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html)
+ [REL11-BP05 Utiliser la stabilité statique pour empêcher le comportement bimodal](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)
**Documents connexes :**
+ [ Automatiser les déploiements sécurisés et sans intervention ](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
+ [Any Day Can Be Prime Day: How Amazon.com Search Uses Chaos Engineering to Handle Over 84K Requests Per Second](https://community.aws/posts/how-search-uses-chaos-engineering)
**Vidéos connexes :**
+ [AWS re:Invent 2020 : fiabilité, cohérence et confiance grâce à l'immuabilité](https://www.youtube.com/watch?v=jUSYnRztttY)