Best practice per Memorystore for Redis Cluster

Questa pagina fornisce indicazioni sull'utilizzo ottimale di Memorystore for Redis Cluster. Questa pagina indica anche i potenziali problemi da evitare.

Nota: per visualizzare esempi di configurazione del client del cluster Redis, consulta Esempi di codice della libreria client.

Best practice di gestione della memoria

Questa sezione descrive le strategie per la gestione della memoria per i cluster in modo che Memorystore for Redis Cluster funzioni in modo efficiente per le tue applicazioni client.

Concetti di gestione della memoria

• Carico di scrittura: il volume e la velocità con cui aggiungi o aggiorni le chiavi nel tuo cluster Redis. Il carico di scrittura può variare da normale a molto elevato a seconda del caso d'uso di Redis e dei pattern di utilizzo dell'applicazione.

• Criterio di eliminazione: Memorystore for Redis Cluster utilizza il criterio di eliminazione volatile-lru. Puoi utilizzare comandi come EXPIRE per impostare le espulsioni per le chiavi.

Monitora un cluster con un carico di scrittura normale

Visualizza la metrica /cluster/memory/maximum_utilization. Se /cluster/memory/maximum_utilization è al 100% o inferiore, il tuo cluster Redis funziona bene quando utilizzi un carico di scrittura normale.

Tuttavia, se la memoria utilizzata si avvicina al 100% e prevedi che l'utilizzo dei dati aumenterà, devi fare lo scale up delle dimensioni del cluster per fare spazio ai nuovi dati.

Monitorare un cluster con un carico di scrittura elevato

Visualizza la metrica /cluster/memory/maximum_utilization. A seconda della gravità del carico di scrittura elevato, il cluster può riscontrare problemi di prestazioni alle seguenti soglie:

• Carichi di scrittura molto elevati possono riscontrare problemi se /cluster/memory/maximum_utilization raggiunge il 65% o più.

• Carichi di scrittura moderatamente elevati possono riscontrare problemi se /cluster/memory/maximum_utilization raggiunge l'85% o più.

In questi scenari devi fare lo scale up delle dimensioni del cluster per migliorare il rendimento.

Se riscontri problemi o temi che il tuo cluster abbia un carico di scrittura elevato, contatta l'assistenzaGoogle Cloud .

Scalare gli shard

Quando aumenti il numero di shard in un cluster, devi farlo durante i periodi di bassa attività di scrittura. Lo scaling durante i periodi di carico di scrittura elevato può esercitare pressione sulla memoria del cluster a causa dell'overhead della memoria causato dalla replica o dalla migrazione degli slot.

Se il tuo caso d'uso di Redis utilizza l'eliminazione delle chiavi, il ridimensionamento a una dimensione del cluster più piccola può ridurre la percentuale successi cache. In questo caso, tuttavia, non devi preoccuparti di perdere dati, poiché l'eliminazione delle chiavi è prevista.

Per i casi d'uso di Redis in cui non vuoi perdere le chiavi, devi eseguire lo scale down solo a un cluster più piccolo che abbia ancora spazio sufficiente per i tuoi dati. Il nuovo numero di shard di destinazione deve consentire almeno 1,5 volte la memoria utilizzata dai dati. In altre parole, devi eseguire il provisioning di un numero di shard pari a 1,5 volte la quantità di dati nel cluster. Puoi utilizzare la metrica /cluster/memory/total_used_memory per visualizzare la quantità di dati archiviati nel cluster.

Best practice per l'utilizzo della CPU

Se si verifica un'interruzione imprevista a livello di zona, le risorse CPU del cluster vengono ridotte a causa della capacità persa dai nodi nella zona non disponibile. Ti consigliamo di utilizzare cluster ad alta disponibilità. L'utilizzo di più repliche per shard (anziché una replica per shard) fornisce risorse CPU aggiuntive durante un'interruzione. Puoi avere fino a cinque repliche per shard.

