Optimisation de Moodle SGA – la grande révélation

Chez Catalyst, nous discutons souvent des améliorations continues et incrémentielles que nous apportons aux services d’hébergement et de cloud existants. Cependant, nous avons rarement l’occasion de les appliquer tous à la fois, avec « The Big Reveal » qui compare les performances avant et après. Cet article partage notre expérience de la livraison d’un projet d’optimisation Moodle SGA, en examinant l’avant et l’après, et les améliorations spectaculaires.

Explorer les services pour SGA Open Source

Bilan d’état SGA – l’avant

Fin 2020, un nouveau client nous est parvenu avec des charges de travail Moodle existantes s’exécutant dans Amazon Web Services (AWS). Comme c’est souvent le cas, les plates-formes Moodle ont connu une atrophie SGA, entraînant des performances bien inférieures aux attentes et au potentiel.

Résultats

L’équipe technique de Catalyst a réalisé une première évaluation des plateformes d’apprentissage. Les principales conclusions comprenaient :

• Deux sites Moodle ayant un besoin urgent de correctifs et de mises à niveau de sécurité, il n’était pas clair si ces sites avaient déjà été corrigés ;
• Site One était une instance de production unique, sans infrastructure de test et sans haute disponibilité (HD) ;
• Le site 2 était légèrement meilleur, il avait un site de test et de production. La haute disponibilité a été partiellement fournie, dans l’environnement de test uniquement ;
• L’infrastructure a été nommée de manière incorrecte, avec des sites de production connectés à des bases de données nommées avec des noms de test ;
• L’infrastructure était mal dimensionnée, la base de données étant provisionnée bien plus que nécessaire ;
• Pas de mise à l’échelle automatique ;
• Pas de cryptage, n’importe où, et pas de SSL ;
• Une installation surprise du CMS WordPress, qui n’a pas été corrigée ;
• Seaux S3 lisibles par le monde ;
• Les informations d’identification du compartiment S3 qui étaient comprises par l’instance du CMS WordPress ;
• Des groupes de sécurité partout, permettant, par exemple, un accès SSH global ;
• Aucune preuve d’optimisation des coûts AWS, par ex. pas d’instances réservées, etc.

La liste a continué, essentiellement une représentation de “Ce qu’il ne faut pas faire lors de l’hébergement Web”. Bien que cela puisse paraître surprenant, il n’est pas rare que de nombreuses organisations se retrouvent… se lançant dans une initiative, avec de bonnes intentions et un « Comment cela peut-il être difficile ? » attitude. Offrir des performances cloud optimales et une gestion des coûts est une compétence finement réglée, qui doit être pratiquée pour rester à jour.

Normalement, Catalyst se lance dans un projet de migration des sites Moodle vers nos propres clusters d’hébergement. Ces clusters sont déjà HA, hautes performances, bien entretenus et disposent de bonnes disciplines de gestion des coûts. Cependant, dans ce cas, le client a choisi de conserver la propriété de son propre compte AWS avec Moodle, hébergé sur une plate-forme dédiée.

Le plan du projet d’optimisation de Moodle

Il y avait un certain nombre d’étapes impliquées dans le plan du projet.

Infrastructure d’hébergement Moodle

La première priorité était d’établir un nouvel ensemble d’infrastructures d’hébergement Moodle, en suivant les meilleures pratiques de Catalyst :

• Terraform déployé pour une mise en place rapide et cohérente de l’infrastructure ;
• Site haute disponibilité pour les serveurs Web, le stockage de données, la gestion de session et les bases de données ;
• Staging, test d’acceptation utilisateur (TAU) et infrastructure de production.

Mises à niveau du site vers la dernière version de Moodle

En mettant à jour la dernière version de Moodle, le client a l’avantage de s’assurer qu’il dispose des derniers correctifs de sécurité, qu’il peut accéder aux nouvelles fonctionnalités et aux améliorations de l’expérience utilisateur (UX).

