Evoluzione di una infrastruttura Magento

infrastruttura magento

Lo store online Artimondo.it ospita lo shop de “L’Artigiano in Fiera”, una delle manifestazioni dell’artigianato più grandi del mondo.
Il cliente aveva la necessità di far evolvere l’architettura originale in modo che aumentassero contemporaneamente le performance e la robustezza.
Gli obiettivi iniziali erano aumentare le performance e supportare il carico stagionale dovuto alla fiera, cercando di contenere i costi e senza stravolgere l’applicazione preesistente.

Lo shop, basato su Magento, era ospitato originamente su un’infrastruttura così composta:

infrastruttura

Le componenti dell’infrastruttura iniziale che ospitava l’ecommerce di Artimondo.it erano:

  • Layer “Proxy FrontEnd”: Nginx ha il duplice ruolo di effettuare del caching delle risorse statiche prelevate dallo filesystem NFS condiviso e di proxy delle richieste verso Magento, interrogando Apache per eseguire il codice PHP.
  • Layer “Web Tier”: è’ il nodo Apache che esporta il filesystem NFS condiviso per le risorse statiche, esegue il codice Magento ed ospita anche la parte admin dello shop.
  • Layer “Database BackEnd”: nodo MySQL per i contenuti di Magento e per il blog WordPress aziendale.

Tutto questo funzionava fino a quando non si è presentata l’esigenza di scalare orizzontalmente. La soluzione più ovvia, quindi, è stata quella di aggiungere nodi web per poter soddisfare il picco di richieste che si verifica nel mese di dicembre. Nell’ultimo mese dell’anno, infatti, si tiene l’edizione annuale della fiera dell’artigiano: questa dura 2 settimane, durante le quali il numero di visitatori raddoppia.
Nell’ultimo anno abbiamo assistito ad un aumento costante del traffico mese su mese e con il cliente abbiamo valutato un’espansione graduale della piattaforma server.

Il nuovo diagramma dell’architettura si è così evoluto:

infrastruttura magento

  • Layer “Proxy FrontEnd”: abbiamo aggiunto un nuovo ruolo a Nginx, quello di bilanciatore verso le due macchine Apache. Nginx ci ha permesso anche di creare delle regole ad-hoc per alcune specifiche della piattaforma.
  • Layer “Web Tier”: in questa parte abbiamo aggiunto un nodo Apache per motivi di ridondanza incrementando il numero di richieste al secondo Layer.
  • Database Backend”: il database MySQL non è stato oggetto di modifiche. Abbiamo aggiunto una nuova macchina per Memcache e Logstash: la prima per condividere le sessioni PHP che non sia quello direttamente a bordo del webserver. Memcache ci permette di condividere in maniera facile, veloce ed efficiente le sessioni PHP esternamente ai webserver.

Infine ci serve un modo per centralizzare i log applicativi e di sistema, per questo possiamo utilizzare lo stack ELK come spiegato in maniera più estesa in questo blog post: http://www.ideato.it/technical-articles/integrazione-logstash-magento
Esso ci permette di poter indicizzare i log dei webserver e quelli applicativi per poi successivamente poterli consultare in modo grafico tramite l’interfaccia HTML5/Javascript Kibana.

Possibili sviluppi futuri

Per poter far evolvere l’architettura verso una flessibile e robusta, dobbiamo ancora risolvere alcuni aspetti:

  • Filesystem NFS condiviso: bisogna rendere ridondante e resistente la parte NFS; ad oggi c’è solo un nodo Apache che esporta i dati verso il proxy di frontend.
  • Database MySQL: mettere in alta disponibilità il database.
  • Nodo Admin separato: esternalizzare il nodo Magento rispetto ai nodi di frontend.

Nei prossimi mesi cercheremo di risolvere queste criticità mostrando un’ipotetica infrastruttura Magento basata su Amazon AWS. Di seguito lo schema generale realizzato con i servizi di AWS.

Gefi-AWS infrastruttura

