Distributed Cache

Distributed Cache

Perché le aziende si fondono o acquisiscono altre aziende?
1 Giugno 2022
crescere
Far crescere i propri collaboratori: i piani di sviluppo individuali
8 Giugno 2022

Una cache distribuita è un sistema che riunisce la memoria ad accesso casuale (RAM) di più computer collegati in rete in un unico archivio di dati in-memoria.  

Mentre la maggior parte delle cache sono tradizionalmente in un server fisico o in un componente hardware, una cache distribuita può crescere oltre i limiti di memoria di un singolo computer collegando insieme più computer, chiamato architettura distribuita o cluster distribuito, per una maggiore capacità ed una maggiore potenza di elaborazione. 

Le cache distribuite sono particolarmente utili in ambienti con un alto volume di dati. L’architettura distribuita permette l’espansione e la scalabilità incrementale aggiungendo più computer al cluster, permettendo alla cache di crescere di pari passo con la crescita dei dati. 

Una cache distribuita è una cache che ha i suoi dati sparsi su diversi nodi in un cluster o su diversi cluster in diversi data center situati in tutto il mondo. 

Essere distribuita su più nodi aiuta la scalabilità orizzontale e le istanze possono essere aggiunte al volo in base alla domanda. 

Il caching distribuito è usato principalmente nell’industria oggi, per avere il potenziale di scalare su richiesta ed essere altamente disponibile. 

Scalabilità, alta disponibilità, tolleranza ai guasti sono cruciali per i servizi su larga scala che funzionano online oggi. Le aziende e le organizzazioni non possono permettersi che i loro servizi vadano offline. Pensate ai servizi sanitari, ai mercati azionari, ai servizi militari. Si tratta di servizi distribuiti su più nodi con una quantità abbastanza solida di ridondanza. 

I sistemi distribuiti sono la scelta preferita per il cloud computing per la capacità di scalare ed essere sempre disponibili. 

Google Cloud usa Memcache per il caching dei dati sulla sua piattaforma cloud pubblica. Redis è usato dai giganti di Internet per il caching, il datastore NoSQL e molti altri casi d’uso. 

Design e architettura di una cache distribuita

La progettazione di una cache distribuita richiede un articolo separato e approfondito. Per ora, vi darò una breve panoramica di come funziona una cache distribuita dietro le quinte. 

Una cache distribuita è in fondo una Distributed Hash Table che ha la responsabilità di mappare i valori degli oggetti sulle chiavi distribuite su più nodi. 

La tabella Hash distribuita permette ad una cache distribuita di scalare al volo, gestisce l’aggiunta, la cancellazione, il fallimento dei nodi continuamente finché il servizio di cache è online. Le tabelle hash distribuite sono state originariamente utilizzate nei sistemi peer to peer. 

Parlando del design, la cache elimina i dati in base alla politica Least Recently Used (LRU). Idealmente, utilizza una Linked-List per gestire i puntatori ai dati. Il puntatore dei dati a cui si accede frequentemente viene continuamente spostato in cima alla lista/coda. Una coda è implementata usando una lista collegata. 

I dati che non sono usati così frequentemente vengono spostati alla fine della lista ed eventualmente espulsi. 

Linked-List è una struttura dati adatta nei casi in cui ci siano molti inserimenti, cancellazioni e aggiornamenti nella lista. Fornisce prestazioni migliori rispetto a una ArrayList. 

Inoltre, la cache distribuita spesso funziona con coordinatori di sistemi distribuiti come Zookeeper¹. Facilita la comunicazione e aiuta a mantenere uno stato coerente tra i diversi nodi di cache in esecuzione. 

Sul versante software, alcune soluzioni di cache distribuita sono costruite su archivi di dati come le griglie di dati in-memory o i database in-memory. Alcune soluzioni sono costruite appositamente per il caching, ma le organizzazioni che implementano più casi d’uso in-memory possono trovare più pratico sfruttare una base tecnologica coerente, dove possibile. 

Differenza tra caching distribuito e caching tradizionale/locale

I sistemi progettati e distribuiti per scalare intrinsecamente, sono progettati in modo tale che la loro potenza possa essere aumentata al volo, sia che si tratti di calcolo, storage o altro. Lo stesso vale per la cache distribuita. 

La cache tradizionale è ospitata su poche istanze e soffre di un limite fisico. È difficile scalarla al volo. Non è facilmente disponibile e tollerante agli errori in confronto al design della cache distribuita. 

Il cloud è tecnicamente un sistema massicciamente distribuito di servizi come il calcolo, lo storage, … 

Strategie di caching distribuito

Ci sono diversi tipi di strategie di caching che servono casi d’uso specifici. Queste sono Cache Aside, Read-through cache, Write-through cache & Write-back. 

