La panne majeure de la région us-east-1 d’AWS due à une dépendance quadratique entre serveurs

Mercredi dernier, quelques heures avant le Black Friday, la région us-east-1 d’Amazon Web Services (AWS) s’effondra pendant des heures : pratiquement tous ses services devinrent indisponibles et même le tableau de bord de santé du nuage ne fut pas mis à jour.

Cette panne occasionna celle de centaines de services en ligne tiers, tels que Adobe Spark, Flickr, iRobot ou Roku.

Une fois n’est pas coutume, le service de nuage moins disert que ses concurrents, a effectué une analyse post-mortem de la panne.

Elle a été causée par celle du service Amazon Kinesis qui permet le traitement en temps réel de flux de données, et qui est à la base de nombreux autres services d’AWS.

En ajoutant de nouveaux serveurs à la flotte frontale des serveurs de Kinesis, AWS a augmenté le nombre de fils d’exécution, un fil étant nécessaire par communication d’un serveur avec chacun des autres serveurs, de manière à synchroniser certaines données telles que les attributions de shards, i. e. des partitions de données : soit au total le carré du nombre de serveurs de la flotte frontale.

Jusqu’ici, le processus pouvait prendre jusqu’à une heure pour que les membres existants de la flotte apprennent l’existence des nouveaux serveurs.

Or, cette quantité de fils d’exécution a fini par dépasser la limite configurée dans le système d’exploitation de ses serveurs. Une fois dépassée, la construction du cache de la carte des partitions échouait sur les serveurs de la flotte frontale de Kinesis, ce qui les empêcher de rediriger les requêtes vers les bonnes partitions des serveurs dorsaux.

Il fallut 4 h 30 à AWS pour découvrir cette cause originale de la panne, vu la complexité du système, et la dépendance avec les autres systèmes.

La solution, une fois testée, fut d’augmenter le nombre maximal de fil d’exécution du système d’exploitation, puis de redémarrer, petit à petit, les serveurs frontaux, ce qui prit encore une heure.

AWS a tiré plusieurs leçons de cette panne, qui seront appliquées immédiatement. Les serveurs vont être migrés vers des serveurs avec processeurs plus puissants et plus de mémoire, afin que le nombre total de serveurs diminue fortement, offrant ainsi une marge de manœuvre quadratique.

Le nombre maximal de fils d’exécution du système d’exploitation sera augmenté, et une alerte plus fine sur la consommation en fils d’exécution sera mise en place.

Pour accélérer le démarrage du service, la réplication de la carte des partitions deviendra la seule et exclusive responsabilité d’un sous-ensemble des serveurs frontaux, les autres effectuant les tâches additionnelles qui étaient jusqu’à présent également de la responsabilité de tous les serveurs frontaux.

Certains services d’Amazon reposant sur Kinesis, comme CloudWatch, seront déportés vers leur propre flotte.

La panne a mis en évidence que l’algorithme de tamponnage d’autres services dépendant comme Cognito, était bogué.

Enfin, Amazon n’a pas pu informer avec précision ses clients durant la panne, ce qui s’effectue typiquement sur le tableau de bord public de la santé des services d’AWS, car le service exploité à cet effet est basé sur Cognito…

Du coup, Amazon a opté pour l’information directe des clients affectés sur leurs tableaux de bord privés.

Cette très longue et très large panne d’Amazon Web Services est à la fois une tâche sur un bilan exepmplaire – jusqu’ici sans doute le meilleur des fournisseurs de services de nuages – , exemplifie l’interdépendance de très nombreux services en lignes tiers, et montre à quel point la mise à l’échelle des ressources est un exercice complexe.

De l’analyse, on tire deux critiques à AWS :

  • L’entreprise aurait dû s’interroger dès la conception de Kinésis sur une dépendance quadratique ;
  • Une communication asynchrone avec une queue de profondeur limitée de message aurait permis aux serveurs en charge de la réplication de la carte des partitions de travailler beaucoup plus efficacement et avec un nombre de connexions simultanées très inférieur : pourquoi ce modèle n’a-t-il pas été retenu ?

Enfin, un client d’AWS a émis une hypothèse intéressante : us-east-1 est la première région d’AWS, et d’après lui, sans doute la raison pour laquelle le nombre de problèmes l’affectant est disproportionnellement élevé en comparaison des régions plus jeunes. Son conseil : ne pas placer de charge de travail critique dans cette région.