English version follows.
Entre 8h53 et 9h52, la couche de front a été surchargée suite au mauvais redémarrage automatique de certaines machines. Pendant cette période, seul un nombre restreint de machines ont assuré le trafic. Le trafic n’a été rerouté que quelques minutes malgré les sondes rapportant l’indisponibilité de la plateforme.
Tous les jours, l’infrastructure Fasterize est ajustée en terme de trafic et des machines sont éteintes ou démarrées en fonction. A 6h30, les machines front ont été démarrées normalement mais le service HTTP n’a pas correctement démarré.
Le démarrage du service HTTP a été rendu impossible par un problème de configuration lié au renouvellement automatique des certificats Let’s Encrypt : le service HTTP n’avait plus accès à la clef privée des certificats renouvelés pendant la nuit et refusait de démarrer. Cet accès a été rendu impossible à cause du nouveau mécanisme de renouvellement des certificats impliquant des droits différents sur les certificats et clefs privées et suite au renouvellement automatique effectué à 06h30.
Le load-balancer a bien vu les machines démarrées mais les voyait en unhealthy. Les machines restantes ont donc pris tout le trafic et ont commencé à être surchargées après avoir atteint leur capacité maximale. La couche de CDN a donc eu du mal à joindre l’origine et a provoqué des erreurs 50x.
La disponibilité de la couche d’optimisation mesurée par les sondes externes montre bien l’indisponibilité à partir de 8h52 alors que les sondes de disponibilité globale montre une indisponibilité seulement pendant 3 minutes à partir de 9h18. Les origines clients sont branchés sur les sondes globales (incluant CDN et couche d’optimisation) et donc n’ont pas été reroutées à partir du début de l’incident. Les sondes de disponibilité au niveau global étaient paramétrées avec une sensibilité moindre et comme une partie du trafic continuait de passer, elles n’ont pas relevée la même indisponibilité.
Les alertes remontées à l’astreinte ont concerné le trafic réseau excessif mais pas les erreurs 504 car le taux d’erreur moyen de 504 n'a pas dépassé les seuils classiques que nous utilisons, au plus fort de l’incident vers 9h17.
Aucune alerte n’a été remontée sur la non disponibilité du service HTTP des fronts.
Niveaux de sévérité de l'incident :
Temps de détection : 2h (à partir du démarrage des fronts)
Temps de résolution : 3h
Durée de l’incident : 60 minutes
Sur la durée de l’incident, les erreurs 50x ont représenté 10,77% du trafic des pages HTML, 3,52% du trafic non caché et 1,15% du trafic total.
Au plus fort de l’incident (9h17), ces taux sont montés à respectivement 38,7%, 16,3% et 5,5%
Onze clients ont remonté des erreurs via le support.
[ ] à planifier, [-] en cours, [x] fait
Court terme :
Moyen terme :
Long terme :
Between 8:53 and 9:52 a.m (UTC+2)., the front layer was overloaded due to the poor automatic restart of some machines. During this period, only a limited number of machines were running. Traffic was only re-routed for a few minutes despite availability probes reporting the unavailability of the platform.
Every day, Fasterize infrastructure is adjusted in terms of traffic and machines are switched off or started up accordingly. At 6:30 am, the front machines were started normally but the HTTP service did not start correctly.
Starting the HTTP service was made impossible by a configuration problem related to the automatic renewal of Let's Encrypt certificates: the HTTP service no longer had access to the private key of the certificates renewed during the night and refused to start. This access was made impossible because of the new certificate renewal mechanism involving different rights on certificates and private keys and following the automatic renewal performed at 06:30.
The load-balancer did see the machines started but saw them as unhealthy. So the remaining machines took all the traffic and started to be overloaded after reaching their maximum capacity. The CDN layer therefore had trouble reaching the origin and caused 50x errors.
The availability of the optimization layer measured by the external probes shows unavailability from 8:52 am while the global availability probes show unavailability only for 3 minutes from 9:18 am. The customer origins are connected to the global probes (including CDN and optimization layer) and therefore were not rerouted from the beginning of the incident. The global availability probes were set up with a lower sensitivity and as some traffic continued to pass, they did not detect the same unavailability.
The alerts raised on call concerned the excessive network traffic but not the 504 errors because the average error rate of 504 did not exceed the classic thresholds that we use.
No alert was raised on the non-availability of the HTTP service of the fronts.
Incident Severity Levels :
Detection time: 2h (from the start of the edges)
Resolution time: 3h
Duration of the incident: 60 minutes
Over the duration of the incident, 50x errors accounted for 10.77% of the HTML page traffic, 3.52% of the non-cached traffic and 1.15% of the total traffic.
At the peak of the incident (9:17 a.m.), these rates rose to 38.7%, 16.3% and 5.5% respectively.
Eleven customers reported errors via support.
[ ] planned, [-] doing, [x] done
Short term :
[x] Correct the sensitivity of the availability probe at the global level
[x] Organization: systematic disconnection of the platform in the event of an incident impacting all customers.
[-] Test manual disconnect in a staging environment
[x] Review the alert thresholds on the 504 seen by Cloudfront.
[-] Add an alert on the availability of HTTP service for the fronts.
[ ] Organization: improve response time before publication of an incident
Medium term :
Long term :