Best practice per Memorystore for Redis Cluster

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

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

Best practice di gestione della memoria

Questa sezione descrive le strategie per la gestione della memoria dei 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 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.

• Policy di espulsione: Memorystore for Redis Cluster utilizza la policy di espulsione 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 è pari o inferiore al 100%, 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.

Monitora 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:

• Se /cluster/memory/maximum_utilization raggiunge il 65% o un valore superiore, potrebbero verificarsi problemi con carichi di scrittura molto elevati.

• I carichi di scrittura moderatamente elevati possono riscontrare problemi se /cluster/memory/maximum_utilization raggiunge l'85% o un valore superiore.

In questi scenari, devi aumentare le dimensioni del cluster per migliorare le prestazioni.

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

Scala shard

Quando scali il numero di shard in un cluster, devi farlo durante i periodi di scrittura ridotta. La scalabilità durante periodi di carico di scrittura elevato può esercitare una pressione sulla memoria del cluster a causa dell'overhead di memoria causato dalla replica o dalla migrazione degli slot.

Se il tuo caso d'uso di Redis utilizza le espulsioni delle chiavi, lo scale down a un cluster di dimensioni inferiori 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 fare lo scale down solo a un cluster più piccolo che abbia ancora spazio sufficiente per i tuoi dati. Il nuovo numero di shard target deve consentire almeno 1,5 volte la memoria utilizzata dai dati. In altre parole, devi eseguire il provisioning di un numero di shard sufficiente per 1,5 volte la quantità di dati nel cluster. Puoi utilizzare la metrica /cluster/memory/total_used_memory per vedere quanti dati sono archiviati nel tuo cluster.

Best practice per l'utilizzo della CPU

Se si verifica un'interruzione imprevista a livello di zona, le risorse della CPU per il tuo cluster vengono ridotte a causa della perdita di capacità dei nodi nella zona non disponibile. Ti consigliamo di utilizzare cluster ad alta affidabilità. 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, ti consigliamo di gestire l'utilizzo della CPU dei nodi in modo che abbiano un overhead della CPU sufficiente per gestire il traffico aggiuntivo proveniente dalla capacità persa in caso di interruzione imprevista a livello di zona. Devi monitorare l'utilizzo della CPU per le istanze principali e le repliche utilizzando la metrica Secondi CPU thread principale /cluster/cpu/maximum_utilization.

A seconda del numero di repliche di cui esegui il provisioning per nodo, ti consigliamo i seguenti target di utilizzo della CPU di /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 l'istanza principale e 0,5 secondi per la replica.
• Per i cluster con due o più repliche per nodo, scegli come target un valore /cluster/cpu/maximum_utilization di 0,9 secondi per la replica principale e di 0,5 secondi per ogni replica.

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

Se il cluster registra un utilizzo elevato della CPU o se 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 un uso intensivo delle 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 con risorse insufficienti

La tabella seguente elenca esempi di comandi Redis che richiedono un utilizzo intensivo delle risorse e fornisce alternative efficienti in termini di risorse.

Suggerimento: oltre a richiedere un uso intensivo delle risorse, con l'aumentare delle dimensioni totali dei dati, aumenta anche il costo di utilizzo di questi comandi.

Per scoprire quali comandi a lunga esecuzione utilizzi, usa SLOWLOG. Questo strumento fornisce un elenco dei comandi che richiedono più tempo per l'esecuzione. In questo modo, saprai quali comandi causano problemi di latenza. Per determinare alternative efficienti in termini di risorse per questi comandi, consulta la tabella seguente.

Category	Comando che richiede un utilizzo intensivo delle risorse	Alternativa efficiente in termini di risorse
Esegui per l'intero keyspace	KEYS	SCAN
Esegui per un set di chiavi 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
Blocca l'esecuzione di uno script	EVAL	Assicurati che lo script non venga eseguito a tempo indeterminato.
	EVALSHA	Assicurati che lo script non venga eseguito a tempo indeterminato.
Rimuovi file e link	DEL	UNLINK
Pubblica e sottoscrivi	PUBLISH	SPUBLISH
	SUBSCRIBE	SSUBSCRIBE

Best practice per le soglie di scalabilità

Gli scenari relativi alle soglie 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 workload si basa sull'eliminazione delle chiavi, Google sconsiglia lo scale in per l'utilizzo della CPU o della memoria. In questi workload, l'utilizzo della memoria raggiunge spesso la capacità massima prima che le espulsioni avvengano automaticamente. I picchi di memoria risultanti bloccano le operazioni di scale in.

Le sezioni seguenti descrivono in dettaglio gli scenari comuni e le soglie delle metriche che potrebbero giustificare la scalabilità.

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 tuo cluster soddisfa una delle seguenti condizioni, valuta la possibilità di attivare un'operazione di scale out:

• 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 scale in:

• 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 tuo cluster soddisfa una delle seguenti condizioni, valuta la possibilità di attivare un'operazione di scale out:

• 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 scale in:

• 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 con il carico più elevato, mentre il valore medio rappresenta il carico dell'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ù, consulta Scala la capacità del cluster.

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 i client Redis

L'applicazione deve utilizzare un client Redis compatibile con i cluster quando si connette a un cluster. Per esempi di client sensibili ai 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 richieste ai nodi corretti ed evitare l'overhead delle prestazioni causato dai reindirizzamenti del cluster.

Mappatura dei client

I client devono ottenere un elenco completo degli slot e dei nodi mappati nelle seguenti situazioni:

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

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

• Quando il server restituisce un errore CLUSTERDOWN o le connessioni a un determinato server vanno costantemente in timeout.

• Quando il server restituisce un errore READONLY. Questo può accadere quando un'istanza principale viene retrocessa a replica.

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