Inoltre, consigliamo di gestire l'utilizzo della CPU dei nodi in modo che abbiano un overhead della CPU sufficiente per gestire il traffico aggiuntivo dovuto alla capacità persa in caso di interruzione zonale imprevista. Devi monitorare l'utilizzo della CPU per i nodi primari e le repliche utilizzando la metrica Secondi CPU thread principale /cluster/cpu/maximum_utilization.

A seconda del numero di repliche che esegui il provisioning per nodo, ti consigliamo i seguenti target di utilizzo della CPU /cluster/cpu/maximum_utilization:

• Per i cluster con una replica per nodo, scegli come target un valore /cluster/cpu/maximum_utilization di 0,5 secondi per il nodo principale e 0,5 secondi per la replica.
• Per i cluster con due o più repliche per nodo, scegli un valore di /cluster/cpu/maximum_utilization pari a 0,9 secondi per la replica primaria e 0,5 secondi per ogni replica.

Se i valori della metrica superano questi consigli, ti consigliamo di aumentare il numero di shard nel cluster. Se hai meno di cinque repliche per il tuo cluster, puoi anche fare lo scale up del numero di repliche fino a un massimo di cinque repliche.

Se il cluster registra un utilizzo elevato della CPU o le risorse del cluster si esauriscono (ad esempio, a causa di un numero eccessivo di connessioni), il cluster potrebbe non funzionare correttamente e le metriche esterne potrebbero non essere disponibili.

Comandi Redis che richiedono molte risorse

Ti consigliamo vivamente di evitare di utilizzare comandi Redis che richiedono molte risorse. L'utilizzo di questi comandi potrebbe causare i seguenti problemi di prestazioni:

• Latenza elevata e timeout del client
• Pressione della memoria causata da comandi che aumentano la memoria utilizzata
• Perdita di dati durante la replica e la sincronizzazione dei nodi perché il thread principale di Redis è bloccato
• Controlli di integrità, osservabilità e replica in caso di risorse insufficienti

La tabella seguente elenca alcuni esempi di comandi Redis che richiedono molte risorse e fornisce alternative efficienti in termini di risorse.

Suggerimento: oltre a richiedere molte risorse, man mano che le dimensioni totali dei dati aumentano, aumenta anche il costo dell'utilizzo di questi comandi.

Per trovare i comandi a lunga esecuzione che utilizzi, utilizza SLOWLOG. Questo strumento fornisce un elenco di comandi la cui esecuzione richiede più tempo. Di conseguenza, conosci i comandi che causano problemi di latenza. Per determinare alternative efficienti in termini di risorse per questi comandi, consulta la tabella seguente.

Category	Comando che richiede molte risorse	Alternativa efficiente in termini di risorse
Esegui per l'intero keyspace	KEYS	SCAN
Esegui per un keyset di lunghezza variabile	LRANGE	Limita le dimensioni dell'intervallo che utilizzi per una query.
	ZRANGE	Limita le dimensioni dell'intervallo che utilizzi per una query.
	HGETALL	HSCAN
	SMEMBERS	SSCAN
Bloccare l'esecuzione di uno script	EVAL	Assicurati che lo script non venga eseguito all'infinito.
	EVALSHA	Assicurati che lo script non venga eseguito all'infinito.
Rimuovere file e link	DEL	UNLINK
Pubblica e sottoscrivi	PUBLISH	SPUBLISH
	SUBSCRIBE	SSUBSCRIBE

Best practice per le soglie di scalabilità

Gli scenari di soglia di scalabilità rientrano nelle seguenti categorie:

• Scalabilità per l'utilizzo della memoria
• Scalabilità per l'utilizzo della CPU
• Scalabilità per mitigare gli hotspot

Se il tuo carico di lavoro si basa sull'eliminazione delle chiavi, Google non consiglia lo scale-in per l'utilizzo della CPU o della memoria. In questi carichi di lavoro, l'utilizzo della memoria raggiunge spesso la capacità massima prima che si verifichino automaticamente le espulsioni. I picchi di memoria risultanti bloccano le operazioni di riduzione.

