Panne sur le cloud Amazon : l’erreur est humaine

Amazon l’affirme : une erreur humaine est à l’origine de la panne qui a mis à mal son cloud mardi dernier.

Localisé dans le datacenter d’Ashburn, en Virginie, l’incident avait entraîné des complications pendant plusieurs heures dans l’est des États-Unis, sur des sites Web parmi lesquels GitHub, Quora et Kickstarter, mais aussi des services comme Slack, Heroku et Citrix… ainsi que des objets connectés, dont les thermostats Nest.

Il était 9 h 37 du matin sur place (18 h 37 à Paris) lorsque l’événement déclencheur est intervenu. L’équipe AWS examinait alors un souci de ralentissement du sous-système de facturation associé au service de stockage S3.

Dans ce cadre, un employé a exécuté une commande destinée à déconnecter provisoirement un petit nombre de serveurs rattachés à ce sous-système. Problème : il a supprimé plus de capacité que prévu, à cause… d’une faute de frappe.

Effet domino

Les serveurs mis hors circuit supportaient deux autres sous-systèmes de S3.

Le premier (« index ») gère les métadonnées et les informations de localisation de l’ensemble des objets S3 pour la zone géographique concernées (ici, US-EAST-1). Son fonctionnement est indispensable pour la gestion des requêtes GET, LIST, PUT et DELETE.

Le deuxième sous-système (« placement ») gère l’allocation de nouvelles ressources de stockage, en réponse aux requêtes PUT. Il ne peut fonctionner sans le sous-système « index ».

La baisse subite de capacité a obligé à redémarrer les deux sous-systèmes, affectant non seulement S3, mais aussi une brochette de services qui en dépendent : EC2 (impossible de créer des instances), Elastic Block Store (indisponibilité des données), Lambda (API non accessibles), etc.

À 12 h 26, le sous-système « index » avait récupéré suffisamment de capacité pour gérer les requêtes GET, LIST et DELETE. La situation est revenue à la normale à 13 h 18. Dès lors, il a été possible de restaurer le sous-système « placement », à nouveau pleinement opérationnel à 13 h 54. Certains services ayant accumulé des tâches en attente, il leur a fallu plusieurs heures pour revenir à un fonctionnement normal.

Des garde-fous

Pour éviter qu’une telle erreur entraîne autant de complications, Amazon a pris plusieurs mesures. En premier lieu, l’outil exploité pour déconnecter provisoirement des ressources ne permettra plus de supprimer aussi rapidement autant de capacité. Il est plus globalement ajusté pour éviter d’aller en deçà du niveau minimal de serveurs requis pour un sous-système.

Rappelant avoir mis en place un système de « partitionnement » de ses services en « cellules » pour une intervention plus rapide en cas de problème, Amazon assure qu’il était prévu de pousser le concept plus loin cette année. La démarche devient, dans un tel contexte, une priorité.

Avec une disponibilité dans une quarantaine de « zones » réparties sur 16 régions du globe, le cloud Amazon Web Services a dégagé plus de 12 milliards de dollars de C.A. en 2016, pour un résultat d’exploitation frôlant le milliard de dollars qui en fait la plus rentable des activités du groupe.