Note : les temps indiqués dans ce document sont au format UTC sauf indication contraire.

Description de l'incident

Le 23/10/2019, à partir de 09:39, les frontaux de l’environnement euwest1 ont commencé à devenir instable.

Les premiers éléments montrent que les healthchecks entre le load balancer et les frontaux de euwest1 étaient négatifs de manière sporadique, ce qui entraînait la sortie alternative des frontaux de la ferme.

Une pré-analyse montre que les frontaux subissaient une charge anormalement élevée lorsqu’ils recevaient du trafic. Une saturation au niveau de leur disques durs a été constatée.

Le mécanisme de failover DNS a fonctionné. Le trafic a progressivement été rerouté vers les origines ou le second datacenter dc1.

Timeline

09h39 : Premier serveur sortant du loadbalancer.

09h45 : Une partie du trafic est remise sur dc1 et l’autre va directement à l’origine.

09h50 : L'équipe détecte le problème d'instabilité au niveau du load balancer.

10h50 : Après une analyse poussée, nous détectons l’origine de l’incident et effectuons une modification de la configuration du service web afin de mitiger le problème.

10h52 : le service est à nouveau disponible sur la région et les serveurs sont réintroduits dans le load balancer.

11h00 :Le trafic reprend progressivement sur la region euwest1.

Durant le reste de la journée, une solution est déployée à plus petite échelle afin de la valider techniquement.

16h00 : la solution validée est déployée sur l’ensemble des frontaux et le service est à nouveau nominal.

Analyse des causes de l’incident et correction

La charge des frontaux a commencé à augmenter de manière anormale. Lors de la première analyse, nous détectons que celle-ci est causée par des I/O wait, donc des latences d'accès disque des processus.

Les processus posant problème concernent le cache placé devant l’origine pour limiter les accès à l’origine lors de la phase d’optimisations des ressources statiques.

La mitigation a consisté dans un premier temps à couper le cache devant les origines. Puis, nous avons remplacer les disques durs par une gamme de disque SSD plus performante dédiée à ce cache. Nous avons enfin ré-activé le cache.

Métriques

* Niveaux de sévérité de l'incident :

Sévérité 2 : dégradation du site, problème de performance et/ou feature cassée avec difficulté de contourner impactant un nombre significatif d'utilisateur.

* Time to detect : 10 minutes

* Time to resolve :

• mitigation : 1 heure
• patch: 5 heures

Impacts

• Durant un instant, certains clients ont reçu des erreurs 5xx dû à la surcharge des serveurs. Cela représente 3% de taux d’erreurs (nombre de MISS sur CloudFront et erreurs 50{1..4}).
• Une partie du trafic a été détourné vers la région dc1 afin de limiter l’impact du point de vue client.

Plan d'actions

• Revoir le niveau d’alerte autour de la fonctionnalité du cache devant les origines
• Prévoir la possibilité de rapidement couper les caches devant les origines