Redis e Memcached: scegliere il motore giusto

Amazon ElastiCache è un servizio di caching in memoria completamente gestito che semplifica la distribuzione, la gestione e la scalabilità nel cloud dei più diffusi data store open source in memoria. Supporta due motori: Redis e Memcached. Servendo dalla memoria i dati richiesti più frequentemente invece di recuperarli da un database, ElastiCache può ridurre di diversi ordini di grandezza il carico sul database e diminuire la latenza delle risposte da millisecondi a microsecondi. La scelta tra Redis e Memcached è una domanda comune dell'esame SAA-C03.

Memcached è un key-value store distribuito e in memoria, progettato per la semplicità e la scalabilità orizzontale. Caratteristiche principali: multi-thread (può utilizzare tutti i core della CPU di un singolo nodo), archiviazione semplice chiave-valore (solo stringhe, senza strutture dati complesse), nessuna persistenza (i dati vengono persi al riavvio di un nodo), nessuna replica (nessun nodo standby o replica) e sharding orizzontale tramite consistent hashing lato client. Memcached è la scelta corretta quando è necessaria una cache semplice e su larga scala, senza esigenze di persistenza, tipi di dati complessi o alta disponibilità.

Redis (Remote Dictionary Server) è un data store in memoria a thread singolo (per istanza) e ricco di funzionalità, che supporta stringhe, hash, liste, set, set ordinati, bitmap, HyperLogLog, stream e indici geospaziali. I principali vantaggi rispetto a Memcached sono: persistenza opzionale (snapshot AOF e RDB), replica (read replica e failover automatico), messaggistica pub/sub, scripting Lua, transazioni (MULTI/EXEC) e modalità cluster per lo sharding orizzontale. Redis è la scelta corretta per la maggior parte degli scenari reali di caching.

Redis supporta due meccanismi di persistenza: RDB (Redis Database) — snapshot periodici di un preciso momento, salvati su disco a intervalli configurabili (riavvii rapidi, ma possibile perdita dei dati modificati tra uno snapshot e l'altro). AOF (Append-Only File) — registra ogni operazione di scrittura; al riavvio Redis riproduce il log per ricostruire lo stato (maggiore durabilità, a fronte di file più grandi e riavvii più lenti). In ElastiCache può abilitare AOF per mantenere i dati tra i riavvii dei nodi. Questo è fondamentale quando ElastiCache viene utilizzato non solo come cache, ma come data store primario, ad esempio per i dati di sessione.

Redis supporta i gruppi di replica con un nodo primario che gestisce tutte le scritture e fino a 5 read replica che gestiscono le letture. Con Multi-AZ e failover automatico abilitati, ElastiCache promuove automaticamente una read replica a nodo primario quando il primario ha un guasto, completando in genere il failover in meno di 60 secondi. In questo modo le applicazioni basate su Redis ottengono un'elevata disponibilità che Memcached non può offrire (Memcached non supporta la replica). Per le applicazioni di produzione che richiedono il caching ad alta disponibilità, utilizzi sempre Redis con failover automatico.

I set ordinati sono una delle strutture dati più potenti di Redis. Ogni elemento ha un punteggio a virgola mobile associato e gli elementi vengono mantenuti sempre in ordine. Questo rende i set ordinati ideali per le classifiche (ordinamento per punteggio), le code con priorità (elaborazione prima dei processi con priorità più alta) e il rate limiting (finestra scorrevole con timestamp usati come punteggi). Le operazioni ZADD, ZRANGE, ZREVRANGE, ZRANK e ZRANGEBYSCORE sono tutte O(log n): estremamente efficienti anche con milioni di elementi.

Il pub/sub di Redis consente ai publisher di trasmettere messaggi ai canali senza sapere chi vi è iscritto. I subscriber ricevono in tempo reale tutti i messaggi pubblicati sui canali a cui sono iscritti. I messaggi pub/sub non vengono resi persistenti: se un subscriber è offline, perde il messaggio. Per una messaggistica persistente con consegna garantita, utilizzi Redis Streams (una struttura dati più robusta aggiunta in Redis 5) oppure un servizio di messaggistica dedicato come SQS o SNS. Per l'esame SAA-C03, Redis pub/sub è un'opzione per notifiche leggere e in tempo reale tra servizi.

Utilizzi questo criterio per scegliere in vista dell'esame SAA-C03: scelga Memcached quando Le serve una cache semplice senza requisiti di HA, prestazioni multi-thread e scalabilità orizzontale tramite l'aggiunta di nodi (cache pura). Scelga Redis quando Le servono: persistenza (session store), replica e failover (HA), tipi di dati complessi (set ordinati per classifiche, set, liste), pub/sub, transazioni Lua o la Cluster Mode per la scalabilità orizzontale su più shard. Se la domanda d'esame menziona una funzionalità che va oltre il semplice caching chiave-valore, la risposta è quasi sempre Redis.

ElastiCache offre diverse famiglie di tipi di nodo: r7g (Graviton 3, ottimizzata per la memoria: miglior rapporto prezzo/prestazioni, consigliata per la maggior parte dei casi di caching), m7g (calcolo e memoria bilanciati) e t4g (a prestazioni espandibili, a basso costo per sviluppo e test). Le dimensioni dei nodi vanno da cache.t4g.micro (500 MB) a cache.r7g.16xlarge (425 GB). In produzione, scelga una dimensione che mantenga il dataset in memoria con un margine del 20-25%. L'esaurimento della memoria causa eviction (Memcached) o errori OOM (Redis).

ElastiCache viene distribuito all'interno del Suo VPC, con i security group che controllano l'accesso: per impostazione predefinita non è previsto alcun accesso tramite Internet pubblico. Per Redis, abiliti i token AUTH (una password che i client devono fornire) e la crittografia in transito (TLS) per le connessioni, oltre alla crittografia a riposo tramite KMS. Per Memcached è disponibile solo la crittografia TLS in transito (non la crittografia a riposo né AUTH). Quando esegue la migrazione da Redis non crittografato a Redis crittografato, non è possibile effettuare una migrazione in-place: deve creare un nuovo cluster crittografato e precaricarlo.

Quando una cache Redis o Memcached è piena, la policy di eviction determina quali chiavi rimuovere per liberare spazio. Policy di eviction comuni di Redis: noeviction (restituisce un errore OOM: utile quando la cache è il data store primario), allkeys-lru (rimuove la chiave usata meno di recente tra tutte le chiavi: utile per una cache generica), volatile-lru (applica LRU alle chiavi con TTL impostato: preserva le chiavi senza scadenza), allkeys-random (rimozione casuale), allkeys-lfu (rimuove la chiave usata meno frequentemente). Per i casi d'uso tipici del caching, sono consigliate allkeys-lru o allkeys-lfu.

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

In questa lezione ha imparato che: Memcached è semplice, multi-thread e non offre HA, quindi è ideale per la scalabilità orizzontale pura di cache semplici; Redis supporta strutture dati complesse, persistenza, pub/sub e failover Multi-AZ, quindi è la scelta migliore per la maggior parte degli scenari di caching in produzione; inoltre, i set ordinati rendono Redis la scelta naturale per classifiche e code con priorità. Ora esamineremo i gruppi di replica Redis e la Cluster Mode per lo sharding orizzontale.