CASE STUDY N#1. Deploy e automazione di un applicazione scalabile con il supporto di SaltStack per Corley

Transcript

2 SUMMARY I risultati Il deploy e l automazione di un applicazione scalabile con il supporto di SaltStack I protagonisti Walter Dal Mut e Gabriele Mittica, soci fondatori di Corley. Corley è un azienda nata nel 2012 che riunisce professionisti con un esperienza pluriennale nei servizi cloud e nello sviluppo di applicativi web. Il settore Servizi IT e sviluppo web La sfida Corley si è trovata di fronte alla necessità di fare il deploy di Cwitter, un applicazione PHP-MySQL, con previsione di 800 utenti contemporanei. L esigenza era quella di avere un infrastruttura conveniente, scalabile e in alta affidabilità su cui poter installare l applicazione, senza doverne modificare il codice sorgente ad ogni aggiornamento o estensione dell infrastruttura. La soluzione Creazione di un architettura su Enter Cloud Suite composta da 19 nodi e 4 livelli (proxy, applicativo, cache, dati), deploy dell applicazione, esecuzione di operazioni di automazione e orchestrazione con SaltStack per gestire gli aggiornamenti e scalare l infrastruttura. Abbattimento dei costi dell infrastruttura del 50% rispetto al prezzo di corrispondenti server dedicati* Riduzione consistente del time to market, sia in fase di installazione della prima infrastruttura che in occasione dei successivi adattamenti: il risparmio di tempo per l introduzione di un nuovo nodo è stato stimato nell intorno del 95% Miglioramento della velocità dell applicazione, per effetto di bassi tempi di latenza garantiti da un infrastruttura cloud situata in Italia Abbattimento dei tempi di gestione per effetto di tool di automazione, quali SaltStack, che fanno chiamate ad Enter Cloud Suite attraverso le API standard di OpenStack Affidabilità dell applicazione anche in caso di problematiche dei server su cui risiede. Abbiamo creato un infrastruttura a livelli, scalabile automaticamente in base alle necessità dell applicazione. Questo ci ha permesso di non allocare risorse di calcolo eccessive che sarebbero rimaste inutilizzate. Con Enter Cloud Suite abbiamo risparmiato tempo e denaro. CONTATTACI PER SAPERNE DI PIÙ O PER CHIEDERE UN PREVENTIVO info@entercloudsuite.com * Dati rilevati il 21 luglio 2014, confrontando il prezzo delle istanze di ECS con il prezzo di server dedicati OVH 2

3 CASE STUDY I protagonisti Walter Dal Mut e Gabriele Mittica, soci fondatori di Corley. Corley è un azienda nata nel 2012 che riunisce professionisti con un esperienza pluriennale nei servizi cloud e nello sviluppo di applicativi web. La sfida Corley ha sviluppato un applicazione, Cwitter, che, come Twitter, consente agli utenti di pubblicare brevi messaggi di testo. Può essere utilizzata per generare meccaniche di networking durante eventi dedicati ad una cerchia di persone come, ad esempio, tutti i partecipanti ad un grande congresso. Trattandosi di un applicazione esposta a picchi di traffico forti ma limitati nel tempo (nel caso specifico si parla di un massimo di 800 utenti contemporanei), si è posto il problema di come creare un infrastruttura efficiente e scalabile, con lo scopo di evitare inutili costi durante i tempi morti: di fatto, prima e dopo l evento nessun utente avrebbe usato l applicazione. Inoltre, data l importanza dell evento, doveva essere garantita l alta affidabilità. Cwitter è un applicazione PHP-MySQL con una struttura classica, articolata in 4 livelli: 1 livello: proxy 2 livello: applicativo 3 livello: caching (per velocizzare l applicazione) 4 livello: base dati (tipica base dati MySQL) Mettere tutto su un server solo avrebbe generato una serie di problemi. In primis, ci sarebbe stata una cannibalizzazione di risorse: ad esempio, Memcached e MySQL si sarebbero rubati la RAM, perché entrambi i servizi ne fanno largo uso. Secondariamente, sarebbe stato difficile gestire la scalabilità perché ognuno dei livelli scala a modo proprio. Da ultimo, non sarebbe stata comunque garantita l alta affidabilità, essendo l applicazione residente su un singolo nodo. La soluzione Per far fronte a queste criticità, è stata scelta l infrastruttura cloud di Enter Cloud Suite. In particolare, da un punto di vista architetturale, invece di utilizzare una o più macchine per tutta l applicazione replicata più volte nella sua interezza, sono state utilizzate istanze diverse per ciascuno dei differenti livelli dell applicazione; questo ha consentito di gestire la scalabilità in funzione delle effettive esigenze di calcolo di ciascun livello e di ottimizzare l investimento in risorse. Gestire un infrastruttura realmente cloud e distribuita è impensabile senza dei tool di automazione, sostiene Walter. Fig. 1. Home page Cwitter 3

