Panne du mercredi 29 juillet post-mortem

À partir de ce matin autour de 3 heures GMT, Scalingo a connu sa plus grande panne depuis l'ouverture commerciale du service (1er février). La plupart des applications ont été indisponibles jusqu'à 7h30 GMT, pour un total de plus de 4h30 d'interruption de service.

Que s'est-il passé ?

Vers 3 heures GMT mercredi 29, nos services internes ont commencé à générer des exceptions inhabituelles. Nous utilisons Rollbar pour suivre les erreurs et recevoir des notifications de leur part. Malheureusement, aucun membre de l'équipe n'a vu la notification à temps et certains de nos serveurs ont été indisponibles pendant la nuit. C'est à 6 heures GMT que nous avons commencé à enquêter sur ce qui n'allait pas et comment le résoudre.

Plusieurs serveurs ont été gravement affectés et il n'a pas été possible d'y accéder à nouveau, toutes les applications s'exécutant sur eux n'étaient pas non plus disponibles. Parmi les serveurs en fonctionnement, nous avons eu un indice sur ce qui s'était passé, la partition d'exécution de Docker était pleine à 100 %. Cela, en conséquence, rend Docker non réactif, aucun nouveau conteneur n'aurait pu être créé, et toute opération sur les conteneurs en cours d'exécution peut échouer.

Après avoir redémarré les serveurs défaillants, nous avons constaté qu'ils étaient dans la même situation, mais de plus, les journaux ont suggéré que le noyau Linux souffrait d'un blocage léger lié aux files d'attente d'E/S attendant d'écrire sur la partition Docker mais échouant à cause de son état. Cela expliquerait pourquoi les serveurs ne répondaient pas.

Nous sur-provisionnons généralement la partition Docker pour être sûrs que cette situation ne se produise pas, car nous sommes avertis qu'un espace sur cette partition est nécessaire pour faire fonctionner correctement les conteneurs, mais dans ce cas, quelque chose d'inhabituel a rempli la partition.

Cause du problème

Une application avec un très fort volume de visiteurs (en fait des capteurs) a été arrêtée par son propriétaire récemment, l'application recevait plusieurs dizaines de requêtes par seconde. Dans ce cas, nos serveurs front divertissent la requête HTTP vers une autre application qui rend une page web (souvent mise en cache) indiquant que l'application a été arrêtée.

Cette application gérant l'erreur est une application Ruby on Rails. En général, les applications Ruby on Rails affichent les paramètres de la requête. C'est ce qui s'est passé ici, tous les paramètres de la requête faite à l'application arrêtée ont été écrits dans les journaux, et le corps était particulièrement important : presque 7 Ko. Chaque ligne pesait alors cette taille.

En conséquence, la taille des journaux de l'application a explosé très rapidement, remplissant la partition Docker de plusieurs Go par minute. Une fois qu'un nœud a été considéré comme indisponible, l'application a été déplacée vers un autre nœud pour éviter l'interruption de service. Ici commence ce que l'on appelle un "effet de cascade" mettant nos serveurs hors service un par un. Ce qui a entraîné une interruption de service pour de nombreuses applications.

Remédiation

Une fois le problème correctement identifié, le résoudre a pris du temps mais a été plus simple, les serveurs ont été redémarrés, d'énormes fichiers journaux ont été tronqués et ensuite, toutes les bases de données et applications à l'arrêt ont été redémarrées. Une fois cela fait, tout était à nouveau disponible et il est temps de travailler sur la non-répétabilité de ce qui s'est passé la nuit dernière.

Que ferons-nous pour éviter de telles erreurs ?

Tout d'abord, le principal problème ici a été le facteur humain. Si l'erreur avait été traitée au moment de la première exception, nous aurions pu éviter toute interruption de service. Nous allons améliorer la façon dont nous sommes notifiés, les erreurs critiques devraient pouvoir réveiller toute l'équipe instantanément.

Deuxièmement, l'une des causes techniques du problème a été la manière dont Docker gère les journaux. Comme indiqué dans le blog de Sirupsen hier, la journalisation est encore un peu limitée avec Docker, nous devrons donc trouver un autre moyen de récupérer les journaux de vos applications pour éviter de remplir les disques avec eux, la journalisation doit être complètement isolée de l'environnement d'exécution des applications. De plus, la manière dont nous gérons les pages d'erreur doit être faite différemment, les paramètres ne doivent pas être journalisés du tout pour éviter que de telles situations se reproduisent.

Conclusion

Toute l'équipe de Scalingo s'excuse pour ce qui s'est passé la nuit dernière. Il y a eu un peu d'interruption de service, mais la bonne nouvelle est que cela nous a beaucoup appris sur des parties sous-estimées de l'infrastructure et nous pourrons améliorer pour fournir un service toujours meilleur.