Best practice per Memorystore for Redis Cluster

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

Best practice di gestione della memoria

Questa sezione descrive le strategie per la gestione della memoria dell'istanza in modo che Memorystore for Redis Cluster funzioni in modo efficiente per la tua applicazione.

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.

  • Policy di eliminazione : Memorystore for Redis Cluster utilizza la volatile-lru policy di eliminazione. Puoi utilizzare comandi come EXPIRE per impostare le eliminazioni per le chiavi.

Monitorare un cluster con un carico di scrittura normale

Visualizza la /cluster/memory/maximum_utilization metrica. Se /cluster/memory/maximum_utilization è pari o inferiore al 100%, il cluster Redis funziona correttamente 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 /cluster/memory/maximum_utilization metrica. A seconda della gravità del carico di scrittura elevato, il cluster può riscontrare problemi di prestazioni alle seguenti soglie:

  • I carichi di scrittura molto elevati possono riscontrare problemi se /cluster/memory/maximum_utilization raggiunge il 65% o un valore superiore.

  • 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 fare lo scale up delle dimensioni del cluster per migliorare le prestazioni.

Se riscontri problemi o temi che la tua istanza abbia un carico di scrittura elevato, contatta Google Cloud l'assistenza.

Scalare gli shard

Quando aumenti il numero di shard in un'istanza, devi farlo durante i periodi di bassa scrittura. Se esegui lo scaling durante i periodi di carico di scrittura elevato, puoi esercitare una pressione sulla memoria dell'istanza a causa dell'overhead di memoria causato dalla replica o dalla migrazione degli slot.

Se il tuo caso d'uso di Redis utilizza le eliminazioni delle chiavi, lo scaling a dimensioni del cluster più piccole 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 ridurre le dimensioni del cluster solo se il cluster più piccolo ha ancora spazio sufficiente per i tuoi dati. Il nuovo conteggio degli shard di destinazione deve consentire almeno 1,5 volte la memoria utilizzata dai dati. In altre parole, devi eseguire il provisioning di un numero sufficiente di shard per 1,5 volte la quantità di dati nel cluster. Puoi utilizzare la metrica /cluster/memory/total_used_memory per vedere la quantità di dati archiviati in nell'istanza.

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 perdita di capacità dei 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, ti consigliamo di gestire l'utilizzo della CPU dei nodi in modo che i nodi abbiano un overhead di CPU sufficiente per gestire il traffico aggiuntivo dovuto alla perdita di capacità in caso di interruzione imprevista a livello di zona. Devi monitorare l'utilizzo della CPU per i nodi primari e le repliche utilizzando la metrica Secondi CPU del 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 /cluster/cpu/maximum_utilization:

  • Per le istanze con una replica per nodo, imposta un valore /cluster/cpu/maximum_utilization di 0,5 secondi per il nodo primario e 0,5 secondi per la replica.
  • Per le istanze con due o più repliche per nodo, imposta un valore /cluster/cpu/maximum_utilization di 0,9 secondi per il nodo primario e 0,5 secondi per ogni replica.

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

Comandi Redis che richiedono molte risorse

Ti consigliamo vivamente di evitare di utilizzare i 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 sulla 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 insufficienti

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

Category Resource-intensive command Resource-efficient alternative
Run for the entire keyspace KEYS SCAN
Run for a variable-length keyset LRANGE Limit the size of the range that you use for a query.
ZRANGE Limit the size of the range that you use for a query.
HGETALL HSCAN
SMEMBERS SSCAN
Block the running of a script EVAL Ensure that your script doesn't run indefinitely.
EVALSHA Ensure that your script doesn't run indefinitely.
Remove files and links DEL UNLINK
Publish and subscribe PUBLISH SPUBLISH
SUBSCRIBE SSUBSCRIBE

Best practice per il client Redis

Quando ti connetti a un'istanza di Memorystore for Redis Cluster, l'applicazione deve utilizzare un client Redis che riconosce il cluster. Per esempi di client che riconoscono il 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 corretti ed evitare l'overhead di prestazioni causato dai reindirizzamenti del cluster.

Mapping client

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

  • Quando il client viene inizializzato, deve popolare il mapping 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 acquisiti dalla replica o in caso di ripartizionamento quando gli slot vengono spostati dal nodo primario di origine al nodo primario di destinazione.

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

  • Quando viene ricevuto un errore READONLY dal server. Questo può accadere quando un nodo primario viene declassato a replica.

  • Inoltre, i client devono aggiornare periodicamente la topologia per mantenere i client attivi per eventuali modifiche e conoscere le modifiche che potrebbero non comportare reindirizzamenti o errori dal server, ad esempio quando vengono aggiunti nuovi nodi 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.