Configurer des déploiements CI/CD complets

Les déploiements CI/CD permettent à nos clients d’accéder aux pipelines optimisés de Catalyst qui intègrent et déploient en continu les modifications de code.

Analyse commerciale du site WordPress

Nous avons découvert que le site WordPress était utilisé dans un seul but, inscrire certains groupes d’utilisateurs dans Moodle. Catalyst a développé un plugin personnalisé, dans Moodle, permettant la suppression complète de l’instance WordPress et la surcharge de maintenance qui lui est associée.

Migration

L’équipe Infrastructure a migré les sites Moodle de l’ancienne infrastructure vers la nouvelle infrastructure de cloud privé virtuel (CLPV)..

Démantèlement d’anciennes infrastructures

Les meilleures pratiques et réglementations, telles que PCI DSS et HIPPA, dictent que les actifs informatiques doivent être mis hors service de manière responsable. Cela inclut des tâches telles que la sauvegarde et le stockage d’anciennes données, ainsi que la mise à jour de votre registre d’actifs.

Optimisation des coûts

L’équipe a examiné les politiques de mise à l’échelle, redimensionnant l’infrastructure (le processus de mise en correspondance des types et des tailles d’instances avec les performances de votre charge de travail et les exigences de capacité au coût le plus bas possible) et en achetant des instances réservées avec une remise significative par rapport à la tarification à la demande.

Premiers résultats – 6 mois en

Le projet est maintenant terminé, ce qui nous donne l’occasion de réfléchir sur ce qui a été réalisé :

• Deux sites Moodle ont été mis à niveau, avec des mises à niveau à double saut ;
• Deux sites Moodle ont été migrés vers une toute nouvelle infrastructure ;
• Un nouveau thème Moodle personnalisé a été créé;
• Des tests unitaires complets réussissent maintenant pour chaque version de sécurité que nous faisons, et ;
• Mise en place de pipelines de versions entièrement automatisés.

La gestion des coûts

Nous avons réalisé une gestion complète des coûts de l’infrastructure pour :

• Redimensionner toutes les instances de calcul ;
• Tirer parti des instances AMD ou ARM moins chères, le cas échéant ;
• Utilisez la base de données AWS Aurora MySQL et configurez Moodle pour répartir le trafic de lecture et d’écriture entre l’instance de l’écrivain principal et les instances de lecture DR ;
• Activez la mise à l’échelle horizontale des serveurs Web et des bases de données de réplica en lecture ;
• Acheminez intelligemment le trafic vers la base de données de réplica en lecture et l’instance de cache Redis dans la même zone de disponibilité, pour réduire les coûts ;
• Tirez parti des instances ponctuelles AWS, partout où nous le pouvons ;
• Configurez des politiques de cycle de vie sur les compartiments S3, pour tirer parti d’un stockage moins cher pour les objets les moins fréquemment consultés ;
• Activez la compression Brotli pour réduire autant que possible le trafic sortant ;
• Prenez en charge l’achat d’instances réservées et de plans d’économies AWS, pour couvrir la partie cohérente à la demande de la charge de travail.​​​​​​​

Le travail a entraîné une réduction d’environ 50 % des coûts quotidiens moyens, y compris les paiements de réservation initiaux amortis pour la charge de travail AWS. Ces coûts incluent désormais la capacité et les environnements HA, qui n’existaient pas avant le projet.

Optimisation des performances

Moodle peut bien fonctionner lorsqu’il est installé sur une seule machine avec la base de données et le système de fichiers de données de site, les deux étant locaux pour le code PHP. Lors du passage à une configuration HA, où la base de données se trouve sur une machine distante et les données du site sont un système de fichiers réseau partagé entre plusieurs machines, beaucoup de travail doit être fait pour ramener les performances à ces niveaux de machine unique.

Pour ce projet particulier, Catalyst a appliqué un certain nombre d’actions pour soutenir l’optimisation des performances des plateformes SGA :

