Amazon S3 : c’est une erreur humaine qui a provoqué la panne de plusieurs heures

Amazon est revenu aujourd’hui sur l’incident qui a touché ses Web Services dans la nuit de mardi à mercredi. Il s’agissait bien d’une erreur humaine : une instruction malencontreuse a été envoyée pendant qu’une équipe cherchait à éliminer un autre problème.

Quelques serveurs vous manquent et tout est dépeuplé. C’est la mésaventure d’Amazon et de nombreux utilisateurs de ses services, plusieurs heures durant en début de nuit mardi. Un centre de données en Virginie a provoqué une réaction en chaine, privant de connexion des sites, applications, services et nombreux objets connectés qui nécessitaient un accès à AWS.

Deux sous-systèmes arrêtés, plus d'Amazon S3

Dans un billet technique publié aujourd’hui, la firme revient sur cet incident. Elle explique que l’équipe S3 (Simple Storage Service) travaillait à la résolution d’un problème qui touchait le système de facturation mardi après-midi. Normalement, elle devait lancer une commande qui aurait dû retirer quelques serveurs « dans l’un des sous-systèmes S3 utilisés pour le processus de facturation ». C’est évidemment là que les choses ont dérapé, une erreur dans la commande modifiant le périmètre de son exécution.

Dans la foulée malheureusement, deux autres sous-systèmes ont été touchés, dont un d’indexation qui s’occupait des métadonnées et des informations de géolocalisation de tous les objets S3 dans la région de Virginie. Plus précisément, il s’occupe de l’ensemble des requêtes GET, LIST, PUT et DELETE pour ces objets, empêchant de nombreuses opérations d’être réalisées.

L’autre sous-système est celui qui aura donné le plus de fil à retordre aux équipes techniques. Il était en charge de toutes les allocations pour les nouveaux objets. Il est notamment utilisé pour allouer du stockage lors des requêtes PUT. Or, sans le sous-système d’indexation, il ne peut pas fonctionner.

À ce stade, la seule solution était de lancer un redémarrage complet des sous-systèmes concernés.  Évidemment, durant cette opération, Amazon S3 était incapable de s’occuper des requêtes générées par l’ensemble des clients. Toutes les API S3 étaient inaccessibles, provoquant dans la région US-EAST-1 des blocages pour la console S3, des nouvelles instances Elastic Compute Cloud (EC2), les volumes Elastic Block Store (EBS) et AWS Lambda.

Amazon n'a pas pris en compte la masse croissantes des données

Pourtant, ce type d’infrastructure de cloud est pensé pour un uptime de 99,99 %. Que s’est-il passé pour que les opérations créent une telle coupure de plusieurs heures ? Le redémarrage aurait en fait dû prendre bien moins longtemps. Mais comme l’avoue Amazon, cette opération pour une région entière n’avait pas été refaite « depuis bien des années ».

C’est ce laps de temps qui a provoqué la pagaille. La firme explique : « S3 a bénéficié d’une large croissance pendant les dernières années et le processus redémarrant ces services et exécutant les tests nécessaires de sécurité pour valider l’intégrité des métadonnées a pris plus longtemps que prévu ». En clair, le temps prévu ne tenait pas compte de la masse imposante de données accumulées en quelques années. 

En temps normal, le redémarrage n’aurait dû être que partiel, l’outil utilisé ne retirant que les parties nécessaires. Il s’est cependant montré trop zélé. Amazon indique que ce problème ne devrait plus se représenter : « Nous avons modifié cet outil pour retirer la capacité de stockage plus lentement et avons ajouté des mesures de sauvegarde pour empêcher la capacité d’être supprimée si cela devait entrainer un sous-système en-dessous du seuil de stockage requis ».

Rappel brutal qu'un objet connecté est... connecté

Il est clair que l’entreprise a appris de sa bourde, puisque l’incident a mis en lumière les faiblesses lors du processus de restauration. Durant les premières heures, elle n’était même pas capable de communiquer sur le statut de ses services, la page consacrée s’appuyant sur… Amazon S3. Le problème aura en tout eu le mérite de faire office de piqure de rappel, et pas seulement pour les équipes techniques de l’entreprise.

De très nombreux services ont besoin d’Amazon en effet, actuellement leader dans l’hébergement de type cloud, même si Microsoft comble rapidement l’écart avec Azure. Slack, Trello, Quora, Business Insider, Coursera, Time Inc, Giphy, Instagram, IMDb, American Airlines, Imgur et tous les sites créés avec la plateforme Wix étaient ainsi inaccessibles, pour ne citer qu’eux.

Parallèlement, de nombreux utilisateurs d’objets connectés ont été dans l’impossibilité d’utiliser certaines fonctions. Ce n’est peut-être pas grand-chose quand on parle d’un téléviseur, mais un four qui ne s’arrête plus, des lumières qui ne veulent pas s’allumer ou une porte d’entrée qui ne remplit pas son rôle sont des soucis autrement plus sérieux. Là encore, les utilisateurs se sont vu rappeler que ces appareils, aussi pratiques soient-ils, sont dépendants de serveurs distants, et qui peuvent donc être inaccessibles eux aussi.