A l’instar de Netflix, AWS éprouve la résistance de son service de streaming Prime Video en introduisant de façon contrôlée des turbulences dans ses systèmes de production. C’est le principe de l’ingénierie du chaos. Cette discipline consiste à mettre un système à l’épreuve pour renforcer la confiance dans ses capacités à résister aux pannes lorsqu’il sera en production. On la doit principalement à Netflix qui l’a expérimentée avec son outil Chaos Monkey il y a déjà plusieurs années. Celui-ci arrêtait de manière pseudo-aléatoire un serveur de son service de vidéo en ligne afin de fournir à ses équipes informatiques un incident à résoudre dans les meilleures conditions d’intervention possibles, c’est-à-dire pendant les heures ouvrées à un moment prévu à l’avance. L’objectif étant de pouvoir en tirer enseignement pour faciliter la prise en charge des incidents réels intervenant dans un contexte plus délicat. 

« L’ingénierie du chaos nécessite d’adopter des pratiques pour identifier les interactions dans les systèmes distribués et les défaillances associées de façon proactive, ainsi que la mise en oeuvre et la validation de contre-mesures », rappelle AWS dans un billet daté du 18 août 2020 où l’opérateur de services cloud présente une approche d’injection de pannes (via AWS Systems Manager, SSM Agent) dans les systèmes utilisant Elastic Compute Cloud (EC2) et Elastic Container Service (ECS). Cette approche est associée à une suite de test de charge destinée à valider les contre-mesures mises en place. Elle aussi l’occasion de présenter la bibliothèque open source AWSSSMChaosRunner. La démonstration s’inspire d’un post de 2019 d’Adrian Hornsby, développeur en chef d’AWS, et elle s’accompagne d’un exemple expliquant comment Prime Video utilise la bibliothèque pour prévenir les problèmes pouvant avoir un impact sur les clients.

L'épuisement des ressources, un cas typique d'expérimentation

Dans le billet du 18 août, l’ingénieur logiciel Varun Jewalikar et Adrian Hornsby rappellent que les tests logiciels couramment pratiqués ne prennent pas en compte la totalité des possibilités d’interruption pouvant intervenir dans les systèmes distribués. Notamment ceux qui peuvent être liées à une panne sur la zone de disponibilité, à un problème de dépendance ou lié au réseau, etc. « Généralement, le comportement des logiciels à ces scénarios demeurent inconnus », expliquent MM Jewalikar et Hornsby. « Par exemple, que se passe-t-il si une instance Amazon EC2 dans la flotte du service supporte une consommation CPU élevée ? Une telle situation peut se produire en raison d’une augmentation inattendue du trafic ou bien d’une boucle mise en oeuvre de façon incorrecte dans le code ». Il est difficile d’avoir entièrement confiance dans des systèmes que l’on n’a pas mis à l’épreuve.

Quelles sont les questions à prendre en considération ? AWS en cite plusieurs. A-t-on par exemple testé la façon dont réagit le système lorsque les instances sous-jacentes connaissent un pic d’utilisation d’un CPU ? Est-ce que le monitoring des systèmes est suffisant ? Les alarmes ont-elles été validées ? Y a-t-il des contre-mesures mises en oeuvre ? « Par exemple, est-ce que la mise à l’échelle automatique est mise en place et est-ce qu’elle se comporte comme prévu ? Les délais d’expiration et les nouvelles tentatives sont-elles appropriées ? », énumèrent les ingénieurs logiciels d'AWS. Parmi les expériences typiques d’ingénierie du chaos, ils citent l’épuisement des ressources, le contrôle de ces dernières pouvant se faire en s’assurant que les pratiques de monitoring sont capables de détecter les défaillances. Autre exemple, celui des dépendances réseau défaillante ou trop lente. Dans la suite du billet, ils présentent l’utilisation de la bibliothèque AWSSSMChaosRunner pour l’injection de défaillances en utilisant le logiciel open source SSM Agent à installer sur une instance EC2 pour gérer et configurer les ressources, l'API SendCommand et les documents associés AWS Systems Manager. L'API Send Command permet quant à elle d'exécuter des commandes par programme sur une ou plusieurs instances via SSM Agent.