Le sezioni seguenti descrivono in dettaglio scenari comuni e soglie delle metriche che potrebbero giustificare lo scaling.

Scalabilità dell'utilizzo della memoria

Per determinare quando scalare in base alla memoria utilizzata, monitora le metriche /cluster/memory/average_utilization e /cluster/memory/maximum_utilization. Per saperne di più su queste metriche, consulta Metriche di monitoraggio supportate.

Se il cluster soddisfa una delle seguenti condizioni, valuta la possibilità di attivare un'operazione di scalabilità orizzontale:

• L'utilizzo medio della memoria del cluster supera la soglia suggerita del 70%.
• L'utilizzo massimo della memoria supera l'80% e l'utilizzo medio della memoria supera il 50%.

Se il tuo cluster soddisfa una delle seguenti condizioni, valuta la possibilità di attivare un'operazione di riduzione:

• L'utilizzo medio della memoria del cluster scende al di sotto della soglia suggerita del 50%.
• L'utilizzo massimo della memoria scende al di sotto del 60% e l'utilizzo medio della memoria scende al di sotto del 40%.

Scalabilità dell'utilizzo della CPU

Per determinare quando scalare in base all'utilizzo della CPU, monitora le metriche /cluster/cpu/average_utilization e /cluster/cpu/maximum_utilization.

Se il cluster soddisfa una delle seguenti condizioni, valuta la possibilità di attivare un'operazione di scalabilità orizzontale:

• L'utilizzo medio della CPU del cluster supera la soglia suggerita del 70%.
• L'utilizzo massimo della CPU supera l'80% e l'utilizzo medio della CPU supera il 50%.

Se il tuo cluster soddisfa una delle seguenti condizioni, valuta la possibilità di attivare un'operazione di riduzione:

• L'utilizzo medio della CPU del cluster scende al di sotto della soglia suggerita del 50%.
• L'utilizzo massimo della CPU scende al di sotto del 60% e l'utilizzo medio della CPU scende al di sotto del 40%.

Scalabilità per mitigare gli hotspot

Memorystore for Redis Cluster fornisce variazioni medie e massime della stessa metrica, che puoi utilizzare per identificare gli hotspot per quella famiglia di metriche. Il valore massimo rappresenta il nodo del cluster più carico, mentre il valore medio rappresenta il carico per l'intero cluster. Se il valore massimo è significativamente superiore al valore medio, significa che un nodo specifico è caricato in modo sproporzionato (un hotspot). Per risolvere il problema, ti consigliamo di fare lo scale out del cluster. Per saperne di più, vedi Scalare la capacità dell'istanza.

Quando osservi una divergenza significativa tra le variazioni medie e massime, puoi eseguire i comandi INFO memory e INFO cpu sui nodi del cluster per raccogliere dati in tempo reale direttamente dal cluster. Per saperne di più sull'utilizzo di questi comandi, consulta INFO nella documentazione di Redis.

Best practice per il client Redis

Quando si connette a un cluster, l'applicazione deve utilizzare un client Redis compatibile con i cluster. Per esempi di client compatibili con i cluster e configurazioni di esempio, consulta Esempi di codice della libreria client. Il client deve mantenere una mappa degli slot hash ai nodi corrispondenti nel cluster per inviare le richieste ai nodi giusti ed evitare l'overhead delle prestazioni causato dai reindirizzamenti del cluster.

Mapping client

I clienti devono ottenere un elenco completo di slot e dei nodi mappati nelle seguenti situazioni:

• Quando il client viene inizializzato, deve compilare la mappatura iniziale degli slot ai nodi.

• Quando viene ricevuto un reindirizzamento MOVED dal server, ad esempio in caso di failover quando tutti gli slot gestiti dal nodo primario precedente vengono rilevati dalla replica o di ripartizionamento quando gli slot vengono spostati dal nodo primario di origine a quello di destinazione.

• Quando viene ricevuto un errore CLUSTERDOWN dal server o le connessioni a un determinato server vanno in timeout in modo persistente.

