WordPress è il più famoso e diffuso applicativo PHP per la costruizione di blog, con una storia pregressa che ha poco a che vedere con il cloud computing. Tuttavia, contrariamente a quanto si possa credere, con i giusti accorgimenti lo si può integrare egregiamente con scalabilità e alta disponibilità.
Prima di addentrarci nei meandri della scalabilità e delle potenzialita che WordPress può offrire grazie al cloud computing, dobbiamo porci una domanda. Perché scalare? Perché cimentarsi con un grande ecosistema di nuovi servizi, server virtuali, SDK e nuove strategie per garantire l'alta disponibilità?
Spesso siamo spinti dalla necessità di rispondere a specifiche situazioni di carico: i nostri siti e applicativi crescono (o sono soggetti ad un traffico con picchi stagionali in stile "montagne russe") e ci rendiamo conto che la nostra infrastruttura hardware non è più sufficiente per gestire la mole di lavoro. Ma la risposta non è tutta qui.
Progettare e rilasciare un applicativo completamente integrato con servizi cloud ci permetterà non solo di supportare correttamente il traffico passante, ma anche di offrire l'alta disponibilità, garantendo (con sacrifici soprattutto legati al portafoglio), un impianto sempre funzionante anche in seguito a disservizi geografici.
Potremo "spezzare" il nostro applicativo dedicando risorse specifiche ad ogni servizio, ed il nostro provider, (AWS in questo caso) ci garantirà l'accesso a risorse ridondate attraverso diverse server farm separate e geograficamente indipendenti le une dalle altre.
Allo stesso tempo, specie quando si deve gestire applicativi ad alto traffico, il Cloud Computing può rappresentare una voce di cost saving, o meglio, di una migliore allocazione delle risorse.
Se facciamo il "provisioning" dell'hardware (ovvero dimensioniamo da noi i sistemi) dobbiamo considerare in modo adeguato la potenza di calcolo di cui abbiamo bisogno così da riuscire a sostenere il carico nel caso peggiore, ovvero con più utenti. Questo implica anche un'analisi a medio/lungo termine, dipende per quanto tempo vogliamo coprire il nostro caso peggiore, poi è legittimo immaginare un business con un pronostico di crescita e non di stallo.
Come si vede nell'immagine dobbiamo fornire adeguata potenza di carico per sostenere il picco di utilizzo delle 10 di mattina.
In un applicativo pienamente scalabile, la quantità di risorse in gioco sarà sempre relativamente legata alla reale necessità, grazie ad apposite strategie di monitoraggio e autoscaling. Questo ci permetterà di allocare sempre le giuste risorse per ogni condizione, come mostra la seguente immagine.
Come risulta chiaro dal grafico, entra in gioco un'importante voce di riduzione dei costi, o meglio, di contenimento degli sprechi.
WordPress e Cloud computing
Nel corso della progettazione e attuazione della "scalata", che forzeremo con specifici attacchi simulati per far crescere il carico, incontreremo diversi problemi molto comuni in applicativi ospitati su piattaforme LAMP.
Il primo collo di bottiglia è solitamente rappresentato dal Database, che ad un certo punto si troverà sottoposto ad uno sforzo notevole e, spesso complice una configurazione non ottimale, comincerà a divorare avidamente RAM e CPU ed a scrivere freneticamente su disco.
Proprio su disco si accanirà anche il PHP, specie se adotteremo plugin o servizi con scrittura della sessione su disco (di default WordPress non utilizza le sessioni, ma solo i cookie) o servizi di caching locale non in RAM.
Un uso intensivo del disco è ache dovuto ai tutti i file statici quali immagini e fogli di stile che solitamente sono gestiti dallo stesso Apache su cui è attiva la nostra installazione di WordPress.
Un altro pericoloso collo di bottiglia è spesso rappresentato dalla scheda di rete, solitamente ignorata nelle analisi superficiali dei problemi: un traffico intenso porta ad un alto flusso di dati, che le nostre schede di rete devono correttamente supportare. Chi conosce perfomance e punti deboli della scheda che stiamo magari condividendo con altre decine di siti e applicativi?
WordPress, come tanti suoi simili, è soggetto sostanzialmente a tutti questi pericoli. Spesso non ci rendiamo conto della loro esistenza fino a quando, col passare del tempo e la conseguente crescita del nostro applicativo, non ci troviamo a dover affrontare situazioni critiche dovute al traffico intenso.
La schema di default di un applicativo scalabile prevede di solito l'adozione di un servizio DNS ridondato (come Route 53 di Amazon), e l'adozione di un sistema di loadbalancing e autoscaling che gestisca autonomamente l'accensione di diverse macchine web a seconda del traffico passante. Questo significa, come avrete intuito, che il nostro applicativo potrà mettere in campo diverse istanze virtuali una uguale all'altra, tra le quali dividere il traffico. Questo ci obbligherà a spostare ogni elemento condiviso (file statici, database, caching) fuori dalle singole istanze delegandone la gestione a servizi esterni e centralizzati a cui tutte le istanze in gioco possano accedere condividendone le risorse.
È arrivato il momento di affrontare più a fondo l'obiettivo finale di questa guida, la scalabilità di WordPress. Per i nostri esempi vedremo come sfruttare al meglio i prodotti di Amazon Web Services integrandoli con la nostra installazione di WordPress.
