En milieu de semaine dernière, le cloud d'AWS a connu une panne géante. Une panne qui s'est répercutée sur des milliers de services en ligne. Paradoxalement, c'est en augmentant la capacité de son système qu'AWS a provoqué la panne

AWS a publié un long et très intéressant billet décrivant les événements en détail. En résumé, AWS a voulu augmenter les capacités de son service Kinesis, un produit AWS pour agréger et analyser de grandes quantités de données en temps réel. Ce service fonctionne avec de nombreux serveurs en arrière-plan ou backend. Les flux de travail sont répartis vers ces serveurs par une flotte de serveurs frontaux, ou front-end.

AWS a augmenté le nombre des serveurs de cette flotte frontale. Or les serveurs de cette flotte communiquent entre eux au moyen de threads systèmes instanciés sur le système d'exploitation des machines. Chaque fois qu'un serveur est ajouté à cette flotte, les serveurs déjà présents établissent des threads pour communiquer avec le nouveau venu.

Dans le cas présent, l'augmentation du nombre de serveurs a fait que le nombre de threads devant être instanciés a dépassé les capacités des systèmes d'exploitation. Des capacités établies par configuration. La procédure des serveurs se reconnaissant entre eux dure environ une heure. Au cours de cette heure les serveurs se sont retrouvés avec des données corrompues à cause de cette limitation, cette corruption empêchant une transmission correcte des flux de travail vers le backend. D'où une répercussion en cascade sur toute l'infrastructure.

Dans son billet Amazon tire des conclusions afin d'éviter que le problème se reproduise. Par exemple, AWS explique : "A très court terme, nous passerons à des serveurs de CPU et de mémoire plus grands, réduisant ainsi le nombre total de serveurs et, par conséquent, les threads requis par chaque serveur pour communiquer à travers le parc. Cela fournira une marge de manœuvre significative dans le nombre de threads utilisé car le nombre total de threads que chaque serveur doit maintenir est directement proportionnel au nombre de serveurs de la flotte. Avoir moins de serveurs signifie que chaque serveur gère moins de threads. Nous ajoutons des alarmes à grain fin pour la consommation de threads dans le service. Nous finirons également de tester une augmentation des limites de nombre de threads dans la configuration de notre système d'exploitation, ce qui, selon nous, nous donnera beaucoup plus de threads par serveur et nous donnera également une marge de sécurité supplémentaire significative. En plus, nous apportons un certain nombre de changements pour améliorer radicalement le temps de démarrage à froid de la flotte frontale."

Un billet très intéressant à lire si l'on veut avoir une idée du fonctionnement d'une architecture cloud.

Source : AWS