Partial outage on our cache layer
Incident Report for Fasterize
Postmortem

Incident du 30/10/2018

Date du post mortem :  31/10/2018

Participants du post mortem :

  • Anthony Barré
  • Mikael Robert
  • Grégoire Lejeune
  • Nicolas Alabrune
  • Jérôme Lachaud
  • Stéphane Rios

Description de l'incident

La couche de cache est devenue indisponible suite à une opération de maintenance visant à augmenter les capacités de notre moteur d’optimisation.

L’opération de maintenance visait à rajouter 15% de capacité supplémentaire au moteur d’optimisation. L’ajout de ces nouveaux noeuds a nécessité une mise à jour de plusieurs couches dialoguant avec ces noeuds. Ainsi, les couches de caches, des serveurs frontaux et de stockage ont été mises à jour pour accepter du trafic provenant des nouveaux noeuds.

Lors de la mise à jour de la couche de cache à partir de 15h36, une montée de version a eu lieu par erreur. En effet, cette version initialement prévue pour être déployée le mercredi 24 octobre 2018 avait été repoussée. Mais, le rollback n’avait été que partiellement effectué.

La nouvelle version a modifié le port d’écoute de certain processus de la couche cache et a entraîné un vidage non prévu des caches. Par ailleurs, ces processus sont devenus inaccessibles à cause d’un nombre trop élevée de connexions et le blocage de cette couche n’étant pas pris en compte par des mécanismes de fallback, les connexions se sont empilées et ont ralenti l’ensemble du trafic.

Timeline

15h14 : lancement du déploiement sur la couche de cache

15h31 : premières erreurs 504 reportées par KeyCDN

15h58 : l’équipe CSE remonte via des tickets au support des problèmes de disponibilité de la plateforme, confirmés par notre outil de logs indiquant un nombre élevé d’erreurs 504 vues depuis notre couche de CDN.

A partir de 16h, de nombreux tickets clients informent de forts ralentissements ou d’indisponibilité sur leurs sites.

16h24 : L’ensemble de l’équipe technique est mobilisée sur le problème

16h32 : La nature du problème concernant les processus de la couche de cache est identifiée.

16h37 : L’incident est rendu public sur status.fasterize.com.

16h43 : Suite aux nombreuses alertes client, l’équipe technique suspend l’ajout des noeuds supplémentaires. Ele prend la décision de remettre à jour la couche de cache et de front avec la dernière version déployée en production.

16h50 : La version déployée n’est pas la bonne. Devant l’ampleur de l’incident impactant l’ensemble du trafic, l’équipe prend la décision de router l’ensemble du trafic vers les origines.

16h51 : Le trafic est rerouté vers les origines

17h03 : Modification de la version à déployer et nouvelle tentative.

17h20 : Problème d'accès au code à déployer suite à un changement du serveur hébergeant ce code depuis la dernière mise en production.

17h30 : Mise à jour des configurations pour accéder aux serveurs de code et relance du déploiement.

17h45 : Déploiement effectué avec succès, check de la plateforme.

18h14 : Réactivation de la plateforme sans nouveaux workers.

Analyse des causes de l’incident

La mise à jour involontaire de la configuration des caches sans la mise à jour du moteur d’optimisation associée a autorisé celui-ci à accéder directement à ce service de cache sans pool de connexions. Les process ont alors saturé en terme de nombre de connexions simultanées.

Cela a provoqué des timeout au niveau de la couche de cache (configuré à 60 secondes).

Normalement, un mécanisme de fallback transfère la requête envoyée aux service de cache vers la couche de proxy, toutefois le timeout en place est trop long et les requêtes clientes ont été avortées avant la bascule.

Aucune bascule automatique n’a eu lieu car la requête utilisée par les sondes externes pour valider la disponibilité du système a une faiblesse : elle parcourt l’ensemble des couches via le même serveur de cache, du fait de notre mécanisme de consistent hashing. Or, ce serveur n’ayant pas été déployé, il n’a pas été impacté par le problème au niveau de la couche de cache.

La couche de cache ayant mis trop de temps à répondre, les requêtes ont été annulées par le CDN ou le navigateur. Ceci se traduit par l’augmentation des erreurs 499 au niveau de notre couche de front, ce qui correspond à une augmentation des erreurs 5xx au niveau de notre CDN.

Le mécanisme de fallback situé sur la couche de front se base sur la réponse de la couche de cache mais comme les requêtes n’ont pas été jusqu’au bout, la couche de cache n’a renvoyé aucune réponse et donc il n’a pas pu se déclencher.

Métriques

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

Sévérité 1: arrêt du site non planifié qui affecte un nombre significatif d'utilisateurs

* Time to detect : 28 minutes

* Time to resolve : 2h43

Impacts

* Combien de client impactés nombre absolu ?  tous

* Quelle proportion des clients impactés ?  tous

* Quelle proportion des clients utilisant la feature problématiques impactés ?  tous

Plan d'actions

Court terme

  • Diminution du temps alloué à la réponse du service de cache afin de basculer rapidement sur les proxys en cas d’indisponibilité
  • Revue et ajout de métriques d’alerting
  • Automatisation de la procédure de rollback suite à une mise en production avortée
  • Sortie de la sonde du consistent hashing des caches afin qu’elle vérifie tous les caches
  • Revoir notre procédure de gestion de crise
  • Limiter les interventions sur la production aux cas d’extrême nécessité pendant les heures ouvrées.

Moyen terme

  • Séparer le code de la configuration réseaux de la configuration serveur. Cela permettrait d’éviter une mise à jour involontaire des caches.

Long terme

  • La mise en place d’autoscaling permettra de gérer dynamiquement le nombre de workers du moteur et nous évitera d’intervenir manuellement pour ajouter des ressources.
Posted 3 months ago. Oct 31, 2018 - 20:09 CET

Resolved
This incident has been resolved.
Posted 3 months ago. Oct 30, 2018 - 19:43 CET
Monitoring
The fix has been deployed. We are reopening the service.
Posted 3 months ago. Oct 30, 2018 - 18:15 CET
Update
We are close to fiinalize our fix deployment, we are validating infrastructure global behaviour before reopening service.
Posted 3 months ago. Oct 30, 2018 - 17:54 CET
Update
We are continuing to work on a fix for this issue.
Posted 3 months ago. Oct 30, 2018 - 17:51 CET
Identified
During manipulation to increase our capacity, a mistake has been done on ours caches servers and we have disabled fasterize acceleration while we are fixing.
Posted 3 months ago. Oct 30, 2018 - 16:54 CET
Investigating
We are investigating a partial outage on our cache layer.
Posted 3 months ago. Oct 30, 2018 - 16:37 CET
This incident affected: Acceleration.