LMI MAG 4 Sept 2020 - Flipbook - Page 53
tion 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 tests de charge destinée à valider
les contre-mesures mises en place. Elle est 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
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 survenir dans les systèmes distribués. Notamment celles
qui sont liées à une panne sur la zone de disponibilité,
ou celles dues à un problème de dépendance ou de réseau. « 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 œuvre
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 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 œuvre ?
« Par exemple, est-ce que la mise à
l’échelle automatique est installée,
DEVOPS
Cahier des charges 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 énoncent l’épuisement
cutt.ly/devops
En combinant SSM Agent et l’API SendCommand d’AWS,
on peut injecter des défaillances sur ses instances EC2.
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éfaillantes ou trop lentes. 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.
APPROFONDIR
ÉCOUTER EN LIGNE
Podcast
cutt.ly/primevideo-podcast
LIRE EN LIGNE
Article
cutt.ly/primevideo-article
53