# FIA 11. Comment concevoir votre charge de travail pour la rendre résistante aux défaillances de composants ? Les charges de travail exigeant une haute disponibilité et un faible temps moyen de récupération (MTTR) doivent être conçues pour être résilientes. **Topics** + [ # REL11-BP01 Surveiller tous les composants de la charge de travail pour détecter les défaillances ](rel_withstand_component_failures_monitoring_health.md) + [ # REL11-BP02 Basculer vers des ressources saines ](rel_withstand_component_failures_failover2good.md) + [ # REL11-BP03 Automatiser la réparation sur toutes les couches ](rel_withstand_component_failures_auto_healing_system.md) + [ # REL11-BP04 S’appuyer sur le plan de données et non sur le plan de contrôle pendant la récupération ](rel_withstand_component_failures_avoid_control_plane.md) + [ # REL11-BP05 Utiliser la stabilité statique pour éviter les comportements bimodaux ](rel_withstand_component_failures_static_stability.md) + [ # REL11-BP06 Envoyer des notifications lorsque des événements affectent la disponibilité ](rel_withstand_component_failures_notifications_sent_system.md) + [ # REL11-BP07 Concevoir votre produit pour atteindre les objectifs de disponibilité et les contrats de niveau de service (SLA) ](rel_withstand_component_failures_service_level_agreements.md) # REL11-BP01 Surveiller tous les composants de la charge de travail pour détecter les défaillances REL11-BP01 Surveiller tous les composants de la charge de travail pour détecter les défaillances Surveillez en continu l’état de votre charge de travail afin que vous et vos systèmes automatisés ayez connaissance des dégradations ou des défaillances dès qu’elles se produisent. Surveillez les indicateurs clés de performance (KPI) en fonction de la valeur commerciale. Tous les mécanismes de récupération et de réparation doivent commencer par la capacité à détecter rapidement les problèmes. Les défaillances techniques doivent être détectées au préalable pour être résolues. Cependant, la disponibilité repose sur la capacité de votre charge de travail à fournir une valeur commerciale. Il doit donc s’agir d’indicateurs clés de performance (KPI) de votre stratégie de détection et de correction. **Résultat escompté :** les composants essentiels d’une charge de travail sont surveillés de manière indépendante afin de détecter les défaillances et de les signaler au moment et à l’emplacement où elles se produisent. **Anti-modèles courants :** + Aucune alarme n’a été configurée. Les pannes se produisent donc sans notification. + Des alarmes existent, mais les seuils ne laissent pas assez de temps pour réagir. + Les métriques ne sont pas collectées à une fréquence suffisante pour atteindre l’objectif de délai de reprise (RTO). + Seules les interfaces de la charge de travail axées directement sur le client sont activement surveillées. + Collecte uniquement des métriques techniques et non des métriques de fonction commerciale. + Aucune métrique ne mesure l’expérience utilisateur de la charge de travail. + Trop de contrôleurs sont créés. **Avantages liés au respect de cette bonne pratique :** la surveillance appropriée à tous les niveaux vous permet de raccourcir le délai de reprise en réduisant le temps de détection. **Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élévé ## Directives d’implémentation Directives d’implémentation Identifiez toutes les charges de travail qui seront examinées à des fins de surveillance. Une fois que vous avez identifié tous les composants de la charge de travail à surveiller, déterminez l’intervalle de surveillance. Cet intervalle a un impact direct sur la rapidité avec laquelle la restauration peut être initiée en fonction du temps nécessaire pour détecter une panne. Le délai moyen de détection (MTTD) est le délai entre le moment où une panne survient et le moment où les opérations de réparation commencent. La liste des services doit être longue et complète. La surveillance doit couvrir toutes les couches de la pile d’applications, y compris l’application, la plateforme, l’infrastructure et le réseau. Votre stratégie de surveillance doit tenir compte de l’impact des *défaillances grises*. Pour en savoir plus sur les défaillances grises, consultez la section [Défaillances grises](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) dans le livre blanc Modèles de résilience Multi-AZ avancée. ### Étapes d’implémentation Étapes d’implémentation + Votre intervalle de surveillance dépend de la vitesse à laquelle vous devez effectuer la récupération. Votre délai de reprise dépend du temps nécessaire à la récupération. Vous devez donc déterminer la fréquence de collecte en tenant compte de cette durée et de votre objectif de délai de reprise (RTO). + Configurez la surveillance détaillée des composants et des services gérés. + Déterminez la nécessité d’une [surveillance détaillée pour les instances EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html) et [Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html). La surveillance détaillée fournit des métriques à intervalle d’une minute, et la surveillance par défaut fournit des métriques à intervalle de cinq minutes. + Déterminez la nécessité de la [surveillance améliorée](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html) pour RDS. La surveillance améliorée utilise un agent sur les instances RDS pour obtenir des informations utiles sur différents processus ou fils. + Déterminez les exigences de surveillance des composants sans serveur critiques pour [Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-metrics.html), [API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/monitoring_automated_manual.html), [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/eks-observe.html), [Amazon ECS](https://catalog.workshops.aws/observability/en-US/aws-managed-oss/amp/ecs) et tous les types [d’équilibreurs de charge](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-monitoring.html). + Déterminez les exigences de surveillance des composants de stockage pour [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/monitoring-overview.html), [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/monitoring_overview.html), [Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/monitoring_overview.html) et [Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-volume-status.html). + Créez des [métriques personnalisées](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) pour mesurer les indicateurs clés de performance (KPI) métier. Les charges de travail mettent en œuvre des fonctions commerciales stratégiques, qui doivent être utilisées comme indicateurs clés de performance permettant d’identifier les problèmes indirects. + Surveillez l’expérience utilisateur pour détecter les défaillances à l’aide de tests canary utilisateur. Les [tests de transaction synthétiques](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (également appelés « tests canary », à ne pas confondre avec les déploiements canary) qui peuvent exécuter et simuler le comportement des clients font partie des processus de test les plus importants. Exécutez ces tests en permanence sur vos points de terminaison de charge de travail à partir de divers emplacements distants. + Créez des [métriques personnalisées](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) qui suivent l’expérience utilisateur. Si vous pouvez analyser l’expérience du client, vous pouvez savoir à quel moment l’expérience du consommateur se dégrade. + [Définissez des alarmes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) pour détecter quand une partie de votre charge de travail ne fonctionne pas correctement et pour indiquer quand mettre à l’échelle automatiquement les ressources. Le système peut afficher les alarmes sur des tableaux de bord, envoyer des alertes via Amazon SNS ou par e-mail et fonctionner avec Auto Scaling pour une mise à l’échelle à la hausse ou à la baisse des ressources de la charge de travail. + Créez des [tableaux de bord](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) pour la visualisation de vos métriques. Les tableaux de bord peuvent être utilisés pour afficher visuellement des tendances, des valeurs aberrantes et d’autres indicateurs de problèmes potentiels ou pour fournir une indication des problèmes que vous pourriez vouloir examiner. + Créez un [système de suivi distribué](https://aws.amazon.com/xray/faqs/) pour vos services. La surveillance distribuée vous permet d’analyser les performances de votre application et de ses services sous-jacents, afin d’identifier et de dépanner la cause première des problèmes et des erreurs de performances. + Créez des systèmes de surveillance (à l’aide de [CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html) ou [X-Ray](https://aws.amazon.com/xray/faqs/)), des tableaux de bord et collectez des données dans une région et un compte distincts. + Restez informé des dégradations de service avec [AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/). [Créez des notifications d’événements AWS Health](https://docs.aws.amazon.com/health/latest/ug/user-notifications.html) spécialement adaptées aux e-mails et aux canaux de discussion via [Notifications des utilisateurs AWS](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) et intégrez-les de manière programmatique à [vos outils de surveillance et d’alerte via Amazon EventBridge](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html). ## Ressources Ressources **Bonnes pratiques associées:** + [Définition de la disponibilité](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) + [REL11-BP06 Envoi de notifications lorsque des événements affectent la disponibilité](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html) **Documents connexes:** + [Amazon CloudWatch Synthetics vous permet de créer des tests canary utilisateur](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) + [Activer ou désactiver la surveillance détaillée pour votre instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html) + [Surveillance améliorée](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) + [Surveillance de vos groupes et instances Auto Scaling à l’aide d’Amazon CloudWatch](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html) + [Publication des métriques personnalisées](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) + [Utilisation d’alarmes Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) + [Utilisation des tableaux de bord CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) + [Utilisation de tableaux de bord CloudWatch interrégionaux entre comptes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html) + [Utilisation du suivi X-Ray interrégional entre comptes](https://aws.amazon.com/xray/faqs/) + [Compréhension de la disponibilité](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/understanding-availability.html) **Vidéos connexes:** + [Mitigating gray failures](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) **Exemples connexes :** + [Un atelier sur l’observabilité : explorer X-Ray](https://catalog.workshops.aws/observability/en-US/aws-native/xray/explore-xray) **Outils associés:** + [CloudWatch](https://aws.amazon.com/cloudwatch/) + [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html) # REL11-BP02 Basculer vers des ressources saines REL11-BP02 Basculer vers des ressources saines En cas de défaillance des ressources, les ressources saines doivent continuer à répondre aux requêtes. Pour les altérations liées à l’emplacement (par exemple, zone de disponibilité ou Région AWS), vérifiez que des systèmes sont en place pour basculer vers des ressources saines dans des emplacements intacts. Lorsque vous concevez un service, répartissez la charge entre les ressources, les zones de disponibilité ou les régions. La défaillance d’une ressource individuelle ou l’altération peut ainsi être atténuée en déplaçant le trafic vers les ressources saines restantes. Réfléchissez à la manière dont les services sont découverts et acheminés en cas de défaillance. Concevez vos services en tenant compte de la restauration après panne. Chez AWS, nous concevons les services afin de réduire le temps de restauration au minimum en cas de défaillance, ainsi que l’impact sur les données. Nos services utilisent principalement des magasins de données qui valident les requêtes uniquement lorsque les données sont stockées durablement sur plusieurs réplicas au sein d’une région. Ils sont élaborés de manière à utiliser l’isolation basée sur les cellules et à faire appel à l’isolement des pannes fourni par des zones de disponibilité. Nous utilisons largement l’automatisation dans nos procédures opérationnelles. Nous optimisons également notre fonction de remplacement et redémarrage afin de récupérer rapidement en cas d’interruptions. Les modèles et les conceptions qui permettent le basculement varient pour chaque service de plateforme AWS. De nombreux services natifs gérés par AWS sont dotés de plusieurs zones de disponibilité (comme Lambda ou API Gateway). D’autres services AWS (comme EC2 et EKS) nécessitent des conceptions répondant à des bonnes pratiques spécifiques pour prendre en charge le basculement des ressources ou le stockage des données entre les zones de disponibilité. La surveillance doit être configurée pour vérifier que la ressource de basculement est saine, suivre la progression du basculement des ressources et surveiller le rétablissement des processus métier. **Résultat escompté :** les systèmes sont capables d’utiliser automatiquement ou manuellement de nouvelles ressources pour se remettre d’une dégradation. **Anti-modèles courants :** + La planification des défaillances ne fait pas partie de la phase de planification et de conception. + Le RTO et le RPO ne sont pas établis. + Surveillance insuffisante pour détecter les ressources défaillantes. + Isolement approprié des domaines de défaillance. + Le basculement multi-régional n’est pas pris en compte. + La détection des défaillances est trop sensible ou trop agressive lors de la décision de basculer. + Pas de test ni de validation de la conception du basculement. + Automatisation de la réparation automatique sans notification indiquant que la réparation était nécessaire. + Pas de période d’attente pour éviter un failback trop précoce. **Avantages liés au respect de cette bonne pratique :** vous pouvez créer des systèmes plus résilients qui préservent leur fiabilité en cas de défaillance en se dégradant progressivement et en se rétablissant rapidement. **Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé ## Directives d’implémentation Directives d’implémentation Les services AWS tels que [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-subnets.html) et [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html) aident à répartir la charge entre les ressources et les zones de disponibilité. Par conséquent, la défaillance d’une ressource individuelle (telle qu’une instance EC2) ou l’altération d’une zone de disponibilité peut être atténuée en déplaçant le trafic vers les ressources saines restantes. Pour les charges de travail multi-régionales, les conceptions sont plus complexes. Par exemple, les réplicas en lecture entre régions vous permettent de déployer vos données sur plusieurs Régions AWS. Cependant, le basculement est toujours nécessaire pour faire passer le réplica en lecture au niveau principal, puis pour rediriger le trafic vers le nouveau point de terminaison. Amazon Route 53, [Amazon Application Recovery Controller (ARC)](https://aws.amazon.com/application-recovery-controller/), Amazon CloudFront et AWS Global Accelerator peuvent aider à router le trafic entre les Régions AWS. Les services AWS, tels qu’Amazon S3, Lambda, API Gateway, Amazon SQS, Amazon SNS, Amazon SES, Amazon Pinpoint, Amazon ECR, AWS Certificate Manager, EventBridge ou Amazon DynamoDB, sont automatiquement déployés vers plusieurs zones de disponibilité par AWS. En cas de défaillance, ces services AWS acheminent automatiquement le trafic vers des emplacements sains. Les données sont stockées de manière redondante dans plusieurs zones de disponibilité et restent disponibles. Pour Amazon RDS, Amazon Aurora, Amazon Redshift, Amazon EKS ou Amazon ECS, avoir plusieurs zones de disponibilité est une option de configuration. AWS peut diriger le trafic vers l’instance saine si le basculement est initié. Cette action de basculement peut être prise par AWS ou conformément aux exigences du client. Pour les instances Amazon EC2, Amazon Redshift, les tâches Amazon ECS ou les pods Amazon EKS, vous choisissez les zones de disponibilité dans lesquelles effectuer le déploiement. Pour certaines conceptions, Elastic Load Balancing fournit la solution pour détecter les instances dans les zones défectueuses et acheminer le trafic vers les zones saines. Elastic Load Balancing peut même acheminer le trafic vers les composants de votre centre de données sur site. Pour le basculement du trafic multi-régional, le réacheminement peut tirer parti d’Amazon Route 53, d’Amazon Application Recovery Controller, d’AWS Global Accelerator, de Route 53 Private DNS pour VPC ou de CloudFront pour fournir un moyen de définir des domaines Internet et d’attribuer des politiques de routage, y compris des surveillances de l’état, afin de router le trafic vers des régions saines. AWS Global Accelerator fournit des adresses IP statiques qui agissent comme point d’entrée fixe vers votre application, puis routent le trafic vers les points de terminaison des Régions AWS de votre choix, en utilisant le réseau mondial AWS plutôt qu’Internet pour de meilleures performances et une meilleure fiabilité. ### Étapes d’implémentation Étapes d’implémentation + Créez des modèles de basculement pour toutes les applications et tous les services appropriés. Isolez chaque composant de l’architecture et créez des conceptions de basculement respectant le RTO et le RPO pour chacun d’eux. + Configurez les environnements de bas niveau (tels que le développement ou les tests) avec tous les services requis pour disposer d’un plan de basculement. Déployez les solutions en utilisant l’infrastructure en tant que code (IaC) pour garantir la reproductibilité. + Configurez un site de reprise tel qu’une deuxième région pour implémenter et tester les modèles de basculement. Si nécessaire, les ressources pour les tests peuvent être configurées temporairement afin de limiter les coûts supplémentaires. + Déterminez quels plans de basculement seront automatisés par AWS, ceux qui peuvent être automatisés par un processus DevOps et ceux qui peuvent être manuels. Documentez et mesurez le RTO et le RPO de chaque service. + Créez un manuel de basculement et incluez toutes les étapes nécessaires au basculement de chaque ressource, application et service. + Créez un manuel de failback et incluez toutes les étapes nécessaires (avec calendrier) pour chaque ressource, application et service. + Créez un plan pour lancer et répéter le manuel. Utilisez des simulations et des tests de chaos pour tester les étapes du manuel et l’automatisation. + Pour toute altération liée à l’emplacement (par exemple, zone de disponibilité ou Région AWS), vérifiez que des systèmes sont en place pour basculer vers des ressources saines dans des emplacements intacts. Vérifiez le quota, les niveaux de mise à l’échelle automatique et les ressources en cours d’exécution avant le test de basculement. ## Ressources Ressources **Bonnes pratiques Well-Architected connexes:** + [REL13 – Plan de reprise après sinistre](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html) + [REL10 – Utilisation de l’isolation des défaillances pour protéger votre charge de travail](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html) **Documents connexes:** + [Définition des objectifs RTO et RPO](https://aws.amazon.com/blogs/mt/establishing-rpo-and-rto-targets-for-cloud-applications/) + [Basculement à l’aide du routage pondéré Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack) + [Disaster Recovery with Amazon Application Recovery Controller](https://catalog.us-east-1.prod.workshops.aws/workshops/4d9ab448-5083-4db7-bee8-85b58cd53158/en-US/) + [EC2 avec mise à l’échelle automatique](https://github.com/adriaanbd/aws-asg-ecs-starter) + [Déploiements EC2 – Multi-AZ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) + [Déploiements ECS – Multi-AZ](https://github.com/aws-samples/ecs-refarch-cloudformation) + [Switch traffic using Amazon Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/routing-control.failover-different-accounts.html) + [Lambda avec Application Load Balancer et basculement](https://docs.aws.amazon.com/lambda/latest/dg/services-alb.html) + [Réplication et basculement ACM](https://github.com/aws-samples/amazon-ecr-cross-region-replication) + [Réplication et basculement du magasin de paramètres](https://medium.com/devops-techable/how-to-design-an-ssm-parameter-store-for-multi-region-replication-support-aws-infrastructure-db7388be454d) + [Réplication entre régions ECR et basculement](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry-settings-configure.html) + [Configuration de la réplication entre régions du gestionnaire de secrets](https://disaster-recovery.workshop.aws/en/labs/basics/secrets-manager.html) + [Activation de la réplication entre régions pour EFS et basculement](https://aws.amazon.com/blogs/aws/new-replication-for-amazon-elastic-file-system-efs/) + [Réplication entre régions EFS et basculement](https://aws.amazon.com/blogs/storage/transferring-file-data-across-aws-regions-and-accounts-using-aws-datasync/) + [Basculement du réseau](https://docs.aws.amazon.com/whitepapers/latest/hybrid-connectivity/aws-dx-dxgw-with-vgw-multi-regions-and-aws-public-peering.html) + [Basculement des points de terminaison S3 à l’aide du protocole MRAP](https://catalog.workshops.aws/s3multiregionaccesspoints/en-US/0-setup/1-review-mrap) + [Création d’une réplication entre régions pour S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html) + [Guidance for Cross Region Failover and Graceful Failback on AWS](https://d1.awsstatic.com/solutions/guidance/architecture-diagrams/cross-region-failover-and-graceful-failback-on-aws.pdf) + [Basculement à l’aide d’un accélérateur mondial multi-régional](https://aws.amazon.com/blogs/networking-and-content-delivery/deploying-multi-region-applications-in-aws-using-aws-global-accelerator/) + [Basculement avec DRS](https://docs.aws.amazon.com/drs/latest/userguide/failback-overview.html) **Exemples connexes :** + [Reprise après sinistre sur AWS](https://disaster-recovery.workshop.aws/en/) + [Elastic Disaster Recovery sur AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/080af3a5-623d-4147-934d-c8d17daba346/en-US) # REL11-BP03 Automatiser la réparation sur toutes les couches REL11-BP03 Automatiser la réparation sur toutes les couches Utilisez des capacités automatisées pour effectuer des actions correctives en cas de détection d’une défaillance. Les dégradations peuvent être automatiquement corrigées par le biais de mécanismes de service internes ou peuvent nécessiter le redémarrage ou la suppression des ressources par le biais d’actions correctives. Pour les applications autogérées et la réparation interrégionale, les modèles de restauration et les processus de réparation automatisés peuvent être extraits des [bonnes pratiques existantes](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/). Pouvoir redémarrer ou supprimer une ressource est important pour remédier aux défaillances. Une bonne pratique consiste à rendre les services sans état dans la mesure du possible. Cela évite toute perte de données ou de disponibilité au redémarrage des ressources. Dans le cloud, vous pouvez (et devriez généralement) remplacer la totalité de la ressource (par exemple, une instance de calcul ou une fonction sans serveur) dans le cadre du redémarrage. Le redémarrage proprement dit est un moyen simple et fiable de récupération après une défaillance. De nombreux types de défaillances différents se produisent dans les charges de travail. Les défaillances peuvent se produire au niveau du matériel, des logiciels, des communications et des opérations. Le redémarrage ou la nouvelle tentative s’appliquent également aux requêtes réseau. Appliquez la même approche de récupération à la fois pour un délai d’expiration réseau et une défaillance de la dépendance, si la dépendance renvoie une erreur. Comme ces deux événements ont un effet semblable sur le système, plutôt que d’essayer de traiter l’un ou l’autre comme un « cas particulier », appliquez une stratégie semblable de nouvelle tentative limitée avec un backoff exponentiel et une instabilité. La possibilité d’exécuter un redémarrage est un mécanisme de récupération présenté dans l’informatique orientée récupération et dans les architectures de cluster haute disponibilité. **Résultat escompté :** des actions automatisées sont effectuées pour remédier à la détection d’une panne. **Anti-modèles courants :** + Allocation des ressources sans mise à l’échelle automatique. + Déploiement d’applications une par une dans des instances ou des conteneurs. + Déploiement d’applications qui ne peuvent pas être déployées dans plusieurs emplacements sans utiliser la récupération automatique. + Réparation manuelle des applications impossible à réparer par la mise à l’échelle et la récupération automatiques. + Aucune automatisation pour le basculement des bases de données. + Absence de méthodes automatisées pour rediriger le trafic vers de nouveaux points de terminaison. + Aucune réplication du stockage. **Avantages liés au respect de cette bonne pratique :** la réparation automatisée contribue à réduire le temps moyen de récupération et à améliorer votre disponibilité. **Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé ## Directives d’implémentation Directives d’implémentation Les conceptions pour Amazon EKS ou les autres services Kubernetes doivent inclure à la fois un minimum et un maximum de réplicas ou d’ensembles dynamiques, ainsi que le dimensionnement minimal des clusters et des groupes de nœuds. Ces mécanismes mettent à disposition un minimum de ressources de traitement en permanence tout en corrigeant automatiquement les défaillances à l’aide du plan de contrôle Kubernetes. Les modèles de conception accessibles via un équilibreur de charge utilisant des clusters de calcul doivent tirer parti des groupes Auto Scaling. Elastic Load Balancing (ELB) distribue automatiquement le trafic applicatif entrant sur plusieurs cibles et appareils virtuels dans une ou plusieurs zones de disponibilité (AZ). La taille des conceptions basées sur le calcul en cluster qui n’utilisent pas l’équilibrage de charge doit être conçue pour la perte d’au moins un nœud. Cela permet au service de continuer à fonctionner avec une capacité potentiellement réduite pendant la restauration d’un nouveau nœud. Mongo, DynamoDB Accelerator, Amazon Redshift, Amazon EMR, Cassandra, Kafka, MSK-EC2, Couchbase, ELK et Amazon OpenSearch Service sont des exemples de services. Bon nombre de ces services peuvent être conçus avec des fonctionnalités supplémentaires de réparation automatique. Certaines technologies de cluster doivent générer une alerte en cas de perte d’un nœud, déclenchant un flux de travail automatique ou manuel pour recréer un nœud. Ce flux de travail peut être automatisé avec AWS Systems Manager pour résoudre rapidement les problèmes. Amazon EventBridge peut être utilisé pour surveiller et filtrer les événements tels que les alarmes CloudWatch ou les changements d’état d’autres services AWS. En fonction des informations d’événement, il peut ensuite invoquer AWS Lambda, Systems Manager Automation ou d’autres cibles pour exécuter une logique de correction personnalisée sur votre charge de travail. Amazon EC2 Auto Scaling peut être configuré pour vérifier l’état de l’instance EC2. Si l’instance est dans un état autre que celui en cours d’exécution, ou si le statut du système est dégradé, Amazon EC2 Auto Scaling considère l’instance comme défectueuse et lance une instance de remplacement. Pour les remplacements à grande échelle (comme la perte d’une zone de disponibilité complète), il est préférable d’opter pour la stabilité statique pour une haute disponibilité. ### Étapes d’implémentation Étapes d’implémentation + Utilisez des groupes Auto Scaling pour déployer des niveaux dans une charge de travail. L’[autoscaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) peut effectuer une autoréparation sur les applications sans état et ajouter ou supprimer de la capacité. + Pour les instances de calcul mentionnées précédemment, utilisez l’[équilibrage de charge](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) et choisissez le type d’équilibreur de charge approprié. + Envisagez de réparer Amazon RDS. Avec les instances de secours, configurez le [basculement automatique](https://repost.aws/questions/QU4DYhqh2yQGGmjE_x0ylBYg/what-happens-after-failover-in-rds) vers l’instance de secours. Pour les réplicas en lecture Amazon RDS, un flux de travail automatisé est nécessaire pour rendre un réplica en lecture principal. + Implémentez la [récupération automatique sur les instances EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) dont les applications déployées ne peuvent pas être déployées dans plusieurs emplacements et qui peuvent tolérer le redémarrage en cas de défaillance. La récupération automatique peut être utilisée pour remplacer du matériel défaillant et redémarrer l’instance lorsque l’application ne peut pas être déployée sur plusieurs emplacements. Les métadonnées de l’instance et les adresses IP associées sont conservées, tout comme le sont les [volumes EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) et les points de montage sur [Amazon Elastic File System](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html) ou sur [File Systems for Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) et [Windows](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html). À l’aide de [AWS OpsWorks](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html), vous pouvez configurer la réparation automatique des instances EC2 au niveau de la couche. + Implémentez la récupération automatique à l’aide d’[AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) et d’[AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) lorsque vous ne pouvez pas utiliser la mise à l’échelle automatique ou la récupération automatique, ou lorsque la récupération automatique échoue. Lorsque vous ne pouvez pas utiliser la scalabilité automatique, que vous ne pouvez pas utiliser la récupération automatique ou que la récupération automatique échoue, vous pouvez automatiser la réparation à l’aide d’AWS Step Functions et d’AWS Lambda. + [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) peut être utilisé pour surveiller et filtrer les événements tels que les [alarmes CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) ou les changements d’état d’autres services AWS. En fonction des informations d’événement, il peut ensuite déclencher AWS Lambda (ou d’autres cibles) pour exécuter une logique de correction personnalisée sur votre charge de travail. ## Ressources Ressources **Bonnes pratiques associées:** + [Définition de la disponibilité](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) + [REL11-BP01 Surveiller tous les composants de la charge de travail pour détecter les défaillances](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html) **Documents connexes :** + [Fonctionnement d’AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) + [Récupération automatique Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) + [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) + [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html) + [Qu’est-ce qu’Amazon FSx pour Lustre ?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) + [Qu’est-ce qu’Amazon FSx for Windows File Server ?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) + [AWS OpsWorks : Utilisation de la réparation automatique pour remplacer les instances en échec](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html) + [Qu'est-ce que AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) + [Qu'est-ce que AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) + [Qu’est-ce qu’Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) + [Utilisation d’alarmes Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) + [Basculement d’Amazon RDS](https://d1.awsstatic.com/rdsImages/IG1_RDS1_AvailabilityDurability_Final.pdf) + [SSM - Systems Manager Automation](https://docs.aws.amazon.com/resilience-hub/latest/userguide/integrate-ssm.html) + [Bonnes pratiques en matière d’architecture résiliente](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/) **Vidéos connexes :** + [Automatically Provision and Scale OpenSearch Service](https://www.youtube.com/watch?v=GPQKetORzmE) + [Amazon RDS Failover Automatically](https://www.youtube.com/watch?v=Mu7fgHOzOn0) **Exemples connexes :** + [Atelier sur le basculement d’Amazon RDS](https://catalog.workshops.aws/resilient-apps/en-US/rds-multi-availability-zone/failover-db-instance) **Outils associés:** + [CloudWatch](https://aws.amazon.com/cloudwatch/) + [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html) # REL11-BP04 S’appuyer sur le plan de données et non sur le plan de contrôle pendant la récupération REL11-BP04 S’appuyer sur le plan de données et non sur le plan de contrôle pendant la récupération Les plans de contrôle fournissent les API administratives utilisées pour créer, lire et décrire, mettre à jour, supprimer et répertorier (CRUDL) les ressources, tandis que les plans de données gèrent le trafic quotidien des services. Lorsque vous mettez en œuvre des réponses de restauration ou d’atténuation en cas d’événements susceptibles d’avoir un impact sur la résilience, concentrez-vous sur l’utilisation d’un nombre minimal d’opérations du plan de contrôle pour récupérer, redimensionner, restaurer, réparer ou basculer le service. L’action du plan de données doit remplacer toute activité lors de ces événements de dégradation. Par exemple, les actions suivantes font toutes partie du plan de contrôle : lancement d’une nouvelle instance de calcul, création d’un stockage par blocs et description des services de file d’attente. Lorsque vous lancez des instances de calcul, le plan de contrôle doit effectuer plusieurs tâches, telles que la recherche d’un hôte physique avec la capacité suffisante, l’allocation d’interfaces réseau, la préparation de volumes locaux de stockage par blocs, la génération d’informations d’identification et l’ajout de règles de sécurité. Les plans de contrôle relèvent souvent d’une orchestration complexe. **Résultat escompté :** lorsqu’une ressource passe à un état altéré, le système peut être rétabli automatiquement ou manuellement en transférant le trafic des ressources altérées vers des ressources saines. **Anti-modèles courants :** + Nécessité de modifier les enregistrements DNS pour rediriger le trafic. + Nécessité de réaliser des opérations de mise à l’échelle du plan de contrôle pour remplacer les composants endommagés en raison de ressources sous-provisionnées. + Utilisation d’actions de plan de contrôle étendues, multiservices et multi-API pour remédier à toute catégorie d’altération. **Avantages du respect de cette bonne pratique :** l’augmentation du taux de réussite de la correction automatisée contribue à réduire le temps moyen de récupération et à améliorer la disponibilité de la charge de travail. **Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen : pour certains types de dégradations de service, les plans de contrôle sont affectés. La nécessité d’utiliser de manière intensive le plan de contrôle pour la correction peut augmenter le délai de reprise (RTO) et le temps moyen de récupération (MTTR). ## Directives d’implémentation Directives d’implémentation Pour limiter les actions du plan de données, évaluez chaque service pour déterminer les actions nécessaires afin de restaurer le service. Tirez parti d’Amazon Application Recovery Controller pour déplacer le trafic DNS. Ces fonctionnalités surveillent en permanence la capacité de votre application à se rétablir suite à des défaillances et vous permettent de contrôler la reprise de votre application dans plusieurs Régions AWS, plusieurs zones de disponibilité et sur site. Les politiques de routage Route 53 utilisent le plan de contrôle. Ne vous fiez donc pas à celui-ci pour la récupération. Les plans de données Route 53 répondent aux requêtes DNS et effectuent et évaluent les surveillances de l’état. Ils sont distribués dans le monde entier et conçus pour un [contrat de niveau de service (SLA) de disponibilité à 100 %](https://aws.amazon.com/route53/sla/). Les API et consoles de gestion Route 53 dans lesquelles vous créez, mettez à jour et supprimez des ressources Route 53 s’exécutent sur des plans de contrôle conçus pour donner la priorité à la cohérence forte et à la durabilité dont vous avez besoin lors de la gestion du DNS. Pour ce faire, les plans de contrôle sont situés dans une seule région : USA Est (Virginie du Nord). Bien que les deux systèmes soient conçus pour être très fiables, les plans de contrôle ne sont pas inclus dans le SLA. Dans de rares cas, la conception résiliente du plan de données permet de maintenir la disponibilité alors que les plans de contrôle ne le font pas. Pour les mécanismes de reprise après sinistre et de basculement, utilisez les fonctions du plan de données pour assurer la meilleure fiabilité possible. Concevez votre infrastructure informatique de manière à ce qu’elle soit statiquement stable afin d’éviter d’utiliser le plan de contrôle lors d’un incident. Par exemple, si vous utilisez des instances Amazon EC2, évitez de provisionner de nouvelles instances manuellement ou de demander aux groupes Auto Scaling d’ajouter des instances en réponse. Pour obtenir les niveaux de résilience les plus élevés, allouez une capacité suffisante dans le cluster utilisé pour le basculement. Si ce seuil de capacité doit être limité, définissez des limitations sur l’ensemble du système de bout en bout afin de restreindre en toute sécurité le trafic total atteignant l’ensemble limité de ressources. Pour des services comme Amazon DynamoDB, Amazon API Gateway, les équilibreurs de charge et AWS Lambda sans serveur, leur utilisation permet de tirer parti du plan de données. Cependant, la création de fonctions, d’équilibreurs de charge, de passerelles d’API ou de tables DynamoDB est une action du plan de contrôle qui doit être terminée avant la dégradation afin de préparer un événement et de répéter les actions de basculement. Pour Amazon RDS, les actions du plan de données permettent d’accéder aux données. Pour plus d’informations sur les plans de données, les plans de contrôle et sur comment AWS crée des services pour atteindre les objectifs de haute disponibilité, consultez [Stabilité statique à l’aide de zones de disponibilité](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/). Comprendre quelles opérations relèvent du plan de données et quelles opérations relèvent du plan de contrôle. ### Étapes d’implémentation Étapes d’implémentation Pour chaque charge de travail qui doit être restaurée après un événement de dégradation, évaluez le runbook de basculement, la conception de la haute disponibilité, la conception de la réparation automatique ou le plan de restauration des ressources haute disponibilité. Identifiez chaque action qui pourrait être considérée comme une action du plan de contrôle. Envisagez de remplacer l’action du plan de contrôle par une action de plan de données : + Autoscaling (plan de contrôle) vers les ressources Amazon EC2 préalablement mises à l’échelle (plan de données) + Mise à l’échelle d’instance Amazon EC2 (plan de contrôle) par rapport à la mise à l’échelle AWS Lambda (plan de données) + Évaluez toutes les conceptions utilisant Kubernetes, ainsi que la nature des actions du plan de contrôle. L’ajout de pods est une action du plan de données dans Kubernetes. Les actions doivent se limiter à l’ajout de pods et non à l’ajout de nœuds. L’utilisation de [nœuds surapprovisionnés](https://www.eksworkshop.com/docs/autoscaling/compute/cluster-autoscaler/overprovisioning/) est la méthode préférée pour limiter les actions du plan de contrôle Envisagez d’autres approches qui permettent aux actions du plan de données d’affecter les mêmes mesures correctives. + Modification d’enregistrement Route 53 (plan de contrôle) ou Amazon Application Recovery Controller (plan de données) + [ Surveillance de l’état Route 53 pour des mises à jour plus automatisées ](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/) Envisagez certains services dans une région secondaire, s’ils sont critiques, afin de permettre davantage d’actions du plan de contrôle et du plan de données dans une région non affectée. + Amazon EC2 Auto Scaling ou Amazon EKS dans une région principale par rapport à Amazon EC2 Auto Scaling ou Amazon EKS dans une région secondaire et acheminement du trafic vers la région secondaire (action du plan de contrôle) + Réalisez un réplica en lecture dans la région secondaire ou tentez la même action dans la région principale (action du plan de contrôle). ## Ressources Ressources **Bonnes pratiques associées :** + [Définition de la disponibilité](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) + [REL11-BP01 Surveiller tous les composants de la charge de travail pour détecter les défaillances](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html) **Documents connexes :** + [Partenaire APN : partenaires pouvant vous aider à automatiser votre tolérance aux pannes](https://aws.amazon.com/partners/find/results/?keyword=automation) + [AWS Marketplace : produits pouvant être utilisés pour la tolérance aux pannes](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance) + [L’Amazon Builders’ Library : éviter la surcharge des systèmes distribués en plaçant sous contrôle le plus petit service](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/) + [API Amazon DynamoDB (plan de contrôle et plan de données)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html) + [Exécutions AWS Lambda](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (réparties entre le plan de contrôle et le plan de données) + [Plan de données AWS Elemental MediaStore](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html) + [Création d’applications hautement résilientes à l’aide d’Amazon Application Recovery Controller, partie 1 : pile dans une seule région](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/) + [Création d’applications hautement résilientes à l’aide d’Amazon Application Recovery Controller, partie 2 : pile dans plusieurs régions](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/) + [Création de mécanismes de reprise après sinistre à l’aide d’Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/) + [Qu’est-ce qu’Amazon Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) + [ Plan de contrôle et plan de données Kubernetes ](https://aws.amazon.com/blogs/containers/managing-kubernetes-control-plane-events-in-amazon-eks/) **Vidéos connexes :** + [ Back to Basics - Using Static Stability ](https://www.youtube.com/watch?v=gy1RITZ7N7s) + [ Building resilient multi-site workloads using AWS global services ](https://www.youtube.com/watch?v=62ZQHTruBnk) **Exemples connexes :** + [Présentation d’Amazon Application Recovery Controller](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/) + [ L’Amazon Builders’ Library : éviter la surcharge des systèmes distribués en plaçant sous contrôle le plus petit service ](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/) + [Création d’applications hautement résilientes à l’aide d’Amazon Application Recovery Controller, partie 1 : pile dans une seule région](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/) + [Création d’applications hautement résilientes à l’aide d’Amazon Application Recovery Controller, partie 2 : pile dans plusieurs régions](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/) + [ Stabilité statique avec les zones de disponibilité ](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/) **Outils associés :** + [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/) + [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html) # REL11-BP05 Utiliser la stabilité statique pour éviter les comportements bimodaux REL11-BP05 Utiliser la stabilité statique pour éviter les comportements bimodaux Les charges de travail doivent être statiquement stables et ne fonctionner que dans un seul mode normal. On parle de comportement bimodal lorsque la charge de travail présente un comportement différent en mode normal et en mode d’échec. Par exemple, vous pouvez essayer de récupérer une défaillance de la zone de disponibilité en lançant de nouvelles instances dans une zone de disponibilité différente. Il peut en résulter une réponse bimodale lors d’un mode de défaillance. Pour éviter ce type de comportement, vous devez créer des charges de travail stables statiquement et qui fonctionnent dans un seul mode. Dans cet exemple, ces instances auraient dû être provisionnées dans la deuxième zone de disponibilité avant la panne. Ce modèle de stabilité statique permet de vérifier que la charge de travail ne fonctionne que dans un seul mode. **Résultat escompté :** les charges de travail ne présentent pas de comportement bimodal en mode normal et en mode d’échec. **Anti-modèles courants :** + Supposer que les ressources peuvent toujours être provisionnées quelle que soit l’étendue de la défaillance. + Essayer d’acquérir dynamiquement des ressources lors d’une panne. + Ne pas provisionner les ressources adéquates dans les zones ou les régions jusqu’à ce qu’une panne se produise. + Envisager des modèles statiques et stables pour les ressources informatiques uniquement. **Avantages liés au respect de cette bonne pratique :** les charges de travail exécutées avec des modèles statiquement stables sont capables d’avoir des résultats prévisibles lors d’événements normaux et de défaillances. **Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen ## Directives d’implémentation Directives d’implémentation Un comportement bimodal survient lorsque votre charge de travail adopte un comportement différent en mode normal et en mode de défaillance (par exemple, en s’appuyant sur le lancement de nouvelles instances en cas de défaillance d’une zone de disponibilité). Exemple de comportement bimodal : les modèles Amazon EC2 stables provisionnent suffisamment d’instances dans chaque zone de disponibilité pour gérer la charge de travail si une zone de disponibilité était supprimée. Elastic Load Balancing ou Amazon Route 53 vérifieraient l’état pour éloigner une charge de l’instance défaillante. Une fois le trafic déplacé, utilisez AWS Auto Scaling pour remplacer de manière asynchrone les instances de la zone défaillante et les lancer dans les zones saines. La stabilité statique du déploiement de calcul (par exemple, des conteneurs ou des instances EC2) garantit une fiabilité optimale. ![\[Diagramme illustrant la stabilité statique des instances EC2 dans les zones de disponibilité\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/framework/images/static-stability.png) Cela doit être comparé au coût de ce modèle et à la valeur commerciale du maintien de la charge de travail dans tous les cas de résilience. Il est moins coûteux de provisionner moins de capacité de calcul et de compter sur le lancement de nouvelles instances en cas de panne. Cependant, pour les pannes à grande échelle (comme une zone de disponibilité ou une panne régionale), cette approche se révèle moins efficace, car elle repose à la fois sur un plan opérationnel et sur la disponibilité de ressources suffisantes dans les zones ou les régions non affectées. Votre solution doit également tenir compte de la fiabilité par rapport aux coûts nécessaires pour votre charge de travail. Les architectures de stabilité statique s’appliquent à différentes architectures, notamment les instances de calcul réparties dans les zones de disponibilité, les modèles de réplicas en lecture de bases de données, les modèles de clusters Kubernetes (EKS) et les architectures de basculement multi-régions. Il est également possible de mettre en œuvre un modèle plus stable sur le plan statique en utilisant davantage de ressources dans chaque zone. En ajoutant davantage de zones, vous réduisez la quantité de calcul supplémentaire nécessaire à la stabilité statique. Autre exemple de comportement bimodal : un délai d’expiration du réseau peut amener un système à tenter d’actualiser l’état de configuration de l’ensemble du système. Cela ajouterait une charge inattendue à un autre composant et pourrait provoquer sa défaillance, entraînant d’autres conséquences inattendues. Cette boucle de rétroaction négative a un impact sur la disponibilité de votre charge de travail. Vous pourriez donc créer des systèmes stables statiquement et fonctionnant dans un seul mode. Un modèle statiquement stable consisterait à effectuer un travail constant et à toujours actualiser l’état de la configuration selon une cadence fixe. Lorsqu’un appel échoue, la charge de travail utilise la valeur précédemment mise en cache et déclenche une alarme. Un autre exemple de comportement bimodal consiste à autoriser les clients à contourner votre cache de charge de travail lorsque des défaillances se produisent. Cette solution peut sembler répondre aux besoins des clients, mais elle peut modifier considérablement les exigences de votre charge de travail et risque d’entraîner des échecs. Évaluez les charges de travail critiques afin de déterminer celles qui nécessitent ce type de modèle de résilience. Pour celles qui sont jugées critiques, chaque composant de l’application doit être examiné. Voici quelques exemples de services nécessitant une évaluation de la stabilité statique : + **Calcul** : Amazon EC2, EKS-EC2, ECS-EC2, EMR-EC2 + **Bases de données** : Amazon Redshift, Amazon RDS, Amazon Aurora + **Stockage** : Amazon S3 (zone unique), Amazon EFS (montages), Amazon FSx (montages) + **Équilibreurs de charge :** selon certains modèles ### Étapes d’implémentation Étapes d’implémentation + Créez des systèmes stables statiquement et qui fonctionnent dans un seul mode. Dans ce cas, provisionnez suffisamment d’instances dans chaque zone de disponibilité ou région pour gérer la capacité de la charge de travail si une zone de disponibilité ou une région était supprimée. Plusieurs services peuvent être utilisés pour l’acheminement vers des ressources saines, par exemple : + [Routage DNS entre régions](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html) + [Routage multi-régional MRAP Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html) + [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) + [Amazon Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) + Configurez des [réplicas en lecture de base de données](https://aws.amazon.com/rds/features/multi-az/) pour tenir compte de la perte d’une instance primaire unique ou d’un réplica en lecture. Si le trafic est desservi par des réplicas en lecture, la quantité dans chaque zone de disponibilité et chaque région doit correspondre au besoin global en cas de défaillance de la zone ou de la région. + Configurez les données critiques dans un stockage Amazon S3 conçu pour être statiquement stable pour les données stockées en cas de défaillance d’une zone de disponibilité. Si la classe de stockage [Amazon S3 unizone – Accès peu fréquent](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/) est utilisée, elle ne doit pas être considérée comme statiquement stable, car la perte de cette zone minimise l’accès aux données stockées. + Des [équilibreurs de charge](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html) sont parfois configurés de manière incorrecte ou sciemment pour desservir une zone de disponibilité spécifique. Dans ce cas, le modèle statiquement stable peut consister à répartir une charge de travail sur plusieurs zones de disponibilité dans le cadre d’un modèle plus complexe. Le modèle original peut être utilisé pour réduire le trafic interzone pour des raisons de sécurité, de latence ou de coût. ## Ressources Ressources **Bonnes pratiques Well-Architected connexes:** + [Définition de la disponibilité](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) + [REL11-BP01 Surveiller tous les composants de la charge de travail pour détecter les défaillances](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html) + [REL11-BP04 S’appuyer sur le plan de données et non sur le plan de contrôle pendant la récupération](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_avoid_control_plane.html) **Documents connexes :** + [Minimiser les dépendances dans un plan de reprise après sinistre](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/) + [The Amazon Builders’ Library: Static stability using Availability Zones](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) + [Fault Isolation Boundaries](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/appendix-a---partitional-service-guidance.html) + [Stabilité statique avec les zones de disponibilité](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) + [RDS multizone](https://aws.amazon.com/rds/features/multi-az/) + [Minimiser les dépendances dans un plan de reprise après sinistre](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/) + [Routage DNS entre régions](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html) + [Routage multi-régional MRAP Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html) + [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) + [Amazon Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) + [Amazon S3 à zone unique](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/) + [Équilibrage de charge entre zones](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html) **Vidéos connexes :** + [Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704) # REL11-BP06 Envoyer des notifications lorsque des événements affectent la disponibilité REL11-BP06 Envoyer des notifications lorsque des événements affectent la disponibilité Des notifications sont envoyées en cas de détection de dépassement de seuils, même si l’événement à l’origine du problème a été automatiquement résolu. La réparation automatisée permet à votre charge de travail d’être fiable. Cependant, elle peut également masquer les problèmes sous-jacents à résoudre. Implémentez une surveillance et des événements appropriés afin de pouvoir détecter les schémas de problèmes, y compris ceux résolus par la réparation automatique, afin de pouvoir résoudre les problèmes de cause racine. Les systèmes résilients sont conçus de manière à ce que les événements de dégradation soient immédiatement communiqués aux équipes concernées. Ces notifications doivent être envoyées par un ou plusieurs canaux de communication. **Résultat escompté :** des alertes sont immédiatement envoyées aux équipes chargées des opérations lorsque des seuils sont dépassés, tels que les taux d’erreur, la latence ou d’autres métriques d’indicateurs clés de performance (KPI) critiques, afin que ces problèmes soient résolus dès que possible et que l’impact sur les utilisateurs soit évité ou minimisé. **Anti-modèles courants :** + Envoyer un trop grand nombre d’alarmes. + Envoyer des alarmes non exploitables. + Régler les seuils d’alarme à un niveau trop élevé (sensibilité excessive) ou trop faible (sensibilité insuffisante). + Ne pas envoyer d’alarmes pour les dépendances externes. + Ne pas prendre en compte les [défaillances grises](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) lors de la conception de la surveillance et des alarmes. + Effectuer des réparations automatisées, mais ne pas notifier l’équipe appropriée que des réparations étaient nécessaires. **Avantages du respect de cette bonne pratique :** les notifications de reprise permettent aux équipes commerciales et chargées des opérations d’être informées des dégradations de service, de sorte qu’elles peuvent réagir immédiatement pour minimiser à la fois le temps moyen de détection (MTTD) et le temps moyen de réparation (MTTR). Les notifications d’événements de reprise vous permettent également de ne pas ignorer les problèmes qui se produisent peu fréquemment. **Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen. L’absence de mise en œuvre de mécanismes appropriés de surveillance et de notification des événements peut entraîner l’incapacité à détecter des schémas de problèmes, y compris ceux traités par la réparation automatisée. Une équipe ne sera informée de la dégradation du système que lorsque les utilisateurs contacteront le service clientèle ou par hasard. ## Directives d’implémentation Directives d’implémentation Lors de la définition d’une stratégie de surveillance, le déclenchement d’une alarme est un événement courant. Cet événement contiendra probablement un identifiant pour l’alarme, l’état de l’alarme (comme `IN ALARM` ou `OK`) et les détails de ce qui l’a déclenchée. Dans de nombreux cas, un événement d’alarme doit être détecté et une notification par e-mail doit être envoyée. Voici un exemple d’action sur une alarme. La notification d’alarme est essentielle pour l’observabilité, car elle permet d’informer les bonnes personnes de l’existence d’un problème. Cependant, lorsque l’action sur les événements arrive à maturité dans votre solution d’observabilité, elle peut automatiquement remédier au problème sans nécessiter d’intervention humaine. Une fois que les alarmes de suivi des KPI ont été établies, des alertes doivent être envoyées aux équipes concernées lorsque les seuils sont dépassés. Ces alertes peuvent également être utilisées pour déclencher des processus automatisés qui tenteront de remédier à la dégradation. Pour une surveillance plus complexe des seuils, des alarmes composites doivent être envisagées. Les alarmes composites utilisent un certain nombre d’alarmes de surveillance des KPI pour créer une alerte basée sur la logique métier opérationnelle. Les alarmes CloudWatch peuvent être configurées pour envoyer des e-mails pour consigner des incidents dans des systèmes tiers de suivi des incidents à l’aide de l’intégration d’Amazon SNS ou d’Amazon EventBridge. ### Étapes d’implémentation Étapes d’implémentation Créez différents types d’alarmes en fonction des charges de travail surveillées, par exemple : + Les alarmes d’application permettent de détecter si une partie de votre charge de travail ne fonctionne pas correctement. + Les [alarmes relatives à l’infrastructure](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) indiquent à quel moment il faut mettre les ressources à l’échelle. Le système peut afficher les alarmes sur des tableaux de bord, envoyer des alertes via Amazon SNS ou par e-mail et fonctionner avec Auto Scaling pour une mise à l’échelle des ressources de la charge de travail entrante ou sortante. + Des [alarmes statiques](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) simples peuvent être créées pour surveiller le dépassement d’un seuil statique par une métrique pendant un nombre spécifié de périodes d’évaluation. + Des [alarmes composites](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html) peuvent prendre en compte des alarmes complexes provenant de sources multiples. + Une fois l’alarme créée, créez les événements de notification appropriés. Vous pouvez directement invoquer une [API Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) pour envoyer des notifications et associer toute automatisation à des fins de correction ou de communication. + Restez informé des dégradations de service avec [AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/). [Créez des notifications d’événements AWS Health](https://docs.aws.amazon.com/health/latest/ug/user-notifications.html) spécialement adaptées aux e-mails et aux canaux de discussion via [Notifications des utilisateurs AWS](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) et intégrez-les de manière programmatique à [vos outils de surveillance et d’alerte via Amazon EventBridge](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html). ## Ressources Ressources **Bonnes pratiques Well-Architected connexes:** + [Définition de la disponibilité](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) **Documents connexes:** + [Création d’une alarme CloudWatch basée sur un seuil statique](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) + [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 Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) + [Publication des métriques personnalisées](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) + [Utilisation d’alarmes Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) + [Configuration des alarmes CloudWatch Composite](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html) + [Les nouveautés en matière d’observabilité AWS à re:Invent 2022](https://aws.amazon.com/blogs/mt/whats-new-in-aws-observability-at-reinvent-2022/) **Outils associés:** + [CloudWatch](https://aws.amazon.com/cloudwatch/) + [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html) # REL11-BP07 Concevoir votre produit pour atteindre les objectifs de disponibilité et les contrats de niveau de service (SLA) REL11-BP07 Concevoir votre produit pour atteindre les objectifs de disponibilité et les contrats de niveau de service (SLA) Concevez votre produit de manière à atteindre les objectifs de disponibilité et les contrats de niveau de service (SLA). Si vous publiez ou convenez en privé d’objectifs de disponibilité ou d’accords de niveau de service, vérifiez que votre architecture et vos processus opérationnels sont conçus pour les prendre en charge. **Résultat souhaité :** chaque application dispose d’un objectif défini en matière de disponibilité et d’un contrat de niveau de service pour les indicateurs de performance, qui peuvent être surveillés et maintenus afin d’atteindre les résultats commerciaux. **Anti-modèles courants :** + Concevoir et déployer des charges de travail sans fixer de contrats de niveau de service. + Les métriques des SLA sont fixées à un niveau trop élevé sans justification ni exigences commerciales. + Fixer des contrats de niveau de service sans tenir compte des dépendances et des contrats de niveau de service sous-jacents. + Les conceptions d’applications sont créées sans tenir compte du modèle de responsabilité partagée pour la résilience. **Avantages du respect de cette bonne pratique :** la conception d’applications reposant sur des objectifs de résilience clés vous aide à atteindre les objectifs commerciaux et les attentes des clients. Ces objectifs contribuent à orienter le processus de conception de l’application qui évalue les différentes technologies et envisage divers compromis. **Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen ## Directives d’implémentation Directives d’implémentation La conception des applications doit tenir compte d’un ensemble diversifié d’exigences découlant d’objectifs commerciaux, opérationnels et financiers. Dans le cadre des exigences opérationnelles, les charges de travail doivent avoir des objectifs spécifiques en matière de métriques de résilience afin qu’elles puissent être correctement surveillées et prises en charge. Les métriques de résilience ne doivent pas être définies ou déduites après le déploiement de la charge de travail. Elles doivent être définies pendant la phase de conception et aider à guider les diverses décisions et compromis. + Chaque charge de travail doit disposer de son propre ensemble de métriques de résilience. Ces métriques peuvent être différentes de celles d’autres applications commerciales. + La réduction des dépendances peut avoir un impact positif sur la disponibilité. Chaque charge de travail doit tenir compte de ses dépendances et de leurs contrats de niveau de service. En général, sélectionnez les dépendances dont les objectifs de disponibilité sont égaux ou supérieurs à ceux de votre charge de travail. + Envisagez des conceptions faiblement couplées afin que votre charge de travail puisse fonctionner correctement malgré l’altération des dépendances, lorsque cela est possible. + Réduisez les dépendances du plan de contrôle, notamment lors de la reprise ou d’une dégradation. Évaluez les conceptions statiques stables pour les charges de travail critiques. Utilisez le partage des ressources pour augmenter la disponibilité de ces dépendances dans une charge de travail. + L’observabilité et l’instrumentation sont essentielles pour respecter les contrats de niveau de service en réduisant le temps moyen de détection (MTTD) et le temps moyen de réparation (MTTR). + Des défaillances moins fréquentes (MTBF plus long), des temps de détection des défaillances plus courts (MTTD plus court) et des temps de réparation plus courts (MTTR plus court) sont les trois facteurs utilisés pour améliorer la disponibilité des systèmes distribués. + L’établissement et le respect des métriques de résilience pour une charge de travail sont à la base de toute conception efficace. Ces conceptions doivent tenir compte des compromis entre la complexité de la conception, les dépendances des services, les performances, la mise à l’échelle et les coûts. **Étapes d’implémentation** + Examinez et documentez la conception de la charge de travail en tenant compte des questions suivantes : + Où les plans de contrôle sont-ils utilisés dans la charge de travail ? + Comment la charge de travail met-elle en œuvre la tolérance aux pannes ? + Quels sont les modèles de conception pour la mise à l’échelle, la mise à l’échelle automatique, la redondance et les composants hautement disponibles ? + Quelles sont les exigences en matière de cohérence et de disponibilité des données ? + Y a-t-il des considérations relatives à l’économie des ressources ou à la stabilité statique des ressources ? + Quelles sont les dépendances des services ? + Définissez les métriques SLA en fonction de l’architecture de la charge de travail tout en travaillant avec les parties prenantes. Tenez compte des SLA de toutes les dépendances utilisées par la charge de travail. + Une fois l’objectif du SLA fixé, optimisez l’architecture pour le respecter. + Une fois que la conception a été définie de manière à respecter le contrat de niveau de service, il faut mettre en œuvre les changements opérationnels, l’automatisation des processus et les runbooks qui visent également à réduire les délais d’attente et les temps de réponse. + Une fois le déploiement effectué, surveillez et rendez compte du contrat de niveau de service. ## Ressources Ressources **Bonnes pratiques associées :** + [REL03-BP01 Choisissez comment segmenter votre charge de travail](rel_service_architecture_monolith_soa_microservice.md) + [REL10-BP01 Déploiement de la charge de travail sur plusieurs emplacements](rel_fault_isolation_multiaz_region_system.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) + [REL11-BP03 Automatiser la réparation sur toutes les couches](rel_withstand_component_failures_auto_healing_system.md) + [REL12-BP04 Tester la résilience à l’aide de l’ingénierie du chaos](rel_testing_resiliency_failure_injection_resiliency.md) + [REL13-BP01 Définir les objectifs de reprise pour les temps d’arrêt et les pertes de données](rel_planning_for_recovery_objective_defined_recovery.md) + [ Comprendre l’état de la charge de travail ](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/understanding-workload-health.html) **Documents connexes :** + [ Disponibilité avec redondance ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html) + [ Pilier de fiabilité - Disponibilité ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) + [ Mesurer la disponibilité ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/measuring-availability.html) + [AWS Fault Isolation Boundaries ](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html) + [ Modèle de responsabilité partagée pour la résilience ](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/shared-responsibility-model-for-resiliency.html) + [ Stabilité statique avec les zones de disponibilité ](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/) + [Accords de niveau de service (SLA) AWS](https://aws.amazon.com/legal/service-level-agreements/) + [ Conseils pour l’architecture cellulaire sur AWS](https://aws.amazon.com/solutions/guidance/cell-based-architecture-on-aws/) + [Infrastructure AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/aws-infrastructure.html) + [Livre blanc sur les modèles de résilience multi-AZ avancés](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/advanced-multi-az-resilience-patterns.html) **Services connexes :** + [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/) + [AWS Config](https://aws.amazon.com/config/) + [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)