# Gestion des modifications **Topics** + [FIA 6. Comment surveiller les ressources de charge de travail ?](rel-06.md) + [FIA 7. Comment concevoir votre charge de travail pour qu’elle s’adapte à l’évolution de la demande ?](rel-07.md) + [FIA 8. Comment mettre en œuvre des modifications ?](rel-08.md) # FIA 6. Comment surveiller les ressources de charge de travail ? Les journaux et les métriques sont des outils puissants qui permettent de mieux comprendre l’état de santé de votre charge de travail. Vous pouvez configurer votre charge de travail pour qu’elle surveille les journaux et les métriques et envoie des notifications lorsque des seuils sont franchis ou que des événements importants se produisent. La surveillance permet à votre charge de travail de reconnaître quand des seuils de faibles performances sont franchis ou quand des défaillances se produisent, afin d’y répondre par une récupération automatique. **Topics** + [REL06-BP01 Surveiller tous les composants de la charge de travail (génération)](rel_monitor_aws_resources_monitor_resources.md) + [REL06-BP02 Définir et calculer des métriques (agrégation)](rel_monitor_aws_resources_notification_aggregation.md) + [REL06-BP03 Envoyer des notifications (traitement et alarmes en temps réel)](rel_monitor_aws_resources_notification_monitor.md) + [REL06-BP04 Automatiser les réponses (traitement et alarmes en temps réel)](rel_monitor_aws_resources_automate_response_monitor.md) + [REL06-BP05 Analyser les journaux](rel_monitor_aws_resources_storage_analytics.md) + [REL06-BP06 Passer régulièrement en revue la portée et les métriques de surveillance](rel_monitor_aws_resources_review_monitoring.md) + [REL06-BP07 Surveiller la traçabilité complète des demandes via votre système](rel_monitor_aws_resources_end_to_end.md) # REL06-BP01 Surveiller tous les composants de la charge de travail (génération) Surveillez les composants de la charge de travail avec Amazon CloudWatch ou des outils tiers. Surveillez les services AWS avec le tableau de bord AWS Health. Tous les composants de votre charge de travail doivent être surveillés, y compris le côté utilisateur, la logique métier et les niveaux de stockage. Au besoin, définissez des métriques clés, décrivez leur procédure d’extraction des journaux, puis spécifiez des seuils d’invocation pour les événements d’alarme correspondants. Assurez-vous que les métriques sont pertinentes pour les indicateurs clés de performance (KPI) de votre charge de travail, et utilisez des métriques et des journaux pour identifier les signes avant-coureurs de la dégradation du service. Par exemple, une métrique liée aux résultats commerciaux, telle que le nombre de commandes traitées avec succès par minute, peut indiquer des problèmes de charge de travail plus rapidement qu’une métrique technique, telle que l’utilisation du processeur. Utilisez le tableau de bord AWS Health pour obtenir une vue personnalisée des performances et de la disponibilité des services AWS sous-jacents à vos ressources AWS. La surveillance dans le cloud offre de nouvelles opportunités. La plupart des fournisseurs de cloud ont développé des hooks personnalisables et peuvent fournir des informations pour vous aider à surveiller plusieurs couches de votre charge de travail. Des services AWS comme Amazon CloudWatch appliquent des algorithmes statistiques et de machine learning pour analyser en continu les métriques des systèmes et des applications, déterminer les points de référence normaux et détecter les anomalies avec une intervention minimale de l’utilisateur. Les algorithmes de détection des anomalies tiennent compte de la saisonnalité et des changements de tendance des métriques. AWS met à disposition une multitude d’informations de surveillance et de journalisation qui peuvent être utilisées pour définir des métriques spécifiques à la charge de travail et des processus de changement de la demande, et pour adopter des techniques de machine learning, quelle que soit l’expertise en ML. En outre, surveillez l’ensemble de vos points de terminaison externes afin de vous assurer qu’ils sont indépendants de votre implémentation de base. Cette surveillance active peut être effectuée avec des transactions synthétiques (parfois appelées *Canary utilisateurs* à ne pas confondre avec les déploiements Canary) qui exécutent régulièrement un certain nombre de tâches courantes effectuées par les clients de la charge de travail. Maintenez ces tâches de courte durée et veillez à ne pas surcharger votre charge de travail pendant les tests. Amazon CloudWatch Synthetics vous permet de [créer des scripts Canary synthétiques](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) pour surveiller vos points de terminaison et vos API. Vous pouvez également combiner les nœuds de clients synthétiques Canary avec la console AWS X-Ray pour identifier les scripts Canary synthétiques qui rencontrent des erreurs, des pannes ou des taux de limitation au cours de la période sélectionnée. **Résultat escompté :** Collectez et utilisez des métriques critiques de tous les composants de la charge de travail pour garantir la fiabilité de la charge de travail et une expérience utilisateur optimale. Détecter qu’une charge de travail n’atteint pas les résultats vous permet de déclarer rapidement un sinistre et de vous remettre d’un incident. **Anti-modèles courants :** + Surveillance limitée aux interfaces externes de votre charge de travail. + Ne pas générer de métriques spécifiques à la charge de travail et s’appuyer uniquement sur les métriques qui vous sont fournies par les services AWS utilisés par votre charge de travail. + Utiliser uniquement des métriques techniques dans votre charge de travail et ne surveiller aucune métrique liée aux KPI non techniques auxquels la charge de travail contribue. + S’appuyer sur le trafic de production et de simples surveillances de l’état pour surveiller et évaluer l’état de la charge de travail. **Avantages du respect de cette bonne pratique :** la surveillance à tous les niveaux de votre charge de travail vous permet d’anticiper et de résoudre plus rapidement les problèmes dans les composants qui constituent la charge de travail. **Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé ## Directives d’implémentation 1. **Activez la journalisation lorsqu’elle est disponible.** Les données de surveillance doivent être obtenues à partir de tous les composants des charges de travail. Activez la journalisation supplémentaire, telle que les journaux d’accès S3, et autorisez votre charge de travail à consigner des données qui lui sont spécifiques. Collectez des métriques pour les moyennes du processeur, des E/S réseau et des E/S du disque auprès de services tels qu’Amazon ECS, Amazon EKS, Amazon EC2, Elastic Load Balancing, AWS Auto Scaling et Amazon EMR. Consultez la section [Services AWS qui publient des métriques CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) pour obtenir la liste des services AWS qui publient des métriques sur CloudWatch. 1. **Passez en revue toutes les métriques par défaut et explorez toutes les lacunes de collecte de données.** Chaque service génère des métriques par défaut. La collecte des métriques par défaut vous permet de mieux comprendre les dépendances entre les composants de charge de travail et sur la manière dont la fiabilité et les performances des composants affectent la charge de travail. Vous pouvez également créer et [publier vos propres métriques](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) dans CloudWatch à l’aide de la AWS CLI ou d’une API. 1. **Évaluez toutes les métriques pour décider celles pour lesquelles envoyer des alertes pour chaque service AWS de votre charge de travail.** Vous pouvez choisir de sélectionner un sous-ensemble de métriques qui ont un impact majeur sur la fiabilité de la charge de travail. En vous concentrant sur les métriques et les seuils critiques, vous pouvez affiner le nombre d’[alertes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) et réduire le nombre de faux positifs. 1. **Définissez des alertes et le processus de récupération de votre charge de travail après l’invocation de l’alerte.** La définition d’alertes vous permet de notifier, de faire remonter et de suivre rapidement les étapes nécessaires pour vous remettre d’un incident et atteindre votre objectif de délai de reprise (RTO) prescrit. Vous pouvez utiliser des [https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions) pour invoquer des flux de travail automatisés et lancer des procédures de récupération en fonction de seuils définis. 1. **Explorez l’utilisation de transactions synthétiques pour collecter des données pertinentes sur l’état des charges de travail.** La surveillance synthétique suit les mêmes routes et effectue les mêmes actions qu’un client, ce qui vous permet de vérifier en permanence l’expérience client même lorsque vous n’avez aucun trafic client sur vos charges de travail. En utilisant les [transactions synthétiques](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html), vous pouvez découvrir les problèmes avant vos clients. ## Ressources **Bonnes pratiques associées:** + [REL11-BP03 Automatiser la réparation sur toutes les couches](rel_withstand_component_failures_auto_healing_system.md) **Documents connexes :** + [Premiers pas avec le tableau de bord AWS Health : état de votre compte](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html) + [Services AWS qui publient des métriques CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) + [Journaux d’accès de votre Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-access-logs.html) + [Journaux d’accès pour votre Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html) + [Accès aux journaux Amazon CloudWatch Logs pour AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-logs.html) + [Journalisation des accès au serveur Amazon S](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html) + [Activation des journaux d’accès pour votre Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-access-logs.html) + [Exporter les données du journal vers Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) + [Installer l’agent CloudWatch sur une instance Amazon EC2](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance.html) + [Publication des métriques personnalisées](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) + [Utilisation des tableaux de bord Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) + [Utilisation des métriques Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) + [Utilisation de scripts Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) + [Qu’est-ce qu’Amazon CloudWatch Logs ?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) **Guides de l’utilisateur :** + [Création d’un journal de suivi](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html) + [Surveillance des métriques de mémoire et de disque pour les instances Linux Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html) + [Utilisation de CloudWatch Logs avec des instances de conteneurs](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html) + [Journaux de flux VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html) + [Qu’est-ce qu’Amazon DevOps Guru ?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) + [Qu’est-ce qu AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) **Blogs connexes :** + [Débogage avec Amazon CloudWatch Synthetics et AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) **Exemples connexes :** + [Amazon Builders’ Library : Instrumentation des systèmes distribués au profit de la visibilité opérationnelle](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) + [Atelier sur l’observabilité](https://catalog.workshops.aws/observability/en-US) # REL06-BP02 Définir et calculer des métriques (agrégation) Collectez les métriques et les journaux des composants de votre charge de travail, et calculez des métriques agrégées pertinentes à partir de ces derniers. Ces métriques permettent une observabilité large et approfondie de votre charge de travail et peuvent améliorer de manière significative votre posture de résilience. L’observabilité ne se limite pas à collecter des métriques à partir des composants de votre charge de travail et à être en mesure de les visualiser et d’émettre des alertes à leur sujet. Elle permet de bénéficier d’une compréhension globale du comportement de votre charge de travail. Ces informations comportementales proviennent de tous les composants de vos charges de travail, notamment des services cloud dont elles dépendent, des journaux bien conçus et des métriques. Ces données vous permettent de surveiller le comportement de votre charge de travail dans son ensemble et de comprendre de manière détaillée l’interaction de chaque composant avec chaque unité de travail. **Résultat escompté :** + Vous collectez les journaux des composants de votre charge de travail et des dépendances des services AWS, et vous les publiez dans un emplacement central où ils peuvent être facilement consultés et traités. + Vos journaux contiennent des horodatages fidèles et précis. + Vos journaux contiennent des informations pertinentes sur le contexte du traitement, telles qu’un identifiant de suivi, un identifiant d’utilisateur ou de compte et une adresse IP distante. + Vous créez des métriques agrégées à partir de vos journaux qui représentent le comportement de votre charge de travail d’un point de vue général. + Vous pouvez interroger vos journaux agrégés pour obtenir des informations approfondies et pertinentes sur votre charge de travail et identifier les problèmes réels et potentiels. **Anti-modèles courants :** + Vous ne collectez pas de métriques ou de journaux pertinents à partir des instances de calcul sur lesquelles vos charges de travail s’exécutent ou des services cloud qu’elles utilisent. + Vous négligez la collecte des journaux et métriques liés à vos indicateurs de performances clés (KPI) métier. + Vous analysez la télémétrie liée à la charge de travail de manière isolée, sans agrégation ni corrélation. + Vous laissez les métriques et les journaux expirer trop rapidement, ce qui entrave l’analyse des tendances et l’identification des problèmes récurrents. **Avantages du respect de ces bonnes pratiques :** vous pouvez détecter davantage d’anomalies et corréler les événements et les métriques entre les différents composants de votre charge de travail. Vous pouvez créer des informations exploitables à partir des composants de votre charge de travail en vous basant sur les informations contenues dans les journaux, qui ne sont souvent pas disponibles dans les métriques seules. Vous pouvez déterminer plus rapidement les causes des défaillances en interrogeant vos journaux à grande échelle. **Niveau d’exposition au risque si ces bonnes pratiques ne sont pas respectées :** élevé ## Directives d’implémentation Identifiez les sources des données de télémétrie pertinentes pour vos charges de travail et leurs composants. Ces données proviennent non seulement des composants qui publient des métriques, tels que votre système d’exploitation (OS) et les environnements d’exécution d’applications tels que Java, mais également des journaux des applications et des services cloud. Par exemple, les serveurs Web enregistrent généralement chaque demande avec des informations détaillées telles que l’horodatage, la latence de traitement, l’ID utilisateur, l’adresse IP distante, le chemin et la chaîne de requête. Le niveau de détail de ces journaux vous permet d’effectuer des requêtes détaillées et de générer des métriques qui n’auraient peut-être pas été disponibles autrement. Collectez les métriques et les journaux à l’aide d’outils et de processus appropriés. Les journaux générés par les applications exécutées sur une instance Amazon EC2 peuvent être collectés par un agent tel que l’[agent Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) et publiés dans un service de stockage central tel qu’[Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html). Les services de calcul gérés par AWS tels qu’[AWS Lambda](https://aws.amazon.com/lambda/) et [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) publient automatiquement les journaux dans CloudWatch Logs pour vous. Activez la collecte de journaux pour les services de stockage et de traitement AWS utilisés par vos charges de travail, tels qu’[Amazon CloudFront](https://aws.amazon.com/cloudfront/), [Amazon S3](https://aws.amazon.com/s3/), [Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/) et [Amazon API Gateway](https://aws.amazon.com/api-gateway/). Enrichissez vos données de télémétrie avec des *[dimensions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension)* qui peuvent vous aider à mieux identifier les modèles comportementaux et à isoler les problèmes corrélés à des groupes de composants associés. Une fois ces dimensions ajoutées, vous pouvez observer le comportement des composants de manière plus détaillée, détecter les défaillances corrélées et prendre les mesures correctives appropriées. La zone de disponibilité, l’ID d’instance EC2 et l’ID de pod ou de tâche de conteneur sont des exemples de dimensions utiles. Une fois que vous avez collecté les métriques et les journaux, vous pouvez rédiger des requêtes et générer des métriques agrégées à partir de ces éléments pour fournir des informations exploitables utiles sur les comportements normaux et anormaux. Par exemple, vous pouvez utiliser [Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) pour dériver des métriques personnalisées des journaux de vos applications, [Amazon CloudWatch Metrics Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html) pour interroger vos métriques à grande échelle, [Amazon CloudWatch Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) pour collecter, agréger et résumer les métriques et les journaux de vos applications et microservices conteneurisés, ou [Amazon CloudWatch Lambda Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights.html) si vous utilisez des fonctions AWS Lambda. Pour créer une métrique de taux d’erreur agrégé, vous pouvez incrémenter un compteur chaque fois qu’une réponse ou un message d’erreur est détecté dans les journaux de vos composants ou calculer la valeur agrégée d’une métrique de taux d’erreur existante. Vous pouvez utiliser ces données pour générer des histogrammes illustrant le *comportement de queue*, par exemple les demandes ou les processus les moins performants. Vous pouvez également analyser ces données en temps réel pour détecter des modèles anormaux à l’aide de solutions telles que la [détection des anomalies](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/LogsAnomalyDetection.html) de CloudWatch Logs. Il est possible de placer ces informations exploitables dans des tableaux de bord afin de les organiser en fonction de vos besoins et préférences. L’interrogation des journaux peut vous aider à comprendre comment des demandes spécifiques ont été traitées par les composants de votre charge de travail et à révéler les modèles de demandes ou tout autre contexte ayant un impact sur la résilience de votre charge de travail. Il peut être utile d’étudier et de préparer des requêtes à l’avance, en fonction de votre connaissance des comportements de vos applications et des autres composants, afin de pouvoir les utiliser plus facilement en cas de besoin. Par exemple, [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) vous permet de rechercher et d’analyser de façon interactive les données de vos journaux dans CloudWatch Logs. Vous pouvez également utiliser [Amazon Athena](https://aws.amazon.com/athena/) pour interroger les journaux provenant de plusieurs sources, y compris de [nombreux services AWS](https://docs.aws.amazon.com/athena/latest/ug/querying-aws-service-logs.html), à l’échelle du pétaoctet. Lorsque vous définissez une politique de conservation des journaux, tenez compte de la valeur des journaux d’historique. Les journaux d’historique peuvent aider à identifier les modèles d’utilisation et comportementaux à long terme, les régressions et les améliorations des performances de votre charge de travail. Les journaux définitivement supprimés ne peuvent pas être analysés ultérieurement. Toutefois, la valeur des journaux d’historique tend à diminuer sur de longues périodes. Choisissez une politique capable d’équilibrer vos besoins de manière appropriée et conforme à toutes les exigences légales ou contractuelles auxquelles vous pourriez être soumis. ### Étapes d’implémentation 1. Choisissez des mécanismes de collecte, de stockage, d’analyse et d’affichage de vos données d’observabilité. 1. Installez et configurez des collecteurs de métriques et de journaux sur les composants appropriés de votre charge de travail (par exemple, sur les instances Amazon EC2 et dans les [conteneurs sidecar](https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/)). Configurez ces collecteurs pour qu’ils redémarrent automatiquement s’ils s’arrêtent de façon inattendue. Activez la mise en mémoire tampon du disque ou de la mémoire pour les collecteurs afin que les échecs de publication temporaires n’aient pas d’impact sur vos applications ou n’entraînent aucune perte de données. 1. Activez la journalisation sur les services AWS que vous utilisez dans le cadre de vos charges de travail et transférez ces journaux au service de stockage que vous avez sélectionné si nécessaire. Reportez-vous au guide d’utilisateur ou au manuel du développeur des services respectifs pour obtenir des instructions détaillées. 1. Définissez les métriques opérationnelles pour vos charges de travail en fonction de vos données de télémétrie. Elles peuvent être basées sur des métriques directes émises par les composants de votre charge de travail, qui peuvent inclure des métriques liées aux KPI métier, ou sur les résultats de calculs agrégés tels que des sommes, des taux, des centiles ou des histogrammes. Calculez ces métriques à l’aide de votre analyseur de journaux et placez-les dans des tableaux de bord, de façon appropriée. 1. Préparez des requêtes de journaux appropriées pour analyser les composants de la charge de travail, les demandes ou le comportement des transactions selon les besoins. 1. Définissez et activez une politique de conservation des journaux pour les journaux de vos composants. Supprimez régulièrement les journaux lorsqu’ils sont plus anciens que la politique ne l’autorise. ## Ressources **Bonnes pratiques associées:** + [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) + [REL06-BP04 Automatiser les réponses (traitement et alarmes en temps réel)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_automate_response_monitor.html) + [REL06-BP05 Analyser les journaux](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_storage_analytics.html) + [REL06-BP06 Passer régulièrement en revue la portée et les métriques de surveillance](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_review_monitoring.html) + [REL06-BP07 Surveiller le suivi de bout en bout des demandes via votre système](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_end_to_end.html) **Documentation connexe :** + [Fonctionnement d’Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_architecture.html) + [Amazon Managed Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html) + [Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html) + [Analyse des données de journaux avec CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) + [Amazon CloudWatch Lambda Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights.html) + [Amazon CloudWatch Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) + [Interrogation de vos métriques avec CloudWatch Metrics Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html) + [AWS Distro pour Open Telemetry](https://aws.amazon.com/otel/) + [Exemples de requêtes pour Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html) + [Débogage avec Amazon CloudWatch Synthetics et AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) + [Recherche et filtrage des données de journaux](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) + [Envoi des journaux directement à Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html) + [Amazon Builders’ Library : Instrumentation des systèmes distribués au profit de la visibilité opérationnelle](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) **Ateliers connexes:** + [Un atelier sur l’observabilité](https://observability.workshop.aws/) **Outils associés :** + [AWS Distro for OpenTelemetry (GitHub)](https://aws-otel.github.io/) # REL06-BP03 Envoyer des notifications (traitement et alarmes en temps réel) Lorsque les organisations détectent des problèmes potentiels, elles envoient des notifications et des alertes en temps réel au personnel et aux systèmes appropriés afin de résoudre rapidement et efficacement ces problèmes. **Résultat escompté :** il est possible d’obtenir des réponses rapides aux événements opérationnels en configurant des alarmes pertinentes basées sur les métriques de service et d’application. Lorsque les seuils d’alarme sont dépassés, le personnel et les systèmes appropriés sont avertis afin de résoudre les problèmes sous-jacents. **Anti-modèles courants :** + Vous configurez les alarmes avec un seuil trop élevé, ce qui fait échouer l’envoi des notifications vitales. + Vous configurez les alarmes avec un seuil trop bas, ce qui empêche la prise en compte des alertes importantes à cause du bruit généré par un trop grand nombre de notifications. + Vous ne mettez pas à jour les alarmes et leur seuil en cas de changement d’utilisation. + Pour les alarmes qu’il est préférable de traiter par des actions automatisées, vous envoyez la notification au personnel au lieu de générer l’action automatisée, ce qui entraîne l’envoi d’un trop grand nombre de notifications. **Avantages du respect de cette bonne pratique :** en envoyant des notifications et des alertes en temps réel au personnel et aux systèmes appropriés, vous pouvez détecter rapidement les problèmes et réagir rapidement face aux incidents opérationnels. **Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé ## Directives d’implémentation Les charges de travail doivent être équipées d’un système de traitement et d’avertissement en temps réel afin d’améliorer la détectabilité des problèmes susceptibles d’affecter la disponibilité de l’application et de déclencher une réponse automatique. Les organisations peuvent procéder au traitement et à l’avertissement en temps réel en créant des alertes avec des métriques définies afin de recevoir des notifications chaque fois que des événements importants se produisent ou qu’une métrique dépasse un seuil. [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) vous permet de créer des alarmes [métriques](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) et composites à l’aide d’alarmes CloudWatch basées sur un seuil statique, la détection d’anomalies et d’autres critères. Pour plus de détails sur les types d’alarmes que vous pouvez configurer à l’aide de CloudWatch, consultez la [section sur les alarmes de la documentation de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html). Vous pouvez construire des vues personnalisées des métriques et des alertes de vos ressources AWS pour vos équipes en utilisant les [tableaux de bord CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). Les pages d’accueil personnalisables de la console CloudWatch vous permettent de surveiller vos ressources dans une vue unique sur plusieurs régions. Les alarmes peuvent effectuer une ou plusieurs actions, comme l’envoi d’une notification à un [sujet Amazon SNS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html), l’exécution d’une action [Amazon EC2](https://aws.amazon.com/ec2/) ou d’une action [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/), ou la [création d’un OpsItem](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) ou d’un [incident](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) dans AWS Systems Manager. Amazon CloudWatch utilise [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) pour envoyer des notifications lorsque l’alarme change d’état, ce qui permet de transmettre les messages des diffuseurs de publication (producteurs) aux abonnés (consommateurs). Pour plus de détails sur la configuration des notifications Amazon SNS, consultez [Configuration d’Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-configuring.html). CloudWatch envoie des [événements](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-and-eventbridge.html) à [EventBridge](https://aws.amazon.com/eventbridge/) chaque fois qu’une alerte CloudWatch est créée, mise à jour, supprimée ou change d’état. Vous pouvez utiliser EventBridge avec ces événements pour créer des règles qui exécutent des actions, comme vous avertir chaque fois que l’état d’une alarme change ou déclencher automatiquement des événements sur votre compte à l’aide de l’[automatisation Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html). Restez informé avec [AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/). AWS Health est la source d’informations faisant autorité sur l’état de vos ressources AWS Cloud. Utilisez AWS Health pour être informé de tout événement de service confirmé afin que vous puissiez rapidement prendre des mesures pour atténuer tout impact. Créez des notifications d’événements AWS Health 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). Si vous utilisez AWS Organizations, regroupez les événements AWS Health sur l’ensemble des comptes. ** Quand devriez-vous utiliser EventBridge ou Amazon SNS? ** EventBridge et Amazon SNS peuvent être utilisés pour développer des applications pilotées par des événements. Votre choix dépendra de vos besoins spécifiques. Amazon EventBridge est recommandé lorsque vous souhaitez créer une application qui réagit aux événements de vos propres applications, des applications SaaS et des services AWS. EventBridge est le seul service basé sur des événements qui s’intègre directement à des partenaires SaaS tiers. EventBridge ingère également automatiquement les événements provenant de plus de 200 services AWS sans que les développeurs n’aient à créer de ressources dans leur compte. EventBridge utilise une structure définie basée sur JSON pour les événements et vous aide à créer des règles qui s’appliquent à l’ensemble du corps de l’événement afin de sélectionner les événements à transférer vers une [cible](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html). EventBridge prend actuellement en charge plus de 20 services AWS en tant que cibles, notamment [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html), [Amazon SQS](https://aws.amazon.com/sqs/), Amazon SNS, [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) et [Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/). Amazon SNS est recommandé pour les applications qui nécessitent un niveau de diffusion élevé (des milliers, voire des millions de points de terminaison). Il est courant d’observer que les clients utilisent Amazon SNS comme cible pour leur règle afin de filtrer les événements dont ils ont besoin et de les diffuser sur plusieurs points de terminaison. Les messages ne sont pas structurés et peuvent être de n’importe quel format. Amazon SNS prend en charge le transfert de messages vers six types de cibles différents, notamment Lambda, Amazon SQS, les points de terminaison HTTP/S, les SMS, le push mobile et le courrier électronique. Amazon SNS possède une [latence typique inférieure à 30 millisecondes](https://aws.amazon.com/sns/faqs/). Un large éventail de services AWS envoie des messages Amazon SNS en configurant le service dans cet objectif (plus de 30, y compris Amazon EC2, [Amazon S3](https://aws.amazon.com/s3/) et [Amazon RDS](https://aws.amazon.com/rds/)). ### Étapes d’implémentation 1. Créez une alarme à l’aide des [alarmes Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html). 1. Une alarme de métrique surveille une seule métrique CloudWatch ou une expression qui dépend de métriques CloudWatch. L’alarme déclenche une ou plusieurs actions en fonction de la valeur de la métrique ou de l’expression par rapport à un seuil sur un certain nombre d’intervalles de temps. L’action peut être l’envoi d’une notification à un [sujet Amazon SNS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html), l’exécution d’une action [Amazon EC2](https://aws.amazon.com/ec2/) ou d’une action [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) ou la [création d’un OpsItem](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) ou d’un [incident](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) dans AWS Systems Manager. 1. Une alarme composite est une expression de règle qui prend en compte les conditions d’alarme des autres alarmes que vous avez créées. L’alarme composite ne passe en état d’alarme que si toutes les conditions de la règle sont satisfaites. Les alarmes spécifiées dans l’expression de règle d’une alarme composite peuvent inclure des alarmes de métrique et des alarmes composites supplémentaires. Les alertes composites peuvent envoyer des notifications Amazon SNS lorsqu’elles changent d’état et peuvent créer des [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) de Systems Manager ou des [incidents](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) lorsqu’elles passent à l’état d’alarme, mais ne peuvent pas effectuer d’actions Amazon EC2 ou Auto Scaling. 1. Configurer les [notifications Amazon SNS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html). Lorsque vous créez une alarme CloudWatch, vous pouvez inclure une rubrique Amazon SNS pour envoyer une notification lorsque l’alarme change d’état. 1. [Créez des règles dans EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html) qui correspondent aux alarmes CloudWatch spécifiées. Chaque règle prend en charge plusieurs cibles, y compris des fonctions Lambda. Par exemple, vous pouvez définir une alarme qui se déclenche lorsque l’espace disque disponible est insuffisant, ce qui déclenche une fonction Lambda par le biais d’une règle EventBridge permettant de libérer de l’espace. [Pour plus de détails sur les cibles EventBridge, consultez la section Cibles EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html). ## Ressources **Bonnes pratiques Well-Architected connexes:** + [REL06-BP01 Surveiller tous les composants de la charge de travail (génération)](rel_monitor_aws_resources_monitor_resources.md) + [REL06-BP02 Définir et calculer des métriques (agrégation)](rel_monitor_aws_resources_notification_aggregation.md) + [REL12-BP01 Utiliser des playbooks pour enquêter sur les causes des défaillances](rel_testing_resiliency_playbook_resiliency.md) **Documents connexes:** + [ Amazon CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) + [ Aperçu des journaux CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) + [Utilisation d’alarmes Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) + [Utilisation des tableaux de bord Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) + [Utilisation des métriques Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) + [ Configuration des notifications Amazon SNS ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html) + [ Détection des anomalies CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) + [ Protection des données CloudWatch Logs ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/protect-sensitive-log-data-types.html) + [ Amazon EventBridge ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) + [ Amazon Simple Notification Service ](https://aws.amazon.com/sns/) **Vidéos connexes:** + [ reinvent 2022 observability videos ](https://www.youtube.com/results?search_query=reinvent+2022+observability) + [AWS re:Invent 2022 - Observability best practices at Amazon ](https://www.youtube.com/watch?v=zZPzXEBW4P8) **Exemples connexes:** + [Un atelier sur l’observabilité](https://observability.workshop.aws/) + [ Amazon EventBridge to AWS Lambda with feedback control by Amazon CloudWatch Alarms ](https://serverlessland.com/patterns/cdk-closed-loop-serverless-control-pattern) # REL06-BP04 Automatiser les réponses (traitement et alarmes en temps réel) Utilisez l’automatisation pour agir en cas de détection d’événement, par exemple, pour remplacer les composants défectueux. Un traitement automatique en temps réel des alarmes est mis en œuvre afin que les systèmes puissent prendre rapidement des mesures correctives et tenter d’éviter les pannes ou une dégradation du service lorsque les alarmes se déclenchent. Les réponses automatisées aux alarmes peuvent inclure le remplacement des composants défaillants, l’ajustement de la capacité de calcul, la redirection du trafic vers des hôtes, des zones de disponibilité ou d’autres régions en bonne santé, et la notification des opérateurs. **Résultat escompté :** les alarmes en temps réel sont identifiées et le traitement automatique des alarmes est configuré pour invoquer les actions appropriées prises afin de maintenir les objectifs de niveau de service et les contrats de niveau de service (SLA). L’automatisation peut aller de l’autoréparation de composants individuels au basculement complet du site. **Anti-modèles courants :** + Pas d’inventaire ou de catalogue clair des principales alarmes en temps réel. + Aucune réponse automatique aux alarmes critiques (par exemple, lorsque la capacité de calcul est presque épuisée, une mise à l’échelle automatique se produit). + Réponses aux alarmes contradictoires. + Pas de procédure opérationnelle standard (SOP) que les opérateurs doivent suivre lorsqu’ils reçoivent des notifications d’alerte. + Pas de surveillance des modifications de configuration, alors que des changements de configuration non détectés peuvent entraîner des temps d’arrêt pour les charges de travail. + Pas de stratégie pour annuler les modifications de configuration involontaires. **Avantages du respect de cette bonne pratique :** l’automatisation du traitement des alarmes peut améliorer la résilience du système. Le système prend automatiquement des mesures correctives, réduisant ainsi les activités manuelles qui nécessitent des interventions humaines sujettes aux erreurs. L’exécution de la charge de travail permet d’atteindre les objectifs de disponibilité et de réduire les interruptions de service. **Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen ## Directives d’implémentation Pour gérer efficacement les alertes et automatiser leur réponse, classez les alertes en fonction de leur criticité et de leur impact, documentez les procédures de réponse et planifiez les réponses avant de classer les tâches. Identifiez les tâches nécessitant des actions spécifiques (souvent détaillées dans les runbooks) et examinez tous les runbooks et playbooks pour déterminer les tâches qui peuvent être automatisées. Si les actions peuvent être définies, alors elles sont souvent automatisables. Si elles ne le sont pas, documentez les étapes manuelles dans une SOP et formez les opérateurs à ces étapes. Remettez continuellement en question les processus manuels pour trouver des opportunités d’automatisation où vous pouvez établir et maintenir un plan d’automatisation des réponses aux alertes. ### Étapes d’implémentation 1. **Créez un inventaire des alarmes :** pour obtenir une liste de toutes les alarmes, vous pouvez utiliser la [AWS CLI](https://aws.amazon.com/cli/) utilisant la commande [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) `[describe-alarms](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/describe-alarms.html)`. Selon le nombre d’alarmes que vous avez configurées, vous devrez peut-être utiliser la pagination pour récupérer un sous-ensemble d’alarmes pour chaque appel, ou bien vous pouvez utiliser l’AWS SDK pour obtenir les alarmes [à l’aide d’un appel d’API](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-describing-alarms.html). 1. **Documentez toutes les actions d’alarme :** mettez à jour un runbook avec toutes les alarmes et leurs actions, qu’elles soient manuelles ou automatisées. [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/APIReference/Welcome.html) fournit des runbooks prédéfinis. Pour plus d’informations sur les runbooks, consultez [Travailler avec des runbooks](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html). Pour plus de détails sur la façon d’afficher le contenu du runbook, consultez [Afficher le contenu du runbook](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-runbook-reference.html#view-automation-json). 1. **Configurez et gérez les actions d’alarme :** pour toutes les alarmes nécessitant une action, spécifiez l’[action automatisée à l’aide de CloudWatch SDK](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-using-alarm-actions.html). Par exemple, vous pouvez modifier automatiquement l’état de vos instances Amazon EC2 basées sur une alarme CloudWatch en créant des actions sur l’alarme et en les activant ou désactivant. Vous pouvez également utiliser [Amazon EventBridge](https://aws.amazon.com/eventbridge/) pour automatiser vos événements système, tels que des problèmes de disponibilité d’application ou des modifications de ressources. Vous pouvez créer des règles pour indiquer quels événements vous intéressent et les actions à effectuer quand un événement correspond à une règle. [Les actions qui peuvent être initiées automatiquement incluent l’appel d’une fonction [AWS Lambda](https://aws.amazon.com/lambda/), l’invocation d’[Amazon EC2](https://aws.amazon.com/ec2/)`Run Command`, le transfert de l’événement à [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) et la visualisation d’Automate Amazon EC2 à l’aide d’EventBridge](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/automating_with_eventbridge.html). 1. **Procédures opérationnelles standard (SOP) :** en fonction des composants de votre application, [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) recommande plusieurs [modèles de SOP](https://docs.aws.amazon.com/resilience-hub/latest/userguide/sops.html). Vous pouvez utiliser ces SOP pour documenter tous les processus qu’un opérateur doit suivre en cas d’alerte. Vous pouvez également [construire une SOP](https://docs.aws.amazon.com/resilience-hub/latest/userguide/building-sops.html) basée sur les recommandations du Resilience Hub, où vous avez besoin d’une application Resilience Hub associée à une politique de résilience, ainsi que d’une évaluation historique de la résilience par rapport à cette application. Les recommandations de SOP sont générées par l’évaluation de la résilience. Resilience Hub travaille avec Systems Manager pour automatiser les étapes de vos SOP en fournissant un certain nombre de [documents SSM](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-custom-ssm-doc.html) que vous pouvez utiliser comme base pour ces SOP. Par exemple, Resilience Hub peut recommander une procédure SOP pour ajouter de l’espace disque sur la base d’un document d’automatisation SSM existant. 1. **Effectuer des action automatisées à l’aide d’Amazon DevOps Guru :** vous pouvez utiliser [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) pour surveiller automatiquement les ressources d’applications pour détecter les comportements anormaux et fournir des recommandations ciblées afin d’accélérer l’identification des problèmes et de réduire les temps de remédiation. Avec DevOps Guru, vous pouvez surveiller les flux de données opérationnelles en temps quasi réel à partir de plusieurs sources, notamment les métriques Amazon CloudWatch, [AWS Config](https://aws.amazon.com/config/), [AWS CloudFormation](https://aws.amazon.com/cloudformation/) et [AWS X-Ray](https://aws.amazon.com/xray/). Vous pouvez également utiliser DevOps Guru pour créer automatiquement des [OpsiTems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) dans OpsCenter et envoyer des événements à [EventBridge pour une automatisation supplémentaire](https://docs.aws.amazon.com/devops-guru/latest/userguide/working-with-eventbridge.html). ## Ressources **Bonnes pratiques associées:** + [REL06-BP01 Surveiller tous les composants de la charge de travail (génération)](rel_monitor_aws_resources_monitor_resources.md) + [REL06-BP02 Définir et calculer des métriques (agrégation)](rel_monitor_aws_resources_notification_aggregation.md) + [REL06-BP03 Envoyer des notifications (traitement et alarmes en temps réel)](rel_monitor_aws_resources_notification_monitor.md) + [REL08-BP01 Utiliser des runbooks pour les activités standard telles que le déploiement](rel_tracking_change_management_planned_changemgmt.md) **Documents connexes :** + [Automatisation AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) + [Création d’une règle EventBridge qui se déclenche en cas d’événement provenant d’une ressource AWS](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html) + [Un atelier sur l’observabilité](https://observability.workshop.aws/) + [Amazon Builders’ Library : Instrumentation des systèmes distribués au profit de la visibilité opérationnelle](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) + [Qu’est-ce qu’Amazon DevOps Guru ?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) + [Utilisation des documents d’automatisation (playbooks)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) **Vidéos connexes :** + [AWS re:Invent 2022 - Observability best practices at Amazon ](https://www.youtube.com/watch?v=zZPzXEBW4P8) + [AWS re:Invent 2020: Automate anything with AWS Systems Manager](https://www.youtube.com/watch?v=AaI2xkW85yE) + [ Introduction à AWS Resilience Hub](https://www.youtube.com/watch?v=_OTTCOjWqPo) + [ Créez des systèmes de tickets personnalisés pour les notifications Amazon DevOps Guru ](https://www.youtube.com/watch?v=Mu8IqWVGUfg) + [ Activez l’agrégation d’informations sur plusieurs comptes avec Amazon DevOps Guru ](https://www.youtube.com/watch?v=MHezNcTSTbI) **Exemples connexes:** + [ Atelier Amazon CloudWatch et Systems Manager ](https://catalog.us-east-1.prod.workshops.aws/workshops/a8e9c6a6-0ba9-48a7-a90d-378a440ab8ba/en-US) # REL06-BP05 Analyser les journaux Collectez les fichiers journaux et les historiques de métriques, puis analysez-les pour obtenir des informations plus générales sur les tendances et la charge de travail. Amazon CloudWatch Logs Insights prend en charge un [langage de requête simple et puissant](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html) que vous pouvez utiliser pour analyser les données des journaux. Amazon CloudWatch Logs prend également en charge les abonnements qui permettent aux données de circuler en toute transparence vers Amazon S3 où vous pouvez utiliser Amazon Athena pour interroger les données. Il prend également en charge les requêtes dans une grande variétés de formats. Pour plus d’informations, consultez [Formats de données et SerDes pris en charge](https://docs.aws.amazon.com/athena/latest/ug/supported-format.html) dans le Guide de l’utilisateur Amazon Athena. Pour analyser des ensembles de fichiers journaux volumineux, vous pouvez exécuter un cluster Amazon EMR pour exécuter des analyses à l’échelle du pétaoctet. Il existe divers outils fournis par les partenaires AWS et les tiers qui permettent l’agrégation, le traitement, le stockage et l’analyse. Parmi ces outils figurent New Relic, Splunk, Loggly, Logstash, CloudHealth et Nagios. Cependant, la génération en dehors du système et des journaux d’applications est propre à chaque fournisseur de cloud, et généralement, spécifique à chaque service. Un partie souvent négligée de la surveillance des processus concerne la gestion des données. Vous devez déterminer les exigences de rétention des données de surveillance, puis appliquer des stratégies de cycle de vie en conséquence. Amazon S3 prend en charge la gestion du cycle de vie au niveau du compartiment S3. Cette gestion du cycle de vie peut être appliquée différemment à d’autres chemins dans le compartiment. Vers la fin du cycle de vie, vous pouvez transférer des données dans Amazon Glacier pour un stockage à long terme, puis les laisser expirer à la fin de la période de conservation. La classe de stockage S3 Intelligent-Tiering est conçue pour optimiser les coûts en transférant automatiquement les données vers le niveau d’accès le plus économique, sans impact sur les performances ni surcharge opérationnelle. **Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen ## Directives d’implémentation + CloudWatch Logs Insights vous permet de rechercher et d’analyser de façon interactive les données de vos journaux dans Amazon CloudWatch Logs. + [Analyse des données de journaux avec CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html) + [Exemples de requêtes pour Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) + Utilisez Amazon CloudWatch Logs pour envoyer des journaux vers Amazon S3 où vous pouvez les utiliser ou utiliser Amazon Athena pour interroger les données. + [Comment analyser les journaux d’accès au serveur Amazon S3 à l’aide d’Athena ?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/) + Créez une stratégie de cycle de vie S3 pour votre compartiment de journaux d’accès au serveur. Configurez la stratégie de cycle de vie pour supprimer périodiquement les fichiers journaux. Cela permet de réduire la quantité de données analysées par Athena pour chaque requête. + [Comment créer la stratégie de cycle de vie d’un compartiment S3 ?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html) ## Ressources **Documents connexes :** + [Exemples de requêtes pour Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html) + [Analyse des données de journaux avec CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html) + [Débogage avec Amazon CloudWatch Synthetics et AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) + [Comment créer la stratégie de cycle de vie d’un compartiment S3 ?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html) + [Comment analyser les journaux d’accès au serveur Amazon S3 à l’aide d’Athena ?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/) + [Un atelier sur l’observabilité](https://observability.workshop.aws/) + [Amazon Builders’ Library : Instrumentation des systèmes distribués au profit de la visibilité opérationnelle](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) # REL06-BP06 Passer régulièrement en revue la portée et les métriques de surveillance Passez fréquemment en revue la manière dont la surveillance de la charge de travail est mise en œuvre et mettez-la à jour au fur et à mesure que votre charge de travail et son architecture évoluent. Des audits réguliers de votre surveillance permettent de réduire le risque de négliger ou d’omettre des indicateurs de panne et contribuent à aider votre charge de travail à atteindre ses objectifs de disponibilité. Un suivi efficace s’appuie sur des métriques métier clés, qui évoluent en fonction des priorités de votre entreprise. Votre processus d’examen de la surveillance doit mettre l’accent sur les indicateurs de niveau de service (SLI) et incorporer des informations exploitables provenant de votre infrastructure, de vos applications, de vos clients et de vos utilisateurs. **Résultat escompté :** vous disposez d’une stratégie de surveillance efficace qui est régulièrement revue et mise à jour, ainsi qu’après tout événement ou changement important. Vous vérifiez que les indicateurs d’intégrité clés des applications restent pertinents au fur et à mesure de l’évolution de votre charge de travail et de vos exigences professionnelles. **Anti-modèles courants :** + Vous collectez uniquement les métriques par défaut. + Vous configurez une stratégie de surveillance, mais vous ne la passez jamais en revue. + Vous ne remettez pas en question la surveillance lorsque des modifications majeures sont déployées. + Vous vous fiez à des métriques obsolètes pour déterminer l’état de la charge de travail. + Vos équipes d’exploitation sont submergées d’alertes faussement positives en raison de métriques et de seuils obsolètes. + Vous ne bénéficiez pas de l’observabilité des composants d’application qui ne sont pas surveillés. + Vous vous concentrez uniquement sur des métriques techniques de bas niveau et excluez les métriques métier de votre surveillance. **Avantages liés au respect de cette bonne pratique :** lorsque vous passez régulièrement en revue votre surveillance, vous pouvez anticiper les problèmes potentiels et vérifier que vous êtes capable de les détecter. Cela vous permet également de découvrir des zones d’ombre que vous auriez pu manquer lors d’examens antérieurs, ce qui améliore encore votre capacité à détecter les problèmes. **Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen ## Directives d’implémentation Passez en revue les métriques et la portée de la surveillance au cours de votre processus d’[examen de l’état de préparation opérationnelle (ORR)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html). Effectuez des examens périodiques de l’état de préparation opérationnelle selon un calendrier cohérent afin d’évaluer s’il existe des écarts entre votre charge de travail actuelle et la surveillance que vous avez configurée. Établissez une fréquence régulière d’examen des performances opérationnelles et de partage des connaissances afin d’améliorer votre capacité à obtenir de meilleures performances de la part de vos équipes d’exploitation. Confirmez ou non que les seuils d’alerte existants sont toujours adéquats et vérifiez les situations dans lesquelles les équipes d’exploitation reçoivent des alertes faussement positives ou ne surveillent pas les aspects de l’application qui devraient être surveillés. Le [cadre d’analyse de résilience](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/introduction.html) fournit des conseils utiles qui peuvent vous aider à naviguer dans le processus. L’objectif de ce cadre est d’identifier les modes de défaillance potentiels et les contrôles préventifs et correctifs que vous pouvez utiliser pour atténuer leur impact. Ces connaissances peuvent vous aider à identifier les métriques et les événements appropriés à surveiller pour émettre des alertes. ### Étapes d’implémentation 1. Planifiez et effectuez des vérifications régulières des tableaux de bord de charge de travail. Vous pouvez avoir des cadences différentes selon la profondeur à laquelle vous inspectez. 1. Inspectez les tendances dans les métriques. Comparez les valeurs des métriques aux valeurs historiques pour voir si des tendances peuvent indiquer que quelque chose doit faire l’objet d’une enquête. Cela peut être une augmentation de la latence, une diminution de la fonction principale de l’entreprise ou une augmentation des réponses aux échecs. 1. Recherchez des valeurs aberrantes et des anomalies dans vos métriques, qui peuvent être masquées par des moyennes ou des médianes. Observez les maximales et les minimales sur une période donnée et étudiez les causes des observations qui figurent loin des normales attendues. Au fur et à mesure que vous éliminez ces causes, vous pouvez resserrer les limites des métriques attendues en réponse à l’amélioration de la cohérence des performances de votre charge de travail. 1. Recherchez des changements importants de comportement. Un changement immédiat de quantité ou de direction d’une métrique peut indiquer une modification de l’application ou des facteurs externes, dont le suivi peut nécessiter l’ajout de métriques supplémentaires. 1. Vérifiez si la stratégie de surveillance actuelle reste pertinente pour l’application. Sur la base d’une analyse des incidents précédents (ou du cadre d’analyse de résilience), déterminez si d’autres aspects de l’application devraient être incorporés dans la portée de la surveillance. 1. Passez en revue vos métriques de surveillance des utilisateurs réels (RUM) pour déterminer s’il existe des lacunes dans la couverture des fonctionnalités de l’application. 1. Passez en revue votre processus de gestion des modifications. Mettez à jour vos procédures, si nécessaire, pour inclure une étape d’analyse de surveillance à effectuer avant d’approuver une modification. 1. Mettez en œuvre un examen de surveillance dans le cadre de votre examen de l’état de préparation opérationnelle et de vos processus de correction des erreurs. ## Ressources **Bonnes pratiques associées** + [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-BP02 Définir et calculer des métriques (agrégation)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_notification_aggregation.html) + [REL06-BP07 Surveiller le suivi de bout en bout des demandes via votre système](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_end_to_end.html) + [REL12-BP02 Effectuer une analyse post-incident](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_rca_resiliency.html) + [REL12-BP06 Organiser régulièrement des tests de simulation de panne](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_game_days_resiliency.html) **Documents connexes :** + [Pourquoi mettre en place la correction des erreurs (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/) + [Utilisation des tableaux de bord Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) + [Création de tableaux de bord pour une visibilité opérationnelle](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/?did=ba_card&trk=ba_card) + [Modèles de résilience multi-AZ avancés – Défaillances grises](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) + [Exemples de requêtes pour Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html) + [Débogage avec Amazon CloudWatch Synthetics et AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) + [Un atelier sur l’observabilité](https://observability.workshop.aws/) + [Amazon Builders’ Library : Instrumentation des systèmes distribués au profit de la visibilité opérationnelle](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) + [Utilisation des tableaux de bord Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) + [AWS Bonnes pratiques en matière d’observabilité](https://aws-observability.github.io/observability-best-practices/) + [Cadre d’analyse de résilience](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/introduction.html) + [Cadre d’analyse de résilience – Observabilité](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/observability.html) + [Examen de l’état de préparation opérationnelle – ORR](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) # REL06-BP07 Surveiller la traçabilité complète des demandes via votre système Suivez les demandes au fur et à mesure qu’elles sont traitées dans les composants du service afin que les équipes produits puissent plus facilement analyser et résoudre les problèmes et améliorer les performances. **Résultat escompté :** les charges de travail dotées d’un suivi complet de tous les composants sont faciles à déboguer, ce qui améliore le [temps moyen de résolution](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html) (MTTR) des erreurs et la latence en simplifiant la découverte des causes principales. Le traçage de bout en bout réduit le temps nécessaire à la découverte des composants concernés et à l’analyse détaillée des causes profondes des erreurs ou de la latence. **Anti-modèles courants :** + Le traçage est utilisé pour certains composants, mais pas pour tous. Par exemple, sans traçage pour AWS Lambda, les équipes risquent de ne pas comprendre clairement la latence provoquée par les démarrages à froid dans le cadre d’une charge de travail irrégulière. + Les canarys synthétiques ou la surveillance des utilisateurs réels (RUM) ne sont pas configurés avec le traçage. Sans canarys ni RUM, la télémétrie des interactions avec le client est omise de l’analyse des traces, ce qui donne un profil de performance incomplet. + Les charges de travail hybrides incluent à la fois des outils de suivi natifs du cloud et des outils tiers, mais aucune mesure n’a été prise pour intégrer pleinement une solution de traçage unique. En fonction de la solution de traçage sélectionnée, les kits SDK de traçage natifs du cloud doivent être utilisés pour instrumenter des composants qui ne sont pas natifs du cloud ou des outils tiers doivent être configurés pour ingérer la télémétrie de suivi native du cloud. **Avantages liés au respect de cette bonne pratique :** lorsque les équipes de développement sont alertées de problèmes, elles peuvent obtenir une image complète des interactions entre les composants du système, y compris la corrélation composant par composant avec la journalisation, les performances et les défaillances. Dans la mesure où le traçage permet d’identifier visuellement les causes profondes, vous passez moins de temps à les étudier. Les équipes qui comprennent en détail les interactions entre les composants prennent de meilleures décisions plus rapidement lors de la résolution des problèmes. L’analyse des traces des systèmes permet d’améliorer la prise de décisions, par exemple quand il convient de recourir à la reprise après sinistre (DR) ou de choisir le meilleur endroit pour mettre en œuvre des stratégies d’autoréparation, ce qui permet d’améliorer la satisfaction des clients envers vos services. **Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen ## Directives d’implémentation Les équipes qui exploitent des applications distribuées peuvent utiliser des outils de traçage pour établir un identifiant de corrélation, collecter des traces de demandes et créer des cartes de service pour les composants connectés. Tous les composants de l’application doivent être inclus dans les traces des demandes, notamment les clients de service, les passerelles d’intergiciels et les bus d’événements, les composants de calcul et le stockage, y compris les magasins de clés-valeurs et les bases de données. Incluez des canarys synthétiques et une surveillance des utilisateurs réels dans votre configuration de traçage de bout en bout pour mesurer les interactions avec les clients distants et la latence afin d’évaluer avec précision les performances de vos systèmes par rapport à vos contrats et objectifs de niveau de service. Vous pouvez utiliser [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) et les services d’instrumentation [Amazon CloudWatch Application Monitoring](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html) pour fournir une vue complète des demandes au fur et à mesure qu’elles transitent par votre application. X-Ray collecte la télémétrie des applications et vous permet de la visualiser et de la filtrer en fonction des charges utiles, des fonctions, des traces, des services, des API, et peut être activée pour les composants du système sans code ou à faible code. La surveillance des applications CloudWatch inclut ServiceLens pour intégrer vos traces aux métriques, aux journaux et aux alarmes. La surveillance des applications CloudWatch inclut également des outils synthétiques pour surveiller vos points de terminaison et vos API, ainsi que la surveillance des utilisateurs réels pour instrumenter vos clients d’applications Web. ## Étapes d’implémentation + Utilisez AWS X-Ray sur tous les services natifs pris en charge tels qu’[Amazon S3, AWS Lambda et Amazon API Gateway](https://docs.aws.amazon.com/xray/latest/devguide/xray-services.html). Ces services AWS permettent l’utilisation de X-Ray grâce à des options de configuration utilisant l’infrastructure sous forme de code, de kits AWS SDK ou de la AWS Management Console. + Applications instrumentales [AWS Distro pour Open Telemetry et X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-adot.html) ou agents de collecte tiers. + Consultez le [Guide du développeur AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) pour une implémentation spécifique au langage de programmation. Ces sections de la documentation expliquent comment instrumenter les requêtes HTTP, les requêtes SQL et d’autres processus spécifiques à votre langage de programmation d’application. + Utilisez le suivi X-Ray pour les [canarys Amazon CloudWatch Synthetic](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) et [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) afin d’analyser le chemin des demandes depuis votre client utilisateur final via votre infrastructure AWS en aval. + Configurez les métriques et les alarmes CloudWatch en fonction de l’intégrité des ressources et de la télémétrie canary afin que les équipes soient rapidement alertées des problèmes, puis qu’elles puissent analyser en profondeur les traces et les cartographies de services avec ServiceLens. + Activez l’intégration de X-Ray pour les outils de suivi tiers tels que [Datadog](https://docs.datadoghq.com/tracing/guide/serverless_enable_aws_xray/), [New Relic](https://docs.newrelic.com/docs/infrastructure/amazon-integrations/aws-integrations-list/aws-x-ray-monitoring-integration/) ou [Dynatrace](https://www.dynatrace.com/support/help/setup-and-configuration/setup-on-cloud-platforms/amazon-web-services/amazon-web-services-integrations/aws-service-metrics) si vous utilisez des outils tiers pour votre solution de suivi principale. ## Ressources **Bonnes pratiques associées:** + [REL06-BP01 Surveiller tous les composants de la charge de travail (génération)](rel_monitor_aws_resources_monitor_resources.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:** + [Qu’est-ce qu AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) + [ Amazon CloudWatch : surveillance des applications ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html) + [Débogage avec Amazon CloudWatch Synthetics et AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) + [Amazon Builders’ Library : Instrumentation des systèmes distribués au profit de la visibilité opérationnelle](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) + [ Intégration de AWS X-Ray avec d’autres services AWS](https://docs.aws.amazon.com/xray/latest/devguide/xray-services.html) + [AWS Distro for OpenTelemetry et AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-adot.html) + [ Amazon CloudWatch : utilisation de la surveillance synthétique ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) + [ Amazon CloudWatch : utilisation de CloudWatch RUM ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) + [ Configurer Amazon CloudWatch Synthetics Canary et Amazon CloudWatch Alarm ](https://docs.aws.amazon.com/solutions/latest/devops-monitoring-dashboard-on-aws/set-up-amazon-cloudwatch-synthetics-canary-and-amazon-cloudwatch-alarm.html) + [ Disponibilité et plus encore : comprendre et améliorer la résilience des systèmes distribués sur AWS](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html) **Exemples connexes :** + [Un atelier sur l’observabilité](https://catalog.workshops.aws/observability/en-US) **Vidéos connexes :** + [AWS re:Invent 2022 - How to monitor applications across multiple accounts ](https://www.youtube.com/watch?v=kFGOkywu-rw) + [ How to Monitor your AWS Applications ](https://www.youtube.com/watch?v=UxWU9mrSbmA) **Outils associés :** + [AWS X-Ray](https://aws.amazon.com/xray/) + [ Amazon CloudWatch ](https://aws.amazon.com/pm/cloudwatch/) + [Amazon Route 53](https://aws.amazon.com/route53/) # FIA 7. Comment concevoir votre charge de travail pour qu’elle s’adapte à l’évolution de la demande ? Une charge de travail évolutive permet d’ajouter ou de supprimer automatiquement des ressources de manière à ce qu’elles correspondent à la demande actuelle à un moment donné. **Topics** + [REL07-BP01 Utiliser l’automatisation lors de l’obtention des ressources ou de leur mise à l’échelle](rel_adapt_to_changes_autoscale_adapt.md) + [REL07-BP02 Obtenir des ressources après la détection d’un problème sur une charge de travail](rel_adapt_to_changes_reactive_adapt_auto.md) + [REL07-BP03 Obtenir des ressources après avoir réalisé qu’un plus grand nombre de ressources est nécessaire pour une charge de travail](rel_adapt_to_changes_proactive_adapt_auto.md) + [REL07-BP04 Testez votre charge de travail](rel_adapt_to_changes_load_tested_adapt.md) # REL07-BP01 Utiliser l’automatisation lors de l’obtention des ressources ou de leur mise à l’échelle La définition programmatique, le provisionnement et la gestion de votre infrastructure et de vos ressources constituent la pierre angulaire de la fiabilité dans le cloud. L’automatisation vous aide à rationaliser le provisionnement des ressources, à faciliter des déploiements cohérents et sécurisés et à mettre à l’échelle les ressources sur l’ensemble de votre infrastructure. **Résultat escompté** : vous gérez votre infrastructure en tant que code (IaC). Vous définissez et gérez votre code d’infrastructure dans des systèmes de contrôle de version (VCS). Vous déléguez le provisionnement des ressources AWS à des mécanismes automatisés et vous tirez parti de services gérés tels qu’Application Load Balancer (ALB), Network Load Balancer (NLB) et des groupes Auto Scaling. Vous provisionnez vos ressources à l’aide de pipelines d’intégration continue et livraison continue (CI/CD) afin que les modifications du code déclenchent automatiquement des mises à jour des ressources, y compris des mises à jour de vos configurations Auto Scaling. **Anti-modèles courants :** + Vous déployez des ressources manuellement via la ligne de commande ou dans la AWS Management Console (processus également appelé *ClickOps*). + Vous associez étroitement vos ressources et composants d’application et vous créez ainsi des architectures rigides. + Vous mettez en œuvre des politiques de mise à l’échelle rigides qui ne s’adaptent pas à l’évolution des exigences commerciales, des modèles de trafic ou des nouveaux types de ressources. + Vous estimez manuellement la capacité pour répondre de façon anticipée à la demande. **Avantages liés au respect de cette bonne pratique** : l’infrastructure en tant que code (IaC) permet de définir programmatiquement l’infrastructure. Vous pouvez ainsi gérer les modifications d’infrastructure en suivant le même cycle de développement logiciel que pour des modifications d’application, ce qui favorise la cohérence et la reproductibilité et réduit le risque de tâches manuelles susceptibles d’engendrer des erreurs. Vous pouvez rationaliser davantage le processus de provisionnement et de mise à jour des ressources en implémentant l’infrastructure en tant que code avec des pipelines de livraison automatisés. Vous pouvez déployer des mises à jour d’infrastructure de manière fiable et efficace sans nécessiter d’intervention manuelle. Cette agilité est particulièrement importante lorsque vous mettez à l’échelle les ressources pour répondre à des demandes fluctuantes. Vous pouvez obtenir une mise à l’échelle dynamique et automatisée des ressources en conjonction avec l’infrastructure en tant que code et les pipelines de livraison. En surveillant les métriques clés et en appliquant des politiques de mise à l’échelle prédéfinies, Auto Scaling peut automatiquement provisionner ou déprovisionner les ressources selon les besoins, ce qui améliore les performances et la rentabilité. Cela réduit le risque d’erreurs manuelles ou de retards en réponse aux modifications des exigences en matière d’application ou de charge de travail. La combinaison de l’infrastructure en tant que code, des pipelines de livraison automatisés et d’Auto Scaling aide les organisations à provisionner, mettre à jour et mettre à l’échelle leurs environnements en toute confiance. Cette automatisation est essentielle pour maintenir une infrastructure cloud réactive, résiliente et gérée efficacement. **Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé ## Directives d’implémentation Pour configurer l’automatisation avec des pipelines CI/CD et une infrastructure en tant que code (IaC) pour votre architecture AWS, choisissez un système de contrôle de version tel que Git pour stocker vos modèles et votre configuration IaC. Ces modèles peuvent être écrits à l’aide d’outils tels qu’[AWS CloudFormation](https://aws.amazon.com/cloudformation/). Pour commencer, définissez les composants de votre infrastructure (tels que les VPC AWS, les groupes Amazon EC2 Auto Scaling et les bases de données Amazon RDS) dans ces modèles. Ensuite, intégrez ces modèles d’infrastructure en tant que code à un pipeline CI/CD pour automatiser le processus de déploiement. [AWS CodePipeline](https://aws.amazon.com/codepipeline/) fournit une solution AWS native transparente, ou vous pouvez utiliser d’autres solutions CI/CD tierces. Créez un pipeline qui s’active lorsque des modifications surviennent dans votre référentiel de contrôle de version. Configurez le pipeline de manière à inclure des étapes qui vérifient et valident vos modèles d’infrastructure en tant que code, déploient l’infrastructure dans un environnement intermédiaire, exécutent des tests automatisés et déploient finalement la solution en production. Incorporez des étapes d’approbation si nécessaire pour garder le contrôle sur les modifications. Ce pipeline automatisé accélère le déploiement, mais favorise également la cohérence et la fiabilité entre les environnements. Configurez la mise à l’échelle automatique de ressources telles que les instances Amazon EC2, les tâches Amazon ECS et les réplicas de base de données dans votre infrastructure en tant que code afin d’assurer l’augmentation horizontale et la réduction horizontale automatiques selon les besoins. Cette approche améliore la disponibilité et les performances des applications et optimise les coûts en ajustant dynamiquement les ressources en fonction de la demande. Pour obtenir la liste des ressources prises en charge, consultez [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) et [AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html). ### Étapes d’implémentation 1. Créez et utilisez un référentiel de code source pour stocker le code qui contrôle la configuration de votre infrastructure. Validez les modifications apportées à ce référentiel afin de refléter les modifications continues que vous souhaitez apporter. 1. Sélectionnez une solution d’infrastructure en tant que code, telle qu’AWS CloudFormation pour maintenir à jour votre infrastructure et détecter les incohérences (dérive) par rapport à l’état prévu. 1. Intégrez votre plateforme IaC à votre pipeline CI/CD pour automatiser les déploiements. 1. Déterminez et collectez les métriques appropriées pour la mise à l’échelle automatique des ressources. 1. Configurez la mise à l’échelle automatique des ressources à l’aide de politiques d’augmentation horizontale et de réduction horizontale pour vos composants de charge de travail. Envisagez d’utiliser une mise à l’échelle planifiée pour les modèles d’utilisation prévisibles. 1. Surveillez les déploiements pour détecter les défaillances et les régressions. Mettez en œuvre des mécanismes de restauration au sein de votre plateforme CI/CD pour annuler les modifications si nécessaire. ## Ressources **Documents connexes :** + [AWS Auto Scaling: Fonctionnement des plans de dimensionnement](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) + [AWS Marketplace: produits utilisables avec autoscaling](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling) + [Gestion automatique de la capacité de débit avec l’autoscaling de DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) + [Utiliser un équilibreur de charge avec un groupe Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) + [Qu’est-ce qu’AWS Global Accelerator ?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) + [Qu’est-ce qu’Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) + [Qu’est-ce qu AWS Auto Scaling?](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html) + [Qu’est-ce qu’Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html?ref=wellarchitected) + [Qu’est-ce qu’Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) + [Qu’est-ce qu’Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) + [Qu’est-ce qu’un équilibreur de charge Network Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) + [Qu’est-ce qu’un équilibreur de charge Application Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) + [Intégration de Jenkins avec AWS CodeBuild et AWS CodeDeploy](https://aws.amazon.com/blogs/devops/setting-up-a-ci-cd-pipeline-by-integrating-jenkins-with-aws-codebuild-and-aws-codedeploy/) + [Création d’un pipeline à quatre étapes avec AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials-four-stage-pipeline.html) **Vidéos connexes :** + [Back to Basics : Déployer votre code sur Amazon EC2](https://www.youtube.com/watch?v=f2wvEQ_sWS8) + [AWS Supports You \$1 Démarrer votre solution d’infrastructure en tant que code en utilisant les modèles AWS CloudFormation](https://www.youtube.com/watch?v=bgfx76jr7tA) + [Rationaliser votre processus de publication de logiciel en utilisant AWS CodePipeline](https://www.youtube.com/watch?v=zMa5gTLrzmQ) + [Surveiller les ressources AWS à l’aide des tableaux de bord Amazon CloudWatch](https://www.youtube.com/watch?v=I7EFLChc07M) + [Créer des tableaux de bord CloudWatch inter-comptes et inter-régions \$1 Amazon Web Services](https://www.youtube.com/watch?v=eIUZdaqColg) # REL07-BP02 Obtenir des ressources après la détection d’un problème sur une charge de travail Si la disponibilité est affectée, mettez à l’échelle les ressources de manière réactive si nécessaire, afin de restaurer la disponibilité de la charge de travail. Vous devez commencer par configurer les surveillances de l’état et les critères de ces vérifications pour indiquer quand la disponibilité est affectée par le manque de ressources. Informez ensuite le personnel approprié qu’il doit mettre à l’échelle manuellement la ressource ou lancer l’automatisation pour procéder à une mise à l’échelle automatique. La mise à l’échelle peut être ajustée manuellement en fonction de votre charge de travail. Par exemple, vous pouvez modifier le nombre d’instances EC2 dans un groupe Auto Scaling ou le débit d’une table DynamoDB via la AWS Management Console ou la AWS CLI. Cependant, l’automatisation doit être utilisée dans la mesure du possible (voir **Utiliser l’automatisation lors de l’obtention ou de la mise à l’échelle des ressources**). **Résultat escompté :** les activités de mise à l’échelle (automatiquement ou manuellement) sont lancées pour rétablir la disponibilité en cas de détection d’une panne ou d’une dégradation de l’expérience client. **Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen ## Directives d’implémentation Mettez en œuvre l’observabilité et la surveillance de tous les composants de votre charge de travail, afin de surveiller l’expérience client et de détecter les défaillances. Définissez les procédures, manuelles ou automatisées, de mise à l’échelle des ressources requises. Pour plus d’informations, consultez [REL11-BP01 Surveiller tous les composants de la charge de travail afin de détecter les défaillances](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_monitoring_health.html). ### Étapes d’implémentation + Définissez les procédures, manuelles ou automatisées, de mise à l’échelle des ressources requises. + Les procédures de mise à l’échelle dépendent de la conception des différents composants de votre charge de travail. + Les procédures de mise à l’échelle varient également en fonction de la technologie sous-jacente utilisée. + Les composants qui utilisent AWS Auto Scaling peuvent utiliser des plans de mise à l’échelle pour configurer un ensemble d’instructions pour la mise à l’échelle de vos ressources. Si vous utilisez AWS CloudFormation ou que vous ajoutez des balises à des ressources AWS, vous pouvez configurer des plans de mise à l’échelle pour différents ensembles de ressources, par application. Auto Scaling fournit des recommandations pour les stratégies de mise à l’échelle personnalisées pour chaque ressource. Une fois que vous avez créé votre plan de mise à l’échelle, Auto Scaling combine les méthodes de mise à l’échelle dynamique et prédictive pour prendre en charge votre stratégie de mise à l’échelle. Pour plus de détails, consultez [Comment fonctionnent les plans de mise à l’échelle](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html). + Amazon EC2 Auto Scaling permet de vous assurer que vous disposez du bon nombre d’instances Amazon EC2 disponibles pour gérer la charge de l’application. Vous créez des ensembles d’instances EC2, appelés groupes Auto Scaling. Vous pouvez spécifier le nombre minimal et maximal d’instances dans chaque groupe Auto Scaling et Amazon EC2 Auto Scaling s’assure que votre groupe n’est jamais au-dessus ou en dessous de ces limites. Pour plus d’informations, consultez [Qu’est-ce qu’Amazon EC2 Auto Scaling ?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) + L’autoscaling d’Amazon DynamoDB utilise le service d’autoscaling d’application pour ajuster de manière dynamique la capacité de débit approvisionné en votre nom, en réponse aux schémas de trafic réels. Cela permet à une table ou à un index secondaire global d’augmenter les capacités en lecture et écriture qui lui sont allouées afin de gérer les hausses soudaines de trafic sans limitation. Pour plus d’informations, voir [Gestion automatique de la capacité de débit avec l’autoscaling de DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html). ## Ressources **Bonnes pratiques associées :** + [ REL07-BP01 Utiliser l’automatisation lors de l’obtention des ressources ou de leur mise à l’échelle ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_adapt_to_changes_autoscale_adapt.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_monitoring_health.html) **Documents connexes :** + [AWS Auto Scaling : Fonctionnement des plans de dimensionnement](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) + [Gestion automatique de la capacité de débit avec l’autoscaling de DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) + [Qu’est-ce qu’Amazon EC2 Auto Scaling ?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) # REL07-BP03 Obtenir des ressources après avoir réalisé qu’un plus grand nombre de ressources est nécessaire pour une charge de travail L’une des fonctionnalités les plus précieuses du cloud computing est sa capacité à provisionner des ressources de manière dynamique. Dans les environnements informatiques sur site traditionnels, vous devez identifier et provisionner une capacité suffisante à l’avance pour répondre à un pic de demande. Cela pose problème car cela coûte cher et présente des risques pour la disponibilité si vous sous-estimez la capacité maximale requise par la charge de travail. Dans le cloud, vous n’avez pas à le faire. Au lieu de cela, vous pouvez provisionner comme il se doit des capacités de calcul, de base de données et d’autres ressources pour répondre à la demande actuelle et prévue. Des solutions automatisées telles qu’Amazon EC2 Auto Scaling et Application Auto Scaling peuvent mettre en ligne des ressources pour vous sur la base de métriques que vous spécifiez. Cela peut faciliter le processus de mise à l’échelle et le rendre prévisible, et cela peut rendre votre charge de travail nettement plus fiable en garantissant que vous disposez de suffisamment de ressources à tout moment. **Résultat escompté** : vous configurez la mise à l’échelle automatique des ressources de calcul et autres pour répondre à la demande. Vous prévoyez une marge de manœuvre suffisante dans vos politiques de mise à l’échelle pour permettre de répondre à des pics de trafic pendant que des ressources supplémentaires sont mises en ligne. **Anti-modèles courants :** + Vous provisionnez un nombre fixe de ressources évolutives. + Vous choisissez une métrique de mise à l’échelle qui ne correspond pas à la demande réelle. + Vous ne parvenez pas à prévoir une marge de manœuvre suffisante dans vos plans de mise à l’échelle pour faire face aux pics de demande. + Vos politiques de mise à l’échelle tardent trop à augmenter la capacité, ce qui entraîne l’épuisement de la capacité et une dégradation du service lors de la mise en ligne de ressources supplémentaires. + Vous ne parvenez pas à configurer correctement le nombre minimal et le nombre maximal de ressources, ce qui entraîne des échecs de mise à l’échelle. **Avantages liés au respect de cette bonne pratique :** il est essentiel de disposer de suffisamment de ressources pour répondre à la demande actuelle afin de garantir une haute disponibilité de votre charge de travail et de respecter les objectifs de niveau de service (SLO) définis. La mise à l’échelle automatique vous permet de fournir la bonne quantité de ressources de calcul, de base de données et autres dont votre charge de travail a besoin afin de répondre à la demande actuelle et prévue. Vous n’avez pas besoin de déterminer la capacité maximale requise et d’allouer statiquement des ressources pour la fournir. Au lieu de cela, à mesure que la demande augmente, vous pouvez allouer davantage de ressources pour y répondre et, une fois que la demande est retombée, vous pouvez désactiver les ressources pour réduire les coûts. **Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen ## Directives d’implémentation Tout d’abord, déterminez si le composant de charge de travail est adapté à la mise à l’échelle automatique. Ces composants sont appelés *évolutifs horizontalement* car ils fournissent les mêmes ressources et se comportent de manière identique. Parmi les composants évolutifs horizontalement, citons les instances EC2 configurées de la même manière, les tâches [Amazon Elastic Container Service (ECS)](https://aws.amazon.com/ecs/) et les pods exécutés sur [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/). Ces ressources de calcul sont généralement situées derrière un équilibreur de charge et sont appelées *réplicas*. Les autres ressources répliquées peuvent inclure des réplicas en lecture de base de données, des tables [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) et des clusters [Amazon ElastiCache](https://aws.amazon.com/elasticache/) (Redis OSS). Pour obtenir la liste complète des ressources prises en charge, consultez [Services AWS que vous pouvez utiliser avec Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/integrated-services-list.html). Pour les architectures basées sur des conteneurs, il peut être nécessaire de procéder à une mise à l’échelle de deux manières différentes. Tout d’abord, vous devrez peut-être mettre à l’échelle les conteneurs qui fournissent des services évolutifs horizontalement. Ensuite, vous devrez peut-être mettre à l’échelle les ressources de calcul pour libérer de l’espace pour de nouveaux conteneurs. Il existe différents mécanismes de mise à l’échelle automatique pour chaque couche. Pour mettre à l’échelle les tâches ECS, vous pouvez utiliser [Application Auto Scaling](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html). Pour mettre à l’échelle les pods Kubernetes, vous pouvez utiliser [Horizontal Pod Autoscaler (HPA)](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) ou [Kubernetes Event-driven Autoscaler (KEDA)](https://keda.sh/). Pour mettre à l’échelle les ressources de calcul, vous pouvez utiliser les [fournisseurs de capacité](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/asg-capacity-providers.html) pour ECS, ou pour Kubernetes, vous pouvez utiliser [Karpenter](https://karpenter.sh) ou [Cluster Autoscaler](https://kubernetes.io/docs/concepts/cluster-administration/cluster-autoscaling/). Ensuite, sélectionnez de quelle façon vous voulez effectuer la mise à l’échelle automatique. Il existe trois options principales : la mise à l’échelle basée sur des métriques, la mise à l’échelle planifiée et la mise à l’échelle prédictive. **Mise à l’échelle basée sur des métriques** La mise à l’échelle basée sur des métriques provisionne les ressources en fonction de la valeur d’une ou de plusieurs *métriques de mise à l’échelle*. Une métrique de mise à l’échelle est une métrique qui correspond à la demande de votre charge de travail. Un bon moyen de déterminer les métriques de mise à l’échelle appropriées consiste à effectuer des tests de charge dans un environnement hors production. Pendant vos tests de charge, maintenez fixe le nombre de ressources évolutives et augmentez lentement la demande (par exemple, débit, simultanéité ou utilisateurs simulés). Recherchez ensuite des métriques qui augmentent (ou diminuent) à mesure que la demande augmente, et inversement diminuent (ou augmentent) lorsque la demande diminue. Les métriques de mise à l’échelle typiques incluent l’utilisation du processeur, la profondeur de la file d’attente de travail (telle qu’une file d’attente [Amazon SQS](https://aws.amazon.com/sqs/)), le nombre d’utilisateurs actifs et le débit du réseau. **Note** AWS a observé qu’avec la plupart des applications, l’utilisation de la mémoire augmente à mesure que l’application monte en intensité, puis atteint une valeur stable. Lorsque la demande diminue, l’utilisation de la mémoire reste généralement élevée au lieu de diminuer en parallèle. Étant donné que l’utilisation de la mémoire ne correspond pas à la demande dans les deux cas de figure (à savoir en augmentant ni en diminuant avec la demande), réfléchissez bien avant de sélectionner cette métrique pour la mise à l’échelle automatique. La mise à l’échelle basée sur des métriques est une *opération latente*. Plusieurs minutes peuvent être nécessaires pour que les métriques d’utilisation se propagent aux mécanismes de mise à l’échelle automatique, et ces mécanismes attendent généralement un signal clair d’augmentation de la demande avant de réagir. Ensuite, à mesure que l’outil de mise à l’échelle automatique crée de nouvelles ressources, la mise en service complète de ces dernières peut prendre plus de temps. Pour cette raison, il est important de ne pas définir vos cibles de métriques de mise à l’échelle trop proches de l’utilisation totale (par exemple, 90 % d’utilisation du processeur). Cela risque d’épuiser la capacité de ressources existante avant qu’une capacité supplémentaire puisse être mise en ligne. Les cibles typiques d’utilisation des ressources peuvent varier entre 50 et 70 % pour une disponibilité optimale, en fonction des modèles de demande et du temps nécessaire pour provisionner des ressources supplémentaires. **Mise à l’échelle planifiée** La mise à l’échelle planifiée provisionne ou supprime des ressources en fonction du calendrier ou de l’heure de la journée. Elle est fréquemment utilisée pour les charges de travail dont la demande est prévisible, telles que les pics d’utilisation pendant les heures ouvrables de semaine ou lors de soldes. [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html) et [Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) prennent tous deux en charge la mise à l’échelle planifiée. La fonctionnalité [cron scaler](https://keda.sh/docs/latest/scalers/cron/) de KEDA prend en charge la mise à l’échelle planifiée des pods Kubernetes. **Mise à l’échelle prédictive** La mise à l’échelle prédictive utilise le machine learning pour mettre à l’échelle automatiquement les ressources en fonction de la demande anticipée. La mise à l’échelle prédictive analyse la valeur historique d’une métrique d’utilisation que vous fournissez et prédit en permanence sa valeur future. La valeur prédite est ensuite utilisée pour augmenter ou réduire verticalement la ressource. [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-predictive-scaling.html) peut effectuer une mise à l’échelle prédictive. ### Étapes d’implémentation 1. Déterminez si le composant de charge de travail est adapté à la mise à l’échelle automatique. 1. Déterminez le type de mécanisme de mise à l’échelle le plus approprié pour la charge de travail : mise à l’échelle basée sur des métriques, mise à l’échelle planifiée ou mise à l’échelle prédictive. 1. Sélectionnez le mécanisme de mise à l’échelle automatique approprié pour le composant. Pour les instances Amazon EC2, utilisez Amazon EC2 Auto Scaling. Pour les autres services AWS, utilisez Application Auto Scaling. Pour les pods Kubernetes (tels que ceux exécutés dans un cluster Amazon EKS), pensez à Horizontal Pod Autoscaler (HPA) ou à Kubernetes Event-driven Autoscaling (KEDA). Pour les nœuds Kubernetes ou EKS, pensez à Karpenter et à Cluster Auto Scaler (CAS). 1. Pour une mise à l’échelle basée sur des métriques ou planifiée, effectuez des tests de charge afin de déterminer les métriques de mise à l’échelle et les valeurs cibles appropriées pour votre charge de travail. Pour une mise à l’échelle planifiée, déterminez le nombre de ressources nécessaires aux dates et heures que vous sélectionnez. Déterminez le nombre maximal de ressources nécessaires pour répondre aux pics de trafic attendus. 1. Configurez l’outil de mise à l’échelle en fonction des informations collectées ci-dessus. Pour plus d’informations, consultez la documentation du service de mise à l’échelle automatique. Vérifiez que les limites de mise à l’échelle maximale et minimale sont correctement configurées. 1. Vérifiez que la configuration de mise à l’échelle fonctionne comme prévu. Effectuez des tests de charge dans un environnement hors production, observez comment le système réagit et ajustez le cas échéant. Lorsque vous activez la mise à l’échelle automatique en production, configurez les alarmes appropriées pour être averti de tout comportement inattendu. ## Ressources **Documents connexes :** + [Qu’est-ce qu’Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) + [Conseils prescriptifs AWS : tests de charge des applications](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/) + [AWS Marketplace: produits utilisables avec autoscaling](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling) + [Gestion automatique de la capacité de débit avec l’autoscaling de DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) + [Mise à l’échelle prédictive pour EC2 alimentée par le machine learning](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/) + [Mise à l’échelle planifiée pour Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html) + [Telling Stories About Little’s Law](https://brooker.co.za/blog/2018/06/20/littles-law.html) # REL07-BP04 Testez votre charge de travail Adoptez une méthodologie de test de charge pour déterminer si la mise à l’échelle répond aux exigences de la charge de travail. Il est important d’exécuter régulièrement des tests de charge. Les tests de charge doivent découvrir le point de rupture et tester les performances de votre charge de travail. AWS facilite la mise en place d'environnements de test temporaires qui modélisent l'échelle de votre charge de travail de production. Dans le Cloud, vous pouvez créer un environnement d’essai à l’échelle de la production et à la demande, exécuter les tests, puis désactiver les ressources. Puisque vous ne payez l’environnement de test que lorsqu’il s’exécute, vous pouvez simuler votre environnement réel pour une fraction du coût d’un test sur site. Les tests de charge en production doivent également être intégrés aux tests de simulation de pannes, lors desquels le système de production est mis sous tension pendant les périodes où le client est moins utilisé et tout le personnel est disponible pour interpréter les résultats et résoudre les problèmes qui surviennent. **Anti-modèles courants :** + Exécution de tests de charge sur des déploiements qui n’ont pas la même configuration que votre production. + Exécution d’un test de charge uniquement sur des éléments individuels de votre charge de travail, et non sur l’ensemble de la charge de travail. + Exécution de tests de charge avec un sous-ensemble de demandes et non un ensemble représentatif de demandes réelles. + Exécution de tests de charge avec un faible facteur de sécurité au-dessus de la charge prévue. **Avantages du respect de cette bonne pratique :** vous savez quels composants de votre architecture échouent sous charge et vous pouvez identifier les métriques à surveiller qui indiquent suffisamment à temps que vous approchez de cette charge pour que vous résolviez le problème et empêchiez ainsi l’impact de cette défaillance. **Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen ## Directives d’implémentation + Exécutez des tests de charge pour identifier l’aspect de votre charge de travail qui indique que vous devez ajouter ou supprimer de la capacité. Les tests de charge doivent avoir un trafic représentatif similaire à ce que vous recevez en production. Augmentez la charge tout en surveillant les métriques que vous avez instrumentées pour déterminer quelle métrique indique quand vous devez ajouter ou supprimer des ressources. + [Test de charge distribué sur AWS : simulez des milliers d'utilisateurs connectés](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) + Identifiez le mélange de demandes. Comme vous pouvez avoir divers mélanges de demandes, vous devez examiner les différentes périodes lors de l’identification de la combinaison de trafic. + Implémentez un pilote de charge. Vous pouvez utiliser un code personnalisé, un logiciel open source ou un logiciel commercial pour implémenter un pilote de charge. + Effectuez un test de charge initial avec une faible capacité. Vous constatez des effets immédiats en entraînant une charge moindre, éventuellement aussi petite qu’une instance ou un conteneur. + Effectuez un test de charge par rapport à une capacité plus importante. Étant donné que les effets seront différents sur une charge distribuée, vous devez procéder à des essais dans un environnement aussi proche que possible de celui du produit. ## Ressources **Documents connexes :** + [Test de charge distribué sur AWS : simulez des milliers d'utilisateurs connectés](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) + [Tests de charge des applications](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/welcome.html) **Vidéos connexes :** + [AWS Sommet ANZ 2023 : Accélérez en toute confiance grâce AWS aux tests de charge distribués](https://www.youtube.com/watch?v=4J6lVqa6Yh8) # FIA 8. Comment mettre en œuvre des modifications ? Des modifications contrôlées sont nécessaires pour déployer de nouvelles fonctionnalités et vérifier que les charges de travail et l’environnement d’exploitation fonctionnent avec des logiciels connus et peuvent être corrigés ou remplacés de manière prévisible. Si ces modifications ne sont pas maîtrisées, il devient difficile d’en prévoir les effets ou de résoudre les problèmes qui en découlent. **Topics** + [REL08-BP01 Utiliser des runbooks pour les activités standard telles que le déploiement](rel_tracking_change_management_planned_changemgmt.md) + [REL08-BP02 Intégrer les tests fonctionnels dans le cadre de votre déploiement](rel_tracking_change_management_functional_testing.md) + [REL08-BP03 Intégrer les tests de résilience dans le cadre de votre déploiement](rel_tracking_change_management_resiliency_testing.md) + [REL08-BP04 Effectuer le déploiement à l’aide d’une infrastructure immuable](rel_tracking_change_management_immutable_infrastructure.md) + [REL08-BP05 Déployer les modifications avec l’automatisation](rel_tracking_change_management_automated_changemgmt.md) # REL08-BP01 Utiliser des runbooks pour les activités standard telles que le déploiement Les runbooks sont les procédures prédéfinies destinées à parvenir à un résultat spécifique. Utilisez des runbooks pour effectuer des tâches manuelles ou automatiques standard. Il peut s’agir du déploiement d’une charge de travail, de l’application de correctifs à une charge de travail ou de la modification du DNS. Par exemple, mettez en place des processus pour [assurer la sécurité des restaurations pendant les déploiements](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments). Pour garantir la fiabilité d’un service, il est essentiel de s’assurer que vous pouvez restaurer un déploiement sans interruption pour vos clients. Concernant les procédures de runbook, commencez par un processus manuel efficace valide, mettez-le en œuvre dans le code et, le cas échéant, déclenchez son exécution automatique. Même pour les charges de travail sophistiquées hautement automatisées, les runbooks restent utiles pour exécuter des [tests de simulation de pannes](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays) ou répondre à des exigences rigoureuses en matière de rapports et d’audit. Notez que les playbooks sont utilisés en réponse à des incidents spécifiques et que les runbooks le sont pour obtenir des résultats spécifiques. En règle générale, les runbooks sont destinés aux activités de routine, tandis que les playbooks sont utilisés pour répondre à des événements non réguliers. **Anti-modèles courants :** + Exécution de modifications imprévues de la configuration en production. + Ignorer les étapes de votre plan afin d’accélérer le déploiement, ce qui entraîne un échec du déploiement. + Effectuez des modifications sans tester l’annulation de la modification. **Avantages liés au respect de cette bonne pratique :** une planification efficace des modifications augmente votre capacité à exécuter correctement la modification, car vous êtes conscient de tous les systèmes concernés. Vous gagnez en confiance si vous réussissez à valider des modifications que vous apportez aux environnements de test. **Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé ## Directives d’implémentation + Obtenez des réponses cohérentes et rapides à des événements bien compris en documentant les procédures dans des runbooks. + Utilisez le principe de l’infrastructure en tant que code pour définir votre infrastructure. En ayant recours à AWS CloudFormation ou à un tiers de confiance pour définir votre infrastructure, vous pouvez utiliser le contrôle de version et suivre les modifications apportées à la version du logiciel. + Utilisez AWS CloudFormation ou un fournisseur tiers de confiance pour définir votre infrastructure. + [Qu’est-ce qu AWS CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) + Créez des modèles qui sont singuliers et découplés, en utilisant de bons principes de conception de logiciels. + Déterminez les autorisations, les modèles et les responsables de l’implémentation + [ Contrôle de l’accès avec Gestion des identités et des accès AWS](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html) + Utilisez un système de gestion de code source hébergé basé sur une technologie populaire telle que Git pour stocker votre code source et votre configuration d’infrastructure en tant que code (IaC). ## Ressources **Documents connexes:** + [Partenaire APN : partenaires pouvant vous aider à créer des solutions de déploiement automatisées](https://aws.amazon.com/partners/find/results/?keyword=devops) + [AWS Marketplace: produits pouvant être utilisés pour automatiser vos déploiements](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps) + [Qu’est-ce qu AWS CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) **Exemples connexes:** + [Automatisation des opérations avec les playbooks et les runbooks](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/) # REL08-BP02 Intégrer les tests fonctionnels dans le cadre de votre déploiement Utilisez des techniques telles que les tests unitaires et les tests d’intégration qui valident les fonctionnalités requises. Un test unitaire est un processus consistant à tester la plus petite unité fonctionnelle du code afin de valider son comportement. Un test d’intégration vise à valider que chaque fonctionnalité de l’application respecte les exigences du logiciel. Alors que les tests unitaires visent à tester une partie d’une application de manière isolée, les tests d’intégration prennent en compte les effets secondaires (par exemple, l’effet de la modification des données lors d’une opération de mutation). Dans les deux cas, les tests doivent être intégrés dans un pipeline de déploiement et si les critères de réussite ne sont pas respectés, le pipeline est arrêté ou annulé. Ces tests sont exécutés dans un environnement de pré-production, qui est mis en place avant la production dans le pipeline. Vous obtenez les meilleurs résultats lorsque ces tests sont exécutés automatiquement dans le cadre d’actions de génération et de déploiement. Par exemple, avec AWS CodePipeline, les développeurs valident les modifications apportées à un référentiel source dans lequel CodePipeline détecte automatiquement les modifications. L’application est générée et des tests unitaires sont exécutés. Une fois les tests unitaires réussis, le code ainsi généré est déployé sur les serveurs intermédiaires, à des fins de test. Depuis le serveur intermédiaire, CodePipeline exécute d’autres tests, tels que des tests d’intégration ou de chargement. Une fois ces tests terminés avec succès, CodePipeline déploie le code testé et approuvé sur les instances de production. **Résultat escompté :** vous utilisez l’automatisation pour effectuer des tests unitaires et d’intégration afin de valider que votre code se comporte comme prévu. Ces tests sont intégrés au processus de déploiement, et un échec entraîne l’abandon du déploiement. **Anti-modèles courants :** + Vous ignorez ou contournez les échecs de test et les plans pendant le processus de déploiement afin de raccourcir le délai de déploiement. + Vous effectuez manuellement des tests en dehors du pipeline de déploiement. + Vous sautez des étapes de test dans l’automatisation par le biais de flux de travail d’urgence manuels. + Vous exécutez des tests automatisés dans un environnement qui ne ressemble vraiment pas à l’environnement de production. + Vous créez une suite de tests trop peu flexible et difficile à maintenir, à mettre à jour ou à mettre à l’échelle à mesure de l’évolution de l’application. **Avantages liés au respect de cette bonne pratique :** les tests automatisés effectués au cours du processus de déploiement détectent les problèmes à un stade précoce, ce qui réduit le risque d’une mise en production avec des bogues ou des comportements inattendus. Les tests unitaires valident le fait que le code se comporte comme souhaité et que les contrats d’API sont respectés. Les tests d’intégration valident le fait que le système fonctionne conformément aux exigences spécifiées. Ces types de tests vérifient l’état de fonctionnement escompté de composants tels que les interfaces utilisateur, les API, les bases de données et le code source. **Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé ## Directives d’implémentation Adoptez une approche de développement piloté par les tests (TDD) pour écrire des logiciels, dans laquelle vous développez des cas de test pour spécifier et valider votre code. Pour commencer, créez des cas de test pour chaque fonction. Si le test échoue, vous devez écrire un nouveau code pour réussir le test. Cette approche vous permet de valider le résultat escompté de chaque fonction. Exécutez des tests unitaires et validez leur réussite avant de valider le code dans un référentiel de code source. Mettez en œuvre des tests unitaires et d’intégration dans le cadre des étapes de création, de test et de déploiement du pipeline CI/CD. Automatisez les tests et lancez automatiquement les tests chaque fois qu’une nouvelle version de l’application est prête à être déployée. Si les critères de réussite ne sont pas respectés, le pipeline est arrêté ou annulé. Dans le cas d’une application Web ou mobile, effectuez des tests d’intégration automatisés sur plusieurs navigateurs de bureau ou sur des appareils réels. Cette approche est particulièrement utile pour valider la compatibilité et les fonctionnalités des applications mobiles sur un large éventail d’appareils. ### Étapes d’implémentation 1. Rédigez des tests unitaires avant d’écrire du code fonctionnel (*développement piloté par les tests* ou TDD). Établissez des lignes directrices en matière de code afin que l’écriture et l’exécution de tests unitaires soient une exigence non fonctionnelle de codage. 1. Créez une suite de tests d’intégration automatisés qui couvrent les fonctionnalités testables identifiées. Ces tests doivent simuler les interactions avec les utilisateurs et valider les résultats attendus. 1. Créez l’environnement de test nécessaire pour exécuter les tests d’intégration. Cela peut inclure des environnements de préparation ou de pré-production qui imitent étroitement l’environnement de production. 1. Configurez vos étapes source, de construction, de test et de déploiement à l’aide de la console AWS CodePipeline ou de l’AWS Command Line Interface (CLI). 1. Déployez l’application une fois que le code a été créé et testé. AWS CodeDeploy peut la déployer dans vos environnements intermédiaire (tests) et de production. Ces environnements peuvent inclure des instances Amazon EC2, des fonctions AWS Lambda et des serveurs sur site. Le même mécanisme de déploiement doit être utilisé pour déployer l’application dans tous les environnements. 1. Surveillez la progression de votre pipeline et le statut de chaque étape. Utilisez des contrôles de qualité pour bloquer le pipeline en fonction du statut des tests. Vous pouvez aussi recevoir des notifications en cas d’échec ou d’achèvement d’une étape du pipeline. 1. Surveillez en permanence les résultats des tests et recherchez des modèles, des régressions ou des domaines nécessitant une plus grande attention. Utilisez ces informations pour améliorer la suite de tests, identifier les domaines de l’application nécessitant des tests plus approfondis et optimiser le processus de déploiement. ## Ressources **Bonnes pratiques associées :** + [REL07-BP04 Effectuer un test de charge de votre charge de travail](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_adapt_to_changes_load_tested_adapt.html) + [REL08-BP03 Intégrer les tests de résilience dans le cadre de votre déploiement](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_resiliency_testing.html) + [REL12-BP04 Tester la résilience à l’aide de l’ingénierie du chaos](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_failure_injection_resiliency.html) **Documents connexes :** + [Conseils prescriptifs AWS : automatisation des tests](https://docs.aws.amazon.com/prescriptive-guidance/latest/performance-engineering-aws/test-automation.html) + [Intégration et livraison continues](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html) + [Indicateurs pour les tests fonctionnels](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/indicators-for-functional-testing.html) + [Surveillance des pipelines](https://docs.aws.amazon.com/codepipeline/latest/userguide/monitoring.html) + [Utilisation d’AWS CodePipeline avec AWS CodeBuild pour tester le code et exécuter des générations](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html) + [AWS Device Farm](https://docs.aws.amazon.com/codepipeline/latest/userguide/action-reference-DeviceFarm.html) # REL08-BP03 Intégrer les tests de résilience dans le cadre de votre déploiement Intégrez des tests de résilience en introduisant consciemment des défaillances dans le système afin de mesurer sa fonctionnalité en cas de scénarios perturbateurs. Les tests de résilience sont différents des tests unitaires et fonctionnels qui sont généralement intégrés dans les cycles de déploiement, car ils se concentrent sur l’identification des défaillances imprévues de votre système. Bien qu’il soit prudent de commencer par l’intégration des tests de résilience en préproduction, fixez-vous comme objectif d’implémenter ces tests en production dans le cadre de vos [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays). **Résultat escompté** : les tests de résilience contribuent à renforcer la confiance dans la capacité du système à résister à la dégradation en cours de production. Les expériences identifient les points faibles susceptibles d’entraîner une défaillance, ce qui vous permet d’améliorer le système afin d’atténuer automatiquement et efficacement les défaillances et la dégradation. **Anti-modèles courants :** + Manque d’observabilité et de surveillance dans les processus de déploiement + Dépendance à l’humain pour résoudre les défaillances du système + Mécanismes d’analyse de mauvaise qualité + Accent mis sur les problèmes connus d’un système et manque d’expérimentation pour identifier les problèmes inconnus + Identification des défaillances, mais pas de solution + Aucune documentation sur les résultats ni aucun runbook **Avantages de l’établissement de bonnes pratiques :** les tests de résilience intégrés à vos déploiements permettent d’identifier les problèmes inconnus du système qui, autrement, passeraient inaperçus, ce qui peut entraîner des interruptions de production. L’identification de ces problèmes système inconnus vous permet de documenter les résultats, d’intégrer les tests dans votre processus CI/CD et de créer des runbooks, ce qui simplifie leur atténuation grâce à des mécanismes efficaces et reproductibles. **Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen ## Directives d’implémentation Les formes de test de résilience les plus courantes pouvant être intégrées dans les déploiements de votre système sont la reprise après sinistre et l’ingénierie du chaos. + Incluez des mises à jour de vos plans de reprise après sinistre et de vos procédures opérationnelles standard (SOP) lors de tout déploiement important. + Intégrez des tests de fiabilité à vos pipelines de déploiement automatisés. Des services tels que [AWS Resilience Hub](https://aws.amazon.com/resilience-hub/) peuvent être [intégrés à votre pipeline CI/CD](https://aws.amazon.com/blogs/architecture/continually-assessing-application-resilience-with-aws-resilience-hub-and-aws-codepipeline/) pour établir des évaluations continues de la résilience qui sont automatiquement évaluées dans le cadre de chaque déploiement. + Définissez vos applications dans AWS Resilience Hub. Les évaluations de résilience génèrent des extraits de code qui vous aident à créer des procédures de restauration sous forme de documents AWS Systems Manager pour vos applications et fournissent une liste de moniteurs et d’alarmes Amazon CloudWatch recommandés. + Une fois vos plans de reprise après sinistre et vos SOP mis à jour, effectuez des tests de reprise après sinistre pour vérifier leur efficacité. Les tests de reprise après sinistre contribuent à déterminer si vous pouvez restaurer votre système après un événement et revenir à un fonctionnement normal. Vous pouvez simuler différentes stratégies de reprise après sinistre et déterminer si votre planification est suffisante pour répondre à vos exigences de disponibilité. Les stratégies courantes de reprise après sinistre incluent la sauvegarde et la restauration, l’environnement en veille, la veille à froid, la veille à chaud, la veille permanente et la veille active/active. Elles diffèrent toutes en matière de coût et de complexité. Avant les tests de reprise après sinistre, nous vous recommandons de définir votre objectif de délai de reprise (RTO) et votre objectif de point de reprise (RPO) afin de simplifier le choix de la stratégie à simuler. AWS propose des outils de reprise après sinistre comme [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) destinés à vous aider à démarrer votre planification et vos tests. + Les expériences d’ingénierie du chaos introduisent des perturbations dans le système, telles que des pannes de réseau et des pannes de service. En simulant le système avec des pannes contrôlées, vous pouvez en découvrir les vulnérabilités tout en limitant les impacts des pannes injectées. Comme pour les autres stratégies, exécutez des simulations de défaillances contrôlées dans des environnements non liés à la production en utilisant des services tels que [AWS Fault Injection Service](https://aws.amazon.com/fis/) pour gagner en confiance avant de les déployer en production. ## Ressources **Documents connexes :** + [Tester les défaillances à l’aide de tests de résilience pour renforcer la préparation à la reprise](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/qa.nt.6-experiment-with-failure-using-resilience-testing-to-build-recovery-preparedness.html) + [Évaluation continue de la résilience des applications avec AWS Resilience Hub et AWS CodePipeline](https://aws.amazon.com/blogs/architecture/continually-assessing-application-resilience-with-aws-resilience-hub-and-aws-codepipeline/) + [Architecture de reprise après sinistre (DR) sur AWS, première partie : stratégies de reprise dans le cloud](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/) + [Vérifier la résilience de vos charges de travail à l’aide de Chaos Engineering](https://aws.amazon.com/blogs/architecture/verify-the-resilience-of-your-workloads-using-chaos-engineering/) + [Principes de l’ingénierie du chaos](https://principlesofchaos.org/) + [Atelier d’ingénierie du chaos](https://disaster-recovery.workshop.aws/en/intro/concepts/chaos-engineering.html) **Vidéos connexes :** + [AWS re:Invent 2020: Testing Resilience using Chaos Engineering](https://www.youtube.com/watch?v=OlobVYPkxgg) + [Improve Application Resilience with AWS Fault Injection Service](https://www.youtube.com/watch?v=N0aZZVVZiUw) + [Prepare & Protect Your Applications From Disruption With AWS Resilience Hub](https://www.youtube.com/watch?v=xa4BVl4N1Gw) # REL08-BP04 Effectuer le déploiement à l’aide d’une infrastructure immuable Une infrastructure immuable est un modèle qui exige qu’aucune mise à jour, aucune application de correctifs de sécurité ni aucun changement de configuration ne se produise sur place sur les charges de travail de production. Lorsqu’un changement est nécessaire, l’architecture est intégrée à la nouvelle infrastructure et déployée en production. Suivez une stratégie de déploiement d’infrastructure immuable pour améliorer la fiabilité, la cohérence et la reproductibilité de vos déploiements de charges de travail. **Résultat escompté :** avec une infrastructure immuable, aucune [modification sur place](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/deployment-strategies.html#in-place-deployments) n’est autorisée pour exécuter les ressources de l’infrastructure dans le cadre d’une charge de travail. Lorsqu’une modification est nécessaire, un nouvel ensemble de ressources d’infrastructure contenant toutes les modifications nécessaires est déployé parallèlement à vos ressources existantes. Ce déploiement est validé automatiquement et, en cas de succès, le trafic est progressivement transféré vers ce nouvel ensemble de ressources. Cette stratégie de déploiement s’applique notamment aux mises à jour logicielles, aux correctifs de sécurité, aux modifications de l’infrastructure, ainsi qu’aux mises à jour de la configuration et des applications. **Anti-modèles courants :** + Modifications sur place des ressources d’infrastructure en cours d’exécution. **Avantages liés au respect de cette bonne pratique :** + **Cohérence accrue entre les environnements :** comme il n’existe aucune différence dans les ressources d’infrastructure entre les environnements, la cohérence est améliorée et les tests simplifiés. + **Réduction des dérives de configuration :** en remplaçant fréquemment les ressources d’infrastructure à partir d’une configuration de base connue et contrôlée par les versions, l’infrastructure est réinitialisée à un état connu, testé et fiable, ce qui évite les dérives de configuration. + **Déploiements atomiques fiables :** les déploiements se terminent avec succès ou rien ne change, ce qui améliore la cohérence et la fiabilité du processus de déploiement. + **Déploiements simplifiés :** les déploiements sont simplifiés, car ils n’ont pas besoin de prendre en charge les mises à niveau. Les mises à niveau sont simplement de nouveaux déploiements. + **Déploiements plus sûrs avec des processus de restauration et de récupération rapides :** les déploiements sont plus sûrs, car la version de travail précédente n’est pas modifiée. Vous pouvez la restaurer si des erreurs sont détectées. + **Position de sécurité améliorée :** en interdisant les modifications de l’infrastructure, les mécanismes d’accès à distance (tels que SSH) peuvent être désactivés. Vous pouvez ainsi réduire les vecteurs d’attaque tout en renforçant la sécurité de votre organisation. **Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen ## Directives d’implémentation **Automatisation** Lors de la définition d’une stratégie de déploiement d’infrastructure immuable, il est recommandé de recourir autant que possible à [l’automatisation](https://aws.amazon.com/iam/) afin d’accroître la reproductibilité et de minimiser le risque d’erreur humaine. Pour plus de détails, voir [REL08-BP05 Déployer les modifications grâce à l’automatisation](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_automated_changemgmt.html) et [Automatisation de déploiements sûrs et sans intervention directe](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/). Avec l’[infrastructure en tant que code (IaC)](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html), les étapes de provisionnement, d’orchestration et de déploiement de l’infrastructure sont définies de manière programmatique, descriptive et déclarative et stockées dans un système de contrôle des sources. L’utilisation de l’infrastructure en tant que code simplifie l’automatisation du déploiement de l’infrastructure et contribue à garantir l’immuabilité de cette dernière. **Modèles de déploiement** Lorsqu’une modification de la charge de travail est requise, la stratégie de déploiement d’infrastructure immuable impose le déploiement d’un nouvel ensemble de ressources d’infrastructure comprenant toutes les modifications nécessaires. Il est important que ce nouvel ensemble de ressources suive un schéma de déploiement qui minimise l’impact sur les utilisateurs. Il existe deux stratégies principales pour ce type de déploiement : [https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/canary-deployments.html](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/canary-deployments.html) : consiste à diriger un petit nombre de vos clients vers la nouvelle version, généralement exécutée sur une seule instance de service (la version Canary). Examinez ensuite en profondeur les modifications de comportement ou les erreurs générées. Vous pouvez supprimer le trafic du Canary si vous rencontrez des problèmes critiques et faire basculer les utilisateurs vers la version précédente. Si le déploiement est réussi, vous pouvez le continuer à la vitesse souhaitée, tout en surveillant les modifications (pour éviter les erreurs), jusqu’à ce qu’il soit terminé. AWS CodeDeploy peut être configuré avec une [configuration de déploiement](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html) qui permettra un déploiement canary. [https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html) : semblable au déploiement Canary si ce n’est qu’un parc complet de l’application est déployé en parallèle. Vos déploiements alternent entre deux piles (bleu et vert). Une fois encore, vous pouvez faire basculer le trafic vers la nouvelle version et revenir à l’ancienne si vous rencontrez des problèmes lors du déploiement. Généralement, tout le trafic est commuté en même temps. Vous pouvez toutefois également utiliser des fractions de votre trafic vers chaque version pour modifier l’adoption de la nouvelle version à l’aide des capacités de routage DNS pondéré d’Amazon Route 53. AWS CodeDeploy et [AWS Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2020-05-18-ts-deploy.html) peuvent être configurés avec une configuration de déploiement qui permet un déploiement bleu/vert. ![\[Diagramme illustrant un déploiement bleu/vert avec AWS Elastic Beanstalk et Amazon Route 53\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/framework/images/blue-green-deployment.png) **Détection des écarts** L’*écart* est défini comme tout changement qui fait qu’une ressource d’infrastructure présente un état ou une configuration différent de ce qui est attendu. Toute modification de configuration non gérée va à l’encontre de la notion d’infrastructure immuable et doit être détectée et corrigée afin de garantir la mise en œuvre d’une infrastructure immuable. ### Étapes d’implémentation + Interdisez la modification sur place des ressources d’infrastructure en cours d’exécution. + Vous pouvez utiliser [Gestion des identités et des accès AWS (IAM)](https://aws.amazon.com/iam/) pour spécifier qui ou quoi peut accéder aux services et aux ressources dans AWS, gérer de manière centralisée les autorisations détaillées et analyser les accès pour affiner les autorisations dans AWS. + Automatisez le déploiement des ressources d’infrastructure pour améliorer la reproductibilité et minimiser le risque d’erreur humaine. + Comme décrit dans le [livre blanc Introduction au DevOps sur AWS](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html), l’automatisation est la pierre angulaire des services AWS et est prise en charge en interne dans tous les services, fonctionnalités et offres. + *[La préintégration](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/prebaking-vs.-bootstrapping-amis.html)* de votre Amazon Machine Image (AMI) peut accélérer son lancement. [EC2 Image Builder](https://aws.amazon.com/image-builder/) est un service AWS entièrement géré qui vous permet d’automatiser la création, la maintenance, la validation, le partage et le déploiement d’une AMI Linux ou Windows personnalisée, fiable et à jour. + Les services qui prennent en charge l’automatisation incluent : + [AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/) est un service permettant de déployer et de mettre à l’échelle rapidement des applications et des services web développés avec Java, .NET, PHP, Node.js, Python, Ruby, Go et Docker sur des serveurs courants, tels qu’Apache, NGINX, Passenger et IIS. + [AWS Proton](https://aws.amazon.com/proton/) aide les équipes de plateforme à connecter et à coordonner les différents outils dont vos équipes de développement ont besoin pour le provisionnement de l’infrastructure, les déploiements de code, la surveillance et les mises à jour. AWS Proton permet une infrastructure automatisée sous forme de provisionnement de code et de déploiement d’applications sans serveur et basées sur des conteneurs. + L’utilisation d’une infrastructure en tant que code facilite l’automatisation du déploiement de l’infrastructure et contribue à garantir l’immuabilité de l’infrastructure. AWS fournit des services de création, de déploiement et de maintenance programmatique, descriptive et déclarative de l’infrastructure. + [AWS CloudFormation](https://aws.amazon.com/cloudformation/) aide les développeurs à créer des ressources AWS de manière ordonnée et prévisible. Les ressources sont écrites dans des fichiers texte au format JSON ou YAML. Les modèles nécessitent une syntaxe et une structure spécifiques, qui dépendent des types de ressources créées et gérées. Vous créez vos ressources au format JSON ou YAML avec n’importe quel éditeur de code, vous les archivez dans un système de contrôle de version, puis CloudFormation crée les services spécifiés d’une manière sûre et reproductible. + [AWS Serverless Application Model (AWS SAM)](https://aws.amazon.com/serverless/sam/) est un cadre open source que vous pouvez utiliser pour construire des applications sans serveur sur AWS. AWS SAM s’intègre à d’autres services AWS et constitue une extension de CloudFormation. + [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/) est un cadre de développement logiciel open source que vous pouvez utiliser pour modéliser et allouer vos ressources d’applications cloud à l’aide de langages de programmation familiers. Vous pouvez utiliser AWS CDK pour modéliser l’infrastructure d’applications avec TypeScript, Python, Java et .NET. AWS CDK utilise CloudFormation en arrière-plan pour provisionner les ressources de manière sécurisée et reproductible. + [API de commande du Cloud AWS](https://aws.amazon.com/cloudcontrolapi/) introduit un ensemble commun d’API CRUDL (Create, Read, Update, Delete, and List) pour aider les développeurs à gérer leur infrastructure cloud de manière simple et cohérente. Les API courantes de Cloud Control API permettent aux développeurs de gérer de manière uniforme le cycle de vie des services AWS et tiers. + Mettez en œuvre des modèles de déploiement qui minimisent l’impact sur les utilisateurs. + Déploiements canary : + [ Configuration d’un déploiement de la version canary API Gateway ](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html) + [ Créer un pipeline avec des déploiements Canary pour Amazon ECS à l’aide de AWS App Mesh](https://aws.amazon.com/blogs/containers/create-a-pipeline-with-canary-deployments-for-amazon-ecs-using-aws-app-mesh/) + Déploiements bleu/vert : le [livre blanc sur les déploiements bleu/vert sur AWS](https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html) décrit des [exemples de techniques](https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/implementation-techniques.html) pour mettre en œuvre des stratégies de déploiement bleu/vert. + Détectez les écarts de configuration ou d’état. Pour plus de détails, consultez [Détection de modifications non gérées de la configuration des piles et des ressources](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html). ## Ressources **Bonnes pratiques associées :** + [ REL08-BP05 Déployer les modifications avec l’automatisation ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_automated_changemgmt.html) **Documents connexes :** + [ Automatiser les déploiements sécurisés et sans intervention ](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/) + [ Tirer parti de AWS CloudFormation pour créer une infrastructure immuable chez Nubank ](https://aws.amazon.com/blogs/mt/leveraging-immutable-infrastructure-nubank/) + [ Infrastructure en tant que code ](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html) + [ Implémentation d’une alarme pour détecter automatiquement l’écart dans les piles AWS CloudFormation](https://docs.aws.amazon.com/blogs/mt/implementing-an-alarm-to-automatically-detect-drift-in-aws-cloudformation-stacks/) **Vidéos connexes :** + [AWS re:Invent 2020: Reliability, consistency, and confidence through immutability ](https://www.youtube.com/watch?v=jUSYnRztttY) # REL08-BP05 Déployer les modifications avec l’automatisation Les déploiements et l’application de correctifs sont automatisés pour éliminer l’impact négatif. Les modifications apportées aux systèmes de production sont l’un des secteurs de risque les plus importants pour de nombreuses organisations. Nous considérons les déploiements comme un problème de premier ordre à résoudre, tout comme les problèmes opérationnels que le logiciel rencontre. Aujourd’hui, il convient d’appliquer l’automatisation dès que les opérations le permettent, y compris lors des tests et du déploiement de modifications, lors de l’ajout ou de la suppression de capacités et lors de la migration des données. **Résultat escompté :** vous intégrez la sécurité des déploiements automatisés dans le processus de publication grâce à des tests de pré-production approfondis, à des annulations automatiques et à des déploiements de production échelonnés. Cette automatisation minimise l’impact potentiel de l’échec des déploiements sur la production, et les développeurs n’ont plus besoin de surveiller activement les déploiements jusqu’à la production. **Anti-modèles courants :** + Vous effectuez des modifications manuelles. + Vous sautez des étapes de l’automatisation grâce à des flux de travail d’urgence manuels. + Vous ne suivez pas les plans et processus établis au profit de délais accélérés. + Vous effectuez des déploiements de suivi rapides sans prévoir de durée d’intégration. **Avantages du respect de cette bonne pratique :** lorsque vous utilisez l’automatisation pour déployer toutes les modifications, vous éliminez le risque d’erreur humaine et vous offrez la possibilité de tester avant de modifier la production. L’exécution de ce processus avant la phase de production permet de vérifier que vos plans sont complets. En outre, la restauration automatique de votre processus de publication peut identifier les problèmes de production et ramener votre charge de travail à son état de fonctionnement antérieur. **Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen ## Directives d’implémentation Automatisez votre pipeline de déploiement. Le déploiement des pipelines vous permet d’une part d’invoquer des tests automatisés et la détection des anomalies et, d’autre part, d’arrêter le pipeline à une certaine étape avant le déploiement en production ou de restaurer automatiquement l’environnement d’avant la modification. L’adoption de la culture de l’[intégration continue et de la livraison/du déploiement continus](https://en.wikipedia.org/wiki/CI/CD) (CI/CD) en fait partie intégrante. Lors de celle-ci, un commit ou une modification de code passe par différentes étapes automatisées, des étapes de construction et de test au déploiement dans les environnements de production. Bien que les principes traditionnels suggèrent d’impliquer l’intervention humaine pour les procédures opérationnelles les plus complexes, nous vous conseillons d’automatiser ces mêmes procédures pour cette même raison. ### Étapes d’implémentation Vous pouvez automatiser les déploiements pour supprimer les opérations manuelles en procédant comme suit : + **Configurez un référentiel de code pour stocker votre code en toute sécurité :** utilisez un système de gestion de code source hébergé basé sur une technologie populaire telle que Git pour stocker votre code source et votre configuration d’infrastructure en tant que code (IaC). + **Configurez un service d’intégration continue pour compiler votre code source, exécuter des tests et créer des artefacts de déploiement :** pour configurer un projet de génération à cette fin, voir [Commencer avec l’utilisation de la console par AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/getting-started.html). + **Configurez un service de déploiement qui automatise les déploiements d’applications et gère la complexité des mises à jour des applications sans recourir à des déploiements manuels sujets aux erreurs :** [AWS CodeDeploy](https://aws.amazon.com/codedeploy/) automatise les déploiements de logiciels vers divers services informatiques, tels qu’Amazon EC2 [AWS Fargate](https://aws.amazon.com/fargate/), [AWS Lambda](https://aws.amazon.com/lambda) et vos serveurs sur site. Pour configurer ces étapes, consultez [Premiers pas avec CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/getting-started-codedeploy.html). + **Configurez un service de livraison continue qui automatise vos pipelines de publication pour des mises à jour plus rapides et plus fiables des applications et de l’infrastructure :** envisagez d’utiliser [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/getting-started-codepipeline.html) pour vous aider à automatiser vos pipelines de publication. Pour plus de détails, consultez les [didacticiels CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials.html). ## Ressources **Bonnes pratiques associées:** + [OPS05-BP04 Utiliser des systèmes de gestion du développement et du déploiement](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_build_mgmt_sys.html) + [OPS05-BP10 Automatiser complètement l’intégration et le déploiement](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_auto_integ_deploy.html) + [OPS06-BP02 Déploiements de tests](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_mit_deploy_risks_test_val_chg.html) + [OPS06-BP04 Automatiser les tests et les restaurations](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_mit_deploy_risks_auto_testing_and_rollback.html) **Documents connexes:** + [Livraison continue de piles AWS CloudFormation imbriquées à l’aide de AWS CodePipeline](https://aws.amazon.com/blogs/devops/continuous-delivery-of-nested-aws-cloudformation-stacks-using-aws-codepipeline) + [Partenaire APN : partenaires pouvant vous aider à créer des solutions de déploiement automatisées](https://aws.amazon.com/partners/find/results/?keyword=devops) + [AWS Marketplace: produits pouvant être utilisés pour automatiser vos déploiements](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps) + [Automatisez les messages de chat avec les webhooks.](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html) + [L’Amazon Builders’ Library : Garantir la sécurité des restaurations pendant les déploiements](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments) + [L’Amazon Builders’ Library : Aller plus vite avec la distribution continue](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/) + [Qu’est-ce que AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) + [Qu’est-ce que CodeDeploy?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) + [AWS Gestionnaire de correctifs d’ Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) + [Qu’est-ce qu’Amazon SES?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html) + [Qu’est-ce qu’Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) **Vidéos connexes:** + [AWS Summit 2019: CI/CD on AWS](https://youtu.be/tQcF6SqWCoY)