Introduzione
La maggioranza delle attuali architetture di dati nasce da un processo di analisi, studio e disegno che si basa sull’anticipazione di eventuali punti di debolezza e criticità relative alla sicurezza, all’affidabilità e alla scalabilità del sistema stesso. Lo scopo di queste analisi è evitare che l’architettura o il software possano essere vulnerabili o presentare problemi in seguito.
Con il tempo si sono introdotti (sia per quanto riguarda il software che l’architettura) due metodi di verifica:
- gli Unit Test, che sono in sostanza il collaudo delle funzioni;
- gli Integration Test che si concentrano, invece, sull'integrazione tra due architetture o moduli software differenti.
Con l’avanzare della IaC (Infrastructure as Code), del Platform Engineering e del Serverless Computing (Modern Application), queste tipologie di test, sebbene rimangano utili, hanno mostrato i loro limiti di fronte alla complessità di soluzioni che possono implicare effetti a catena non facilmente prevedibili.
In questo nuovo scenario, infatti, la domanda da porsi non è se il sistema fallirà, ma quando fallirà.
Ora il punto è: come evidenziare i punti deboli di un servizio o di un insieme di servizi siffatti? Per rispondere a questa esigenza, viene in nostro soccorso la metodologia del Chaos Engineering.
Metodologia e Flusso
Il Chaos Engineering si avvale di un flusso di operazioni cicliche, che viene avviato con lo scopo di verificare la veridicità delle ipotesi di resilienza, scalabilità e fallibilità del sistema. Vediamo nel dettaglio le fasi e gli elementi che costituiscono questo flusso.
|
|
Steady State
È lo stato iniziale del sistema, quando è stabile e le sue performance sono ottimali. È in questo stadio che si definiscono i KPI (Keys Performance Indicator), gli stessi che verranno in seguito monitorati per verificare eventuali scostamenti. Lo stadio, in breve, funge da benchmark di confronto.
Definizione dei Gruppi
Per processare il sistema vengono definiti due gruppi. Un Control Group che è il gruppo di controllo su cui applicare e valutare i KPI. Un Experiment Group su cui si faranno le sperimentazioni di Chaos Engineering.
Hypothesis State
In questo stadio si definiscono alcune ipotesi sulle metriche dei KPI (ad esempio, si potrebbe ipotizzare che nel caso in cui un application server andasse in crash, si riscontrerebbe un aumento del carico del 10% della CPU e le transazioni al secondo non subirebbero variazioni, mantenendo un tempo di risposta inferiore ai 100ms).
Chaos State
Una volta decisi i KPI, formati i gruppi e definite le ipotesi, si passa alla fase del Chaos State, in cui si induce in maniera controllata sull'Experiment Group, l'esperimento (si potrebbe, ad esempio, eseguire un kill del processo dell'application server, oppure un aumento delle richieste al servizio).
Verify State
Si giunge così al momento di verifica in cui si valuta, sulla base dei KPI, se le ipotesi definite siano veritiere o meno. In caso di sforamento dei KPI, si induce, a seconda dei casi, lo stop del Chaos State o l'Alerting per studiare e capire i motivi per cui le ipotesi non si sono verificate.
Correction Phase
È la fase finale. Se le ipotesi non sono state rispettate e se ne è compresa la ragione, si effettua la correzione all'applicazione/architettura e si ritorna allo Steady State.
Software OpenSource di Chaos Engineering
| Software | Descrizione | Caratteristiche | Risorse |
|---|---|---|---|
|
PowerfulSeal
|
Tool di Chaos Engineering cloud native, dedicato a Kubernetes, con esperimenti quali kill del pod o delete.
|
Si integra con Datadog e Prometheus | |
|
Chaos Toolkit
|
Come PowerfulSeal è uno strumento cloud native. Permette di scrivere esperimenti in json o yaml e applicare tali esperimenti sia a livello di infrastruttura (Cloud Provider, Ansible, ecc.), di Rete o di Load Testing.
|
Si integra a livello di metriche con numerosi software o servizi. Non ha un sistema di scheduling interno. | |
|
Chaos Mesh
|
Tool cloud native che ha integrato il sistema di dashboarding degli esperimenti.
|
È necessaria l'installazione di Clusterwide. | |
|
Kraken
|
Tool specifico per Kubernetes che si lega a Cerberus come sistema di monitoring per interrompere e controllare i Chaos State.
|
Integrazione con Cerberus per monitoring avanzato | |
|
Litmus
|
È una piattaforma OpenSource per il Chaos Engineering molto completa, che mette a disposizione anche un hub con relativi esperimenti già pronti all'uso.
|
Necessita di Kubernetes. Esiste anche un Servizio SaaS Enterprise. |
Servizi SaaS di Chaos Engineering
Descrizione: Sostanzialmente la versione di Litmus SAAS.
Caratteristiche: Piattaforma completa per il Chaos Engineering basata su cloud con interfaccia user-friendly e gestione centralizzata degli esperimenti.
Risorse: Sito ufficiale
Descrizione: È il Chaos Engineering Tool di AWS. Si completa con Cloudwatch e gli esperimenti principali ci sono, ma mancano alcuni servizi ormai diffusi come Opensearch e non è multicloud.
Caratteristiche: Integrazione nativa con l'ecosistema AWS, gestione degli esperimenti tramite console AWS, monitoraggio integrato con CloudWatch.
Risorse: Documentazione AWS
Descrizione: Supporta vari servizi tra cui CosmosDB e SqlServer. È ben integrato nella piattaforma e dà una visibilità completa degli esperimenti. È agentless.
Caratteristiche: Integrazione completa con Azure, supporto per database e servizi specifici Microsoft, interfaccia unificata con Azure Portal.
Risorse: Documentazione Microsoft
Descrizione: Servizio SaaS, basato su agent. Si integra con tutti e tre i provider cloud. Molto complesso, fornisce un'ampia gamma di esperimenti.
Caratteristiche: Supporto multi-cloud (AWS, Azure, GCP), vasta libreria di esperimenti, interfaccia avanzata per la gestione e il monitoraggio.
Risorse: Sito ufficiale
Possibili Sviluppi Futuri
Il Chaos Engineering è una metodologia che sta incontrando sempre maggior interesse e nel tempo andrà certamente implementata come dotazione di base, in modo da rendere i propri servizi più resilienti.
Vi sono già i primi tentativi di dotare software o piattaforme di Chaos Engineering di AI, anche se al momento si tratta più di meri strumenti di statistica per aiutare il Chaos Engineer a fare degli esperimenti corretti.
Una delle evoluzioni della metodologia sarà quella di non limitarsi all'uso della statistica applicata agli outlier, con lo scopo di comprendere quali siano gli elementi deboli della catena, ma evidenziare comportamenti cronici dei sistemi, analizzare i problemi e fornire suggerimenti per eliminarne le cause, magari fornendo il codice IAC o Dev necessario.
Ti è piaciuto quanto hai letto? Iscriviti a MISPECIAL, la nostra newsletter, per ricevere altri interessanti contenuti.
Iscriviti a MISPECIAL
