Scalare WordPress: liberiamoci del file system distribuito

file system analytics scaling

Quando i numeri della nostra piattaforma cominciano a salire, WordPress mostra evidenti difetti in termini di scalabilità.

Il cloud, rispetto ai setup in colocation, ci permette un veloce provisioning delle risorse. Non richiede alcun capacity planning e non ci fa domandare se una ipotetica nuova esecuzione troverà spazio nel rack.

Lo scaling verticale, non ci porterà nient’altro che ad un sovradimensionamento della nostra infrastruttura, tale da resistere proprio al picco conosciuto (es. ritorno a casa dal lavoro, pausa pranzo), mentre avremo capacità computazionale inutilizzata per tutto il resto della giornata.

Per essere cost effective in tutti gli intervalli della giornata è preferibile quindi uno scaling orizzontale.

Scalare orizzontalmente con il file system distribuito

Un classico approccio per scalare orizzontalmente WordPress è quello di rendere la sua web folder condivisa fra tutte le sue esecuzioni tramite NFS.

Tuttavia NFS introduce un ulteriore grado di latenza alla nostra infrastruttura.

Da sempre si è cercato di attenuare questa mancanza di prestazioni lato file system distribuito tramite una CDN a monte, con Monrif, pionieri dello sviluppo tecnologico dell’editoria, si è cercata una soluzione differente, on-the-edge, per eliminare questa pesante dipendenza.

Il file system distribuito per WordPress è necessario proprio per sincronizzare tra le varie istanze:

  • upload dei media;
  • modifiche al template da backend.

Per risolvere l’upload dei media e non utilizzare NFS, ci viene in aiuto WP Offload S3 con il quale possiamo direttamente fornirli da bucket S3, o meglio da CDN con Origin il bucket stesso.

Per il template, le modifiche lato backend sono effettuate solo in fase di setup della piattaforma e mantenute sotto controllo di versione, che ci permette quindi di fornirlo staticamente anche questo attraverso CDN.

file system distribuito

 

Nel prossimo articolo parleremo del database e vedremo come intervenire per migliorare ulteriormente le performance del nostro sito.

  • Pingback: Scalare WordPress: analizziamo il database - ideato()

  • Giuseppe Arrigo

    Per quali volumi di traffico (visite/min) consigliereste di utilizzare una configurazione di questo tipo?
    Potete fornire qualche dettaglio in più riguardo la realtà, e gli scenari, cui fate riferimento (Monrif)?

  • alessandro mazzoli

    Ciao @giuseppearrigo:disqus

    noi ad oggi forniamo 4M sessioni/mese, circa 2000 utenti attivi con durata delle sessioni di circa 1 minuto/1 minuto e mezzo.

    Il file system distribuito introduce a prescindere latenza ed è un layer architetturale che si ancora al passato, il plugin garantisce proprio di slegarci da esso.

    Recentemente abbiamo pubblicato un ulteriore approfondimento sul db: https://www.ideato.it/technical-articles/scalare-wp-analizziamo-il-database. Il prossimo articolo tratterà il deployment e il sizing per la parte computing quindi continua a seguirci :slightly_smiling_face: