REL11-BP03 Automatiser la guérison sur toutes les couches - AWS Framework Well-Architected
Directives d’implémentation Ressources

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

REL11-BP03 Automatiser la guérison sur toutes les couches

Utilisez des capacités automatisées pour effectuer des actions correctives en cas de détection d’une défaillance. Les dégradations peuvent être automatiquement corrigées par le biais de mécanismes de service internes ou peuvent nécessiter le redémarrage ou la suppression des ressources par le biais d’actions correctives.

Pour les applications autogérées et la réparation interrégionale, les modèles de restauration et les processus de réparation automatisés peuvent être extraits des bonnes pratiques existantes.

Pouvoir redémarrer ou supprimer une ressource est important pour remédier aux défaillances. Une bonne pratique consiste à rendre les services sans état dans la mesure du possible. Cela évite toute perte de données ou de disponibilité au redémarrage des ressources. Dans le cloud, vous pouvez (et devriez généralement) remplacer la totalité de la ressource (par exemple, une instance de calcul ou une fonction sans serveur) dans le cadre du redémarrage. Le redémarrage proprement dit est un moyen simple et fiable de récupération après une défaillance. De nombreux types de défaillances différents se produisent dans les charges de travail. Les défaillances peuvent se produire au niveau du matériel, des logiciels, des communications et des opérations.

Le redémarrage ou la nouvelle tentative s’appliquent également aux requêtes réseau. Appliquez la même approche de récupération à la fois pour un délai d’expiration réseau et une défaillance de la dépendance, si la dépendance renvoie une erreur. Comme ces deux événements ont un effet semblable sur le système, plutôt que d’essayer de traiter l’un ou l’autre comme un « cas particulier », appliquez une stratégie semblable de nouvelle tentative limitée avec un backoff exponentiel et une instabilité. La possibilité d’exécuter un redémarrage est un mécanisme de récupération présenté dans l’informatique orientée récupération et dans les architectures de cluster haute disponibilité.

Résultat souhaité : des actions automatisées sont effectuées pour remédier à la détection d’une panne.

Anti-modèles courants :

  • Allocation des ressources sans mise à l’échelle automatique.

  • Déploiement d’applications une par une dans des instances ou des conteneurs.

  • Déploiement d’applications qui ne peuvent pas être déployées dans plusieurs emplacements sans utiliser la récupération automatique.

  • Réparation manuelle des applications impossible à réparer par la mise à l’échelle et la récupération automatiques.

  • Aucune automatisation pour le basculement des bases de données.

  • Absence de méthodes automatisées pour rediriger le trafic vers de nouveaux points de terminaison.

  • Aucune réplication du stockage.

Avantages du respect de cette bonne pratique : la réparation automatisée contribue à réduire le temps moyen de récupération et à améliorer votre disponibilité.

Niveau d’exposition au risque si cette bonne pratique n’est pas respectée : élevé

Directives d’implémentation

Les conceptions d'Amazon EKS ou d'autres services Kubernetes doivent inclure à la fois un minimum et un maximum de répliques ou d'ensembles dynamiques, ainsi que le dimensionnement minimal des clusters et des groupes de nœuds. Ces mécanismes mettent à disposition un minimum de ressources de traitement en permanence tout en corrigeant automatiquement les défaillances à l’aide du plan de contrôle Kubernetes.

Les modèles de conception accessibles via un équilibreur de charge utilisant des clusters de calcul doivent tirer parti des groupes Auto Scaling. Elastic Load Balancing (ELB) distribue automatiquement le trafic applicatif entrant sur plusieurs cibles et appliances virtuelles dans une ou plusieurs zones de disponibilité (AZs).

La taille des conceptions basées sur le calcul en cluster qui n’utilisent pas l’équilibrage de charge doit être conçue pour la perte d’au moins un nœud. Cela permet au service de continuer à fonctionner avec une capacité potentiellement réduite pendant la restauration d’un nouveau nœud. Mongo, DynamoDB Accelerator, Amazon Redshift, Amazon, Cassandra, MSK Kafka, EC2 -, Couchbase et EMR Amazon Service sont des exemples de services. ELK OpenSearch Bon nombre de ces services peuvent être conçus avec des fonctionnalités supplémentaires de réparation automatique. Certaines technologies de cluster doivent générer une alerte en cas de perte d’un nœud, déclenchant un flux de travail automatique ou manuel pour recréer un nœud. Ce flux de travail peut être automatisé AWS Systems Manager pour résoudre rapidement les problèmes.

Amazon EventBridge peut être utilisé pour surveiller et filtrer des événements tels que des CloudWatch alarmes ou des changements d'état dans d'autres AWS services. Sur la base des informations relatives aux événements, il peut ensuite invoquer AWS Lambda Systems Manager Automation ou d'autres cibles pour exécuter une logique de correction personnalisée sur votre charge de travail. Amazon EC2 Auto Scaling peut être configuré pour vérifier l'état de l'EC2instance. Si l'instance est dans un état autre qu'en cours d'exécution, ou si l'état du système est altéré, Amazon EC2 Auto Scaling considère que l'instance n'est pas saine et lance une instance de remplacement. Pour les remplacements à grande échelle (comme la perte d’une zone de disponibilité complète), il est préférable d’opter pour la stabilité statique pour une haute disponibilité.

Étapes d’implémentation

  • Utilisez des groupes Auto Scaling pour déployer des niveaux dans une charge de travail. L’autoscaling peut effectuer une autoréparation sur les applications sans état et ajouter ou supprimer de la capacité.

  • Pour les instances de calcul mentionnées précédemment, utilisez l’équilibrage de charge et choisissez le type d’équilibreur de charge approprié.

  • Envisagez de guérir pour AmazonRDS. Avec les instances de secours, configurez le basculement automatique vers l’instance de secours. Pour Amazon RDS Read Replica, un flux de travail automatisé est nécessaire pour créer une réplique de lecture principale.

  • Mettez en œuvre la restauration automatique sur les EC2 instances dont les applications ne peuvent pas être déployées sur plusieurs sites et qui peuvent tolérer le redémarrage en cas de panne. La récupération automatique peut être utilisée pour remplacer du matériel défaillant et redémarrer l’instance lorsque l’application ne peut pas être déployée sur plusieurs emplacements. Les métadonnées de l'instance et les adresses IP associées sont conservées, ainsi que les EBSvolumes et les points de montage vers Amazon Elastic File System ou File Systems for Lustre et Windows. À l'aide de AWS OpsWorks, vous pouvez configurer la guérison automatique des EC2 instances au niveau de la couche.

  • Implémentez la récupération automatique à l’aide d’AWS Step Functions et d’AWS Lambda lorsque vous ne pouvez pas utiliser la mise à l’échelle automatique ou la récupération automatique, ou lorsque la récupération automatique échoue. Lorsque vous ne pouvez pas utiliser le dimensionnement automatique, que vous ne pouvez pas utiliser la restauration automatique ou que la restauration automatique échoue, vous pouvez automatiser la guérison à l'aide de AWS Step Functions et AWS Lambda.

  • Amazon EventBridge peut être utilisé pour surveiller et filtrer des événements tels que des CloudWatchalarmes ou des changements d'état dans d'autres AWS services. En fonction des informations d’événement, il peut ensuite invoquer AWS Lambda (ou d’autres cibles) pour exécuter une logique de correction personnalisée sur votre charge de travail.

Ressources

Bonnes pratiques associées :

Documents connexes :

Vidéos connexes :

Exemples connexes :

Outils associés :