Front layer is experiencing some trouble since 8:15
Incident Report for Fasterize
Postmortem

Incident indisponibilité du 27/06/2018

Date du post mortem : 28/06/2018

Description de l'incident

Deux perturbations de services ont eu lieu entre 8h15 et 8h45 puis entre 10h48 et 11h06. Des lenteurs et erreurs 502 ont été constatées.

Deux serveurs front ont été saturés lors de l’incident. Le trafic entrant et les multiples flushs de cache lors de la matinée ont saturé deux machines frontales plus faiblement dimensionnées. Notre CDN a aussi connu des perturbations réseau.

Faits et Timeline

8h00 : Début des soldes. Le trafic est multiplié par 2 par rapport à un jour normal. Le pic de requêtes est d’environ 6200 req / sec.

8h15 : Plusieurs clients vident le cache. Cela entraîne un nombre important de tâches d’optimisation synchrone et asynchrone.

8h20 : Un serveur frontal commence à avoir une indisponibilité.

8h20 : Ajout de workers asynchrones supplémentaires en plus de ceux ajoutés au préalable

8h26 - 8h44 : Emails au support de Fasterize concernant des lenteurs et erreurs 502.

8h36 : L’équipe technique modifie la répartition de charge pour soulager le serveur en souffrance.

8h45 : La première perturbation se termine lorsque l’ensemble des ressources statiques est optimisé.

9h13 : Une nouvelle machine frontale est commandée pour effectuer un remplacement

10h40 : Flushs successifs de plusieurs gros clients

10h42 : Nouveau problème de disponibilités d’une machine frontale.

11h06 : La seconde perturbation se termine lorsque l’ensemble des ressources statiques est optimisé.

Analyse

Les flushs successifs de plusieurs clients ont provoqué un grand nombre de tâches d’optimisations de pages et de ressources statiques. Celles-ci se sont correctement déroulées grâce à une capacité de traitement accrue au niveau de notre moteur pour notre dispositif de soldes.

Cependant, cela a provoqué un grand nombre de requêtes de mise en cache de ressources optimisées. Ces requêtes PUT ont largement augmentées la bande passante entrante au niveau de notre couche frontale.

Certains serveurs frontaux ont alors saturé et provoqué des coupures de services intermittentes.

Le trafic de requêtes entrantes est resté relativement stable pendant la période :

Le nombre de requêtes de mise en cache a augmenté significativement suite à plusieurs évolutions faites dans le moteur : la mise en cache préventive des ressources statiques non optimisées ainsi que l’auto-refresh des pages en smartcache.

Notre monitoring effectué par Cedexis et Route53 a repéré les perturbations et a sorti de façon intermittente les serveurs frontaux surchargés. Cela n’a cependant pas été suffisant pendant la période de trouble.

Par ailleurs, notre CDN principal KeyCDN a aussi connu des perturbations pendant la matinée et la soirée.

Nous avons des données discordantes sur l’état réel du CDN pendant cette période :

Métriques

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

Le temps de détection a été d’environ 10 minutes.

Le temps de résolution a été de 30 minutes puis 24 minutes

Impacts

L’ensemble des clients a été impacté. Sur la période 8:00-12:00, au total, il y a eu 0.17% d'erreurs 502 émises à la sortie du CDN.

En ne comptabilisant que les cache MISS du CDN, le taux passe à 0.46% d’erreurs avec un maximum à 7% à 8:20 et 20% à 8:39.

Plan d'actions

Court terme

  • Remplacement des serveurs frontaux sous-dimensionnés par des serveurs plus puissants.
  • Ajout de noeuds supplémentaires dans cette couche frontale.
  • Amélioration de la visibilité ainsi que d’une alerte sur le nombre d’erreurs renvoyés par la plateforme perçues par le CDN
  • Ajout d’un indicateur sur le nombre de requêtes et sur la bande passante utilisée par le trafic interne de la plateforme.
  • Ajout d’une alerte en cas de paquets réseau abandonnés.

Moyen terme

  • Modification de la méthode de mise en cache des ressources pour l’isoler du trafic entrant. Cela permettra d’éviter des perturbations liées à du trafic interne.

  • Revue de l’efficacité des fonctionnalités mettant beaucoup de ressources en cache. Par ailleurs, nous allons prévoir des systèmes de coupure des services non prioritaires.

Posted 7 months ago. Jun 28, 2018 - 15:44 CEST

Resolved
This incident has been resolved.
Posted 7 months ago. Jun 27, 2018 - 15:05 CEST
Update
Our platform experienced another period of degraded performance between 10:48 and 11:06. Everything is back to normal since 11:06.
We are working in replacing faulty servers.
A post mortem will follow with more details.
Posted 7 months ago. Jun 27, 2018 - 13:45 CEST
Update
The incident has been mitigated. The acceleration is operational since 8:45.
Posted 7 months ago. Jun 27, 2018 - 09:57 CEST
Monitoring
A fix has been implemented and we are monitoring the results.
Posted 7 months ago. Jun 27, 2018 - 08:53 CEST
This incident affected: Acceleration.