• Quando il server restituisce un errore READONLY. Ciò può accadere quando un primario viene declassato a replica.

• Inoltre, i client devono aggiornare periodicamente la topologia per mantenere i client pronti per eventuali modifiche e conoscere quelle che potrebbero non comportare reindirizzamenti o errori dal server, ad esempio quando vengono aggiunti nuovi nodi di replica. Tieni presente che anche le connessioni obsolete devono essere chiuse nell'ambito dell'aggiornamento della topologia per ridurre la necessità di gestire le connessioni non riuscite durante l'esecuzione dei comandi.

Ricerca di clienti

Il rilevamento del client viene in genere eseguito inviando un comando CLUSTER SLOT, CLUSTER NODE o CLUSTER SHARDS al server Redis. Ti consigliamo di utilizzare il comando CLUSTER SHARDS. CLUSTER SHARDS sostituisce il comando CLUSTER SLOTS (ritirato) fornendo una rappresentazione più efficiente ed estensibile del cluster.

Le dimensioni della risposta per i comandi di rilevamento dei client del cluster possono variare in base alle dimensioni e alla topologia del cluster. I cluster più grandi con più nodi producono una risposta più grande. Di conseguenza, è importante assicurarsi che il numero di client che eseguono l'individuazione della topologia del cluster non aumenti senza limiti.

Questi aggiornamenti della topologia sono costosi sul server Redis, ma sono anche importanti per la disponibilità dell'applicazione. Pertanto, è importante assicurarsi che ogni client effettui una singola richiesta di rilevamento in un determinato momento (e memorizzi nella cache il risultato in memoria) e che il numero di client che effettuano le richieste sia limitato per evitare di sovraccaricare il server.

Ad esempio, quando l'applicazione client si avvia o perde la connessione dal server e deve eseguire il rilevamento del cluster, un errore comune è che l'applicazione client effettua diverse richieste di riconnessione e rilevamento senza aggiungere il backoff esponenziale al nuovo tentativo. Ciò può rendere il server Redis non reattivo per un periodo di tempo prolungato, causando un utilizzo della CPU molto elevato.

Evitare il sovraccarico di rilevamento su Redis

Per ridurre l'impatto causato da un improvviso afflusso di richieste di connessione e rilevamento, ti consigliamo di procedere nel seguente modo:

• Implementa un pool di connessioni client con dimensioni finite e ridotte per limitare il numero di connessioni in entrata simultanee dall'applicazione client.

• Quando il client si disconnette dal server a causa del timeout, riprova con backoff esponenziale con jitter. In questo modo si evita che più client sovraccarichino il server contemporaneamente.

• Utilizza l'endpoint di rilevamento di Memorystore for Redis Cluster per eseguire il rilevamento del cluster. L'endpoint di rilevamento è a disponibilità elevata e il bilanciamento del carico viene eseguito su tutti i nodi del cluster. Inoltre, l'endpoint di rilevamento tenta di indirizzare le richieste di rilevamento del cluster ai nodi con la visualizzazione della topologia più aggiornata.

Rilevare e gestire le connessioni che non rispondono

Ti consigliamo vivamente di configurare l'applicazione client in modo che rilevi le connessioni non rispondenti a Memorystore for Redis Cluster. Quando viene rilevata una connessione che non risponde, il client deve ripristinarla. Per creare un'applicazione resiliente, ti consigliamo le seguenti configurazioni client:

• Configura i parametri TCP keep-alive: imposta i parametri TCP keepalive time, TCP keepalive interval e TCP keepalive probes in modo che i client rilevino e interrompano le connessioni che non rispondono in modo proattivo, anche quando le connessioni sono inattive. Ad esempio, se imposti il parametro TCP keepalive time su 30 secondi, TCP keepalive interval su 10 secondi e TCP keepalive probes su 3, i client reimpostano le connessioni inattive che non rispondono entro un minuto.
• Configura i timeout utente TCP: imposta questo timeout nei client per reimpostare le connessioni con richieste in sospeso e interrompere la risposta. Ad esempio, se imposti il timeout su 15 secondi, i client reimpostano le connessioni che non rispondono e che hanno richieste in sospeso dopo 15 secondi.

