Gruppi di replica Redis e modalità cluster di ElastiCache

Un gruppo di replica ElastiCache è un raggruppamento logico costituito da un nodo Redis primario e fino a 5 read replica. Il nodo primario gestisce tutte le operazioni di scrittura; le repliche ricevono la replica asincrona dal primario e gestiscono il traffico di lettura. I gruppi di replica consentono due funzionalità fondamentali: scalabilità in lettura (distribuzione delle richieste di lettura tra più repliche) e alta disponibilità con failover automatico (promozione di una replica a primario in caso di guasto del primario). Tutti i nodi di un gruppo di replica condividono lo stesso dataset.

ElastiCache fornisce due endpoint DNS per un gruppo di replica: il primary endpoint punta sempre al nodo primario corrente (e viene aggiornato automaticamente durante il failover); lo utilizzi per tutte le operazioni di scrittura. Il reader endpoint distribuisce il carico delle richieste di lettura tra tutte le repliche disponibili; lo utilizzi per le operazioni di lettura, così da distribuire il carico. L'applicazione dovrebbe mantenere due connection pool: una per il primary endpoint, destinata alle scritture, e una per il reader endpoint, destinata alle letture. Questo è il pattern di connessione consigliato per i gruppi di replica Redis di ElastiCache.

Quando il nodo primario ha un guasto (rilevato da ElastiCache in pochi secondi tramite gli health check), il failover automatico seleziona una delle read replica e la promuove a primario. Il processo di promozione è il seguente: (1) la replica selezionata viene promossa a primario, (2) il record DNS del primary endpoint viene aggiornato per puntare al nuovo primario (TTL di circa 1 secondo), (3) il vecchio primario viene sostituito da una nuova replica. Il tempo totale di failover è in genere di 30-60 secondi. Le applicazioni che utilizzano il DNS del primary endpoint si riconnettono automaticamente quando la modifica DNS si propaga: non sono necessari indirizzi IP hardcoded.

Per ottenere la massima resilienza, distribuisca le repliche su più Availability Zone. Quando abilita Multi-AZ su un gruppo di replica, ElastiCache colloca automaticamente il primario e le repliche in AZ diverse. Se un'intera AZ diventa non disponibile, il failover promuove una replica di un'AZ ancora operativa. Quando crea il gruppo di replica, può anche specificare esplicitamente le AZ preferite per ogni nodo utilizzando l'opzione --preferred-cache-cluster-a-zs.

Redis Cluster Mode Enabled (CME) suddivide il dataset tra più gruppi di nodi (shard), ciascuno contenente un primario e fino a 5 repliche. Questa è la soluzione di sharding orizzontale di Redis. Cluster Mode consente di superare la memoria di un singolo nodo: può avere fino a 500 gruppi di nodi da 500 GB ciascuno, permettendo a un singolo cluster Redis di contenere fino a 500 × 500 GB = 250 TB di dati. Cluster Mode moltiplica inoltre il throughput di scrittura, poiché ogni gruppo di nodi elabora in modo indipendente le scritture per il proprio intervallo di chiavi.

Redis Cluster Mode suddivide lo spazio delle chiavi in 16.384 hash slot. Ogni gruppo di nodi possiede un intervallo contiguo di hash slot. Quando viene scritta una chiave, Redis calcola CRC16(key) % 16384 per determinare l'hash slot e quindi il gruppo di nodi responsabile. L'applicazione deve utilizzare un client Redis compatibile con i cluster (come redis-py-cluster o Jedis in modalità cluster) che conosca la mappa degli slot e instradi ogni comando al nodo corretto. I client standard restituiscono errori di reindirizzamento MOVED se inviano una chiave allo shard errato.

Per l'esame SAA-C03, scelga la modalità non cluster quando: i dati entrano in un singolo nodo (< ~400 GB lasciando un margine), è necessaria una configurazione semplice primario/replica oppure l'applicazione utilizza operazioni complesse su più chiavi (le transazioni che coinvolgono più chiavi richiedono che tutte le chiavi si trovino nello stesso slot). Scelga la modalità cluster quando: il dataset supera la memoria di un singolo nodo, è necessario aumentare orizzontalmente il throughput di scrittura oppure prevede una crescita futura che richiederà il resharding online. La modalità cluster supporta l'aggiunta di shard senza downtime (resharding online).

ElastiCache Global Datastore estende la replica di Redis tra più Regioni AWS. Si designa una Regione come cluster primario e si aggiungono cluster secondari in altre Regioni. Le scritture vengono inviate al primario; i secondari ricevono la replica asincrona, con un ritardo tipico inferiore a 1 secondo. I cluster secondari possono gestire le letture locali con una latenza molto bassa. Global Datastore consente di realizzare applicazioni globali, in cui gli utenti di continenti diversi leggono i dati dalla Regione più vicina, e scenari di DR tra regioni, in cui è possibile promuovere un cluster secondario a primario se la Regione primaria si guasta.

In un gruppo di replica Redis non in cluster, i messaggi Pub/Sub vengono distribuiti a tutte le repliche: qualsiasi sottoscrittore su qualunque nodo riceve i messaggi pubblicati su un canale. Tuttavia, in Cluster Mode, Pub/Sub è limitato alle notifiche keyspace e Pub/Sub basato sui canali funziona solo all'interno di un singolo shard, a meno di utilizzare Redis 7+ con lo sharding Pub/Sub (SSUBSCRIBE / SPUBLISH per un Pub/Sub consapevole degli shard). Si tratta di una limitazione importante da considerare quando si progetta un sistema Pub/Sub su larga scala con Cluster Mode.

Monitorare la metrica CloudWatch ReplicationLag sulle repliche di lettura per verificare che rimangano sincronizzate con il primario. Un ritardo superiore a pochi secondi indica un collo di bottiglia sulla replica, ad esempio un nodo sovraccarico, problemi di rete o un numero di scritture eccessivo per la capacità di elaborazione della replica. Negli scenari con Global Datastore, monitorare GlobalDatastoreReplicationLag. Un ritardo di replica elevato indica che le repliche di lettura potrebbero restituire dati obsoleti, un aspetto importante per le applicazioni che richiedono una consistenza eventuale entro limiti ristretti.

È possibile effettuare una scalabilità verticale (modificando il tipo di nodo) oppure una scalabilità orizzontale (aggiungendo o rimuovendo repliche). La modifica del tipo di nodo richiede una chiamata modify-replication-group e, se applicata immediatamente, causa un breve failover: il primario viene sostituito da un nuovo nodo del tipo scelto. L'aggiunta di repliche avviene online, senza downtime. Per passare dalla modalità non in cluster alla modalità cluster, è necessario creare un nuovo gruppo in modalità cluster ed eseguire la migrazione: non è possibile convertire direttamente una modalità nell'altra.

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

In questa lezione ha appreso che i gruppi di replica consentono di scalare le letture tramite le repliche e garantiscono un'elevata disponibilità grazie al failover automatico con endpoint primario e di lettura; Cluster Mode suddivide i dati tra un massimo di 500 gruppi di nodi utilizzando 16.384 hash slot, permettendo di superare orizzontalmente la memoria di un singolo nodo; infine, Global Datastore replica i dati tra le Regioni per garantire letture globali a bassa latenza e il DR tra regioni. Nella prossima lezione esamineremo le strategie di caching: lazy loading e write-through.