Alta disponibilità e tolleranza ai guasti: definizioni e compromessi

Alta disponibilità (HA) e tolleranza ai guasti (FT) sono due obiettivi distinti di affidabilità che gli architetti spesso confondono. L'alta disponibilità significa che un sistema subisce tempi di inattività minimi: può tollerare i guasti, ma potrebbe verificarsi una breve interruzione durante il ripristino. La tolleranza ai guasti significa che un sistema continua a funzionare senza alcuna interruzione anche quando alcuni componenti si guastano, grazie a percorsi completamente ridondanti che subentrano istantaneamente.

La disponibilità viene misurata come percentuale di uptime nell'arco di un anno. Una disponibilità del 99,9% (tre nove) corrisponde a circa 8,7 ore di inattività all'anno, mentre il 99,99% (quattro nove) consente solo 52,6 minuti. Il 99,999% (cinque nove) consente appena 5,26 minuti. Ogni ulteriore nove richiede in genere maggiore ridondanza, automazione e costi più elevati. L'esame SAA-C03 chiede spesso di individuare l'architettura che soddisfa un determinato obiettivo di disponibilità.

Un'architettura ad alta disponibilità tollera il guasto di un componente rilevandolo automaticamente e passando a un sostituto integro entro pochi secondi o minuti. Tra gli esempi vi sono RDS Multi-AZ (failover automatico verso lo standby in una AZ diversa), gli Auto Scaling Group che sostituiscono le istanze terminate e gli Elastic Load Balancer che instradano il traffico evitando i target non integri. Si verifica una breve interruzione, ma il sistema si ripristina senza intervento manuale.

Un'architettura tollerante ai guasti dispone di ridondanza attiva: più componenti identici gestiscono simultaneamente le richieste, così quando uno si guasta gli altri assorbono immediatamente il carico senza tempi di inattività. Tra gli esempi vi sono ELB active-active con più istanze EC2, le DynamoDB Global Tables che gestiscono simultaneamente letture e scritture in più regioni e Aurora con più read replica. La tolleranza ai guasti richiede più risorse sempre in esecuzione.

La tolleranza ai guasti è significativamente più costosa dell'alta disponibilità, perché richiede capacità ridondante completamente allocata in ogni momento. Un'istanza RDS Multi-AZ ad alta disponibilità raddoppia il costo del database per uno standby che si attiva solo in caso di guasto. Un'implementazione Aurora active-active tollerante ai guasti su più regioni può costare quattro volte tanto, ma elimina ogni inattività durante i guasti regionali. Gli architetti devono bilanciare il costo della ridondanza con il costo aziendale dell'inattività.

Il Recovery Time Objective (RTO) è il tempo massimo accettabile durante il quale un sistema può non essere disponibile. Le architetture ad alta disponibilità puntano a un RTO ridotto, in genere di pochi minuti, tramite il failover automatico. Le architetture tolleranti ai guasti puntano a un RTO quasi nullo. Quando progetta un'architettura HA, deve scegliere servizi e configurazioni che garantiscano il ripristino entro il budget RTO. Ad esempio, RDS Multi-AZ offre un RTO di circa 60-120 secondi, adatto a molti requisiti di alta disponibilità.

Un Single Point of Failure (SPOF) è qualsiasi componente il cui guasto causa il malfunzionamento dell'intero sistema. Tra gli SPOF comuni vi sono una singola istanza EC2 senza ASG, un database RDS in una singola AZ, un singolo NAT gateway o una singola Availability Zone. Eliminare gli SPOF è il primo passo verso HA e FT. L'esame SAA-C03 verifica frequentemente la capacità di individuare ed eliminare gli SPOF nei diagrammi architetturali forniti.

Ottenere HA o FT è molto più semplice per i servizi stateless (come i server web o le funzioni Lambda), perché qualsiasi istanza può gestire qualsiasi richiesta. I servizi stateful (database, cache, file system) sono più complessi: è necessario sincronizzare lo stato tra le repliche, gestire il ritardo di replica e garantire la coerenza durante il failover. Servizi AWS come EFS (file system condiviso), ElastiCache con gruppi di replica e Aurora (storage condiviso) sono progettati per semplificare l'HA dei servizi stateful.

I pattern HA comuni su AWS includono: 1) Bilanciamento del carico Multi-AZ: distribuzione delle istanze EC2 tra le AZ dietro un ALB. 2) Read replica: gestione del traffico di lettura e promozione in caso di DR. 3) S3 per risorse stateless: S3 è intrinsecamente HA, con 11 nove di durabilità. 4) Global Accelerator: IP statici Anycast che instradano il traffico verso endpoint integri in più regioni. Ogni pattern scambia costi con uno specifico livello di disponibilità.

I pattern tolleranti ai guasti richiedono ridondanza attiva ovunque. Pattern FT principali: DynamoDB è intrinsecamente tollerante ai guasti: replica i dati in tre AZ senza richiedere il failover. S3 dispone di FT integrata. Aurora Multi-Master (ora Aurora Serverless v2 multi-writer) consente scritture simultanee in più AZ. Kinesis archivia i dati in più AZ per impostazione predefinita. Scegliere servizi gestiti con FT integrata è il percorso più conveniente verso architetture senza tempi di inattività.

La progettazione per HA o FT è efficace solo quanto i test che la convalidano. AWS consiglia di utilizzare AWS Fault Injection Simulator (FIS) per eseguire esperimenti controllati che terminano istanze, limitano le API o iniettano guasti di rete. Deve verificare che il failover si completi effettivamente entro il proprio RTO, che i dati persi non superino il proprio RPO e che gli allarmi si attivino correttamente. Le regolari giornate di test e gli esercizi di chaos engineering fanno emergere le lacune nelle ipotesi di resilienza prima che lo facciano gli incidenti in produzione.

Verifichi la Sua comprensione dei concetti di AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione ha appreso che: l'alta disponibilità riduce al minimo i tempi di inattività tramite il ripristino automatico (RTO di pochi minuti), la tolleranza ai guasti elimina i tempi di inattività tramite la ridondanza attiva (RTO nullo) e il costo aumenta significativamente a ogni livello di resilienza. L'eliminazione dei Single Point of Failure è il fondamento di entrambi gli approcci. Ora esploreremo i pattern Multi-AZ per i servizi stateful.