Description

Le 27/04/21 à 16h45, nos workers sont devenus indisponibles suite à une opération de maintenance sur la base de données gérant la configuration du moteur et les configurations client. Le dashboard et les API sont devenus très lents voir indisponibles, et ont généré des erreurs.

L’opération de maintenance de la base de donnée visait à mettre à jour son code de configuration.

Certaines pages des sites des clients ont été ralenti, notamment les pages HTML non cachées et les fragments de Smartcache. Les pages en SmartCache provoquaient des redirections vers les versions non cachées.

Faits et timeline

• A 16h33, fin de la maintenance, la mise à jour des workers est déclenchée. Les tests fonctionnels et API sont OK (mais pas fiables car les tests sont alors joués sur les anciens workers).
• A partir de 16h34, la service discovery ne trouve plus les nouvelles instances de la base de données de configuration
• A partir de 16h35, il n’y a plus de worker async disponibles vus par les proxys
• A partir de 16h45, il n’y a plus de worker sync disponibles vus par les proxys
• 16h55 : alerte sur les workers sync, les proxys ouvrent le circuit breaker et bypassent les workers, les pages ne sont plus optimisées en majeure partie
• 17h10 : redémarrage de la service discovery et retour du service de base de données de configuration dans la service discovery
• 17h13 : communication de l’incident sur Statuspage
• 17h23 : lancement d’une nouvelle mise à jour des workers
• 17h30, fin de l’incident de l’indisponibilité des workers
• 17h35, communication de la fin de l’incident sur statuspage
• 17h38, redémarrage des services de l’API pour retrouver un service normal au niveau du dashboard

Analyse

A partir de 16h35, suite à la migration de la base de données de configuration, le renommage des nouvelles machines avec le nom des anciennes a généré un conflit dans la service discovery, ce qui a éjecté les nouvelles machines.

Conséquence, les DNS internes de la service discovery pour le service de base de données de configuration ne répondaient plus d’adresse IP. Sur les nouveaux workers utilisant la découverte de ce service via la service discovery, le service worker était toujours en attente de la récupération des fichiers de configuration et ne démarrait pas.

Le redémarrage des agents de service discovery a suffi à rétablir la situation, ce redémarrage ayant eu lieu avec la mise à jour de tous les workers.

D’autre part, l’indisponibilité de la base de données de configuration a aussi impacté l’ancienne API encore utilisée par le Dashboard (récupération du statut de branchement). Cette ancienne API, directement connecté à la base de données de configuration, n’avait plus non plus accès aux configurations pour la même raison et a généré des temps de réponse très long du Dashboard.

Un redémarrage de cette API a suffi à la forcer à refaire une résolution DNS via la service discovery et à retrouver la connexion à la base de données de configuration.

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

• Temps de détection : 10 minutes (16h45 ⇢ 16h55)

• Temps de résolution : 45 minutes (16h45 ⇢ 17h30)

• Durée de l’incident : 45 minutes

Impacts

• ⅔ des pages ne sont pas optimisées. ⅓ des pages est ralenti (timeout de 500ms)

• Un ticket client au sujet de redirection suite à des erreurs de Smartcache

Contre mesures

Actions pendant l’incident

• restart des services

Plan d'actions

Court terme :

• Revoir si les paramètres du circuit breaker dans le proxy sont corrects (⅓ de tâches envoyées aux brokers alors que les circuits breaker des proxys étaient ouverts) 
• Alerting lorsqu’un service ou un pourcentage de noeud d’un service est down sur la service discovery
• Mettre à jour la documentation de la service discovery
• Statuspage : ne pas faire d’auto-closing des maintenances

‌

English version

Description

On 04/27/21 at 4:45pm, our workers became unavailable following a maintenance operation on the database managing the engine configuration and the client configurations. The dashboard and the APIs became very slow or even unavailable, and generated errors.

The database maintenance operation aimed at updating its configuration code.

Some pages of the clients' sites were slowed down, especially the non-cached HTML pages and the Smartcache fragments. The SmartCache pages caused redirects to the non-cached versions.

Facts and timeline

• At 16:33, end of maintenance, the workers update is triggered. The functional and API tests are OK (but not reliable because the tests are then played on the old workers)
• From 16:34, the service discovery does not find the new instances of the configuration database
• From 16:35, there are no more available async workers seen by the proxies
• From 16h45, there are no more available worker sync seen by the proxies
• 16h55 : alert on the sync workers, the proxies open the circuit breaker and bypass the workers, the pages are not optimized anymore
• 17h10 : restart of the service discovery, the configuration database service in the service discovery is back
• 17h13 : communication of the incident on Statuspage
• 17h23 : launch of a new update of the workers
• 17h30, end of the incident of the unavailability of the workers
• 17h35, communication of the end of the incident on statuspage
• 17h38, restart of the API services to get back to a normal service on the dashboard

Analysis

From 16:35, following the migration of the configuration database, the renaming of the new machines with the name of the old ones generated a conflict in the service discovery, which ejected the new machines.

As a result, the internal DNS of the service discovery for the configuration database service was no longer responding with IP addresses. On the new workers using service discovery for this service, the service worker was still waiting for the configuration files to be retrieved and would not start.

Restarting the service discovery agents was enough to restore the situation, as this restart took place with the update of all workers.

On the other hand, the unavailability of the configuration database also impacted the old API still used by the Dashboard (connection status management). This old API, directly connected to the configuration database, did not have access to the configurations for the same reason and generated very long response times of the Dashboard.

A restart of this API was enough to force it to redo a DNS resolution via the service discovery and to recover the connection to the configuration database.

Metrics

• Incident severity levels:

  • Severity 2: degradation of the site, performance problem and/or broken feature with difficulty to bypass impacting a significant number of users

• Detection time: 10 minutes (16h45 ⇢ 16h55)

• Resolution time: 45 minutes (16h45 ⇢ 17h30)

• Duration of the incident: 45 minutes

Impacts

• ⅔ of pages are not optimized. ⅓ of the pages is slowed down (timeout of 500ms)
• A customer ticket about redirection due to Smartcache errors

Countermeasures

Actions during the incident

• service restart

Action plan

Short term :

• Review if the circuit breaker settings in the proxy are correct (⅓ of tasks sent to brokers while the proxies' circuit breakers were open)
• Alerting when a service or a percentage of a service node is down on service discovery
• Update the service discovery documentation
• Statuspage: do not auto-close maintenance