Télécharger ce rapport en PDF ici.

Le lundi 4 octobre 2021, à partir de 14h25 (UTC+2 Paris), l’infrastructure Dokeos a commencé à subir des ralentissements. Certaines requêtes aboutissaient à une erreur 5xx, correspondant à un délai trop long de réponse. Dokeos a détecté immédiatement le problème et l’équipe technique a stoppé ses chantiers de développement pour analyser les outils de monitoring, effectuer des tests réseau et collecter un maximum de données clés depuis les serveurs. Des clients nous ont contacté pour signaler ce même constat.

L’équipe technique a consulté ses trois outils : AppSignal, Sentry et le monitoring du fournisseur, Amazon. Voici ce qu’il en est ressorti :

Même si ces deux derniers éléments sont les causes des ralentissements et inaccessibilités, le point de départ de l’augmentation des requêtes sur la base de données remonte à un peu plus loin. Notre implémentation des « Logs de connexion/déconnexion » est extrêmement gourmande et puisque chaque accès d’apprenant est un enregistrement en base de données, celle-ci est davantage sollicitée. Dans notre outil de monitoring, nous avons vu que plusieurs gros clients ont demandé des exports volumineux de données en même temps, cette coïncidence et simultanéité ont amené nos outils à leur saturation.

Notre infrastructure est prévue pour être « élastique » et « adaptative » aux besoins de notre application. Un premier ajustement a donc été fait, remettant en ligne les portails. S’en est suivi une nouvelle vague de ralentissements car tous les systèmes se sont remis en route pour absorber toutes les requêtes en attente. Ce pic a de nouveau dépassé le seuil maximum. Vers 17h45, la stabilité est revenue suite à l’absorption des requêtes en attente et à la diminution du nombre de connexion sur la plateforme.

L’ANDPC (Agence Nationale du Développement Professionnel Continu) a annoncé le 5 août 2021 à tous ses organismes de formation qu’elle contrôlera dorénavant les dates de connexions et déconnexions de tout apprenant qui suit une formation. Cette demande n’ayant jamais été formulée ni requise auparavant, nous avons, en urgence, développé un outil qui capte toutes les entrées et sorties sur les modules des formations sur notre LMS. Cette nouvelle fonctionnalité génère l’écriture d’une ligne par connexion et par utilisateur. Cela va sans dire que ça représente donc quelques milliers de lignes par minute. Nous avons identifié immédiatement l’enjeu technique ainsi que les conséquences en bande passante de ce nouveau flux de données. Une upgrade (augmentation) de la base de données a été mise en place. Un monitoring spécifique a démontré que tout se passait correctement et que les requêtes étaient bien traitées en parallèle des autres jobs sur le serveur asynchrone.

Suite à l’explosion des requêtes d’exports avec la nouvelle réglementation DPC dans le courant du mois d’août, nous avons également pris la décision stratégique de confier les exports volumineux à notre serveur asynchrone. En effet, les gros exports provoquaient une erreur 500 car le temps de chargement était trop long pour les navigateurs. Cette solution permet de fluidifier la navigation sur les portails et compiler les données « en parallèle ». Depuis la création des fonctionnalités statistiques de Rapport Réglementaire et Rapport Détaillé, ces exports sont compilés avec le traitement d’un job = une ligne (=un apprenant pour une formation). Ce qui encombre énormément le serveur asynchrone. Ces centaines voire milliers de lignes sont générées et une ligne est traitée en quelques millisecondes, mais même un traitement si rapide ne peut pas compenser les centaines exports volumineux demandés en même temps.

L’addition de notre nouveau développement d’enregistrement du journal de connexions/déconnexion avec la demande croissante en exports nous a donné comme résultat une saturation du serveur asynchrone, et plus particulièrement, de sa mémoire en cache. Cette mémoire permet l’affichage et le traitement à court terme et est une étape incontournable pour les jobs avant d’arriver et d’être traités sur le Sidekiq (serveur asynchrone). Notre Redis et notre Sidekiq étant à saturation, l’application a subi d’importants ralentissements et a connu 3 périodes d’inaccessibilité de quelques minutes. Ces deux outils, véritables poumons de la solution SaaS sont maintenant notre priorité numéro 1 pour les deux prochaines semaines.

Voici les principaux facteurs qui ont amené Dokeos à cette situation :

· Augmentation considérable du nombre de requêtes sur le Sidekiq ;

· Saturation de la mémoire cache de Redis ;

· Une seule base de données pour l’écriture et la lecture ;

Nous avons procédé à l’arrêt méthodique des services suspects :

L’équipe Dokeos s’excuse sincèrement pour la gêne occasionnée ce lundi 4 octobre 2021. Tout système est perfectible, cet incident nous le prouve et met en lumière des axes d’amélioration pour la stabilité et les performances de notre LMS. Les actions correctives décrites ci-dessus sont déjà en cours de mise en place à l’heure où vous lisez ces lignes.

Télécharger ce rapport en PDF ici.