Les limites d’une infrastructure standard recommandée par Mautic
Comme proposé sur le projet open source GitHub de Mautic, il est recommandé de choisir une infrastructure stack LAMP. Nous avons écarté cette option car les performances allaient être très vite limitées dès lors qu’on aurait dépassé une dizaine de clients et cela aurait rendu notre service inutilisable. Aussi, nous avons accueilli chez Webmecanik le logiciel de certaines entreprises qui utilisaient Mautic Open Source avec une base de contacts conséquente par exemple car ils arrivaient très rapidement à la limite de l’infrastructure recommandée par Mautic.
Une approche par la scalabilité horizontale
Pour pallier à cela, nous avons opté pour une mutualisation de ressources de plusieurs VMs afin de ne pas avoir de limite sur les capacités d’un serveur web.
Nous avons donc fait le choix de :
- mettre en place un load-balancer
- booster la performance de la base de données existantes pour nos clients ayant une utilisation standard du logiciel
- installer une nouvelle base de données haute performance sur laquelle nous avons déplacé les bases de nos clients les plus consommateurs
Aujourd’hui, notre infrastructure consiste en 6 serveurs applicatifs dont 5 VMs haute disponibilité et 1 serveur dédié, 2 serveurs de fichiers (filers) dont 1 VM haute disponibilité et 1 serveur dédié, notre load-balancer et nos deux bases de données. Nous sommes maintenant dans une position où il est trivial d’installer un nouveau serveur applicatif.
Les bases de données quant à elles, peuvent encore monter en puissance avant qu’il devienne nécessaire d’en installer de nouvelles.
Autrement dit, il est maintenant facile pour nous de scaler horizontalement à chaque nouveau client, et lorsqu’il faudra installer une nouvelle base de données, nous mettrons en place une stratégie de partition des bases qui nous permettra de facilement distribuer les données sur plusieurs serveurs.
Nous formons nos clients, ils utilisent de plus en plus le logiciel
Suite à la bonne utilisation du logiciel par nos clients, un autre défi posé par le logiciel Mautic était la répartition des tâches planifiées. En effet, pour chaque instance installée, il est nécessaire de mettre en place plusieurs tâches planifiées pour permettre la mise à jour des segments, campagnes et l’envoi des emails.
Plus le nombre de clients utilisant la plateforme augmentent plus les tâches sont longues et nombreuses à traiter.
Sur cette nouvelle infrastructure, nous ne pouvions pas laisser chaque serveur applicatif exécuter ces tâches en parallèle car cela aurait engendré une situation de compétition. Nous avons donc décidé de mettre de côté un des serveurs applicatifs web afin de se concentrer sur les tâches planifiées de l’infrastructure entière. Nous avions donc mis en place un système qui limitait le nombre maximal de tâches planifiées en exécution. Ce système nous permettait de garantir un service de qualité en situation normale et un service amoindri qui nous évitait un échec total du système dans les situations de plus haute activité. Ce système nous a accompagné longtemps mais il dépendait du dimensionnement d’une seule machine et était donc éphémère.
Nous nous sommes mis au travail sur un nouveau système qui nous permettrait de distribuer ces tâches sur l’ensemble de notre infrastructure. En interne, nous avons nommé ce système : le séquenceur.
Le séquenceur a dû répondre à de nombreux problèmes :
- Comment faire pour envoyer une tâche sur la machine la plus disponible ?
- Comment traiter les tâches qui partent en erreur ?
- Et comment empêcher une même tâche d’être exécutée sur plusieurs machines en même temps ?
Le séquenceur a récemment été déployé sur notre infrastructure. Suite à la bonne réaction de notre infrastructure, nous pouvons accueillir plus d’instances et même améliorer nos performances.
