Comprendre le Chaos Engineering et les outils qui en découlent

Comment définir une stratégie de chaos engineering ?

Concrètement, le chaos engineering c’est choisir comme cible une ou plusieurs pièces de l’infrastructure à éprouver et les rendre indisponibles :

• Éteindre/Redémarrer une VM
• Dropper des trames TCP
• Supprimer des pods Kubernetes

L’infrastructure doit réagir à cette perte et retrouver rapidement son état stable. Cela passe par l’automatisation de recréation de ressources comme le fait nativement Kubernetes. C’est cette capacité à s’auto-régénérer, appelée résilience, qui est mise à l’épreuve en chaos engineering. Comme expliqué dans les principes du chaos engineering, l'approche se base sur 4 principes :

Définir un état stable

L’état stable est celui dans lequel l’infrastructure délivre le service attendu dans les temps attendu. Ces niveaux d’attentes sont définis par le SRE sous forme de SLO, pour Service Level Objectives et surtout ils sont mesurés par des SLI, pour Service Level Indicators.

Le monitoring est le moyen de définir l’état stable de l’infrastructure, d’y parvenir et de le maintenir. Plusieurs outils de monitoring open source et très performants sont disponibles. Ci-dessous, vous pouvez trouver un exemple de dashboard Grafana représentant l’activité d’une application.

Cette partie est essentielle afin de pouvoir descendre dans la mise en place du chaos engineering et heureusement, ce travail est déjà l’adage des Site Reliability Engineers qui savent dégager les indicateurs clefs du cycle de vie d’une application.

Émettre une ou plusieurs hypothèses

La confiance n'évite pas le contrôle.

C’est l'action de définir des hypothèses qui marquent l’entrée dans la réflexion chaos engineering. Par exemple : “Mon infrastructure conserve son état stable après la perte d’un nœud Kubernetes, de 2 ou après une panne de disque ”.

Sous la forme d’une affirmation, l’hypothèse établie le niveau de confiance souhaité. À l’image de l’évaluation des risques en cybersécurité, le chaos engineer place ses hypothèses selon la gravité et la probabilité de l’apparition du dysfonctionnement.

Les ingénieurs ont dégagé des niveaux de qualité à atteindre pour obtenir un niveau de confiance dans leurs produits. Le but de la manœuvre est de construire une plateforme résistante à des conditions 'menaçantes', supérieures à ce qu'elles seraient en production.

Définir des conditions expérimentales

Une fois les hypothèses précisées, il faut définir des conditions expérimentales en adéquation avec les briques d’infrastructure à éprouver. La perte d’un nœud Kubernetes se traduit par l’extinction planifiée de la VM dans l’hyperviseur VMWare par exemple et pour la panne de disque, cela peut être une surcharge d’IO ou bien sa déconnexion pure et simple.

Pour appliquer ces conditions, il faut ensuite se tourner vers les outils de chaos engineering adaptés. Tout déploiement peut être envisagé comme faillible : de la panne hardware à la saturation du réseau en passant par l'envoi de réponses HTTP mal formées. Même les AWS lambda peuvent être ciblées, (voir l'outil open source chaos-lambda).

Étudier l'écart

Ce qu’il faut observer dans l’écart c’est d’une part le rétablissement de l’état stable et le temps passé entre l’apparition du dysfonctionnement et le retour à la normale.

Sur cette demo de chaos-mesh (outil de chaos engineering que je détaille plus bas), on voit très nettement sur les graphes de Grafana, un retour très lent à l’état stable. C’est grâce à la bonne supervision de l’infrastructure induite par le principe de définition de l’état stable que les indicateurs permettent de dégager des écarts pertinents.

L’étape suivante consiste à catégoriser ces écarts en gardant en tête la question suivante : “Combien coûte 1 / 2 / 5 minutes de déni de service ?”. L'objectif est d'établir quels sont ceux à traiter en axes d’améliorations et ceux qui sont acceptés.

"D'accord mais comment je mets ça en place ?"

