Come sfruttare i punti di forza del cloud in termini di alta affidabilità e semplicità di gestione? Come sfruttare le potenzialità in AWS per l’ottimizzazione dei costi? Ne parliamo con il supporto di una case history reale, illustrando un’architettura in alta affidabilità e alte performance per Magento2 su cloud AWS.
1. Come configurare un sistema per Magento2 in alta affidabilità e in ridondanza geografica all’interno della stessa Region AWS
Per meglio comprendere i concetti di alta affidabilità e ridondanza geografica occorre qualche premessa sulla terminologia specifica AWS.
La Region è luogo fisico nel mondo in cui vengono clusterizzati i data center, in pratica la città: Dublino, Francoforte, Milano, ecc.
La Availability Zone, abbreviata in AZ, consiste in uno o più data center provvisti di alimentazione, rete e connettività ridondanti all’interno di una stessa regione AWS.
Le AZ sono distanti alcuni chilometri l’una dall’altra e per questo le possiamo considerare geograficamente separate.
Il VPC invece (Virtual Private Cloud), a differenza delle Region e della AZ, è una suddivisione logica di rete all’interno della Region che copre una o più AZ: in pratica il nostro piano di indirizzamento in una determinata Region, isolato a livello di rete.
Il concetto di “infrastruttura first-class” rimanda sia al tema delle prestazioni sia a quello dell’affidabilità. In particolare, in riferimento a quest’ultimo, abbiamo studiato una configurazione in alta affidabilità e ridondanza geografica.
Quali sono i passi chiave per ottenere un sistema “First-class”?
- Sono stati eliminati tutti i Single Point of Failure (SPOF), sfruttando, ove possibile, i servizi gestiti
- È stata garantita la ridondanza geografica, utilizzando, all’interno del VPC, due o più zone di disponibilità
- Il sistema è stato strutturato per scalare anche orizzontalmente, garantendo performance variabili in tempi rapidi
- Il sistema è stato strutturato per scalare verticalmente a caldo o con impatti minimi
1.1. Descrizione del sistema
Fig.1 disegno architetturale complessivo del sistema con Magento2
ALB: è un bilanciatore layer 7 che viene puntato con almeno due IP pubblici che risiedono in diverse zone. L’oggetto scala orizzontalmente in caso di traffico elevato, aggiungendo, in modo dinamico, ulteriori IP all’occorrenza. È un automatismo AWS, non servono interventi manuali.
Per sfruttare appieno le potenzialità di Magento, a valle del bilanciatore troviamo subito lo strato di Varnish, una webcache realizzata su nodi computazionali EC2.
Questo strato, in autoscaling, è distribuito su tre zone e abbiamo impostato il minimo numero di nodi a due. In questo modo avremo sempre un nodo in una zona di disponibilità e uno in un’altra. Quindi alta affidabilità (se spengo un nodo le chiamate vengono gestite dall’altro finché non viene ripristinato) e ridondanza geografica: uno per zona.
In caso di problemi, possiamo aumentare il numero di nodi in automatico o manualmente.
Il nodo ADMIN, invece, è un webserver con nginx/php utilizzato solo per servire il backend di Magento. È l’unico punto in cui ci siamo accollati il rischio di avere un solo nodo, in quanto non è essenziale per l’erogazione del servizio ai clienti. È comunque possibile portarlo in HA o in configurazione attivo/passivo all’occorrenza.
A completamento della parte di frontend web per l’utente abbiamo la CDN: per definizione ridondata e distribuita geograficamente anche in Region diverse da quelle dove risiede l’infrastruttura. Eroga il traffico tramite endpoint locali per ottimizzare le prestazioni in particolare sulle latenze di rete (ad esempio, un utente in Germania riceverà traffico dall’endpoint più vicino, tipicamente in Germania, anche se l’infrastruttura è situata in Irlanda).
Proseguendo il percorso del traffico proveniente dagli utenti, troviamo una batteria di webserver nginx/php con Magento2, da cui si alimentano le webcache di Varnish.
I server sono distribuiti su tutte le tre AZ in egual misura, quindi anche in questo caso ridondanza sia per numero di nodi che geografica. I meccanismi di autoscaling, oltre a garantire un numero minimo di istanze impostato (dobbiamo configurare almeno due istanze per essere in alta affidabilità), provvedono anche ad aggiungere nodi in base al carico.
Ciò significa che possiamo triggerare il numero dei nodi in funzione del carico macchina dei frontend web in modo da distribuire il carico su un numero maggiore di nodi in caso di picco o aumento e su un numero basso di nodi in caso di basso carico.
A completare la configurazione ci sono tutti i servizi necessari per eseguire Magento2 sui frontend web, erogati in modalità SaaS da AWS, tutti in alta affidabilità e multi zona:
- Aurora cluster: un reader e un writer in multiAZ con elezione automatica del writer in caso di failure. Il cluster garantisce anche migliori performance del singolo nodo, potendo sfruttare il puntamento readonly (sul quale possiamo girare tutte o parte delle query in lettura)
- Elasticsearch cluster: tipicamente sei nodi, di cui tre master e tre data nodes, puntato con DNS
- Redis: due cluster con reader, writer e elezione automatica. Il cluster garantisce anche migliori performance del singolo nodo: anche in questo caso, AWS mette a disposizione il puntamento readonly, permettendo di distribuire il carico su entrambi i nodi
- EFS: servizio NFS ridondato, multiAZ
Come abbiamo visto, analizzando componente per componente, tutto il sistema è in High Availability. Le performance sono garantite dallo sfruttamento dei meccanismi autoscaling e dallo sfruttamento dei nodi replica nei cluster utilizzati.
2. Ottimizzazione dei costi
A questo punto ci si potrebbe chiedere
“Perché utilizzare servizi gestiti al posto di nodi computazionali? Le macchine costano molto meno”.
Purtroppo questo è vero solo in apparenza. Un servizio non gestito comporta costi aggiuntivi sia in fase di setup sia in esercizio.
A titolo di esempio, faremo ora una comparazione dei costi tra un servizio MySQL fornito da AWS (RDS Aurora) e costruito con pila software su nodi computazionali EC2 (mariaDB o mySQL).
Come si vede nella tabella riassuntiva (Fig. 2 – prima riga), il costo annuo dei due server 4vCPU e 32Gb di ram su Aurora è addirittura più del doppio rispetto ad EC2.
Attenzione però all’HA: in caso di cluster su EC2, non ci sono le garanzie che si hanno su Aurora e c’è sempre il rischio di split brain, a meno di mettere a budget altri sistemi o soluzioni con relativi ulteriori costi.
Per quanto riguarda il setup, nel computo totale della attività per l’attivazione di un sistema su AWS, l’incidenza della parte RDS è pari a 0 o poco più, mentre su EC2 servono attività di setup e installazione, stress test, verifiche funzionali, ecc, indicate nella seconda riga di fig. 2.
Vanno poi considerati anche eventuali incident: in un mondo ideale, al termine del setup tutto funziona senza problemi in entrambi i casi. Per esperienza diretta, però, in caso di cluster su EC2, almeno un paio di interventi l’anno per perdita di sincronizzazione sono abbastanza fisiologici (Fig 2 – terza riga).
Infine, in un’ottica di continuità per il corretto funzionamento di un sistema, devono essere considerati anche i costi per manutenzione, modifiche di settaggi, monitoraggio e aggiornamenti che risultano molto superiori su EC2 (quarta riga).
| Aurora MySQL | EC2 | |
| 2 nodi MySQL 4cpu 32Gb Ram | $11,496.00 | $5,300.00 |
| SETUP (una tantum) | $0.00 | $1,500.00 |
| Incident | $0.00 | $800.00 |
| Aggiornamenti sicurezza e monitoraggio | $1,200.00 | $4,800.00 |
| TOTALE annuo | $12,696.00 | $12,400.00 |
Fig.2 tabella comparativa costi annuali SaaS e Ec2
Come si vede dal totale, i costi in linea di massima si pareggiano, andando di fatto ad annullare la convenienza economica di optare per nodi EC2 al posto di SaaS.
Non dobbiamo altresì dimenticare le grandi differenze in termini di affidabilità/funzionalità, a parità di costo, su EC2:
- a valle di un cambio di ruolo dei nodi, si perde immediatamente la fault tolerance e in caso di failure di una zona si perde immediatamente la ridondanza geografica
- la complessità architetturale per gestire il doppio nodo RW e RO è molto più alta
- la gestione di backup e snapshot è più complessa e meno affidabile (vale anche per i restore)
- non si può avere una scalabilità orizzontale sulle letture (Aurora permette fino a 15 read replica)
- le operazioni di manutenzione sono più onerose: in caso di modifiche architetturali come uno scaling verticale, con RDS ci sono circa 30-60 secondi di buco, per EC2 molto di più
3. Costo totale di una architettura top class su AWS
Per quantificare anche in modo approssimativo una infrastruttura Magento2, ipotizziamo i dimensionamenti come in figura 3, in un momento di picco o durante una promozione.
Fig.3 rappresentazione grafica della capacità di calcolo del sistema
Spesso si considerano i costi del cloud on-demand, ma per progetti a lungo termine, come si spera sia una infrastruttura di questo genere, si possono operare diversi accorgimenti per avere grandi performance a costi contenuti.
Se si effettua il calcolo con tutte le risorse on-demand, il costo totale mensile per l’infrastruttura è pari a circa € 9.500,00 al netto dei costi variabili di traffico di rete e supporto AWS. Carichi di tale livello, però, si hanno in corrispondenza di promozioni, orari di maggior afflusso, ecc. e non sempre si arriva al 100% della capacità, ma possono esserci diverse situazioni in cui il sistema si posiziona automaticamente su un numero di frontend web compreso tra il minimo impostato e il massimo.
Per il nostro esempio ipotizziamo di aver impostato il minimo dei frontend web a 5 e il massimo a 17. Restano così 12 macchine “variabili” in autoscaling che, nel caso di utenza prevalentemente da una unica nazione o fuso orario, tipicamente si assesterenno sul minimo la notte e su un numero intermedio durante il giorno. Da ciò emerge che possiamo considerare l’utilizzo di questi nodi in autoscaling al 40% del tempo totale mensile, con conseguenti costi al 40% per queste macchine.
Quindi, per il solo fatto di aver messo i frontend web in scaling automatico, si ottiene un risparmio del 16% sul costo totale dell’infrastruttura.
Un altro tipo di approccio è quello di fissare, invece, l’infrastruttura sul massimo delle sue potenzialità e cercare di ridurre i costi con metodi “commerciali”: c’è la possibilità su AWS di ottenere sconti interessanti, impegnandosi per l’acquisto delle risorse necessarie per lunghi periodi da 1 anno fino a 3 anni, con conseguenti sconti proporzionali al tempo dell’impegno e all’eventuale anticipo di pagamento delle risorse (nullo, parziale o totale).
Nella nostra simulazione abbiamo ipotizzato di non versare nessun anticipo e impegnarci per 12 mesi (condizione meno vantaggiosa economicamente, ma che ci comporta un impegno minimo).
A conti fatti, la soluzione “reserved” ci porta a risparmiare circa il 33%.
Ma non finisce qui! Perché non combinare le 2 soluzioni precedenti? Fare, cioè, una reservation a un anno su tutta l’infrastruttura, tranne una parte in autoscaling che teniamo invece on demand. Lasceremo in autoscaling on-demand i 12 nodi e faremo reservation per tutto il resto.
Con la soluzione combinata si arriva al 41% di risparmio, non male!
Ci sono altre opzioni di sconto che AWS ci offre, come l’utilizzo di SPOT instances. Le istanze SPOT sfruttano la capacità inutilizzata di AWS e vengono offerte con sconti molto forti.
Il rovescio della medaglia delle SPOT è che possono venire spente in qualunque momento senza preavviso. Certo su un singolo nodo è un grosso problema, non però su una batteria in autoscaling fino a 17 nodi.
Allora potremmo decidere di utilizzare, per 8 dei 12 nodi del caso precedente, la modalità SPOT.
Con questa ultima combinazione di reserved, spot, autoscaling, arriviamo al 45% di risparmio rispetto al costo iniziale.
Certo lo use case cambia da sistema a sistema, ma applicando i concetti esposti, si ottengono comunque risultati molto interessanti.
Ad esempio, se il minimo dei nodi a sistema “scarico” deve essere 10 al posto di 5, combinando opportunamente le varie soluzioni, possiamo arrivare anche al 40% di sconto.
4. Diamo i numeri…
Abbiamo effettuato, con l’infrastruttura indicata in figura 3, dei test di carico specifici per Magento2, con una parte di navigazione senza acquisti e una parte di simulazione carrello e checkout.
Dove possiamo arrivare con le nostre 206 vCPU ?
- una media di 224 ordini/minuto
- una media di 34.100 pageview/minuto
In un dato momento ci sono sempre 10.000 utenti attivi!
Sono stati inoltre registrati i seguenti picchi:
- 277 ordini/minuto
- 56.400 pageview/minuto
Diego Belotti – Responsabile Gestione Infrastruttura Cloud @ Subcom