Rilevamento client

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 (deprecato) fornendo una rappresentazione più efficiente ed estensibile del cluster.

Le dimensioni della risposta per i comandi di rilevamento del 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 il rilevamento 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 un 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:

  • Implementa un pool di connessioni client con una dimensione finita e ridotta 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 un backoff esponenziale con jitter. In questo modo, più client non sovraccaricano il server contemporaneamente.

  • Utilizza l'endpoint di rilevamento di Memorystore for Redis Cluster per eseguire il rilevamento del cluster. L'endpoint di rilevamento è ad alta disponibilità e il bilanciamento del carico viene eseguito 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.

Best practice per la persistenza

Questa sezione illustra le best practice per la persistenza.

Persistenza RDB e aggiunta di repliche

Per ottenere risultati ottimali dal backup dell'istanza con gli snapshot RDB o dall'aggiunta di repliche all'istanza, segui queste best practice:

Gestione della memoria

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

Per assicurarti 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 al monitoraggio degli snapshot, ti aiuta a gestire il carico di lavoro per avere snapshot riusciti. Inoltre, quando aggiungi repliche, riduci il più possibile il traffico di scrittura. Per saperne di più, consulta Monitorare un cluster con un carico di scrittura elevato.

Snapshot obsoleti

Il recupero dei nodi da uno snapshot obsoleto può causare problemi di prestazioni per l'applicazione, in quanto tenta di riconciliare una quantità significativa di chiavi obsolete o altre modifiche al database, ad esempio una modifica dello schema. Se temi di recuperare 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 sulle prestazioni degli snapshot RDB

A seconda del pattern del carico di lavoro, gli snapshot RDB possono influire sulle prestazioni dell'istanza e aumentare la latenza delle applicazioni. Puoi ridurre al minimo l'impatto sulle prestazioni degli snapshot RDB pianificandone l'esecuzione durante i periodi di traffico ridotto dell'istanza, se non ti dispiace avere snapshot meno frequenti.

Ad esempio, se l'istanza 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 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 carico di lavoro.

Aggiungere una replica

L'aggiunta di una replica richiede uno snapshot RDB. Per ulteriori informazioni sugli snapshot RDB, consulta Gestione della memoria.

Quando utilizzare un cluster a zona singola

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

Costo e prestazioni

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

Ridurre al minimo l'impatto delle interruzioni

Quando scegli un cluster a zona singola, è meno probabile che le interruzioni a livello di zona influiscano sul cluster. Se posizioni tutti i nodi all'interno di una singola zona, la probabilità che un'interruzione a livello di zona influisca sul 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 rapidamente il provisioning di un nuovo cluster in una zona funzionante 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'istanza di Memorystore for Redis Cluster.

Aggiornare i valori dei parametri

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

Abilitare Transport Layer Security (TLS)

Questa sezione illustra i vantaggi in termini di sicurezza e le implicazioni per le prestazioni dell'utilizzo di Transport Layer Security (TLS), insieme ai consigli per la sua abilitazione.

Vantaggi di sicurezza

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

  • Autenticazione di Identity and Access Management (IAM): TLS utilizza questo tipo di autenticazione per proteggere dagli attacchi di spoofing del server, come gli attacchi man-in-the-middle.
  • Crittografia in transito: Google Cloud's built-in encryption protects traffic within Google's network at a livello di infrastruttura. Tuttavia, ciò comporta l'affidamento sia agli stack host che di rete di Google. Sebbene questa crittografia sia trasparente e abilitata per impostazione predefinita, non è 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'abilitazione di TLS riduce al minimo il rischio di esporre e perdere i token di autenticazione.

Implicazioni per le prestazioni

TLS influisce sulle prestazioni nei seguenti modi:

  • Stabilire connessioni: un client e un server che hanno stabilito una sessione TLS possono riprendere la sessione senza ripetere il processo che richiede molte risorse per stabilire la connessione tra il client e il server. Abilitando la ripresa TLS, riduci l'overhead della creazione di una connessione tra il client e il server.

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

  • Criptare e decriptare i dati: La crittografia e la decrittografia dei dati comportano operazioni che richiedono molta CPU e che influiscono sia sul client che sul server. Ciò può ridurre la capacità del cluster e aumentare la latenza del cluster.

Consigli

Quando valuti se abilitare TLS, ti consigliamo di valutare le tue policy di sicurezza tenendo conto dei vantaggi e degli svantaggi di TLS. Se scegli di abilitare TLS, tieni presente le seguenti considerazioni:

  • L'abilitazione della ripresa TLS riduce l'overhead per la creazione delle connessioni. È necessaria una connessione tra il client e il server 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 codice personalizzato per integrare questa funzionalità nei tuoi cluster.