cloudfront.jpg
CloudFront è il servizio di Amazon che ha la funzione di distribuire i contenuti verso l’utente finale. Alla richiesta di un particolare contenuto, CloudFront ne verificherà la presenza all’interno dei server che compongono le “edge locations”. Se il contenuto è in cache, il contenuto verrà servito dalla edge location con latenza minore; se non lo è verrà recuperato dalla “origin”. Nel nostro caso l’origin è rappresentata dai server web che ospitano l’applicazione Magento.
L’utilizzo di CloudFront non solo distribuirà i contenuti della piattaforma il più velocemente e con minor latenza possibile, ma ridurrà anche il carico sulle nostre istanze EC2.
Prevedendo un carico minore, le istanze saranno sicuramente dimensionate al ribasso.
Un altro fattore da considerare, è l’analisi dei costi fissi e costi variabili: CloudFront sarà un costo variabile rapportato al volume di traffico in ingresso mentre Ec2 sarà un costo fisso qualunque volume la piattaforma abbia in ingresso.

elasticlb.jpg
ELB (Elastic LoadBalancer) è il servizio di loadbalancing offerto da AWS che consente di ripartire il traffico tra le istanze Ec2 allocate.
Periodicamente il servizio effettua dei controlli di integrità sulle istanze (health checks) per determinare quante e quali sono in grado di rispondere alle richieste provenienti dai client. In caso di guasto o malfunzionamenti software di una delle instanze, essa verrà rimossa dal gruppo di loadbalancing.

ec2.jpg
Le istanze Ec2 ospitano i webserver Apache che eseguono il codice PHP di Magento. Il servizio di AutoScaling Group ci permetterebbe di poter modificare il numero di instanze dinamicamente ed automaticamente in base al carico.
L’AutoScaling Group è quello che ci servirebbe per rispondere alla caratteristica “stagionale” del traffico e quindi di aumentare automaticamente il numero di server solamente nel periodo fieristico.

efs
EFS (Elastic File System) è il nuovo servizio che ci consente di avere a disposizione un filesystem condiviso NFSv4 gestito. Il termine “Elastic” è dovuto al fatto che la sua capacità non dovrà essere definita a priori, essa si ridurrà o aumenterà (così come le performance di termini di IOPS) in base allo spazio occupato.
Nel nostro scenario, EFS ci permette di disaccoppiare dalle istanze Ec2 la componente di filesystem condiviso.

elasticache.jpg
ElastiCache è il servizio che ci permette di poter utilizzare i motori di caching di Memcache e Redis. Nel nostro scenario potremmo creare un cluster Memcache per ospitare le sessioni PHP; creando il cluster su Availability Zones differenti si riuscirebbe a garantire una maggior resistenza ai guasti.

aurora.jpg
Amazon Aurora è il nuovo motore database MySQL 5.6 compatibile, però con performance fino cinque volte superiori al classico MySQL sia installato localmente su una instanza Ec2, oppure come servizio su RDS (Relational Database Service).
Aurora è una delle scelte di database relazionale che possiamo avviare tramite RDS; possiamo quindi beneficiare della maggiore velocità e di altre caratteristiche solamente con un click in fase di creazione!
Per maggiori dettagli potete trovare benchmark e caratteristiche nelle slide rilasciate pubblicamente da Amazon durante l’ultima conferenza re:Invent (http://www.slideshare.net/AmazonWebServices/sdd415-new-launch-amazon-aurora-amazons-new-relational-database-engine-aws-reinvent-2014)

Conclusioni

Al giorno d’oggi è possibile creare infrastrutture robuste e scalabili scegliendo in maniera corretta gli strumenti e i servizi che il Cloud computing ci mette a disposizione, componendoli a seconda dello stack applicativo di cui ha bisogno la nostra applicazione.
Da qualche giorno Amazon ha messo a disposizione anche della documentazione e dei template CloudFormation per poter ricreare da zero e in maniera semi-automatica un ambiente di test/produzione simile a quello descritto sopra.
(link https://s3.amazonaws.com/quickstart-reference/magento/latest/doc/Magento_on_the_AWS_Cloud.pdf)

 

In collaborazione con Alessandro Mazzoli.

Ti piacerebbe restare aggiornato su tutte le novità e i migliori case studies?

Iscriviti alla newsletter