Black Friday: l'esperimento rischioso che ha evitato un disastro
Venerdì scorso, Digitec Galaxus AG ha dichiarato lo stato di emergenza in tutta la Svizzera. Il problema principale: i server non riuscivano a reggere il massiccio traffico di utenti e richieste. In prima linea avevamo Enes Poyaz, software engineer. Ci ha raccontato del giorno in cui gli ingegneri hanno puntato tutto su una carta, senza essere troppo sicuri di cosa sarebbe successo.
17 secondi. Ecco quanto ci è voluto perché digitec.ch andasse offline la prima volta venerdì scorso, giornata nota a livello internazionale come Black Friday. Il motivo: troppe richieste da parte degli utenti. I server della nostra azienda sono crollati dopo 17 secondi dopo che tu e altri utenti avete iniziato a navigare sul sito. Perché eravate in troppi a voler approfittare delle nostre offerte speciali durante il Black Friday.
«In realtà pensavamo che i server avrebbero resistito più a lungo», dice Enes Poyraz, Junior Software Engineer.
L’ingegnere mi racconta del giorno in cui lui e il suo team hanno costretto un’intera azienda ad azzerare la produttività e in cui hanno evitato il disastro completo con un tentativo disperato.
Nel preciso instante in cui crollano i server la prima volta, Esen è lì. Perché gli ingegneri (tutti i team sono denominati in base ai film di James Bond) rimangono in stand-by, pronti a qualsiasi evenienza, ogni Black Friday; che si trovino nei nostri nuovi uffici della Förrlibuckstrasse, nell’ufficio di casa o da qualche parte con il loro portatile e Internet mobile. Aspettano che i server cedano e fanno quello che possono.
Ma, a mezzanotte, sono arrivati al limite. I poveri ingegneri, solitamente molto orgogliosi delle loro imprese, devono incassare un duro colpo: gli uomini e le donne per cui un downtime di pochi secondi è già troppo ci mettono ben due ore a riportare i server in vita. Ma i problemi non sono finiti: il sito continua ad andare offline, a intermittenza e solo per poco. L’unica cosa che funziona è il Livestream del Digital Marketing.
«Per i clienti la cosa non è particolarmente piacevole, ma gli ingegneri si aspettavano una cosa del genere», dice Enes. Scrolla le spalle. Certo, è una situazione che non piace a nessuno e gli ingegneri cercano di farla durare il meno possibile, ma è del tutto prevedibile se un’intera nazione si fionda su un sito web nello stesso momento.
La seconda ondata
Poi, la calma. Dopo le 2 di notte gli abitanti della Svizzera dormono sonni tranquilli, contenti di essersi assicurati qualche bella offerta. Più tardi, nel corso della giornata, vengo a sapere dal negozio di Zurigo che una persona è stata dedicata esclusivamente a stipulare gli abbonamenti per smartphone. Il giorno prima, infatti, avevamo il 50% di sconto su tutti gli smartphone per chiunque stipulasse un abbonamento ed era possibile farlo anche online.
Ma Enes non ne sa nulla. Poco prima delle 3 del mattino, torna a casa e dorme qualche ora di sonno inquieto. Sul comodino, il cellulare con la suoneria attiva: in qualsiasi momento potrebbe ricevere una chiamata e dovrebbe presentarsi immediatamente in ufficio a occuparsi dei server. Ma la chiamata non arriva e ad Enes è concessa qualche ora di riposo in più. La stessa sorte tocca anche agli altri ingegneri, ad esempio al team leader del reparto software engeneering Raphael Renaud, che rimane sempre reperibile per eventuali problemi. Il telefono di Raphael suona alle 5:00 del mattino. Qualcuno chiama da Wohlen con una domanda: perché ci sono così pochi ordini nel sistema? Anche il centro logistico di Wohlen è in stato di emergenza per il Black Friday e lavora a pieno ritmo, con tutto il personale.
Verso le 9 Raphael è di nuovo in ufficio, in uno stato che descrive come «sonnolento». I server reggono. O quasi.
«Il traffico è aumentato costantemente nel corso della mattinata», dice Enes, «e abbiamo capito che, se continua così, i server non reggeranno fino a fine giornata».
Questo è fuori discussione. Visto che in ufficio ci sono più ingegneri rispetto alla sera prima, ora possono dividersi gli incarichi: un team si concentra sui sistemi interni. Tutto ciò che può essere spento viene spento. Alle ore 9:36 circa, lo Chief Information Officer Oliver Herren informa i dipendenti di digitec che gli strumenti interni, come il sistema di registrazione delle ore di lavoro e alcune delle funzioni del back-end, saranno disattivate per risparmiare le risorse del server. Tutto ciò che può essere ospitato localmente ed essere spento viene spento.
Negli uffici della sede centrale di Zurigo i dipendenti vengono colti di sorpresa. Siamo un negozio online; il nostro sito web è la nostra capitale, il luogo che paga le nostre bollette e quello dove acquisti i tuoi dispositivi. Ci preoccupiamo. Soprattutto perché la redazione può, per come stanno le cose al momento, chiudere baracca e burattini e andare a casa. Tutta la rivista viene bandita dall’homepage. Le foto su cui clicchi si mangiano troppe risorse.
Ma è tutto invano: a mezzogiorno, il server collassa di nuovo. La cosa è meno grave rispetto alla sera prima: il sito va e viene nell’arco di pochi secondi, ma in modo ancora troppo instabile perché l’esperienza d’acquisto degli utenti sia piacevole.
Gli ingegneri si lasciano la situazione alle spalle per la pausa pranzo, poi si preparano a riportare il sito online.
Un esperimento azzardato risolve il disastro
Mentre Oliver e un team di ingegneri provenienti da tutti i reparti di servizi di ingegneria mettono il sito offline, Enes è impegnato a lavorare con altri due colleghi per mettere insieme un piano d’azione. Cosa fare, se scollegare i servizi interni non serve a niente?
Ai tre ingegneri tocca il compito di trovare una soluzione quando tutto il resto fallisce.
«Più fuori dagli schemi di così non si può», dice Enes. Si sente decisamente orgoglioso di aver fatto parte del team che ha trovato una soluzione; quest’uomo, normalmente tranquillo e pacato, improvvisamente parla a voce alta.
La soluzione si chiama Redis, un sistema di cache che gli ingegneri hanno tenuto sott’occhio. Enes è uno di quelli che l’ha testata. Una cache non è altro che un archivio di dati che memorizza le richieste più frequenti e può quindi elaborarle più velocemente. Esempio: se tu e migliaia di altre persone volete accedere alla pagina Black Mobile, non è necessario che il database del sito web venga consultato ogni volta: la cache ha già salvato una versione della pagina e la visualizza, così le risorse possono essere utilizzate per altri processi di acquisto.
«Naturalmente abbiamo una soluzione di cache che funziona perfettamente in situazioni normali», continua Enes. Ma ogni volta che un server si blocca, le cache devono essere rielaborate. Peggio ancora: ognuno dei nostri server elabora la cache localmente. In altre parole, ogni volta che un server si blocca, la cache deve essere ricalcolata localmente sul computer dei server; questo consuma risorse che invece andrebbero utilizzate per il cliente. Nessuno in azienda pensa più ai lettori della rivista. I reparti di marketing hanno alzato bandiera bianca, quello di Product Management si chiede se le loro scorte saranno sufficienti e i dipendenti del negozio devono smaltire lunghe code. Ma gli ingegneri si trovano di fronte a un’intera nazione che vuole comprare, perciò non hanno alcuna intenzione di arrendersi.
«Non ho ancora provato Redis», dice, «ma ho fatto qualche test per due giorni». Secondo i calcoli, non sarà in grado di gestire il sistema del più grande negozio online della Svizzera. Quando Enes guarda i suoi appunti di due settimane fa, sorride.
Sicuramente ha alcuni campi di applicazione qua da noi
Gli ingegneri decidono di iniziare a usare Redis senza averlo testato su un sistema demo. Un’impresa rischiosa. Normalmente, prima che un'azienda integri un software in un sistema online, viene accuratamente testato da diverse postazioni interne e spesso anche esterne. Infatti, solo perché chi si occupa del marketing del software lo descrive come la miracolosa soluzione a tutti i tuoi problemi, non significa necessariamente che abbia il valore aggiunto promesso. A volte, le cose possono solo peggiorare.
Chiediamo a Enes: «Pensi che andrà così?»
L'ingegnere dice di sì.
Redis prende le redini
Da questo punto in poi, tutto avviene molto rapidamente. Poiché, secondo le informazioni di Enes, Redis è «super veloce e facile da usare», il server è pronto in 20 minuti. Mentre il vecchio sistema di caching di digitec funzionava localmente su ogni server, Redis gira centralmente su un unico server ed elabora le richieste anche su altri server. In altre parole, ogni server scrive nella cache di Redis, che rende la soluzione più scalabile e riduce il carico sui server di lettura.
«Ma, per evitare di imbarcarci in una missione #yolo al di fuori della nostra portata, abbiamo installato di nuovo uno SwitchBit», dice Enes. Inoltre, un piccolo team delle IT Operations spiega che è necessario monitorare sempre i server per assicurarsi che il negozio non vada mai completamente fuori uso. Stanno monitorando le prestazioni del server dall’inizio della giornata ed Enes racconta che sono loro ad aver coperto le spalle al suo team durante l’esperimento con Redis.
Il problema si presenta con il go-live, che avviene nel modo più caotico possibile. Enes vuole lanciare Redis su un Managed Server di Microsoft in modo che i carichi non siano eccessivi internamente.
«Purtroppo, Redis lavora con la porta 6380, che da noi è chiusa», dice. Ne richiede con urgenza l'apertura, cosa che purtroppo non è possibile, dato che il server di Microsoft blocca proprio questa porta. Ma Enes ha imparato una cosa: ha sempre un piano B.
«Contemporaneamente, ho cercato di far lavorare Redis sul cloud di Google», aggiunge. Ma anche questo si rivela più difficile del previsto. Con l'aiuto di Michal Nebes, Senior Software Engineer, riesce ad avviare un Redis Cluster.
Intorno alle 16:00, la situazione è grave. Viene fatta una rapida revisione del codice. Secondo Boško Stupar, Senior Software Engineer, il codice funziona e misura troppi Round Trip dei dati, vale a dire il tempo necessario per inviare i dati al server e tornare al computer dell'utente.
- Normale: da 50 a 500 millisecondi. Troppo lento
- Redis, sistema di test locale: da 8 a 9 millisecondi
- Redis, produttivo: da 16 a 19 millisecondi
Redis va online. In pratica, le vendite della sera sono state affidate a un sistema non testato, con la minima sicurezza.
Alcuni secondi di panico.
Redis legge le richieste e crea una cache.
Il carico sui server è notevolmente ridotto. Il negozio online si sta stabilizzando.
Gli ingegneri tirano un sospiro di sollievo.
Più tardi, su Facebook, Boško Stupar scrive:
Sopravvissuti al Black Friday. È stata la giornata più incredibile della mia carriera! Stressante, dura e gratificante. Per i nerd: abbiamo allestito un sistema di caching a due stadi con farm Redis centralizzata. Chirurgia a cuore aperto senza anestesia. PS: odio il Black Friday.
Dopo il tramonto, gli ingegneri si riuniscono intorno ad una birra al quinto piano della Pfingstweidstrasse, tenendo sempre un occhio puntato sul negozio. Non è proprio una festa selvaggia, ma almeno si rilassano un po’.
Intorno alle 18:55, Enes ha revocato lo stato di emergenza tramite WhatsApp:
I server funzionano normalmente, a carico normale. Nel frattempo, in negozio ci sono persone che aspettano in coda, sottoscrivono abbonamenti smartphone ed effettuano ordini. Adrian Maier, Store Manager, si trova all'ingresso della filiale di Zurigo e informa i clienti sui tempi di attesa. Venti minuti, quaranta minuti. È stanco, così come il personale dietro le casse.
Gli ingegneri ormai hanno finito di lavorare, ma i colleghi delle filiali sono gli ultimi a lasciare il negozio. Per il personale delle casse, la giornata termina alle 20.00. Niente più abbonamenti, consegne, domande.
Quo vadis, Redis?
Il sistema Redis rimane online durante il fine settimana e fino a lunedì sera per far fronte al Cyber Monday. Gli ingegneri sono soddisfatti e orgogliosi del loro operato: lunedì il negozio è ancora stabile. Bene: Redis ha prestato servizio per la prima volta e il cluster verrà rimosso dalla rete.
«In fin dei conti, stiamo parlando di un sistema che non è stato ancora completamente testato», dice Enes.
Gli ingegneri hanno un lungo elenco di domande da affrontare prima di poter aggiungere Redis alla rete permanentemente e senza preoccuparsi di causare qualche disastro. Di queste domande, tante somigliano a questa: «Redis, cos’è quella variabile $?»
Ora che la situazione è nuovamente sotto controllo, gli ingegneri possono concentrarsi su questi temi. Perché se il Black Friday ci ha insegnato una cosa, quella è il potenziale di Redis. Sarebbe un peccato non utilizzarlo.
Giornalista. Autore. Hacker. Sono un contastorie e mi piace scovare segreti, tabù, limiti e documentare il mondo, scrivendo nero su bianco. Non perché sappia farlo, ma perché non so fare altro.