Chaos Engineering, principes et mise en application

Cette année, parmi les thèmes qui ont secoué DevoxxFr, le chaos engineering a fait son entrée à travers une conférence et un tool-in-action qui nous ont appris pas mal de choses.
Le chaos engineering, c’est une discipline en plein essor chez Thoughworks, QCon ou d’autres. Mais d’abord, c’est quoi le chaos ? Dans le framework cynefin, le chaos, c’est le dernier niveau de complexité (lisez par exemple cet article). Un autre outil conceptuel important, c’est la résilience, c’est-à-dire la capacité de la vie à résister aux perturbations.
https://twitter.com/TheBigPilou/status/986954631388565504
Le chaos engineering vise à accroître la résilience des systèmes d’information en les soumettant à des pannes prévues pour observer le rétablissement des fonctionnalités.

Comment s’articulent les tests et ce chaos engineering ?

En fait, quels que soient les tests (unitaires, intégration, technique), ils sont réalisés hors prod dans un environnement déterministe. Le chaos engineering complète tout cela en travaillant en production. Cela implique que le chaos engineering est ensembliste, en travaillant sur l’application en prod. Il est aussi non déterministe, puisqu’on ne sait pas trop ce qui se passe quand on agit.
Netflix donne une assez bonne définition sur https://principlesofchaos.org
Il y a plusieurs phases :

1. Que cherche-t-on à prouver
2. Restreindre le périmètre
3. Identifier ce qu’il faut observer
4. Communiquer
5. Injecter le chaos
6. Analyser les impacts
7. Recommencer

Ça devient important parce que pour les entreprises, les pannes deviennent plus préoccupantes que les failles de sécurité.
Comme le dit le CTO d’Amazon “everything fails all the time”. Le but est donc pour nous, puisqu’il y aura des pannes, de les provoquer au plus tôt pour les analyser et trouver la meilleure façon d’y survivre.
Pour ça, Amazon a créé chaos monkey. Leur implémentation marche bien chez eux, mais il s’agit en fait plutôt d’un concept, qui peut être implémenté n’importe où (kill -9 suffit à fournir une implémentation simple). Mais il vaut mieux faire une implémentation propre et adapté aux besoins locaux.
oui.sncf dispose donc d’un fulldisk monkey qui remplit les disques, d’un latency monkey qui ajoute des latences réseau, d’un properties monkey (pour modifier la configuration des applications), d’un processkiller monkey (pour tuer les processus autour de l’application).
Avant de mettre en prod, les chaos monkeys ont été livrés dans une version bridée aux développeurs pour qu’ils puissent tester leur application. Un an après avoir lancé le projet, le premier chaos monkey a été lancé en production. Il va donc maintenant être appliqué aux applications critiques de oui.sncf.
Une bonne pratique de l’équipe de résilience a été de lancer des game days afin d’identifier les équipes qui ont besoin d’avancer vers la résilience (voir days of chaos).
Pour préparer ça, l’équipe résilience est allée voir les ops pour leur demander quelles pannes seraient possibles. En deux heures, ils ont obtenu une bonne quarantaine de pannes. Par exemple, l’équipe ops s’est amusée à casser le lien entre le load balancer et l’application servie par celui-ci (et pour avoir déjà eu affaire à ce genre de panne, c’est bien vicieux).
Et tout ça, c’est évidemment du chaos engineering, puisque ça permet d’expérimenter sur un environnement iso-prod des pratiques qui dégradent cette prod.
Voir aussi https://medium.com/russmiles/chaos-engineering-for-the-business-17b723f26361
Cette conférence fournissait une bonne première approche du chaos engineering, avec les concepts clairement présentés, et une bonne vision du process permettant d’apporter cette culture aux équipes. Il fallait ensuite appliquer ça d’une manière un peu plus précise :

 

Ajouter du Chaos Engineering dans son cluster Kubernetes avec des opérateurs

L’objectif de la présentation, c’est de casser des pods Kubernetes à grands coups d’opérateurs K8s et de custom resources.

Dans une stack K8s, il y a :

• un déploiement
• un replica set géré par K8s. Son seul rôle est de compter les pods et de vérifier que c’est le bon nombre.
• des pods dans lesquels tourne l’application
• un service qui expose les pods
• un ingress qui rend tout ça accessible

Le but de la manœuvre est maintenant d’ajouter un Kaos Operator (qui est lui aussi un pod), qui va être utilisé pour arrêter des pods selon des Kaosrules.
Ça permet avant tout de tester que les sondes définies dans les applications sont correctes.
Le kaos operator utilisé est disponible sur Docker Hub : https://hub.docker.com/r/arnaudmz/kaos/
Et pour l’utiliser, il faut créer la custom resource definition. Ainsi que le kaos operator défini plus haut.
L’un des éléments essentiels est que l’opérateur envoie des événements à K8s lorsqu’il détruit un conteneur. Ça permet de suivre le fonctionnement de l’opérateur et d’expliquer l’état du cluster.
L’opérateur reçoit des événements de K8s qui vont lui permettre d’effectuer des actions. Les opérateurs courants sont par exemple le monitoring prometheus, rook (un système de stockage ceph distribué), heptio ark (qui fournit des sauvegardes) Il y a par ailleurs des opérateurs en cours de développement : soumettre des jobs spark, instancier des clusters Kafka, et globalement définir des bases de données managées.
Conclusion : Embrassez le chaos ! Dans des patterns d’architecture type K8s, c’est franchement pratique pour valider le bon fonctionnement d’une application.
Les CRD sont globalement une bonne idée, mais ça n’est pas encore totalement terminé dans tous les cas. Et surtout, les CRD et opérateurs nécessitent d’être administrateur !
 

Conclusion

A travers ces deux présentations, sans compter l’université donnée par Clément Escoffier le mercredi, on a pu voir apparaître le chaos engineering comme une méthode de validation d’une application, non pas à travers des tests ciblés qui permettent de valider qu’une fonctionnalité est conforme à un besoin, mais à travers la capacité des applications à être résilientes. Et pour le coup, il ne faut pas voir ça comme de la littérature, mais plus comme la capacité des applications à ne plus nécessiter des équipes d’astreintes en continu (ou tout au moins des équipes bien plus réduites), car les pannes simples ont déjà été prévues, et bénéficient de corrections appliquées automatiquement par l’écosystème applicatif.
Évidemment, cela entraîne des coûts de développement et de test supplémentaires, mais ça garantit une maintenance en état opérationnel bien au-delà des contraintes habituellement envisagées, pour approcher un maintien opérationnel dans le monde réel (c’est-à-dire résistant par exemple aux coups de pelleteuse dans les fibres optiques, aux pertes de sources d’alimentation sur un ou deux datacenters, et à tous ces événements qui font les choux gras de la presse spécialisée). Et surtout, ça garantit la tranquillité d’esprit des équipes.