Outils

La palette des outils de chaos engineering s'est étoffée ces dernières années. La plupart d'entre eux sont créés pour être déployés sur un cluster Kubernetes (les kubes dont on parlait dans l'intro 😉). Ceux-ci implémentent les conditions expérimentales que les chaos engineers ont conceptualisées.

Tous les outils que je vous présente ci-dessous sont affichés sur le site de la cncf.

Il y a ceux qui s’attaquent à Kubernetes :

• chaoskube qui n’a pas la prétention d’être fourni mais qui se concentre sur la suppression aléatoire de pods Kubernetes et qui le fait parfaitement.

• chaos-mesh dont les scénarios sont très simples mais efficaces :
• pod/conteneur kill ou failure
• CPU/memory burn
• Kernel/Time chaos
• IO/Network chaos

Il y a les couteaux suisses :

• Litmus qui propose au travers d’un catalogue de scénarios nommé ChaosHub, certains essentiels mais offrant la possibilité à la communauté de contribuer en publiant leurs scénarios et donc d'agrandir rapidement le catalogue.

• chaosblade qui capitalise sur les pratiques du fournisseur cloud chinois Alibaba. Il permet d’attaquer les ressources basiques comme CPU, mémoire, disques ; mais également des applications en Java ou en C++ et aussi des conteneurs Docker ou des objets Kubernetes

Il y a les outils guidés :

• PowerfulSeal qui s’attaque à Kubernetes, OpenStack, AWS, Azure, GCP, qui se connecte facilement à Prometheus et Datadog pour analyser son activité mais qui surtout peut être lancé en mode autonome ! Ce qui permet, en se contentant de conditions expérimentales prédéfinies, de se concentrer l’analyse des résultats et sur la recherche des pièces faillibles.

• ChaosToolkit, une API open source qui se veut suffisamment simple d’utilisation pour se présenter comme facilitateur de l’adoption du chaos engineering avec des conditions expérimentales rédigées au format JSON

Avantages et inconvénients

Avantages

Les avantages du chaos engineering sont nombreux et tournent tous autour du gain de confiance que cette pratique apporte. En effet, cela permet d’établir une marge de panne mesurée et anticipée dans laquelle l’infrastructure conserve son état stable et continue de délivrer le service comme attendu.

Après avoir fait vos premiers pas dans ce modèle, si vous sentez avoir gagné en maturité, il devient envisageable d'appliquer les conditions expérimentales du chaos engineering à votre production. En décision avec votre SRE, et selon “l'error budget”, des dénis de service sont acceptés s'ils sont contrôlés, surveillés et contenus et peuvent dégager de nouveaux axes d'amélioration.

Inconvénients

Ce qui n’est pas forcément un inconvénient mais qui peut freiner la mise en place de chaos engineering sur son infrastructure c’est la remise en question que cela implique. Il faut faire preuve d’une humilité vertueuse qui amènera à plus de résilience, c’est un passage obligé.

Ensuite c’est la mise en évidence des dysfonctionnements qui peuvent être tellement divers qu’il est facilement possible d’en oublier certains et ceux-ci peuvent s’avérer relativement graves et probables.

Le chaos engineering s'adresse à toute équipe de production informatique soucieuse de la qualité de sa livraison d'infrastructure et de la résilience de cette dernière : sa capacité à résister aux chocs et à s'auto-régénérer.

Les barrières à l'entrée technique sont relativement faibles, en revanche, il faut un certain temps de conception pour implémenter ces pratiques sur une infrastructure existante voire pour l'intégrer au déploiement d'une future plateforme.

On peut prendre en exemple les GAFAM qui ont implémenté le chaos engineering et autres Netflix, Dailymotion, LinkedIn, UnderArmour, Expedia, Target / Wallmart et qui sont parmi les plateformes les plus robustes à l'heure actuelle.

"Mais alors les singes dans cette histoire ?" Et bien je vous laisse lire cet article sur Kube-monkey