4 Per automatizzare la scalabilità dell infrastruttura, è stato usato il tool SaltStack, che facilita l orchestrazione delle operazioni di deploy di un software su più macchine, attraverso chiamate API alle risorse di Enter Cloud Suite. Enter Cloud Suite, infatti, rende immediata la creazione di nuove risorse. SaltStack ha facilitato l automazione anche della parte software dell applicazione. Separare i servizi è stato anche utile per monitorarne la corretta funzionalità, oltre che a gestire il dimensionamento dell infrastruttura in modo più efficiente. Non ci sono stati problemi ma, in caso si fossero verificati, un architettura cloud avrebbe consentito di identificare più facilmente i colli di bottiglia e di gestirli prontamente. Sul tema dell alta affidabilità, è stata considerata la tecnica della fiamma pilota : una piccolissima istanza, su un altra region, ad Amsterdam. In caso di disastro o di un semplice problema di connettività sull area geografica di Milano, l intera infrastruttura avrebbe potuto essere ricostruita, partendo dalla fiamma pilota, sul nodo di Amsterdam in pochi minuti e, con un semplice cambiamento del puntamento del DNS, l applicazione avrebbe girato sulla nuova infrastruttura in Olanda. Infine, la scelta è ricaduta su Enter Cloud Suite anche per motivi di tempi di latenza. Come region primaria è stata scelta l Italia, visto che gli accessi all applicazione si sarebbero verificati principalmente da punti di accesso alla rete italiana. I risultati La scelta di Enter Cloud Suite si è tradotta innanzitutto in un risparmio del 50% rispetto ai costi di un infrastruttura dedicata*. Da un punto di vista del time to market, con l aiuto di SaltStack collegato ad Enter Cloud Suite, è stato possibile ridimensionare l infrastruttura o deployare l applicazione su un infrastruttura gemella in una region differente in pochi minuti, con un risparmio di tempo del 95% rispetto ad una riconfigurazione manuale. Ad esempio, aggiungere una macchina tradizionale con funzioni di web server e collegarla ad un proxy comporta almeno 4 ore di lavoro; con SaltStack collegato ad Enter Cloud Suite tutte le operazioni si esauriscono in 10 minuti. * Rilevazione fatta il 21 luglio 2014 su listini Enter Cloud Suite e listini on line per server dedicati OVH. Analoghi benefici sono stati raggiunti per la velocizzazione delle operazioni di aggiornamento. Corley lavora sull ottimizzazione delle applicazioni a 360, ribadisce Walter. Poter far affidamento su un infrastruttura con tempi di latenza convincenti, più bassi di alcuni provider americani, ha consentito di poter migliorare ulteriormente le performance dell applicazione. A noi interessa l affidabilità del servizio, non tanto l affidabilità del server. In questo senso Enter Cloud Suite è stato un servizio particolarmente utile. Poter replicare l infrastruttura su una seconda region, in caso di down (non verificatosi) della prima, ha consentito di realizzare un applicazione in alta affidabilità. Il progetto tecnico Per quanto riguarda l architettura, ad ogni livello sono state abbinate istanze proporzionate al compito e alle necessità di calcolo che ciascun livello deve svolgere (Fig. 2). Per le funzionalità di proxy, sono state create 3 macchine con il taglio più basso e1standard.x1. Anche per i server web sono state create 8 istanze molto piccole con flavor e1standard.x1 (1 CPU, 0,5 GB RAM, 20 GB storage); difficilmente un server Apache richiede molte risorse se deve solo eseguire operazioni di web application, quindi degli script. Per il livello di cache e di gestione della sessione (con utente univoco indipendentemente dal web server su cui fosse atterrato), sono state selezionate 4 macchine e1standard.x4 RAM intensive (2 CPU, 4 GB RAM, 160 GB storage), come richiesto da Memcached che lavora tutto in RAM. La parte più complicata riguarda il livello del database. Partendo dal presupposto che il master deve solo scrivere e farlo spesso, mentre le macchine slave devono leggere velocemente, è stata configurata un architettura master-slave composta da 1 macchina master e1standard.x4 (2 CPU, 4 GB RAM, 160 GB storage) e 3 macchine slave più potenti e1standard.x7 (4 CPU, 8 GB RAM, 1200 GB storage). Solo alle tre istanze di proxy è stato abbinato un IP pubblico e, pertanto, le stesse sono state rese raggiungibili da fuori; le altre (web, caching, 4

5 db) sono state mantenute private, grazie alla configurazione dei Security Group messi a disposizione da Enter Cloud Suite. Sono state quindi eliminate le connessioni con l esterno non necessarie, con un conseguente aumento della sicurezza dell applicazione (Fig. 3). Con questo tipo di architettura, non essendoci colli di bottiglia sul database, è stato sperimentato come incrementando il numero di web server aumentasse sensibilmente anche la possibilità di gestire molte più richieste al secondo, migliorando tangibilmente la performance dell applicazione. Entrando nel merito dell orchestrazione dell infrastruttura con SaltStack, di fatto sono stati creati dei gruppi di istanze, per ciascuno dei quali sono state indicate regole sia relative alle risorse delle macchine appartenenti al gruppo sia relative al deploy della parte software. Aggiungendo una nuova istanza ad un gruppo, ad esempio quello dei web server, SaltStack innesca la creazione di una nuova istanza, la aggiunge al gruppo e il proxy automaticamente serve il traffico al nuovo web server, su cui l applicazione è stata resa disponibile. Nelle figure 3 e 4 si illustrano alcune operazioni di esecuzione integrata su più macchine. Il tutto, senza dover intervenire sul software dell applicazione. È l infrastruttura che si adatta all applicazione, non viceversa (...) Di fatto, osserva Gabriele, ci siamo potuti concentrare sul continuous delivery dell applicazione; l infrastruttura di produzione, dopo essere stata configurata, va da sola!. Fig. 2. Architettura di CTwitter su Enter Cloud Suite 5

