Active-active multi-site con Global Tables e Route 53

Multi-Site Active-Active è il livello più avanzato di disaster recovery, in cui l'applicazione viene eseguita alla piena capacità di produzione simultaneamente in due o più regioni AWS. A differenza dell'architettura attivo-passivo, in cui un ambiente di standby attende di subentrare, nell'architettura attivo-attivo entrambe le regioni gestiscono traffico reale degli utenti in ogni momento. Quando una regione si guasta, l'altra assorbe immediatamente il 100% del traffico, senza ritardi di failover. Questo modello riduce anche la latenza per gli utenti distribuiti a livello globale, servendoli dalla regione più vicina.

DynamoDB Global Tables costituisce la base dati delle architetture attivo-attivo. Global Tables abilita la replica multi-master e multi-regione: le applicazioni di qualsiasi regione possono leggere e scrivere in una tabella DynamoDB locale e le modifiche vengono replicate in tutte le altre regioni in circa 1 secondo. Per abilitare Global Tables, specifichi le regioni in cui deve esistere la tabella. AWS gestisce automaticamente tutta la replica, la risoluzione dei conflitti (vince l'ultima scrittura) e il failover.

Aurora Global Database fornisce letture attive-attive, ma scritture attive-passive. Tutte le regioni secondarie gestiscono le letture con un ritardo di replica inferiore a 1 secondo, mentre solo la regione primaria accetta scritture. Questa soluzione è ideale per le applicazioni con molte letture che richiedono letture a bassa latenza a livello globale e una primaria di scrittura ben definita. In caso di guasto regionale della primaria, è possibile promuovere una secondaria a primaria in meno di 1 minuto, ottenendo un RTO ridotto per il livello di scrittura. Si confronti questa soluzione con DynamoDB Global Tables, che supporta scritture attivo-attive in tutte le regioni.

Route 53 dirige il traffico nelle architetture multi-sito attivo-attivo. Utilizzi il routing basato sulla latenza per inviare ogni utente alla regione con la latenza di rete più bassa dalla sua posizione. Associ controlli dello stato a ogni record regionale: quando una regione non supera il controllo dello stato, Route 53 la rimuove automaticamente dalle risposte DNS e invia tutto il traffico alle regioni sane rimanenti. Imposti un TTL DNS di 60 secondi o inferiore per ridurre al minimo il tempo necessario agli utenti per passare alla regione sana.

Quando una regione si guasta in una configurazione attivo-attivo, la regione superstite deve gestire il doppio (o più) del traffico normale. Il Suo Auto Scaling Group deve avere una capacità massima sufficiente e policy di scale-out che reagiscano rapidamente. Configuri il target tracking scaling in base al numero di richieste ALB per destinazione, in modo che l'ASG aggiunga automaticamente istanze quando il traffico raddoppia. Valuti anche il pre-riscaldamento: durante le esercitazioni di failover, osservi la rapidità con cui l'ASG aumenta la capacità e verifichi che possa raggiungere la capacità richiesta entro l'obiettivo RTO.

In un'architettura a singola regione, le sessioni degli utenti possono essere archiviate localmente sui server applicativi. In un'architettura multi-regione attivo-attivo, gli utenti potrebbero passare da una regione all'altra nelle richieste successive, interrompendo le sessioni lato server. Soluzioni: 1) sessioni stateless — memorizzi i dati della sessione in un JWT firmato o in un cookie che qualsiasi server di qualsiasi regione possa convalidare. 2) DynamoDB Global Tables per le sessioni — memorizzi le sessioni centralmente, con accesso in millisecondi da qualsiasi regione. 3) ElastiCache con Global Datastore — utilizzi la replica Redis tra regioni per archiviare le sessioni.

La sfida principale dell'attivo-attivo con scritture multi-master consiste nei conflitti di scrittura. Se due utenti in regioni diverse aggiornano simultaneamente lo stesso record, quale aggiornamento deve prevalere? DynamoDB Global Tables utilizza la strategia vince l'ultima scrittura, basata sul timestamp della scrittura. Questa soluzione funziona bene nella maggior parte dei casi d'uso, ma può causare la perdita di dati in caso di aggiornamenti concorrenti (ad esempio, due utenti che incrementano simultaneamente un contatore). Progetti il modello dati in modo da evitare scritture simultanee sullo stesso elemento da parte di regioni diverse, utilizzando scritture condizionali oppure assegnando la proprietà dei dati in base alla regione.

Per l'archiviazione di oggetti in un'architettura attivo-attivo, utilizzi S3 Cross-Region Replication con replica bidirezionale (disponibile nei bucket con il versioning abilitato). A differenza della CRR unidirezionale, la replica bidirezionale mantiene sincronizzati i bucket di entrambe le regioni: gli oggetti scritti in una regione vengono replicati automaticamente nell'altra. Questo è fondamentale per le applicazioni che scrivono i file caricati dagli utenti nel bucket S3 della regione locale, ma devono renderli accessibili a livello globale. Abiliti S3 Replication Time Control (RTC) per garantire che il 99,99% degli oggetti venga replicato entro 15 minuti.

Utilizzi CloudFront con gruppi di origini per creare una CDN attivo-attiva con failover automatico. Configuri un'origine primaria (ALB in us-east-1) e un'origine secondaria (ALB in eu-west-1). CloudFront esegue automaticamente il failover verso l'origine secondaria quando quella primaria restituisce errori 5xx. Per gli asset statici distribuiti da S3, configuri gruppi di origini che puntino a bucket S3 in più regioni con replica bidirezionale. In questo modo aggiunge un livello di resilienza a livello CDN al routing attivo-attivo di Route 53.

Le architetture attivo-attivo richiedono un monitoraggio efficace per garantire che entrambe le regioni siano sane e che il traffico sia bilanciato come previsto. Metriche chiave: Route 53 HealthCheckPercentageHealthy per regione, DynamoDB ReplicationLatency per il ritardo di Global Tables, ALB RequestCount per regione per verificare la distribuzione del traffico e dashboard CloudWatch tra account e regioni per una visione unificata. Imposti allarmi quando il ritardo di replica supera la soglia RPO o quando la distribuzione del traffico diventa fortemente sbilanciata.

L'attivo-attivo è appropriato quando: gli utenti sono distribuiti a livello globale e la latenza verso una singola regione è inaccettabile. L'RTO deve essere quasi nullo: l'azienda non può tollerare nemmeno pochi minuti di inattività. Un elevato throughput di scrittura richiede di distribuire le scritture tra più regioni. I requisiti normativi impongono l'elaborazione dei dati nel Paese di origine. Il costo è sostanzialmente maggiore rispetto agli altri livelli di DR, quindi scelga l'attivo-attivo solo quando i requisiti aziendali e gli aspetti economici lo giustificano chiaramente. Per molti carichi di lavoro, Warm Standby è sufficiente e molto più economico.

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

In questa lezione ha imparato che: DynamoDB Global Tables abilita scritture multi-master tra regioni per un vero attivo-attivo, il routing basato sulla latenza di Route 53, insieme ai controlli dello stato, indirizza gli utenti verso la regione sana più vicina e la gestione delle sessioni deve essere stateless oppure utilizzare uno storage replicato a livello globale nell'attivo-attivo. L'attivo-attivo offre RTO e RPO quasi nulli, ma a un costo significativamente maggiore. Prossimamente esamineremo i pilastri dell'Eccellenza operativa e della Sicurezza del Well-Architected Framework.