Archiviazione delle sessioni e pattern per le classifiche

Le applicazioni web tradizionali archiviano i dati di sessione nella memoria del server. Questa soluzione funziona con un singolo server, ma non quando si esegue una scalabilità orizzontale: se la richiesta successiva di un utente viene instradata verso un'istanza EC2 diversa, tale istanza non conosce la sessione dell'utente, che viene quindi disconnesso. Le sessioni persistenti (affinità di sessione nel load balancer) risolvono il problema solo in parte, ma riducono l'efficacia del bilanciamento del carico. La soluzione scalabile consiste nello spostare lo stato della sessione in un archivio condiviso a bassa latenza, accessibile da tutte le istanze: è esattamente ciò che offre ElastiCache Redis.

Archiviare le sessioni in Redis offre: letture delle sessioni in meno di un millisecondo su tutti i server applicativi, TTL integrato per la scadenza automatica delle sessioni, aggiornamenti atomici delle sessioni per evitare condizioni di gara e la possibilità di invalidare immediatamente una sessione eliminando la chiave. L'applicazione memorizza l'ID della sessione in un cookie; a ogni richiesta cerca l'ID della sessione in Redis per recuperare i dati della sessione. Tutti i server applicativi condividono lo stesso Redis, quindi qualsiasi server può gestire la richiesta di qualsiasi utente.

Un TTL fisso indica che la sessione scade N secondi dopo la creazione, indipendentemente dall'attività. Un TTL scorrevole (che estende la scadenza a ogni accesso) è più pratico per gli utenti: la sessione scade N secondi dopo l'ultimo accesso. In Redis, si implementa un TTL scorrevole chiamando EXPIRE (o EXPIREAT) sulla chiave della sessione a ogni lettura riuscita della sessione, così da reimpostare il conto alla rovescia della scadenza. In questo modo gli utenti attivi non vengono disconnessi inaspettatamente, mentre le sessioni inattive scadono automaticamente, liberando memoria.

Un carrello per gli acquisti di un'applicazione di e-commerce è particolarmente adatto a Redis. Ogni carrello viene archiviato come un Redis Hash, in cui il campo è lo SKU del prodotto e il valore è la quantità. Le operazioni sugli hash, come HINCRBY e HDEL, consentono aggiornamenti atomici senza recuperare e riscrivere l'intero carrello. In combinazione con un TTL (per far scadere i carrelli abbandonati dopo 24 ore), Redis offre un archivio dei carrelli rapido e persistente, senza il sovraccarico di utilizzare un database relazionale per ogni evento di aggiunta al carrello.

Una classifica in tempo reale è un caso d'uso classico di Redis, reso possibile dagli Sorted Set (ZSET). Ogni voce del giocatore ha un punteggio; lo sorted set mantiene sempre i membri in ordine crescente di punteggio. Le query sulle classifiche (i primi N giocatori, la posizione di un giocatore, i giocatori in un intervallo di punteggio) hanno complessità O(log n) o O(log n + m): sono estremamente veloci anche con milioni di giocatori. Gli sorted set di Redis sono alla base di molte funzionalità di classificazione nel gaming, nel fitness e nei social network, senza dover ricorrere a query complesse sul database o ricalcolare la posizione a ogni visualizzazione della pagina.

Due funzionalità comuni delle classifiche, oltre a "mostra i primi 10", sono mostrare la posizione di un giocatore e mostrare i giocatori vicini a un determinato giocatore. Entrambe sono semplici da implementare con gli sorted set di Redis. ZREVRANK restituisce la posizione indicizzata a partire da 0 di un giocatore in ordine decrescente di punteggio. Per mostrare 5 giocatori sopra e sotto un giocatore, si recupera la sua posizione e poi si usa ZREVRANGE dall'indice posizione-5 all'indice posizione+5. In questo modo si ottiene una visualizzazione personalizzata della classifica con due comandi Redis, senza ricorrere a complesse funzioni finestra SQL.