6 Fig. 3. Gestione dei security group Fig. 4. Creazione di una nuova macchina database a partire dal modello RDB definito precedentemente Fig. 5. Collegamento di un nuovo MySQL Slave direttamente in modo centralizzato e automaticamente replicato su tutti gli slave presenti Cosa dice il cliente di noi Avere più server spaventa: con gli strumenti che ci sono oggi, infrastrutture convenienti, aperte ed elastiche come Enter Cloud Suite e tool di orchestrazione e automazione come SaltStack, la gestione delle applicazioni risulta più facile, più rapida e meno costosa. Enter Cloud Suite ci ha aiutato a creare un infrastruttura scalabile orizzontalmente per la nostra applicazione a più livelli: questo ci ha consentito di scalare in modo efficiente, veloce, con bassi tempi di latenza a tutto vantaggio delle performance dell applicazione. Il tutto in tempo reale, senza dover chiedere aiuto a nessuno. Abbiamo creato un infrastruttura a livelli, scalabile automaticamente in base alle necessità dell applicazione. Questo ci ha permesso di non allocare risorse di calcolo eccessive che sarebbero rimaste inutilizzate. Con Enter Cloud Suite abbiamo risparmiato tempo e denaro. CONTATTACI PER SAPERNE DI PIÙ O PER CHIEDERE UN PREVENTIVO info@entercloudsuite.com