Introduction au concept du Chaos Engineering

Les étapes à suivre pour un système robuste

6 min readDec 1, 2021

Introduction

L’ingénierie du Chaos (Chaos Engineering) est une discipline visant à tester un système, telle qu’une application, afin de connaître sa capacité à faire face à des crises de gravités variables en environnement de production. L’optique de la manœuvre est ainsi de prévenir des perturbations ou interruptions de services.

La panne massive qu’a connu OVH il y a quelques semaines, causée par une erreur humaine de reconfiguration réseau, est un bon exemple de crise qui peut être prévenue grâce au Chaos Engineering.

Ce concept, qui s’est vu fortement boosté au début des années 2010, s’applique suivant une méthodologie précise et s’appuie sur un modèle à adapter selon le besoin.

Ce sont ces éléments que nous explorerons dans cet article, afin de savoir quelle stratégie adopter pour tester son système de manière efficace.

1- Le concept

Le principe de l’ingénierie du Chaos est simple : casser un ou plusieurs composants de son système en générant une perturbation telle que :

L’arrêt d’une ou plusieurs ressources
La désactivation d’un serveur
L’introduction de latences
La création d’incidents réseau
La suppression des données d’un ensemble de ressources
L’intensification du trafic (ex : augmentation du nombre de requêtes par minute)
La déconnexion du système entier (ex : toutes les ressources d’une application) au Datacenter

Le tout est ensuite d’observer la réaction du système face à cette(ces) perturbation(s), et de faire un comparatif avec les prévisions théoriques initialement déterminées. Ce faisant, il sera alors possible de connaître :

Les vulnérabilités à corriger
Les aspects qui peuvent impacter le service et les utilisateurs finaux
Les mécanismes de prévention à mettre en place
Les comportements à adopter en environnement de production

Il convient de préciser que la thématique étudiée ici diffère de la notion de tests unitaires. En effet, un test unitaire permet de vérifier une propriété connue sur une partie spécifique d’un logiciel ou d’un programme. A contrario, un test de Chaos Engineering mêle une combinaison d’hypothèses, de variables et de paramètres, survenant à un instant pas forcément connu et à une échelle variable du système étudié. Ces deux concepts, bien qu’alliables, ne visent donc pas les mêmes problématiques.

Maintenant que nous connaissons ces grands principes, place à la méthodologie !

2- Les étapes à suivre

Emettre une hypothèse

Cette première étape consiste, à partir d’une situation stable, à supposer la réaction de son système face à une perturbation réaliste donnée. Le succès de cette hypothèse sera notamment vérifié grâce à des valeurs de métriques prédéfinies, telles que la latence, le nombre de ressources encore actives, le nombre de requêtes par seconde ou le nombre de commandes utilisateurs passées sur une période donnée.

Déclencher la perturbation

En accord avec ce qui a été décrit dans l’hypothèse, vient l’étape de la mise en place, en environnement hors production, des événements qui viendront perturber le comportement routinier du système. C’est cette phase qui donnera la meilleure idée de ce qui pourrait se passer en production, et indiquera donc un ensemble (non exhaustif) de mesures à prendre pour limiter la casse le moment venu. Ces correctifs seront apportés à l’environnement hors-production mais également à celui de production, afin de renforcer et préparer au mieux ce dernier.

Une fois le test hors production entièrement étudié, la même perturbation est introduite en environnements de pré-production et de production. Cette étape peut révéler des vulnérabilités supplémentaires, induites par les incidents rencontrés en conditions réelles. Les mesures additionnelles associées à ces vulnérabilités seront également à instaurer dans le système.

Automatiser les expériences pour une exécution continue

Une fois que le « quoi » et le « comment » ont été étudiés, il faut étudier la question du «quand ». Pour étudier cette dernière au mieux, il semble pertinent de perturber le système à répétition. Cela ne veut pas pour autant dire que les perturbations doivent être périodiques, au contraire ! Définir des occurrences aléatoires est ce qui reflète le mieux la réalité.

Minimiser l’étendue des dégâts

Les valeurs de métriques initialement définies permettent de surveiller le comportement du système, mais également de maîtriser les dégâts causés en effectuant les actions nécessaires aux moments opportuns. Au-delà du système, l’objectif est aussi de réduire l’impact de l’incident sur les consommateurs du service.

Vérifier l’hypothèse

La dernière étape est celle durant laquelle l’hypothèse de départ est comparée à ce qui s’est réellement passé. Dans le cas où la robustesse du système a été vérifiée, il n’y a rien à changer. Dans le cas contraire, l’expérience aura mis en lumière une vulnérabilité à traiter. Ces deux résultats sont efficaces car ils permettent tous deux de mieux connaître l’aspect du système qui a été étudié.

3- Quelques modèles Open Source de perturbations

Netflix, pionnier du concept, a présenté au début des années 2010 ses outils et modèles de Chaos Engineering pour gérer son infrastructure dans le cloud AWS : la Simian Army. Parmi les modèles qui ont fortement contribué à la résilience du leader de la VOD, nous retrouvons :

Chaos Monkey (désactive des ressources de manière aléatoire)
Chaos Gorilla (neutralise une zone de disponibilité entière)
Chaos Kong (attaque une région entière)
Latency Monkey (injecte de la latence sur une requête)

Le modèle Chaos Monkey a su se préserver dans le temps et reste à ce jour un incontournable. Il a aussi vu naître d’autres modèles, répondant à des cas d’usages, architectures et objectifs différents. A ses côtés figurent, entre autres, les solutions suivantes :

Gremlin: ce logiciel permet d’effectuer des injections sur des serveurs ou des conteneurs Kubernetes, tout en gardant le contrôle sur ces événements. Les attaques peuvent viser les paramètres des ressources (utilisation de CPU, RAM , etc.), leur état, le trafic entrant ou encore l’état du réseau.

Chaos Toolkit: ce modèle s’adresse aux plateformes Docker, Kubernetes ou encore cloud et offre la possibilité de créer simplement ses propres tests. Chaque test est constitué d’Actions (commandes exécutées sur la cible interne au système) et de Probes (comparatif entre le résultat des commandes exécutées et les valeurs attendues).

Litmus: cet autre outil open source se concentre spécifiquement sur des ressources Kubernetes, et induit des perturbations telles que des suppressions de pods, rend des nœuds ou des clusters indisponibles.

Que retenir ?

Les systèmes actuels présentent une multitude de paramètres et de variables à prendre en compte à différentes échelles. C’est à ce niveau qu’intervient l’Ingénierie du Chaos, qui prévient les pannes et pertes importantes, met en lumière les dépendances intra-système, améliore la résilience et maîtrise au mieux l’expérience utilisateur.

Le Chaos Engineering, avec les bonnes clés, a su ainsi montrer sa pertinence au fil des années, plus spécifiquement vis-à-vis des systèmes de grande ampleur. Pour ne pas se retrouver victime d’incidents internes ou de cyber-attaques, il convient donc de prévoir la mise en place d’infrastructures, de ressources, de solutions et de mécanismes nécessaires au sein de son Système d’Information. Ces mesures de prévention sont d’autant plus importantes à mettre en place dans les structures sensibles, telles que les Opérateurs de Services Essentiels (transports, santé, énergie, banques, etc.).

Des modèles de Chaos Engineering ont su faire leurs preuves pour répondre à différents besoins, en Datacenter comme dans le cloud. Et pour aller plus loin, il est même possible de créer son propre modèle, afin d’éprouver son Datacenter.

Si vous avez une question ou un besoin d’accompagnement sur l’un des aspects abordés dans cet article, n’hésitez pas à contacter Pramana !