Date du post mortem : 28/06/2018
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.
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é.
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 :
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
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.
Court terme
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.