Best practice per la persistenza

Questa sezione illustra le best practice per la persistenza.

Persistenza RDB e aggiunta di repliche

Per ottenere i migliori risultati del backup del cluster con snapshot RDB o dell'aggiunta di repliche al cluster, utilizza le seguenti best practice:

Gestione della memoria

Gli snapshot RDB utilizzano un fork di processo e un meccanismo di "copy-on-write" per acquisire uno snapshot dei dati del nodo. A seconda del pattern di scrittura nei nodi, la memoria utilizzata dei nodi aumenta man mano che vengono copiate le pagine toccate dalle scritture. Il footprint della memoria può essere fino al doppio delle dimensioni dei dati nel nodo.

Per garantire che i nodi abbiano memoria sufficiente per completare lo snapshot, mantieni o imposta maxmemory all'80% della capacità del nodo, in modo che il 20% sia riservato all'overhead. Questo overhead di memoria, oltre agli snapshot di monitoraggio, ti aiuta a gestire il workload per avere snapshot riusciti. Inoltre, quando aggiungi repliche, riduci il traffico di scrittura il più possibile. Per saperne di più, consulta Monitorare un cluster con un carico di scrittura elevato.

Nota: se aggiungi una replica a un cluster che utilizza più dell'80% della memoria massima del cluster, l'operazione non va a buon fine e ricevi un messaggio di errore.

Per risolvere il problema, riduci la memoria utilizzata del cluster in uno dei seguenti modi:

• Riduci il footprint della memoria del cluster a meno dell'80% della memoria massima consentita del nodo.
• Scala il tipo di nodo per il cluster in modo che abbia più memoria.

Una volta che la memoria utilizzata del cluster è inferiore alla soglia dell'80%, aggiungi di nuovo la replica.

Snapshot obsoleti

Il recupero dei nodi da un'istantanea obsoleta può causare problemi di rendimento per la tua applicazione, in quanto tenta di riconciliare una quantità significativa di chiavi obsolete o altre modifiche al database, ad esempio una modifica dello schema. Se ti preoccupa il recupero da uno snapshot obsoleto, puoi disattivare la funzionalità di persistenza RDB. Una volta riattivata la persistenza, viene creato uno snapshot al successivo intervallo di snapshot pianificato.

Impatto sul rendimento degli snapshot RDB

A seconda del pattern del carico di lavoro, gli snapshot RDB possono influire sulle prestazioni del cluster e aumentare la latenza delle applicazioni. Puoi ridurre al minimo l'impatto sul rendimento degli snapshot RDB pianificandone l'esecuzione durante i periodi di basso traffico del cluster, se preferisci snapshot meno frequenti.

Ad esempio, se il tuo cluster ha un traffico basso dalle 01:00 alle 04:00, puoi impostare l'ora di inizio alle 03:00 e l'intervallo a 24 ore.

Se il tuo sistema ha un carico costante e richiede snapshot frequenti, devi valutare attentamente l'impatto sulle prestazioni e soppesare i vantaggi dell'utilizzo degli snapshot RDB per il workload.

Aggiungere una replica

L'aggiunta di una replica richiede uno snapshot RDB. Per saperne di più sugli snapshot RDB, consulta Gestione della memoria.

Quando utilizzare un cluster a zona singola

Se configuri un cluster in modo che non utilizzi repliche, ti consigliamo di utilizzare un cluster a zona singola. Ecco perché:

Costo e rendimento

Se i tuoi obiettivi principali sono ridurre al minimo i costi e ottenere le massime prestazioni per i client che si trovano nella stessa regione, ti consigliamo di scegliere un cluster a zona singola.

Ridurre al minimo l'impatto dell'interruzione

