Pattern Multi-AZ per servizi stateful

I servizi stateful — database, cache e file system — sono i componenti più difficili da rendere altamente disponibili, perché contengono dati che devono sopravvivere ai guasti. Se un database in una singola AZ si guasta, l'intera applicazione perde il proprio archivio dati. La risposta di AWS sono le implementazioni Multi-AZ, in cui il servizio mantiene una replica sincrona o quasi sincrona in una seconda Availability Zone, che può subentrare rapidamente quando il primario si guasta.

RDS Multi-AZ mantiene una replica standby sincrona in una AZ diversa. Ogni scrittura sul primario viene replicata in modo sincrono prima che venga confermato il completamento: ciò significa perdita di dati nulla (RPO=0), ma comporta un leggero aumento della latenza di scrittura. Quando il primario si guasta, RDS aggiorna automaticamente l'endpoint DNS affinché punti allo standby entro 60-120 secondi. L'applicazione deve solo riconnettersi allo stesso endpoint: non sono necessarie modifiche al codice.

Amazon Aurora porta il concetto di Multi-AZ a un livello superiore grazie a un livello di storage distribuito condiviso che replica automaticamente i dati in tre AZ, creando sei copie. Le istanze Aurora sono senza stato: leggono e scrivono in questo storage condiviso. Quando il writer Aurora primario si guasta, una replica di lettura in un'altra AZ viene promossa a writer in meno di 30 secondi. È più veloce del failover Multi-AZ di RDS e i dati sono sempre coerenti tra le AZ, senza dover configurare esplicitamente la replica su un'istanza standby.

ElastiCache for Redis supporta la modalità Multi-AZ tramite i gruppi di replica. Un nodo primario accetta le scritture e le replica in modo asincrono sulle repliche di lettura presenti in altre AZ. Quando il primario si guasta, ElastiCache promuove automaticamente una replica a primario. Con Redis in modalità cluster mode enabled, i dati vengono suddivisi tra più gruppi di nodi, ciascuno con un proprio primario e le relative repliche distribuite tra le AZ: ciò offre sia alta disponibilità sia scalabilità orizzontale.

Amazon Elastic File System (EFS) è nativamente Multi-AZ: è un servizio regionale che archivia i dati in modo ridondante in più AZ all'interno di una regione. Si creano mount target nella subnet di ogni AZ e le istanze EC2 di qualsiasi AZ possono montare il file system tramite il mount target locale. Non è necessaria alcuna configurazione manuale della modalità Multi-AZ. EFS offre uno storage di file POSIX condiviso, a cui più istanze distribuite tra le AZ possono accedere contemporaneamente.

Gli Elastic Load Balancer sono a loro volta Multi-AZ: ALB e NLB distribuiscono i nodi del load balancer in ogni AZ specificata. Con il cross-zone load balancing enabled (impostazione predefinita per ALB), ogni nodo del load balancer distribuisce il traffico in modo uniforme tra tutti i target registrati in tutte le AZ, non solo nella propria AZ. In questo modo, anche se tutte le istanze di una AZ si guastano, il load balancer continua a gestire il traffico attraverso le istanze presenti nelle AZ rimanenti.

Un errore comune consiste nel distribuire un singolo NAT Gateway in una AZ, mentre le subnet private delle altre AZ instradano il traffico attraverso di esso. Se quella AZ si guasta, tutte le istanze private perdono l'accesso a Internet. Il pattern Multi-AZ corretto consiste nel distribuire un NAT Gateway per AZ e configurare la tabella di routing privata di ogni AZ in modo che instradi 0.0.0.0/0 attraverso il proprio NAT Gateway. In questo modo si elimina il NAT Gateway come SPOF tra AZ e si riducono i costi di trasferimento dati tra AZ.

DynamoDB è un servizio completamente gestito che replica automaticamente i dati in tre AZ all'interno di una regione: non è necessario configurare manualmente la modalità Multi-AZ. Ogni scrittura viene archiviata in modo duraturo in tutte e tre le AZ prima che venga restituito l'esito positivo. DynamoDB è quindi tollerante ai guasti a livello di AZ fin dall'uso predefinito. Per questo DynamoDB è spesso la scelta consigliata per il database quando la domanda d'esame sottolinea l'alta disponibilità con un sovraccarico operativo minimo.

Durante un failover Multi-AZ di RDS, le applicazioni che mantengono connessioni persistenti al database possono riscontrare errori quando cambia l'endpoint. RDS Proxy si interpone tra l'applicazione e RDS e mantiene un pool di connessioni al database. Durante il failover, RDS Proxy reindirizza automaticamente le connessioni al nuovo primario, riducendo l'impatto del failover da 60-120 secondi a meno di 30 secondi per le applicazioni che utilizzano l'endpoint del proxy. RDS Proxy è utile anche con le funzioni Lambda, che creano molte connessioni di breve durata.

Comprendere le modalità di replica è fondamentale per scegliere i pattern Multi-AZ. La replica sincrona (RDS Multi-AZ, EFS) garantisce RPO=0, perché ogni scrittura viene confermata in entrambe le AZ prima che venga restituito l'esito positivo. Il compromesso è una latenza di scrittura leggermente maggiore. La replica asincrona (repliche Redis di ElastiCache, Read Replica di RDS) offre una latenza di scrittura inferiore, ma comporta un piccolo ritardo di replica: se il primario si guasta prima del completamento della replica, alcuni dati potrebbero andare persi.

È opportuno testare regolarmente il failover Multi-AZ per verificare le proprie ipotesi sull'RTO. Per RDS, è possibile avviare un failover tramite l'opzione Reboot with failover della console o tramite la CLI. Monitorare CloudWatch per la metrica FailedSQLServerAgentJobsCount e controllare i log dell'applicazione per verificare che la riconnessione avvenga correttamente. Documentare la durata effettiva del failover: può differire dalla documentazione AWS in base alla classe dell'istanza e al carico di lavoro.

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

In questa lezione ha appreso che: RDS Multi-AZ utilizza la replica sincrona con failover DNS automatico, Aurora utilizza un livello di storage condiviso tra tre AZ per un failover più rapido e EFS e DynamoDB sono nativamente Multi-AZ senza configurazione manuale. Distribuisca un NAT Gateway per AZ per evitare gli SPOF tra AZ. Ora esamineremo i pattern multi-regione active-active e active-passive.