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.
Mise en œuvre de l'ingénierie du chaos sur AWS
L'ingénierie du chaos fait partie de la phase d'évaluation et de test du cycle de vie de la AWS résilience, comme illustré dans le schéma suivant. Les applications distribuées ne fonctionnent pas indépendamment des autres applications ou clients. Nous vous recommandons donc de passer en revue le cycle de vie complet de la résilience. Le changement est constant pour les applications distribuées à mesure que le réseau évolue, que les applications en amont et en aval subissent des changements et que l'utilisation des clients change au fil du temps.
Pour comprendre l'impact que ces modifications apportées à votre application peuvent avoir sur sa résilience, intégrez l'ingénierie du chaos à vos day-to-day opérations. Vous pouvez implémenter des expériences de chaos de différentes manières :
-
Ad hoc : vous pouvez réaliser des expériences de chaos sous forme d'expériences ponctuelles pour résoudre un problème ou une question spécifique.
-
Chaos Game Days : il s'agit d'événements structurés et récurrents conçus pour vérifier la fiabilité et la résilience d'une application. Le but d'une journée de jeu sur le chaos est d'identifier les problèmes ou déficiences potentiels en matière de résilience chez les personnes, les processus et les technologies, et de mettre en pratique les processus et procédures permettant d'identifier, d'atténuer et de répondre aux incidents.
-
Chaos Pipeline — Intégration continue et livraison continue (CI/CD) is about building new features and deploying them safely throughout the environments. To implement chaos engineering experiments, create a chaos pipeline that's separate from your CI/CD pipeline. To understand why, let's assume that you want to add a single chaos engineering experiment to your CI/CDpipeline qui entraîne une perte de paquets croissante pour les composants en aval). Cette expérience est exécutée 3 fois et prend 5 minutes pour se terminer à chaque fois. La perte de paquets augmente de 10 % à 20 % à 30 % à chaque exécution, et l'expérience dure 15 minutes au total. Si vous avez 100 déploiements parallèles, vous devrez attendre 1 500 minutes pour qu'une seule expérience soit terminée. Si vous avez 10 expériences à réaliser, l'impact pour vos développeurs serait insupportable. À grande échelle, l'ingénierie du chaos a besoin de son propre pipeline qui vous permet de réaliser des expériences en parallèle avec votre processus de cycle de vie de développement logiciel (SDLC).
-
Déploiements Canary — Les îles Canaries fournissent un environnement de test pour les expériences de chaos. En dirigeant un faible pourcentage du trafic vers un service Canary ou en utilisant des méthodes telles que la mise en miroir du trafic ou le replay, vous pouvez vérifier la nouvelle infrastructure ou les modifications du code sans aucun impact sur votre système de production stable. Vous pouvez effectuer des tests sur le Canary et injecter des erreurs si nécessaire, car vous pouvez limiter l'impact sur l'utilisateur final.
-
Expériences planifiées : vous pouvez planifier des expériences afin de vérifier les mécanismes de restauration prévisibles pour votre application. Utilisez des expériences planifiées pour rejouer des événements courants afin de comprendre comment vos systèmes peuvent se remettre d'événements tels que la mise hors service d'une EC2 instance associée à un groupe de dimensionnement automatique, le retrait d'un pod Kubernetes ou la suppression d'une tâche Amazon ECS.
