La boite à outils
Chaos Engineering du Javaiste
J’ai eu la chance lors du Devoxx 2019, d’assister à ce « Tools-in-Action » au sujet du chaos engineering. Présenté par Sylvain Maucourt, tech lead chez Edelia, cette conf n’a pas manquée de rythme et a eu un joli succès (la salle était comble !).
Chaos engineering, késako ?
Pour ceux qui n’en n’auraient jamais entendu parler, le chaos engineering est une pratique visant à améliorer la robustesse d’un système en production, en le soumettant à des turbulences et autres comportements imprévus (perturbations du réseau, latence sur les traitements d’un micro-service, perte de message etc.).
La présentation
« Everything fails all the time » – Werner Vogel
C’est sur cette citation que le « lab » démarre, histoire de donner le ton et d’entrevoir la philosophie du chaos engineering. S’ensuit une démo live sur comment perturber deux micro-services communiquant l’un avec l’autre. Ces deux micro-services sont simples, fait dans les règles de l’art, bien propres sur eux. Les systèmes sont lancés et on les voit fonctionner normalement et sans aucun soucis. L’enjeu sera donc ici de les perturber et d’observer ce qu’il se passe, afin de pouvoir ensuite essayer d’y apporter une solution visant à améliorer leur robustesse.
Premier test
Il s’agit d’utiliser chaos monkey for Spring boot, qui comme son nom le l’indique va nous permettre de créer des perturbations sur notre système réalisé en Spring boot. Cet outil de chaos engineering génère des attaques sur notre SI en ajoutant de la latence, des exceptions ou bien même en supprimant un processus. Précisons qu’il a connaissance du contexte du conteneur et donc des beans instanciés, ce qui lui permet d’agir sur toutes les couches de notre application.
La démonstration est lancée et l’on peut suivre ce qu’il se passe sur une console où tout est logué. Nous constatons bien des temps de traitement en très fortes augmentations, puis l’apparition d’exceptions, ce qui nous permet en effet de constater les faiblesses du SI. C’est alors que Sylvain nous pose l’ultime question: « Comment résoudre ce problème et améliorer la fiabilité du système ? ». Il nous propose pour cela d’utiliser un circuit breaker (principe du disjoncteur), en l’occurrence hystrix. On ajoute alors une simple dépendance dans le pom du projet, ce qui nous permet d’utiliser l’annotation « @HystrixCommand(fallback=fallbackMethodName) » sur la méthode responsable de l’appel et le tour est joué ! De cette façon Hystrix pourra rediriger vers la méthode de fallback lorsque la méthode annotée échoue.
Afin de démontrer que la solution fonctionne, le système est relancé et l’on constate bien la prise en charge du fallback qui affiche « Hello chaos! », lorsqu’il y a trop de latence ou qu’une exception survient. Premiers pas concluant dans l’univers du chaos engineering.
Second test
Cette fois-ci le principe d’attaque est différent. Il va falloir mettre en place un serveur proxy pour créer de la perturbation, non pas dans le système lui-même, mais entre nos deux micro-services.
L’outil qui sera utilisé pour cela c’est Toxyproxy. Il permet de créer des scénarios en ralentissant les connexions, en faisant du déni de requête etc. La démonstration sera faite via un test unitaire: connexion via Toxyproxy avec une route spécifique qui est paramétrée. De nouveau on pourra suivre les impacts des perturbations engendrées par l’outil, et de nouveau on constatera qu’Hystrix nous permet de résoudre le problème.
Le mot de la fin
On comprend bien l’intérêt de cette stratégie qui consiste à créer des perturbations aléatoirement sur nos systèmes afin de les éprouver. Cela nous permet d’entrevoir les possibilités d’un côté de faire des tests intégrés à nos services pour en perturber le comportement interne, et de l’autre à réaliser des tests de plus bas niveau sur la couche réseau, afin de révéler les faiblesse de notre architecture (particulièrement intéressant pour les micro-services et le cloud). Étant donné l’apparente simplicité de mise en œuvre, on a envie de foncer tête baissée, mais attention ! En chaos engineering l’objectif c’est de tester en production, gare à la casse si on a déjà des conditions d’exploitation difficiles.
Un point d’attention cependant: Netflix a passé Hystrix en mode maintenance (voir « Hystrix Status » du README). En effet, ils recommandent de n’utiliser Hystrix que sur les projets qui l’embarquent déjà mais de se tourner vers des solutions comme resilience4j, de conception plus moderne (« reactive and functional programming » notamment)