Scopriamo cosa sono e perché abbiamo bisogno di strategie diverse per la cache. 

1 Cache Aside

Si tratta della strategia di caching più comune. In questo approccio la cache lavora insieme al database cercando di ridurre il più possibile gli hit su di essa. I dati sono caricati in background nella cache. 

Quando l’utente invia una richiesta per particolari dati, il sistema prima li cerca nella cache. Se sono presenti in cache, i dati vengono semplicemente restituiti. Diversamente, i dati vengono recuperati dal database, la cache viene aggiornata e vengono restituiti all’utente. 

Questo tipo di strategia funziona meglio con carichi di lavoro pesanti in lettura come, ad esempio, dati che non sono aggiornati molto frequentemente, come i dati del profilo utente in un portale. 

I dati in questa strategia sono scritti direttamente nel database. Questo significa che i dati tra la cache e il database potrebbero diventare incoerenti. 

Per evitare questo, i dati nella cache hanno un Time to Live (TTL). Dopo questo periodo stabilito i dati vengono invalidati dalla cache. 

2 Read-Through

La strategia Read-Through è abbastanza simile alla strategia Cache Aside con alcune sottili differenze. Come nella strategia Cache Aside il sistema deve recuperare le informazioni dal database se non si trovano nella cache, ma nella strategia Read-through la cache rimane sempre coerente con il database. La libreria della cache si prende l’onere di mantenere la coerenza con il backend; 

Le informazioni anche in questa strategia sono caricate nella cache solo quando l’utente le richiede. 

Quindi, quando per la prima volta l’informazione viene richiesta, risulta in una cache miss, il backend deve allora aggiornare la cache mentre restituisce la risposta all’utente. 

Per ottimizzare la fruizione del servizio, gli sviluppatori possono precaricare la cache con le informazioni che ci si aspetta vengano richieste maggiormente dagli utenti. 

3 Write-Through 

Nella strategia Write-Through, ogni informazione scritta nel database passa attraverso la cache. Prima che i dati vengano scritti nel database, la cache viene aggiornata con essi. 

Tale strategia mantiene un’alta coerenza tra la cache e il database anche se aggiunge un pò di latenza durante le operazioni di scrittura poiché i dati devono essere aggiornati anche nella cache. Questo funziona bene per carichi di lavoro pesanti come i giochi multiplayer online. 

Questa strategia è usata unitamente alle altre strategie di caching per ottenere prestazioni ottimizzate. 

4 Write-Back 

Nella strategia di caching Write-back i dati vengono scritti direttamente nella cache invece che nel database. La cache, con un determinato ritardo secondo la logica di business, scrive i dati sul database. 

Se c’è un numero abbastanza elevato di scritture nell’applicazione, gli sviluppatori possono ridurre la frequenza delle scritture sul database per ridurre il carico e i costi associati. 

Un rischio in questo approccio è che se la cache fallisce prima che il database sia aggiornato, i dati potrebbero andare persi.  

Ancora una volta questa strategia è usata con altre strategie di caching per ottenere il massimo da queste. Comunque, tale approccio aiuta ad ottimizzare i costi in modo significativo. 

Vantaggi di una cache distribuita

Ci sono molti casi d’uso per cui uno sviluppatore di applicazioni può includere una cache distribuita come parte della sua architettura. Questi includono: 

1 Accelerazione delle applicazioni.

Le applicazioni che si basano su database relazionali basati su disco non possono sempre soddisfare i requisiti di performance delle transazioni più esigenti. Memorizzando i dati più frequentemente acceduti in una cache distribuita, è possibile ridurre drasticamente il collo di bottiglia I/O dei sistemi basati su disco. Questo assicura che le vostre applicazioni vengano eseguite molto più velocemente, anche con un gran numero di transazioni quando l’utilizzo raggiunge un picco. 

2 Memorizzazione dei dati di sessione web.

Un sito può memorizzare i dati di sessione degli utenti in una cache per servire come input per i carrelli della spesa e le raccomandazioni per esempio. Con una cache distribuita, si può avere un gran numero di sessioni web concorrenti a cui si può accedere da qualsiasi server di applicazioni web che esegue il sistema. Questo permette di bilanciare il traffico web su diversi server applicativi e di non perdere i dati delle sessioni in caso di guasto di un server applicativo. 

3 Riduzione dell’uso e dei costi di rete.

Mettendo in cache i dati in più punti della rete, compresi gli stessi computer dell’applicazione, è possibile ridurre il traffico di rete e lasciare più larghezza di banda disponibile per altre applicazioni che dipendono dalla rete. 

4 Riduzione dell’impatto delle interruzioni.

A seconda dell’architettura, una cache può essere in grado di rispondere alle richieste di dati anche quando il database sorgente non è disponibile. Questo aggiunge un livello di alta disponibilità al sistema. 

