Nella notte italiana tra martedì e mercoledì scorsi un’intera regione di Amazon Web Services, la Northern Virginia (Us-East-1), si è scontrata con massicci problemi di erogazione del Simple Storage Service (S3), rendendo inaccessibili per quasi quattro ore migliaia di siti e oggetti connessi tra cui Docker Hub, Trello, Travis CI, Github, Minecraft e Yahoo! Mail. Il provider aveva garantito spiegazioni, che sono arrivate ieri. In estrema sintesi, si è trattato di un banale errore umano dovuto allo “spegnimento” temporaneo di una serie sbagliata di server. Andiamo con ordine. Come illustrato da Aws a questa pagina, martedì 28 febbraio il team di S3 stava effettuando il debugging di un errore che stava rallentando in modo inaspettato il sistema di fatturazione del servizio di storage sulla nuvola.
Alle 9.37 del mattino, un membro autorizzato del team ha lanciato un comando per scollegare un piccolo numero di server da uno dei sottosistemi S3 utilizzati nel processo di fatturazione. Per usare le parole di Aws, “sfortunatamente” uno dei comandi è stato inserito in modo scorretto, causando la rimozione di un numero ben più consistente di server, i quali supportavano altri due sottosistemi S3.
Uno di questi, incaricato di gestire l’indice, processava i metadati e le informazioni di localizzazione di tutti gli oggetti S3 presenti nella regione Us-East-1, elaborando tutte le richieste Get, List, Put e Delete. Il secondo cluster, invece, gestiva l’allocazione di nuovo storage e si appoggiava all’infrastruttura di indicizzazione per funzionare correttamente.
“Rimuovere una porzione significativa della capacità ha richiesto un riavvio completo dei sistemi”, ha scritto Amazon Web Services nella nota. Ovviamente, durante l’inattività dei server, S3 non è riuscito a processare le richieste, bloccando di fatto anche altri servizi dipendenti dallo storage cloud di Aws, tra cui Ec2, Ebs, Lambda e, cosa ancora più importante, la stessa dashboard della piattaforma.
Per questo, nei primi istanti del disservizio (e prima che Aws ne desse conferma), il cruscotto del provider non segnalava alcun problema. Per concludere, a rallentare le operazioni di ripristino è stato proprio il riavvio del sottosistema indice, che non avveniva da tempo e ne ha quindi richiesto molto più “del previsto”. Come anticipato già nella giornata di martedì dall’azienda di Seattle, l’interruzione non è stata quindi causata da attacchi hacker.
Per evitare problemi analoghi in futuro, il provider ha deciso di modificare i parametri dello strumento che serve e rimuovere capacità di storage, rallentandone la velocità di esecuzione. Inoltre, il gruppo ha aggiunto un elemento di salvaguardia per evitare che la capacità di elaborazione scenda al di sotto di un certo livello.
Infine, Aws è intervenuta sulla velocità di recupero dei sottosistemi S3, teoricamente già oggi ottimizzata per “spezzettare” i servizi di storage in “celle” più piccole, su cui lavorare più agilmente. Ma, come sottolineato dall’azienda, quanto implementato non si è rivelato all’altezza di un evento così importante. Una vicenda che farà sicuramente riflettere il provider, ma che sottolinea ancora una volta come sia fondamentale adottare strategie multicloud, che permettono in casi come questo di limitare fortemente i danni.