Nuova struttura, più sicurezza e costi ridotti: Archismall su AWS

In questo articolo parleremo della migrazione di Archismall su AWS. Vedremo come l’infrastruttura e le applicazioni di Archismall sono state migrate interamente da Google Cloud Platform ad AWS ed i vantaggi legati a questa scelta.

Composizione di Archismall su AWS

L’infrastruttura è composta principalmente da un cluster Kubernetes contenente le varie applicazioni che compongono Archismall tra cui:

• il suo front-end;
• dei Walker Java in background;
• dei Web Service e delle api;
• una serie di altri microservice che collaborano e parlano tra loro;
• un Network File System che viene utilizzato da questi microservice per condividere file;
• un database MySQL;
• un database MongoDB.

La migrazione che abbiamo fatto è stata, come già detto, da Google Cloud Platform ad AWS. Non si è trattato solo di un lift and shift, ovvero copiare interamente quello è stato fatto, bensì abbiamo approfittato dell’occasione per fare degli upgrade e migliorare una serie di componenti dell’infrastruttura. Essendo questi sotto il nostro controllo, dovendoci occupare del loro aggiornamento e debug in caso di problemi, li abbiamo migrati a servizi gestiti da AWS.

Più avanti in questo articolo entreremo più nel dettaglio dei servizi utilizzati e dei vantaggi ottenuti.

I servizi

Per portare a termine questa operazione abbiamo usato diverse tipologie di servizi, i principali che compongono l’infrastruttura di Archismall sono:

• EKS, ovvero Kubernetes service;
• RDS per MySQL;
• Elastic File System (EFS) per il network file system che utilizziamo.

Inoltre abbiamo sfruttato altri servizi AWS di contorno, che non compongono propriamente l’infrastruttura, ma servono per monitorare e controllare l’accesso. Due esempi sono rappresentati da Cloudwatch e Identity Access Management (IAM).

In fase di migrazione è stato essenziale AWS Database Migration System (DMS), che ci ha permesso di migrare il nostro database MySQL con un downtime minimo, praticamente 0. Con altri tool come Dump e Restore, invece, ci sarebbe voluta una giornata intera, vista la grandezza del database e la necessità di non perdere o danneggiare i dati. DMS è stato essenziale durante la migrazione.

Archismall Analytics

Quella che vedete nell’immagine qui sopra è una parte del cruscotto di Archismall, tramite una Dashboard Cloudwatch, tutti questi dati vengono raccolti da AWS e riguardano per esempio:

• l’utilizzo del database MySQL;
• le richieste al NGINX di Archismall che passano tramite un load balancer AWS;
• l’utilizzo delle varie partizioni dello stesso file system che vengono condivise tra i pod di Archismall.

Abbiamo anche, grazie a Cloudwatch, i vantaggi di aggregazione dei log che vengono raccolti dal nostro Cluster e possiamo controllare con molta precisione quando vengono salvati e con che frequenza. Il nostro scopo è poter fare query su questi Log ed andare anche ad attivare degli alert nel caso di log che richiedono l’intervento di uno sviluppatore.

I vantaggi della migrazione di Archismall

Gestione

Passando da servizi con infrastruttura gestita da noi ad infrastruttura gestita da altri, non dobbiamo più compiere gli aggiornamenti, i controlli ed una serie di azioni che sono soggette all’errore umano e costano tempo a tutti gli sviluppatori. In particolare il Network File System era gestito da noi ed era quindi un pod all’interno del cluster Kubernetes, con al suo interno un container Docker. Ora, invece, siamo passati ad EFS.

EFS contiene dei dati critici per l’applicazione di Archismall (ovvero gran parte delle fatture) e viene replicato su più zone di disponibilità AWS. Questo garantisce un’elevata sicurezza dei dati al suo interno, anche grazie al fatto che viene backuppato programmaticamente in maniera incrementale. In questo modo abbiamo più sicurezza e resilienza dei dati.

Scalabilità

Un altro vantaggio molto importante di EFS è la sua scalabilità automatica che ci permette di pagare solo la vera e propria quantità di dati che sono al suo interno in ogni momento. Con il metodo precedente, invece, bisognava pagarne un volume molto più ampio, che doveva essere scalato ogni tot mesi, per appunto aumentare la sua grandezza e fare spazio ai nuovi dati.

MongoDB

MongoDB era gestito all’interno del Cluster Kubernetes come una serie di pod, adesso invece si trova su Atlas, quindi il servizio di MongoDB as a service.

Questo Cluster Atlas in realtà si trova nella stessa regione AWS, permettendo di ottenere una latenza minima nella connessione tra la nostra applicazione nel Cluster Kubernetes ed il database MongoDB. Abbiamo anche creato un VPC peering che quindi ci permette di avere anche una sicurezza a livello di networking sul nostro Cluster Atlas. Qui entrano in gioco altre funzionalità come backup automatizzati, grande controllo sulle metriche del database, sulle query che vengono effettuate, l’utilizzo di indici ecc.

AWS DMS

Altro vantaggio che non riguarda l’infrastruttura, ma la migrazione, consiste nell’utilizzo di AWS DMS. Come abbiamo anticipato, questo servizio ci ha permesso appunto di migrare interamente la nostra infrastruttura con un downtime veramente minimo. Nel nostro caso è stato inferiore ad un’ora, ma potrebbe potenzialmente essere ancora inferiore. Questo è un risultato eccellente.

Risparmio

Infine, parliamo del vantaggio dei bassi costi che non è banale. Infatti, dopo l’utilizzo di una serie di scontistiche per le istanze riservate, abbiamo ridotto i costi sull’infrastruttura fino al 40%. Il risultato è stata una migrazione che non ha avuto solamente vantaggi dal lato tecnico o di visibilità della nostra applicazione, ma dal punto di vista del risparmio.

Cliccando questo link è possibile visualizzare un video della durata di 9 minuti nel quale espandiamo ulteriormente i contenuti di questo articolo.