• Configuration optimisée de la mise en cache unifiée Moodle, utilisant une combinaison de caches de système de fichiers APCu, Redis, locaux et partagés ;
• Configurations de cache MUC empilées, donc en cas de mise à l’échelle, les éléments de cache peuvent être récupérés à partir d’un cache réseau au lieu de les reconstruire ;
• Vernis Reverse Proxy Cache nous permet de décharger environ 40 % des requêtes du serveur Web Moodle, ce qui entraîne des chargements de page beaucoup plus rapides et beaucoup moins de charge sur PHP et la base de données ;
•  Surprovisionnement des serveurs Web, en exploitant des instances ponctuelles pour une capacité supplémentaire ;
• Acheminer le trafic du cache et de la base de données vers le cache ou l’instance de base de données dans la même zone de disponibilité (centre de données) – permet d’économiser quelques millisecondes à chaque aller-retour ;
• La compression Brotli dans nos serveurs Web maximise la compression du trafic Web résultant, ce qui signifie que les navigateurs Web prennent moins de temps pour télécharger les pages résultantes ;
• Mise à niveau de PHP 5.6 à 7.4. PHP devient plus rapide à chaque version, dans ce cas, le temps de génération des pages a chuté d’environ 25 %.

Initialement, nous sommes partis dans le but de protéger l’UX, en veillant à ce que la vitesse de chargement des pages soit maintenue, malgré l’introduction des composants HA. En réalité, nous avons réduit le temps moyen de rendu des pages de 40 % du jour au lendemain, enregistré à l’aide de Matomo Analytics :

Sécurité des informations

La sécurité de l’information est intégrée à nos constructions d’infrastructure standard, en tant que partie intégrante de notre certification ISO 27001. La plupart de ces informations sont entièrement transparentes pour nos utilisateurs de Moodle et méritent probablement leur propre série d’articles de blog. En résumé, l’infrastructure que nous avons construite comprend désormais :

• Implémentation SSL uniquement pour Moodle ;
• Chiffrement au repos, pour toutes les données, y compris : serveur Web EBS, cache, serveurs de fichiers, bases de données et sauvegardes hors site ;
• Serveurs proxy de sortie, avec listes d’autorisation filtrées pour le trafic ;
• Patching automatisé de l’infrastructure ;
• Correction automatisée du code Moodle, avec des pipelines CI/CD robustes ;
• Journalisation étendue au niveau de l’application et de l’infrastructure ;
• Surveillance 24h/24 et 7j/7 ;
• Ensemble réduit d’autorisations de gestion des identités et des accès (IAM), conformément aux ​​​​​​​ principes du moindre privilège ;
• Suivi de toutes les dates de rotation clés, et ;
• Intégration de pare-feu d’application Web

Toutes mes excuses à notre RSSI pour les choses que j’ai peut-être oubliées de cette liste !

Bilan de santé SGA – l’après

Compte tenu de l’impact de ce projet de revitalisation de Moodle, certaines optimisations importantes ont été réalisées :

• Environnement Moodle moderne entièrement patché
• Hébergement moins cher, une économie de 50%
• Chargements de pages plus rapides, temps réduit de 40%
• Infrastructure HA complète, sans point de défaillance unique
• Excellente posture de sécurité, pour résister au « Wild West » moderne qu’est Internet

Il ne fait aucun doute que ce projet a donné des résultats étonnants pour notre client. Cela a également été un projet fantastique de montrer ce qui peut être fait lorsque les petits changements incrémentiels que nous apportons quotidiennement sont appliqués en une seule fois.

Des services pour transformer votre SGA Moodle

Si vous souhaitez découvrir comment l’équipe d’experts SGA de Catalyst peut vous aider à atteindre vos objectifs SGA, n’hésitez pas à nous contacter.

Contactez l’équipe Catalyst dès aujourd’hui