Application downtime
Incident Report for Wisembly
Postmortem

Nos alertes automatiques nous ont remonté des soucis le mercredi 16 septembre à 11h43 (heure de Paris). Soucis mineurs dans un premier temps, donnant lieu à une simple alerte de routine auprès de notre hébergeur. (dumps Redis trop longs)

Ces erreurs se sont intensifiés au retour de la pause déjeuner (vers 13h54). Nous avions des dump Redis désormais impossible, et ayant des effets de bord sur MySQL. Nous avons ce coup-ci escaladé l'issue précédente en souci "majeur".

Vers 14h30, après investigation de l'équipe tech et de Claranet, nous avons constaté un trop gros usage RAM de Redis pour les sauvegardes automatiques toutes les 2 minutes. Nous avons décidé à 14h39, première action de notre part, de limiter la taille des dump Redis, quitte à tronquer les anciennes valeurs, afin de préserver l'intégrité de la base principale MySQL.

Les sondes de performances indiquent :

  • une dégradation des temps de réponse de l'application à partir de 12h43 (passage de 120ms temps moyen en haute activité à 209ms sur la période)
  • une augmentation du taux d'erreur à partir de cette même heure, passant de 0,0812% à 2,39%

L'action faite à 14h39 n'a malheureusement pas suffit à endiguer l'escalade de l'usage de la RAM des serveurs backend qui ont fini par lâcher à 14h49. Les équipes Claranet ont été informées dans la minute de l'incident, étant déjà en ligne pour les soucis de RAM sus-mentionnés. Après enquête sommaire, et avoir escaladé en interne chez eux l'incident, il a été décidé de forcer la bascule du backend sur le serveur slave et de redémarer le master, en y ajoutant 10Gb de RAM. Une fois ceci effectué, le trafic a été re-basculé sur le master, puis ce fut au tour du slave de redémarer avec plus de RAM.

A 15h09 précisément, 90% de l'infrastructure était à nouveau disponible et opérationnelle. Le serveur de temps réel était impacté par ces opérations et diffusait les événements live en long polling (toutes les 60 secondes). Nous avons été alerté de ceci vers 15h19 (10 minutes après la fin de l'avarie majeure), et avons effectué les mesures nécessaires sur cet élément à 15h27.

Les symptômes de cette avarie ont été les suivants:

  • tout participant déjà sur Wisembly ne pouvait que consulter le contenu déjà présent, et ne pouvait pas en ajouter de nouveau
  • tout animateur/administrateur de Wiz ne pouvait pas lancer de sondage/passer un document/changer de slide
  • en revanche, les solutions Visio collab et Live event n'ont pas été affectée par ce souci, tout comme les intégrations tierces parties (Zoom, Webex, etc..).

=> Pour les participants en cours de réunion, cette avarie s'est traduite par une perte complète des fonctionalités d'interactivité, mais pas de flux audio/vidéo

=> Pour les participants/administrateurs cherchant à rejoindre une réunion en cours ou à venir, ils ont été dans l'incapacité de le faire de 14h49 à 15h09

Cet incident, dû à une surconsomation de la RAM des serveurs de backend hébergeant les bases de données et queues de messages, a été réglé à court et moyen terme par une augmentation de 40% de la RAM de ces machines + redémarrage. Les équipes Wisembly et Claranet, de concert, dans les prochains jours, vont étudier en détail la consommation de la RAM de chacun des applicatifs de ces serveurs pour être plus efficient, et aboutir à une solution nominale pérenne à la vue de l'augmentation des usages de la plateforme Wisembly de ces derniers mois et des mois à venir.

Veuillez contacter l'équipe Success si vous avez été impacté par cet incident et que cette dernière n'est pas déjà revenue vers vous. Nous avons des offres d'indemnisations à vous proposer.

Posted Sep 16, 2020 - 17:41 CEST

Resolved
We added more RAM (10Gb) to the concerned machines (bdd-01a, bdd-01b), and all is working back like a charm. We'll work in the upcoming weeks to reduce these databases footprint to rely less on the machines RAM.
Posted Sep 16, 2020 - 15:42 CEST
Identified
The issue was provoked by one of our databases that could not make automatics dumps due to machine memory restriction. This instability grew up and provoked a major failure to other databases. We made a RAM increase and rebooted the faulty machine to brings all the systems operational again. We are investigating now the root of the automated backup failure.
Posted Sep 16, 2020 - 15:28 CEST
Investigating
As of today, 14h49 (Paris time), Wisembly application suffered a total outage, users and administrators being unable to access it. The team was immediately alerted and we escalated the issue to our hosting provider. At 15h09, after 5 minutes of investiguation, we decided to reboot the backend machines that were saturated, and the application went up again. We suffered a 20 minutes downtime. The team is actually investigating the issue, for further details.

[EDIT] After more precise logs and performance investiguation, it appears that the application was heavily slowed down since 13h53 (Paris time), due to the previous failure that was growing at that time and consuming more and more resources before crashing.
Posted Sep 16, 2020 - 15:15 CEST
This incident affected: Wisembly application.