Sfruttare il caos per progettare sistemi migliori: un’introduzione
Come l’Errore può aiutarci a realizzare sistemi cloud veramente resilienti e performanti
--
Il vento spegne la candela e alimenta il fuoco.
Lo stesso vale per il caso, l’incertezza e il caos: vogliamo usarli, non nasconderci da loro.
Inizia così il prologo ad Antifragile di Nassim Nicholas Taleb, uno degli autori più apprezzati degli ultimi anni.
Cosa c’entra il caso con il nostro lavoro da ingegneri? Cosa ha a che fare il caos con il cloud? Molto più di quanto possiate immaginare e in questo articolo capiremo il perché.
Generalmente, un’applicazione cloud è composta da varie componenti: macchine virtuali, database, bilanciatori e altri servizi che comunicando tra loro supportano il nostro business. Sistemi complessi e distribuiti che, in quanto tali, potrebbero fallire da un momento all’altro.
La risposta a questo tipo di problematiche si è tradotta, spesso, in un maggior numero di test; il più delle volte test end-to-end che stimolano tutti i layer di un’applicazione. Una sorta di black-box testing dove, a fronte di un input A, ci si attende un output B. Se la risposta è C, da qualche parte nel sistema qualcosa non ha funzionato.
In alcuni casi, test del genere vengono stimolati ad intervalli regolari sui sistemi di produzione per verificarne il funzionamento nell’arco delle 24 ore. Qualora tali risultati fallissero, non direbbero granché relativamente all’errore.
Ancor peggio, questa pratica ci espone ad un altro rischio che è quello dell’illusione del controllo. Ogni volta che un test si conclude con successo, ci convinciamo sempre più della robustezza del sistema; giorno dopo giorno diventiamo sempre più fieri dell’ottimo lavoro svolto.
Il Cigno nero
Una metafora di Bertrand Russell, adattata poi dallo stesso Taleb, racconta il “grande problema del tacchino”:
Un tacchino viene nutrito per mille e più giorni; ogni giorno insieme agli altri tacchini si compiace sempre più dell’agiatezza della sua vita. Poi arriva il giorno del Ringraziamento ed essere un tacchino non sarà stato affatto bello.
Questa sorpresa rappresenta quello che viene definito un Cigno nero: un evento non previsto, dagli effetti catastrofici.
La finta illusione del controllo ha costretto il tacchino a rivedere le sue convinzioni relativamente all’agiatezza della sua vita, proprio nel momento in cui queste erano all’apice.
Allo stesso modo, ripetuti test end-to-end positivi potrebbero portarci alla conclusione – altrettanto fallace – che i nostri sistemi siano effettivamente a prova di errore.
Questa superficialità di giudizio, per utilizzare un lessico caro a Taleb, ci espone al Cigno nero, ovvero, alla possibilità che una problematica non prevista possa rovinare i nostri piani per il weekend.
Possibili esempi di Cigni neri:
- spegnimento improvviso di una macchina;
- fail di un database;
- sovraccarico di una CPU;
- memoria esaurita;
- spazio disco esaurito;
- latenze di rete;
- configurazioni errate;
- permessi insufficienti per utilizzare una risorsa cloud;
Per proteggere il sistema da queste e altre problematiche, un cloud provider offre varie possibilità. In AWS, per contrastare lo shutdown improvviso di una macchina, si potrebbero sfruttare le potenzialità del servizio EC2 Auto Scaling; per mitigare l’impatto del fail di un database si potrebbe sfruttare il meccanismo di failover automatico di Amazon RDS, e così via.
Questi accorgimenti renderanno sicuramente la nostra applicazione meno fragile, ma riusciranno a ridurre la possibilità di un Cigno nero?
Antifragile
Col termine «fragile», in genere, intendiamo un oggetto che potrebbe danneggiarsi – anche irrimediabilmente –, a causa di eventi casuali (es. un bicchiere di cristallo che si rompe dopo un urto).
Al contrario, termini come «robusto» o «resistente» vengono utilizzati per definire oggetti che, all’insorgere di eventi casuali, mantengono le stesse identiche proprietà iniziali.
Il manifestarsi del caso non ha reso questi oggetti né migliori, né peggiori.
Col termine «antifragile», invece, Taleb fa riferimento a tutto ciò che trae beneficio dal caso e dai fattori di stress. I muscoli del nostro corpo, ad esempio, traggono beneficio da un giusto apporto di stress, in quanto questo è propedeutico alla loro crescita.
Tornando ai nostri sistemi, se tutto quello che abbiamo fatto per contrastarne la fragilità si è concluso col configurare l’Auto Scaling, saremo certamente robusti ma non ancora antifragili; quindi ancora esposti a un Cigno nero.
Se volete diventare antifragili collocatevi nella situazione «ama l’errore».
Un primo suggerimento per evitare brutte sorprese ce lo offre proprio Taleb. Per essere antifragili e ridurre quanto più possibile le possibilità di un Cigno nero dobbiamo iniziare ad amare l’errore.
Ma cosa fare se siamo nella situazione in cui i nostri test end-to-end continuano a girare senza problemi e l’errore proprio non arriva?
Chaos engineering
Con «chaos engineering» si intende la pratica di iniettare, deliberatamente, un errore in un sistema, col fine di osservare, in vivo, quali conseguenze ne derivino.
Cosa succederebbe se improvvisamente dovesse andar giù uno dei webserver di produzione?
Il vantaggio principale di questo approccio, rispetto al più classico test end-to-end, deriva dal non dover più dipendere dalle nostre supposizioni. L’impatto dell’errore sarà davanti ai nostri occhi. Così facendo, avremo la possibilità di mettere in luce aspetti del sistema di cui non eravamo a conoscenza: reazioni a catena, problemi di performance, metriche che sfuggivano ai tool di monitoraggio e così via.
Conoscere i punti deboli del sistema è già un ottimo inizio, in quanto ci costringe a non abbassare la guardia; quello a cui dovremo puntare però, sarà la risoluzione di quelle debolezze. Solo questo renderà il sistema un po’ più «antifragile».
Maggiori saranno le casistiche di errore che riusciremo ad iniettare – e risolvere – minore sarà la possibilità di un Cigno nero.
Il processo di chaos engineering
La scelta della parola «engineering» accanto alla parola «chaos» potrebbe sembrare un ossimoro, ma non lo è; anzi, racchiude bene l’essenza del processo alla base della pratica stessa. Così come un esperimento scientifico ha le sue fasi ben codificate, anche l’esperimento di chaos engineering ha le proprie.
Definizione dell’andamento a regime
In questa fase andiamo a mettere nero su bianco quale debba essere l’andamento del sistema quando non vi sono errori. Questo passo è cruciale e sarà fondamentale avere delle infrastrutture di monitoraggio che permettano di raccogliere con precisione le metriche utili a definirlo. Le metriche di sistema (es: CPU, memoria) sono certamente utili, ma sarebbe ancor più utile ottenere delle metriche di business:
«tra le 10:00 e le 11:00 vengono effettuati in media 100 ordini al minuto»
Oppure:
«tra le 20:00 e le 21:00 l’homepage dell’e-commerce viene richiesta 1000 volte»
Elaborazione di un’ipotesi
Fatto ciò andremo a formulare un’ipotesi; ovvero proveremo a immaginare quale possa essere il comportamento del sistema in seguito ad uno specifico errore.
«Cosa succederebbe se fallisse un webserver?»
Oppure:
«Cosa succederebbe se la comunicazione con il database avesse improvvisamente una latenza extra di 100ms?»
Un esercizio utile in questa fase potrebbe essere quello di chiedere le risposte alle seguenti domande ad ognuno dei membri del team. Tale pratica non dovrà avere il fine di trovare il primo o l’ultimo della classe ma, semplicemente, mostrare come, in alcuni casi, la conoscenza del sistema possa variare tra membri dello stesso team.
Un altro modo per ricordare a tutti di non abbassare la guardia.
Definizione di una stop-condition
Altrettanto importante sarà poi capire quando e come bloccare l’esperimento.
Il quando può essere manuale, a tempo oppure dinamico. Ricorreremo al blocco manuale qualora dovessimo renderci conto che l’esperimento sta avendo delle conseguenze inaspettate. Il tempo invece è il limite superiore, ovvero il tempo massimo entro cui, nel bene o nel male, l’esperiemnto dovrà concludersi. Infine, una stop-condition dinamica, bloccherà l’esperimento qualora il nostro tool di monitoraggio dovesse segnalare una situazione di allarme (es: la media degli ordini ha avuto un calo del 70% per più di cinque minuti).
Il come bloccare l’esperimento è un po’ più complesso e dipende dal tool a disposizione.
Esecuzione dell’esperimento
Fatto ciò non ci resta che lanciare il nostro esperimento e iniettare gli errori che avevamo previsto durante la definizione delle ipotesi. Facile a dirsi, un po’ meno a farsi. Fino a qualche tempo fa la pratica del chaos engineering richiedeva buone competenze di scripting per rendere programmatico il presentarsi dell’errore.
Questo rendeva il chaos engineering poco accessibile a team poco strutturati, riducendo la pratica ad appannaggio soltanto di grossi gruppi. Non a caso, alcuni degli script di chaos engineering più famosi sono stati quelli creati in seno a Netflix nel progetto Simian Army, come chaos monkey; uno script che in maniera casuale buttava giù delle macchine di produzione.
Al giorno d’oggi, la necessità di questo tipo di paratiche è sempre più sentita e iniziano a rendersi disponibili degli strumenti avanzati per fare chaos engineering. Al re:Invent 2020, AWS ha presentato Fault Injection Simulator (FIS) un servizio fully-managed per iniettare errori nei nostri sistemi.
Miglioramento del sistema
Il lavoro più interessante viene a valle dell’esperimento. Lì possiamo imparare a conoscere meglio il nostro sistema, facendoci delle domande del tipo:
- come si è comportato il nostro sistema?
- le contromisure (es: autoscaling, failover, circuit-breaker) hanno gestito l’errore?
- ci sono stati degli errori inaspettati in altre parti del sistema?
- ci sono stati problemi di performance?
- l’errore è stato individuato dai nostri tool di monitoraggio?
- quando tempo è stato impiegato per ritornare a regime?
Le risposte e le eventuali soluzioni a tali domande andranno poi prioritizzate e applicate quanto prima. Così facendo saremo un po’ più al riparo da un Cigno nero.
Chaos Engineering in produzione (?)
Per trarre quanti più vantaggi possibili dal chaos engineering gli esperimenti devono essere lanciati in produzione. Punto.
Tuttavia, tale pratica porta con sé i suoi rischi e pensare di iniziare direttamente dalla produzione sarebbe un po’ azzardato. Meglio partire con degli esperimenti in degli scenari di sviluppo, per poi, appena ci sentiamo un po’ più sicuri e pratici, muoverci verso lo staging e, perché no, la produzione.
Conclusioni
Le conclusioni a questo articolo sono ovvie e riassumibili ancora una volta citando le parole di Taleb: «Don’t be a turkey!».
Ovvero, evitiamo di credere in maniera semplicistica che, in assenza di errori per un periodo prolungato siamo al sicuro da ogni rischio. Un Cigno nero può essere sempre in agguato e presentarsi non appena abbassiamo la guardia.
Cerchiamo invece di stressare il nostro sistema, iniettando gli errori più probabili, osservandone il comportamento alla ricerca di eventuali comportamenti imprevedibili. Solo così potremo conoscere veramente il nostro sistema ed essere un po’ più sicuri delle sue capacità di sostenere l’errore e delle nostre capacità di saperlo gestire opportunamente.
In un talk del 2011, Jesse Robbins, pompiere volontario assunto poi in AWS con il titolo di Master of Disaster, ha riportato quella che è la frase che insegnano ad ogni pompiere il primo giorno di scuola di formazione:
Non sei tu che scegli il momento. E’ il momento che sceglie te.
Tu puoi solo scegliere come affrontare il momento quando arriverà.
– Capitano Mike Burtch
Non dimentichiamolo mai.
Approfondimenti
Le idee, i concetti e questo stesso articolo, non avrebbero visto la luce senza i preziosi spunti qui citati:
Libri
- Nassim Nicholas Taleb – Il Cigno nero
- Nassim Nicholas Taleb – Antifragile
- Casey Rosenthal e Nora Jones – Chaos Engineering
Web
- Principle of Chaos Engineering
- AWS Blog – Building Resilient services at Prime Video with Chaos Engineering
- Adrian Hornsby – Chaos Engineering pt.1
- Pavlos Ratis – Chaos Engineering resources
