Il ripristino di un'infrastruttura cloud può rivelarsi un'operazione tanto delicata quanto un castello di carte: basta un movimento sbagliato e l'intera struttura crolla nuovamente. È esattamente quello che è successo ad Amazon Web Services durante il prolungato disservizio che ha colpito la regione US-EAST-1 il 20 ottobre scorso. Quando gli ingegneri hanno creduto di aver risolto il problema iniziale, hanno involontariamente innescato una serie di guasti a catena che hanno prolungato l'interruzione per oltre dodici ore consecutive.
L'effetto domino innescato dalle riparazioni
Tutto è cominciato con un malfunzionamento del DNS che ha impedito ai servizi di raggiungere le API di DynamoDB, provocando interruzioni diffuse. Il team di Amazon è riuscito a sistemare questo primo problema alle 2:24 del mattino, ora del Pacifico. Tuttavia, come ammesso dallo stesso colosso del cloud nella sua pagina di stato dei servizi, le operazioni di recupero hanno paradossalmente causato ulteriori danni.
Il sistema interno di EC2 responsabile dell'avvio delle istanze si è trovato in difficoltà proprio a causa della sua dipendenza da DynamoDB. Per chi non ha familiarità con il gergo tecnico, EC2 rappresenta il servizio fondamentale di Amazon per l'affitto di server virtuali, quello su cui si basa l'intera infrastruttura cloud di migliaia di aziende in tutto il mondo. L'impossibilità di lanciare nuove istanze EC2 ha rappresentato un problema gravissimo, considerando che molti clienti si affidano alla capacità di creare automaticamente server in base alle necessità del momento.
La cascata di problemi successivi
Mentre gli ingegneri cercavano disperatamente di ripristinare la piena funzionalità di EC2, si è verificato un terzo guasto. I controlli di integrità del Network Load Balancer hanno smesso di funzionare correttamente, causando problemi di connettività di rete in una serie di servizi aggiuntivi, tra cui Lambda, DynamoDB stesso e CloudWatch. Una situazione che ricorda il classico gioco del topo dove, appena risolvi un problema, ne spunta subito un altro.
La soluzione trovata da AWS alle 9:38 del mattino è stata tanto pragmatica quanto dolorosa per i clienti: limitare temporaneamente alcune operazioni, come il lancio di istanze EC2, l'elaborazione delle code SQS tramite Lambda Event Source Mappings e le invocazioni asincrone di Lambda. In altre parole, Amazon ha deliberatamente rallentato l'accesso ai propri servizi per evitare che un'ondata di richieste travolgesse completamente i sistemi già in difficoltà.
Il lungo ritorno alla normalità
Soltanto alle 15:01, dopo oltre dodici ore dall'inizio delle operazioni di ripristino, tutti i servizi AWS sono tornati a funzionare normalmente. Ma non è finita qui: l'azienda ha avvertito che alcuni servizi come AWS Config, Redshift e Connect avevano ancora un accumulo di messaggi da elaborare che avrebbe richiesto diverse ore aggiuntive.
Amazon ha promesso di pubblicare un resoconto dettagliato dell'incidente, un documento che molti esperti del settore attendono con curiosità per capire esattamente cosa sia andato storto nei meccanismi di recupero. Nel frattempo, questo episodio offre un'ulteriore dimostrazione di quanto la nostra dipendenza dai servizi cloud sia diventata pervasiva. Basti pensare che quando i principali provider vanno in tilt, il numero di dispositivi e servizi che smettono di funzionare è sorprendentemente elevato, dagli elettrodomestici connessi alle applicazioni aziendali critiche.
La lezione per chi gestisce infrastrutture cloud è chiara: le dipendenze tra servizi possono trasformare un problema localizzato in un'apocalisse sistemica, soprattutto quando si cerca di riparare troppo in fretta senza considerare tutte le conseguenze a cascata.