Scoperta dei clienti

Il rilevamento dei 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.

La dimensione della risposta per i comandi di rilevamento dei client del cluster può 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 il rilevamento della topologia del cluster non cresca in modo illimitato.

Questi aggiornamenti della topologia sono onerosi per il server Redis, ma sono anche importanti per la disponibilità dell'applicazione. Pertanto, è importante assicurarsi che ogni client effettui una singola richiesta di discovery 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 con il 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 molto elevato della CPU.

Evita il sovraccarico di rilevamento su Redis

Per mitigare l'impatto causato da un improvviso afflusso di richieste di connessione e rilevamento, ti consigliamo di:

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

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

• Utilizza l'endpoint di discovery di Memorystore for Redis Cluster per eseguire il discovery del cluster. L'endpoint di rilevamento è ad alta affidabilità e il carico è bilanciato su tutti i nodi del cluster. Inoltre, l'endpoint di rilevamento tenta di instradare le richieste di rilevamento del cluster ai nodi con la visualizzazione della topologia più aggiornata.

Rileva e gestisci le connessioni che non rispondono

Ti consigliamo vivamente di configurare l'applicazione client in modo che rilevi le connessioni non reattive a Memorystore for Redis Cluster. Quando viene rilevata una connessione che non risponde, il client deve reimpostarla. 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 in modo proattivo le connessioni che non rispondono, anche quando 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 dal backup del cluster con snapshot RDB o dall'aggiunta di repliche al cluster, utilizza le seguenti best practice:

Gestione della memoria

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

Per assicurarti che i nodi dispongano di 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 al monitoraggio degli snapshot, ti aiuta a gestire il workload per ottenere snapshot corretti. Inoltre, quando aggiungi repliche, riduci il più possibile il traffico di scrittura. Per saperne di più, consulta Monitora 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 dal 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 del cluster in modo che abbia più memoria.

Quando la memoria utilizzata dal cluster è inferiore alla soglia dell'85%, aggiungi nuovamente la replica.

Snapshot obsoleti

Il recupero dei nodi da uno snapshot obsoleto può causare problemi di prestazioni per l'applicazione, che tenta di riconciliare una quantità significativa di chiavi obsolete o altre modifiche al database, ad esempio una modifica dello schema. Se temi di dover eseguire il recupero da uno snapshot obsoleto, puoi disattivare la funzionalità di persistenza RDB. Una volta riattivata la persistenza, viene acquisito uno snapshot al successivo intervallo di snapshot pianificato.

Impatto sulle prestazioni degli snapshot RDB

A seconda del pattern del workload, gli snapshot RDB possono influire sulle prestazioni del cluster e aumentare la latenza per le tue applicazioni. Puoi ridurre al minimo l'impatto sulle prestazioni degli snapshot RDB pianificandone l'esecuzione durante i periodi di traffico ridotto del cluster, se preferisci snapshot meno frequenti.

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

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

Aggiungi 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 i possibili motivi:

Costo e prestazioni

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

Riduci al minimo l'impatto dell'interruzione

Quando scegli un cluster a zona singola, è meno probabile che le interruzioni a livello di zona influiscano sul tuo cluster. Posizionando tutti i nodi in un'unica zona, la probabilità che un'interruzione della zona 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

In caso di interruzione a livello di zona per un cluster a zona singola, Memorystore for Redis Cluster semplifica il recupero dei dati. Puoi eseguire rapidamente il provisioning di un nuovo cluster in una zona funzionante e reindirizzare l'applicazione per ridurre al minimo le interruzioni delle operazioni.

Best practice per la pianificazione della capacità

Per assicurarti di poter eseguire correttamente il provisioning delle risorse e creare architetture resilienti, ti consigliamo di seguire queste best practice per la pianificazione della capacità:

• Esegui il deployment in più località: se non riesci a creare un cluster nella tua zona preferita a causa di vincoli temporanei delle risorse, prova a creare il cluster in un'altra zona all'interno della stessa regione o in un'altra regione.
• Utilizza l'accesso tra regioni: configura i client in modo che accedano ai cluster che si trovano in regioni diverse. Se devi eseguire il provisioning di un cluster che si trova in un'altra regione a causa di vincoli delle risorse locali, i tuoi client possono connettersi al cluster.
• Utilizza la replica tra regioni: per promuovere un cluster secondario in una regione alternativa a un cluster di lettura o scrittura principale per il ripristino di emergenza, esegui un cambio.

Best practice per l'insalata

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

Aggiorna 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

L'utilizzo di TLS offre i seguenti vantaggi in termini di sicurezza:

• Autenticazione Identity and Access Management (IAM): TLS utilizza questo tipo di autenticazione per proteggersi 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ò implica l'affidamento sia agli stack di host che agli stack di rete di Google. Sebbene questa crittografia sia trasparente e abilitata per impostazione predefinita, non è end-to-end. TLS, invece, 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'abilitazione di TLS riduce al minimo il rischio di esposizione e fuga dei token di autenticazione.

Implicazioni sulle prestazioni

TLS influisce sulle prestazioni nei seguenti modi:

• Stabilisci le connessioni: un client e un server che hanno stabilito una sessione TLS possono riprenderla senza ripetere il processo ad alta intensità di risorse per stabilire la connessione tra il client e il server. Se attivi la ripresa TLS, riduci l'overhead per stabilire una connessione tra il client e il server.

  Se non configuri la ripresa TLS, la creazione delle connessioni richiede molte risorse. Sia per le connessioni nuove che per quelle esistenti, un numero elevato di connessioni tra il client e il server potrebbe 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 ad alta intensità di CPU che influiscono sia sul client che sul server. Ciò può ridurre la capacità del cluster e aumentarne la latenza.

Consigli

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

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