I limiti di un’infrastruttura standard consigliata da Mautic
Come indicato nel progetto open source GitHub di Mautic, è consigliato scegliere una infrastruttura stack LAMP. Abbiamo scartato questa opzione perché le prestazioni sarebbero diventate molto rapidamente limitate non appena si fosse superato un 10-ina di clienti e questo avrebbe reso il nostro servizio inutilizzabile. Inoltre, presso Webmecanik abbiamo accolto il software di alcune aziende che utilizzavano Mautic Open Source con una base contatti considerevole, ad esempio perché riuscivano arrivare molto rapidamente al limite dell’infrastruttura consigliata da Mautic.
Un approccio basato sulla scalabilità orizzontale
Per ovviare a questo, abbiamo optato per la condivisione di risorse tra più VM, così da non avere limiti sulle capacità di un singolo server web.
Abbiamo quindi scelto di:
- implementare un load-balancer
- migliorare le prestazioni dei database esistenti per i clienti che utilizzano il software in modo standard
- installare un nuovo database ad alte prestazioni su cui abbiamo spostato i database dei clienti più esigenti
Oggi la nostra infrastruttura è composta da 6 server applicativi, di cui 5 VM ad alta disponibilità e 1 server dedicato, 2 server di file (filer), di cui 1 VM ad alta disponibilità e 1 server dedicato, il nostro load-balancer e i nostri due database. Ora siamo nella condizione di poter installare un nuovo server applicativo in modo semplice.
Quanto ai database, possono ancora aumentare di potenza prima che diventi necessario installarne di nuovi.
In altre parole, per noi è ora facile scalare orizzontalmente per ogni nuovo cliente e, quando sarà necessario installare un nuovo database, metteremo in atto una strategia di partizionamento dei database che ci consentirà di distribuire facilmente i dati su più server.
Formiamo i nostri clienti: usano sempre di più il software
A seguito di un corretto utilizzo del software da parte dei nostri clienti, un’altra sfida posta dal software Mautic era la ripartizione delle attività pianificate. Infatti, per ogni istanza installata, è necessario predisporre diverse attività pianificate per consentire l’aggiornamento dei segmenti, delle campagne e l’invio delle email.
Più aumenta il numero di clienti che utilizzano la piattaforma, più le attività diventano lunghe e numerose da gestire.
Su questa nuova infrastruttura, non potevamo lasciare che ogni server applicativo eseguisse queste attività in parallelo perché ciò avrebbe creato una situazione di competizione. Abbiamo quindi deciso di mettere da parte uno dei server applicativi web, così da concentrarci sulle attività pianificate dell’intera infrastruttura. Avevamo quindi messo in atto un sistema che limitava il numero massimo di attività pianificate in esecuzione. Questo sistema ci permetteva di garantire un servizio di qualità in condizioni normali e un servizio ridotto che ci evitava un fallimento totale del sistema nelle situazioni di più alta attività. Questo sistema ci ha accompagnato a lungo, ma dipendeva dal dimensionamento di una singola macchina ed era quindi temporaneo.
Ci siamo quindi messi al lavoro su un nuovo sistema che ci avrebbe consentito di distribuire queste attività su tutta la nostra infrastruttura. Internamente abbiamo chiamato questo sistema: il sequenziatore.
Il sequenziatore ha dovuto rispondere a molti problemi:
- Come fare per inviare un’attività alla macchina più disponibile?
- Come gestire le attività che vanno in errore?
- E come impedire che la stessa attività venga eseguita su più macchine contemporaneamente?
Il sequenziatore è stato recentemente distribuito nella nostra infrastruttura. Grazie alla buona risposta della nostra infrastruttura, possiamo accogliere più istanze e persino migliorare le prestazioni.
