-
cronache di una startup 9 May 2011
Report: Cos’è Successo il 21 Aprile
2 commenti
Come promesso, anche se un po’ in ritardo, vogliamo condividere un resoconto delle cause che hanno creato il disservizio di Blomming lo scorso 21 aprile, cogliendo l’occasione per spiegare un po’ meglio “cosa c’è dietro” al nostro sistema.
Premesse
Blomming è una piattaforma sviluppata in Ruby (utilizzando in particolare il framework Ruby On Rails) che è una delle tecnologie più moderne e avanzate per creare servizi web. Allo stesso tempo è molto affidabile, anche rispetto ad alternative per grandi aziende. Sin dal primo giorno in cui siamo andati online siamo stati attenti nella scelta di un partner che fosse in grado di offrire un servizio all’altezza delle aspettative dei nostri utenti e che quindi avesse caratteristiche di robustezza dell’infrastruttura, alta disponibilità del servizio e un alto grado di scalabilità, ovvero la capacità di adattarsi per gestire picchi di traffico offrendo sempre lo stesso ottimo livello di servizio.Dopo un’accurata selezione la nostra scelta è ricaduta su uno dei provider di servizi web più noti e solidi al mondo, ovvero AmazonWS e, per l’esattezza, utilizzando Heroku: un’infrastruttura di cloud computing per applicazioni Ruby che fornisce un ulteriore livello di astrazione e feature dedicate alle nostre tecnologie. In particolare questa infrastruttura risiede in un data center di Amazon in North Virginia ed è utilizzato da molte note startup web USA come Fourquare, Quora e Reddit.
I dati degli utenti, in ogni caso, sono e sono sempre stati tutelati da backup con frequenza oraria e scaricamento giornaliero, distribuiti in zone separate in modo da avere la massima resistenza agli errori. In particolare, per assicurare la massima stabilità e ridondanza del sistema, i dati sono gestiti attraverso un database nel sistema di cloud computing (con gli opportuni backup dislocati di cui sopra) mentre i media (sostanzialmente le foto dei prodotti e degli utenti) risiedono nella piattaforma di cloud storage Amazon S3 (che non è stata toccata dal problema del 21 aprile).
Blomming, quindi, è stato pensato per offrire un ottimo livello di affidabilità da subito. Ma già prima del 21 aprile, per via della crescita del numero degli utenti e dei prodotti a catalogo, avevamo aumentato le capacità dei nostri sistemi sia come “potenza di calcolo” (web server) sia nelle performance e capacità del database, scegliendo una alternativa più costosa ma ancora più affidabile.
Cosa è successo il 21 aprile
Il 21 aprile il data center di AmazonWS del North Virginia ha iniziato ad avere dei problemi intorno alle ore 10:00 italiane: la natura del problema è stata spiegata in ogni dettaglio nel post mortem di AWS. Sostanzialmente si è trattato di un errore, probabilmente umano, di aggiornamento dell’infrastruttura di rete. I server hanno “creduto” di non essere più collegati alle loro “copie specchio” (mirror) e hanno iniziato a cercare di “auto-ripararsi”. Così facendo hanno esaurito lo spazio disponibile nella loro rete locale e hanno messo in crisi anche i server di altre reti, che hanno cercato di “auto-ripararsi” anche loro. Il problema si è quindi amplificato e ha portato a un collasso del sistema. AmazonWS lo definisce un “re-mirroring storm”: una “tempesta”.All’inizio ci sono state delle interruzioni sporadiche del servizio ma dopo circa un’ora (quindi verso le nostre 11:00) Blomming è andato “down”, rimanendo inaccessibile per quasi 24 ore. Il problema di AmazonWS, invece, è durato in totale 80 ore: un fenomeno mai accaduto prima su questa scala. Heroku, la piattaforma di cloud computing che utilizziamo, ha fornito un ottimo supporto nello spostare tutta l’infrastruttura in un’altra zona di AmazonWS non colpita dal problema. Tutti i dati degli utenti, comunque, erano tutelati anche in caso di disastro grazie all’ultimo backup orario effettuato dall’infrastruttura e al backup giornaliero sempre in salvo presso di noi. Oltre a controllare continuamente gli aggiornamenti di stato di AmazonWS ed Heroku e a seguire l’evento in diretta grazie a Twitter, per capire cosa succedeva anche alle altre startup e verificare i termini del problema, siamo rimasti in contatto mail con il supporto di Heroku.
Happy ending
L’upgrade che abbiamo effettuato recentemente non rispondeva a una particolare esigenza immediata. E’ stato fatto in base a un’ipotesi di crescita del traffico, quindi solo per tutela preventiva. A seguito di questa azione il sistema era così in grado di reggere richieste un ordine di grandezza superiori. E grazie al cielo che l’abbiamo fatto, perché proprio per questo Blomming è stata privilegiata da Heroku, riattivando il nostro servizio prima di altri. Questa l’e-mail che abbiamo ricevuto il 22 mattina, quando siamo tornati live:Hello,
You’re running on a cold standby of your dedicated database server. I’ve gone ahead and restarted your app. It appears to be working for me over here.
-Terence…e abbiamo tirato un sospiro di sollievo :). Cliccando qui potete vedere anche il post mortem di Heroku che offre un’analisi approfondita dell’accaduto dal loro punto di vista.
Considerazioni
E’ stata una giornata dura per molte startup. Non possiamo immaginare cosa abbiano passato i tecnici di AWS, Heroku e tutti gli altri servizi. Ci sono stati molti tweet in merito durante il down e svariati blog, sia USA che italiani, ne hanno parlato in modo acceso. A nostro avviso quello che è successo il 21 aprile è sicuramente segno della fallibilità di ogni sistema, anche se ben fatto. Le cloud, in compenso, sono comunque in grado di salvaguardare i dati degli utenti, imparare dagli errori commessi e migliorare giorno per giorno. Tuttavia, nonostante la rarità, un evento del genere non dovrebbe mai accadere e per questo ci scusiamo.Anche sulla base delle riflessioni che emergono dai post mortem di AWS ed Heroku, l’accaduto ha evidenziato un problema impensabile fino a poco prima, ed è quindi occasione per rafforzare e migliorare i livelli di servizio. Heroku ha affermato che “Se non riescono a risolvere il problema i tecnici di AWS, probabilmente non ci può riuscire nessun altro al mondo”. Quora ha scritto “Senza AWS non esisteremmo”. Ed è così: i sistemi di cloud computing come questi permettono l’accesso a sistemi con capacità pari a quelli per le grandi aziende anche ai servizi web. Un po’ come se si potesse installare il proprio server insieme a quelli di una banca, potendo avere lo stesso livello di servizio ed essendo anche sicuri di crescere senza problemi in futuro. Anche per questo un post sul blog di O’Reilly (il più importante editore di tecnologia al mondo) titola Una Splendida Giornata per la Cloud.
In ogni caso ci impegniamo perché cose del genere non accadano più in futuro, assicurando che continueremo ad alzare il livello di servizio anche prima che se ne senta effettivamente il bisogno.
Potrebbero interessarti anche:
Tags: blomming, creare uno shop, down, heroku, servizio, sistemi









2 Responses to “Report: Cos’è Successo il 21 Aprile”
The Cloud Storm: Tutta Colpa di Terminator | Infoservi.it May 9th, 2011 at 12:13 pm
[...] re-mirroring storm , una tempesta. Noi abbiamo fatto una sintesi dal punto di vista di Blomming in questa pagina, con la descrizione di quanto accaduto, link di approfondimento e alcune considerazioni che [...]
Ila May 10th, 2011 at 11:49 am
Sono cose che possono succedere. Meglio se non capita ovviamente, ma usare toni accesi per queste cose, beh….
Un bacio ragazzi, per me siete sempre super ok!