Lo scorso 21 Aprile abbiamo assistito a uno dei più gravi failure dei servizi cloud di Amazon. Nello specifico il guasto ha interessato il servizio di EBS (Elastic Block Storage), questo ha scatenato contemporaneamente il recovery di numerosi volumi, saturando il traffico I/O per la normale operatività del servizio. Nel lasso di tempo per il recovery, che per i più sfortunati è durato fino a 48 ore, l’accesso al servizio EBS da parte degli altri servizi offerti da Amazon, come per esempio EC2 nel datacenter interessato, era notevolmente rallentato se non del tutto inutilizzabile. Il disagio è stato talmente avvertito che è stato creato un sito su cui venivano segnalate le applicazioni web non disponibili a causa del guasto (http://ec2disabled.com/), i nomi noti sono Reddit, MongoHQ e siti come Themoviedb, nonchè alcune applicazioni di Microsoft destinate ai social network.
Ciò che emerge, dalla grande quantità di siti / startups andate down durante il guasto, è la leggerezza con cui si è pensata la propria applicazione e di come ci sia stato un assalto al cloud senza però conoscerne oltre ai vantaggi anche i punti deboli.Il caso eclatante è un’azienda che fornisce un servizio di monitoraggio per pazienti cardiopatici via internet, che si è trovata impossibilitata completamente ad erogare il servizio per ben 2 giorni (https://forums.aws.amazon.com/thread.jspa?threadID=65649&tstart=0). In un ambiente come il cloud, per definizione effimero, diventa di primaria importanza implementare strategie di replica, che proprio grazie ai servizi cloud possono essere pensate non più a livello metropolitano o nazionale , ma addirittura intecontinentale (vedi Availability Zone di Amazon AWS). Queste tecniche hanno infatto garantito l’erogazione del servizio a siti come SmugMug, SimpleGeo e Netflix.
Da questo problema possiamo ricavare 5 regole chiave da utilizzare in un progetto basato su servizi cloud:
- Tutto deve essere automatizzato dalla creaziione di nuove istanze per espandere i propri cluster passando per il monitoring, la gestione delle configurazioni, raccolta di metriche applicative, backup e infine il restore dal backup. Nulla può essere lasciato al caso vista l’imprevedibilità e lo scarso controllo che si ha sul sistema.
- Cercare di creare architetture share-nothing in modo tale da poter “attraversare” più Availabilty Zone o addirittura più provider. Questo ci garantirà livelli di disponibilità veramente elevati.
- Vista la natura effimera di questi servizi sarebbe sconsigliato eseguire database di produzione (Oracle, Mysql, Postgres o similari), questo anche a causa delle velocità di I/O che non sempre sono eccellenti come la fibra a 4 GB/s del nostro server in ufficio.
- I dati devono essere replicati anche su servizi di storage differenti.Un esempio su Amazon può essere Mysql su RDS (Relational Database Service) replicato su un server slave che gira su EBS, o RDS replicato su un’altra Availability Zone.
- Per ovviare a qualunque problema sui servizi sopra citati , si possono prevedere anche metodi di replica a livello applicativo avendo di conseguenze un controllo maggiore su cosa sta accadendo alla propria applicazione.
Il cloud di per sè non è l’arma perfetta, ma può diventarlo solo se chi progetta le applicazioni ha ben presenti quali sono i vantaggi e i limiti di questi nuovi servizi, senza dimenticare i costi che una soluzione maggiormente resiliente può avere nel cloud.
