Le "Chaos Engineering", "Ingénierie du chaos", terme récemment mis en lumière par Netflix, correspond à toutes les activités liées à "l’injection de conditions d’échecs" chez Netflix. Bruce Wong, responsable de ces questions chez Netflix, a écrit un article à ce sujet, expliquant en quoi cela consiste, quels en sont les objectifs et quelle est sa feuille de route pour les réaliser.
InfoQ a contacté Bruce pour en savoir plus.
Bien que le terme "Chaos Engineering" soit nouveau, Bruce souligne qu’il ne s’agit pas d’une "discipline nouvelle mais qu’il correspond plutôt à un renfort d’investissements sur une discipline, une philosophie déjà bien établie chez Netflix [à savoir l’injection de conditions d’échecs en production pour s’assurer de la tolérance aux pannes des systèmes – Ed.]". Netflix cherche à faire du "test de régression par le chaos dans le cadre des systèmes distribués à grande échelle" une discipline aussi bien maîtrisée que le test de régression classique. Ces augmentations d’investissements reflètent la nécessité pour Netflix de relever différents défis.
Bruce explique que Netflix se doit d’accompagner l’expansion d’Internet :
Internet continuant de s’étendre, tout ce qui travaille à l’échelle du Web s’étend aussi. Construire et faire tourner des systèmes à grande échelle sont des activités encore relativement jeunes. Dans ce domaine, il n’y a pas un moment où on arrive définitivement au bout, surtout quand votre base d’utilisateurs et la complexité à laquelle vous faîtes face continuent de croître. Même s’il y a beaucoup de recherches et de connaissances sur la façon dont les systèmes distribués tombent en panne, nous sommes encore en train d’apprendre et de faire évoluer nos technologies, ce qui créer de nouveaux modes d’échec fascinants à prendre en compte. Le "Chaos testing" met en lumière l’incapacité à tester la résilience de façon précise à grande échelle et l’incapacité à simuler "l’Internet".
Pour Netflix, Amazon Web Services (AWS), l’écosystème Cloud qu’ils utilisent pour l’exécution de leurs services, gagne en fiabilité au fil du temps :
AWS devient de plus en plus fiable, ce qui nous pousse à devenir proactifs sur l’injection de conditions de pannes. Si l’environnement et l’infrastructure n’étaient pas aussi stables, cela nous servirait de contrainte nous forçant à faire en sorte que nos systèmes soient résilients. Mais avec la stabilité d’AWS, la tolérance de pannes ne reste pas nécessairement parmi nos premières préoccupations.
Cependant, AWS n’est pas stable au point où les pannes ne se passent que les 36 du mois. Bruce fait référence à un exemple connu, celui de l’indisponibilité d’un ELB régional, à la veille de Noël en 2012, pour illustrer ce genre de problèmes. Cette indisponibilité en particulier avait poussé Netflix à investir dans une infrastructure multirégionale Active-Active. Chacun de ces événements "renforce l’implication [de Netflix] dans le chaos [l’injection de pannes – Ed.]" et représente des scénarios que le Chaos Engineering cherche à trouver et mitiger de façon proactive.
Netflix a défini une approche en trois volets pour la mise en oeuvre du Chaos Engineering : établir des cercles vertueux d’injection des effets chaotiques, élargir l’utilisation de design patterns de fiabilité, anticiper les futurs modes d’échecs.
Cercles vertueux d’injection des effets chaotiques
Netflix a constaté qu’il lui fallait plus d’outillage pour le support de ces cycles. Bruce estime qu’il est possible d’améliorer la Simian Army qui a déjà aidé Netflix dans les problématiques de résilience :
Il y a quelques domaines où nous souhaitons investir plus. Nos investissements devraient nous donner un contrôle plus fin, pour gagner en confiance, disons entre le Chaos Monkey [qui arrête des machines de production au hazard – Ed.] et le Chaos Gorilla [qui simule un arrêt complet de toute une zone de disponibilité d’Amazon – Ed.]. Au fur et à mesure que notre degré de confiance progresse, nous pouvons injecter des effets de chaos de façon plus fréquente, ce qui réduit les possibilités de dérive entre les simulations. Réduire les possibilités de dérive nous permet aussi d’innover plus vite et plus fréquemment sans compromettre la disponibilité.
Tout en faisant croître notre infrastructure en complexité et en taille, nous arrivons constamment avec de nouvelles idées de Monkeys pour nous aider. Nos Hack Days, par exemple, sont en quelque sorte les incubateurs de nos futurs Monkeys. Netflix pratique également des post-mortem sans blâmes suivies d’un plan d’action pour éviter la réapparition des cas d’échec précédents.
Design Patterns de fiabilité
Netflix ayant adopté une architecture de microservices, la prise en charge cohérente des échecs et des modes de service dégradés est essentielle. D’après Bruce, il s’agit d’un des domaines où Netflix recherche activement des avancées significatives :
Les deux domaines de recherche auxquels nous nous intéressons dans le cadre du "Chaos Engineering" sont les nouvelles formes de chaos et les design patterns de fiabilité. Nous continuerons à publier les résultats de ces recherches au fur et à mesure de nos avancées.
Par exemple, les coupe-circuits, tel qu’implémentés dans Hysterix, ont réellement "changé la donne quand il ont été mis en place [par Netflix]", explique Bruce.
Anticiper les futurs modes d’échec
Le travail à l’échelle du Web est un territoire encore relativement inexploré. Dans un monde idéal, les systèmes distribués devraient être si tolérants aux pannes qu’ils ne devraient jamais échouer. Mais ce monde n’existe pas et la fiabilité croissante d’AWS peut instiller une certaine complaisance. Netflix réagit à cet effet pernicieux en recherchant de façon proactive de nouveaux modes d’échecs. Bruce explique comment Netflix procède :
Nous procédons de différentes façons pour identifier ces cas. Le premier et le plus simple est l’expérience. Quand nous sommes confrontés à une situation exceptionnelle, nous nous demandons toujours comment nous pouvons être sûrs de pouvoir y faire face. Nous ne nous satisfaisons pas de simples suppositions. La panne générale de Noël 2012 des ELB d’AWS, par exemple, a été une de ces occasions.
Notre stratégie en matière de conditions d’échecs complexes est de faire en sorte qu’il soit possible et sans risques de simuler et de tester en premier lieu à petite échelle. Ceci nous aide à construire la confiance nécessaire à l’exécution de scénarios de chaos à plus grande échelle. Par exemple, nous avons commencé par le Chaos Monkey avant d’essayer le Chaos Gorilla, et nous avons procédé de même pour le Chaos Kong [qui simule l’arrêt d’une région AWS complète – Ed.].