Quando scegli un cluster a zona singola, le interruzioni zonali hanno meno probabilità di influire sul cluster. Se posizioni tutti i nodi all'interno di una singola zona, la probabilità che un'interruzione zonale influisca sul tuo server scende dal 100% al 33%. Esiste una probabilità del 33% che la zona in cui si trova il cluster non sia disponibile, rispetto a una probabilità del 100% che i nodi, che si trovano nella zona non disponibile, siano interessati.

Recupero rapido

Se si verifica un'interruzione a livello di zona per un cluster a zona singola, Memorystore for Redis Cluster semplifica il recupero dei dati. Puoi eseguire il provisioning di un nuovo cluster in una zona funzionante rapidamente e reindirizzare l'applicazione per operazioni con interruzioni minime.

Best practice per Lettuce

Questa sezione descrive le best practice per l'utilizzo di Lettuce per connettersi a un cluster.

Aggiornare i valori dei parametri

Quando utilizzi Lettuce, modifica il parametro validateClusterNodeMembership in false. In caso contrario, quando la topologia cambia, potresti ricevere errori unknownPartition.

Abilita Transport Layer Security (TLS)

Questa sezione spiega i vantaggi in termini di sicurezza e le implicazioni sulle prestazioni dell'utilizzo di Transport Layer Security (TLS), oltre a fornire consigli per la sua attivazione.

Vantaggi di sicurezza

Utilizzando TLS, ottieni i seguenti vantaggi in termini di sicurezza:

• Autenticazione di gestione di identità e accessi (IAM): TLS utilizza questo tipo di autenticazione per proteggere dagli attacchi di spoofing del server, come gli attacchi person-in-the-middle.
• Crittografia in transito: la crittografia integrata diGoogle Cloudprotegge il traffico all'interno della rete di Google a livello di infrastruttura. Tuttavia, ciò comporta l'affidamento sia agli stack host che di rete di Google. Sebbene questa crittografia sia trasparente e attivata per impostazione predefinita, non sia end-to-end. D'altra parte, TLS utilizza la crittografia in transito a livello di applicazione. Questa crittografia end-to-end ti offre un maggiore controllo sulle chiavi e sui processi di crittografia.
• Protezione dei token di autenticazione: se utilizzi l'autenticazione IAM, l'attivazione di TLS riduce al minimo il rischio di esposizione e perdita dei token di autenticazione.

Implicazioni per il rendimento

TLS influisce sulle prestazioni nei seguenti modi:

• Stabilire connessioni: un client e un server che hanno stabilito una sessione TLS possono riprenderla senza ripetere il processo di stabilimento della connessione tra il client e il server, che richiede molte risorse. Se attivi la ripresa TLS, riduci il sovraccarico di stabilire una connessione tra il client e il server.

  Se non stabilisci la ripresa TLS, la creazione di connessioni richiede molte risorse. Per le connessioni nuove ed esistenti, molte connessioni tra il client e il server potrebbero causare timeout della connessione. Ciò può causare un effetto a catena perché Memorystore for Redis Cluster tenta di ristabilire le connessioni scadute, il che aumenta le risorse utilizzate per stabilire le connessioni.

• Cripta e decripta i dati: la crittografia e la decriptazione dei dati comportano operazioni che richiedono un uso intensivo della CPU e influiscono sia sul client che sul server. Ciò può ridurre la capacità del cluster e aumentare la latenza del cluster.

Consigli

Quando valuti se attivare TLS, ti consigliamo di valutare le tue norme di sicurezza tenendo conto dei vantaggi e degli svantaggi di TLS. Se scegli di abilitare TLS, tieni presente quanto segue:

• L'attivazione della ripresa TLS riduce l'overhead per stabilire le connessioni. Una connessione tra il client e il server è necessaria solo per la connessione iniziale. Tuttavia, un'improvvisa espansione delle dimensioni del cluster del client potrebbe comportare una breve interruzione causata dall'handshake completo iniziale di ogni nuovo host client.
• Sebbene alcune librerie client potrebbero non offrire controlli integrati per abilitare TLS, puoi utilizzare codice personalizzato per integrare questa funzionalità nei tuoi cluster.