La limitazione della frequenza (ovvero limitare il numero di richieste che un client può effettuare in una determinata finestra temporale) è un altro caso d'uso di grande valore per Redis. L'algoritmo della finestra scorrevole utilizza uno sorted set in cui ogni membro è il timestamp di una richiesta. A ogni richiesta: rimuove i membri più vecchi della finestra, conta quelli rimanenti, rifiuta la richiesta se il conteggio supera il limite e aggiunge il nuovo timestamp. In questo modo si implementa una limitazione precisa con finestra scorrevole e risoluzione al millisecondo, molto più accurata dei contatori a finestra fissa e senza il sovraccarico di un database.

I lock distribuiti coordinano l'accesso esclusivo a una risorsa condivisa tra più server applicativi. Il comando SET key value NX EX ttl di Redis permette di acquisire il lock in modo atomico: imposta la chiave solo se questa non esiste (NX = Not eXists) e imposta un TTL per evitare deadlock se il detentore si arresta in modo anomalo. Al termine dell'operazione, il detentore elimina la chiave. L'algoritmo Redlock (che utilizza più nodi Redis per ottenere un quorum) offre un lock distribuito più robusto, ma aggiunge complessità. Per la maggior parte dei casi d'uso, è sufficiente un lock su un singolo nodo Redis.

Sia ElastiCache Redis sia DynamoDB possono archiviare i dati delle sessioni, ma presentano compromessi diversi. ElastiCache Redis: latenza di pochi microsecondi, dati in memoria (volatili se non viene abilitata la persistenza), modello di dati più semplice, richiede un VPC. DynamoDB: latenza nell'ordine dei millisecondi a una cifra (DAX può raggiungere prestazioni pari a Redis), servizio completamente gestito senza cluster da mantenere, durabilità predefinita, accessibile globalmente con Global Tables, serverless con capacità on-demand. Per l'esame SAA-C03: se la domanda enfatizza la latenza di pochi microsecondi o le operazioni complesse in memoria, scelga Redis. Se enfatizza durabilità, serverless o scalabilità globale, consideri DynamoDB.

Redis dispone di un tipo di dati geospaziali integrato (comandi GEO) che memorizza coordinate di latitudine e longitudine e consente query di prossimità. Utilizzando GEOADD, GEODIST e GEORADIUS (ora GEOSEARCH in Redis 6.2), è possibile trovare tutte le posizioni entro un determinato raggio da un punto in O(n + log n). Casi d'uso: trovare autisti nelle vicinanze (ride sharing), trovare ristoranti entro 5 km, ordinare i risultati di ricerca per distanza. Ciò evita di dover utilizzare un database geospaziale separato e mantiene le query sulle posizioni alla velocità della memoria.

Un HyperLogLog è una struttura dati probabilistica che stima il conteggio degli elementi unici in un insieme utilizzando una quantità fissa di memoria (12 KB in Redis), indipendentemente dal numero di elementi unici aggiunti. Fornisce un errore standard approssimativo dello 0,81%. Utilizzi PFADD per aggiungere elementi e PFCOUNT per ottenere la stima. È perfetto per contare gli utenti attivi giornalieri unici, le visualizzazioni di pagina uniche o gli indirizzi IP unici quando non sono richiesti conteggi esatti e l'efficienza della memoria è importante. Memorizzare milioni di ID utente unici come Redis Set consumerebbe diversi GB; HyperLogLog utilizza 12 KB.

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

In questa lezione ha appreso che: l'archiviazione delle sessioni in Redis consente la scalabilità orizzontale senza stato, dando a tutte le istanze accesso allo stato condiviso delle sessioni con una latenza inferiore al millisecondo; gli sorted set di Redis alimentano classifiche in tempo reale con query sulla posizione in O(log n); e i tipi di dati Redis specializzati (HyperLogLog per i conteggi unici, GEO per la prossimità, lock distribuiti) risolvono in modo efficiente problemi architetturali comuni. Con questo si conclude il corso Caching with ElastiCache; ora esploreremo l'alta disponibilità e le architetture tolleranti ai guasti.