5 Scalabilità.

Alcune applicazioni richiedono volumi significativi di dati. Sfruttando più risorse su più macchine, una cache distribuita può rispondere a queste richieste. 

6 Efficientamento dei database.  

Il caching intercetta tutte le richieste di dati degli utenti prima che vadano al database. Questo evita il problema del collo di bottiglia del database. Il database viene interrogato da un numero relativamente minore di richieste, rendendo l’applicazione nel suo complesso performante. L’in-memory è economico se paragonato ai costi di persistenza del disco rigido. Le operazioni di lettura e scrittura del database sono costose, in particolare se ricorriamo a DBaaS Database as a Service. Ci sono momenti in cui ci sono semplicemente troppe scritture sull’applicazione, per esempio, nei giochi online multigiocatore di massa. I dati che non hanno elevata priorità possono essere scritti nella cache e le operazioni batch periodiche possono essere eseguite per scrivere i dati nel database. Questo aiuta a ridurre i costi di scrittura del database di una quantità significativa. 

Casi d’uso delle cache distribuite

Le cache distribuite hanno diversi casi d’uso. Ne indichiamo nel seguito i quattro principali. 

1 Caching su database

Il livello di cache posto davanti ad un database salva in memoria i dati di frequente accesso per ridurre la latenza e il carico non necessario su di esso. L’implementazione della cache porta all’eliminazione dei colli di bottiglia nell’accesso ai database. 

2 Memorizzazione delle sessioni utente

Le sessioni utente vengono memorizzate nella cache per evitare di perdere lo stato degli utenti nel caso in cui cada una delle istanze.  

Se una delle istanze va giù, si avvia una nuova istanza, questa legge lo stato dell’utente dalla cache e continua la sessione senza che l’utente noti nulla di strano. 

3 Comunicazione tra moduli e archiviazione condivisa

Il caching distribuito in memoria è utilizzato anche per la mutua comunicazione dei messaggi tra i diversi microservizi in esecuzione.  

La cache salva in questo caso i dati condivisi che sono comunemente accessibili da tutti i servizi. Agisce come una spina dorsale per la comunicazione dei microservizi. Il caching distribuito in casi d’uso specifici è spesso usato come un datastore NoSQL. 

4 In-memory Data Stream Processing & Analytics

Al contrario dei modi tradizionali di memorizzare i dati in lotti e poi eseguire analisi su di essi, l’elaborazione dei flussi di dati in-memoria comporta l’elaborazione dei dati e l’esecuzione di analisi su di essi mentre scorrono in tempo reale. 

Ciò si rivela utile in molte situazioni come il rilevamento delle anomalie, il monitoraggio delle frodi, le statistiche di gioco online in tempo reale, le pubblicità in tempo reale, l’elaborazione dei pagamenti, … 

Svantaggi di una cache distribuita

Mentre ci sono molti vantaggi nell’usare una cache distribuita, il principale svantaggio è il costo della RAM.  

Poiché i costi della RAM sono significativamente più alti di quelli dei dischi rotazionali o SSD, la velocità in-memory non è facilmente disponibile. Le aziende che utilizzano grandi cache distribuite possono in genere giustificare la spesa hardware attraverso i guadagni quantificabili nell’avere un sistema più veloce. Ma con la continua diminuzione dei costi della RAM, l’elaborazione in-memory sta diventando più mainstream per tutte le aziende. Con le innovazioni relative alla memoria, come l’Intel® Optane™ DC Persistent Memory, le aziende possono adottare soluzioni in-memory come le cache distribuite a un costo molto più basso sfruttando le velocità della RAM. 

Le cache distribuite più popolari

Le cache distribuite popolari utilizzate nel settore sono Eh-cache, Memcache, Redis, Riak, Hazelcast. 

Memcache è usato da Google Cloud nella sua Platform As A Service. Si tratta di un negozio distribuito di valori chiave altamente performante, utilizzato principalmente per alleviare il carico del database. È come una grande tabella hash distribuita su diverse macchine e consente l’accesso ai dati in tempo costante. 

Oltre ad avere la coppia chiave-valore Redis è un sistema distribuito in-memoria open-source che supporta anche altre strutture di dati come liste distribuite, code, stringhe, set, insiemi ordinati. Oltre al caching, Redis è anche spesso trattato come un negozio di dati NoSQL. 

 

Bibliografia: 

 

¹ZooKeeper è un servizio centralizzato per mantenere le informazioni di configurazione, la denominazione, la sincronizzazione distribuita e i servizi di gruppo. Tutti questi tipi di servizi sono utilizzati in una forma o nell’altra dalle applicazioni distribuite.

Condividi su:

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.

EnglishFrenchGermanItalianRussianSpanish