Ingénierie du Chaos — Un exemple d’apprentissage

Il y a toujours quelque chose à apprendre!

Le contexte

Je travaille chez un leader du e-commerce de vente de voyage situé en france. Nous faisons du Chaos Engineering depuis maintenant 2 ans, ou plutôt nous faisions de la résilience avec du Chaos Monkey jusqu’à l’émergence du terme Chaos Engineering depuis un ou deux années. Ce terme est plus parlant et plus correct.

Il a fallu un certain temps pour sensibiliser les équipes et les dirigeants à l’importance de la résilience et de la valider sur les environnements de productions mais nous en sommes arrivés au point de l’expérimentation en production depuis bientôt presque une année. Point important, nous expérimentons aussi sur des applications critiques.

L’expérimentation

Expérimentation classique! Nous arrêtons une seule instance à la fois dans un seul composant de l’application ciblée. Nous regardons ensuite ce qui s’est passé depuis l’incident jusqu’à la résolution complète.

C’est une adaptation du fameux “Chaos Monkey” de netflix ou l’on arrête des instances de serveur et non des VM dans Amazon (car nous ne sommes pas hébergés chez Amazon).

Le plus important est de savoir si nous allons en tirer un enseignement…

Le protocole

Que souhaite-t-on tester? Valider la résilience générale des applications en cas de crash inopiné d’un serveur applicatif. On parle ici d’une application et pas d’une machine.

Quel est le périmètre? Validation technique sur une application et ses partenaires immédiats. Vérification du processus de prise en charge de l’arrêt inopiné des instances par l’exploitation et le suivi de production.

Les métriques à surveiller :

• Temps d’arrêt de l’instance avant redémarrage (manuel pour l’instant).
• Nombre d’erreurs sur l’application. Nous en déduirons l’impact en valeur sur le volume d’affaire.
• Dommages collatéraux (impact sur les applications amont et aval).

Communication autour de l’expérimentation. Le suivi de production est mis au courant de la première expérimentation en production. Un exploitant dédié y est présent pour éviter tout impact trop fort, surtout dans le cas d’une application critique. Seuls les développeurs seront au courant pour les expérimentations suivantes.

Réalisation. A la charge de l’équipe de développement de lancer son expérimentation sur sa production, au moment ou ils le souhaitent, et sur le périmètre qu’ils ont choisi. Personne d’autre n’a les droits pour lancer d’expérimentation à par les développeurs, et ils ne le peuvent que sur leurs applications.

Analyse et (actions). L’analyse doit être rigoureuse et une ressource est dédiée pour faire une analyse aussi poussée que lors d’un tir de charge. En cas de besoin, des actions pourront être lancées par l’équipe pour améliorer les résultats de leur application.

Évolution(s) de l’expérimentation. Élargir progressivement le scope à d’autres composants de l’application et envisager d’autres expérimentations.

Les premiers retours

La première conclusion que nous avons pu tirer est que nos applications sont correctement redondées. En dehors des threads en cours d’exécutions sur l’instance de serveur arrêtée (brutalement) il n’y a pas eu d’autres impacts ou erreurs. A noter que ces erreurs sont des erreurs “définitives” dans la plupart des cas. Nous avons en effet très peu de mécanisme de rejeu et pour l’instant notre stratégie est de remonter rapidement l’information au client.

Cependant notre plus grande surprise aura été de voir qu’il aura fallu longtemps pour que ces erreurs remontent à notre pilotage applicatif. En effet, dans le meilleur des cas il aura fallu pas moins de 20 minutes entre la détection et la remontée de l’erreur! Et dans le pire des cas jusqu’à 40 minutes!

C’est donc sur cette latence que nous avons souhaité porter nos premiers efforts en terme d’action.

La force de la répétition

Une rivière peut mettre des millions d’années pour creuser son lit. Bien que souvent négligée et sous estimée la force de la répétition est certainement une des plus fortes qui soit!

De la même manière, le constat que nous avions fait sur les 5 dernières exécutions est resté le même. A force de faire cette remontée, il est apparu important de prendre des mesures et de tenter de nouvelles approches au niveau de la détection et en particulier sur l’accélération de la remontée. La principale réticence côté exploitation concerne l’apparition de faux positifs entrainant de fausses alertes. Mettre du temps ne pose pas de soucis dans une infrastructure figée en taille et largement redondée pour absorber de grandes quantités de requêtes. Avec notre volonté de basculer sur des architectures adaptatives (on parle aussi d’infrastructures élastiques) nous souhaitons dimensionner notre infrastructure en fonction de la charge (auto-scaling). Ces nouvelles approches de détection sont donc un travail qui sera aussi préparatoire dans notre prochaine migration.

L’action en cours

La remontée des erreurs est actuellement dévolue à centreon. Centreon va procéder lui même à des vérifications avec une fréquence variable (de 3 à 5 minutes) et dans certains cas, pour éviter les faux positifs (serveur en train de redémarrer, etc…) ils faut attendre plusieurs cycles de vérification ce qui entraine une latence plus ou moins importante. Plutôt que de rester sur la détection initiale via centreon, nous expérimentons la détection via HAProxy qui est le load balancer en charge des vérifications des “healthcheck” des instances. Cette remontée est beaucoup plus rapide mais nécessite des “checks” complémentaires pour éviter les faux positifs et une remontée intempestive et inutile d’alerte.

En conclusion

Pour l’instant le Chaos Engineering nous permet de valider la confiance que nous portons dans notre production. Nous sommes bien redondés et les expérimentations n’ont pas entrainé de catastrophe. Mieux que cela, elles ont été quasiment invisibles pour les utilisateurs finaux et sans impact sur notre volume d’affaire.

Nous avons cependant commencé à relever des points que nous n’aurions pas forcément noté sans ces expérimentations et nous en relèverons certainement d’autres en diversifiant nos expérimentations. Il est aussi moins coûteux de s’en apercevoir de manière ciblée, contrôlée, répétée et en dehors d’une crise majeur.

You can think of #ChaosEngineering as a form of unit tests for your alarming and engagement process.

Matthew Fornaciari
@callmeforni
#Founder & #CTO @GremlinInc — avid practitioner of #chaosengineering