Best practice per Memorystore for Valkey

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

Best practice di gestione della memoria

Questa sezione descrive le strategie per gestire la memoria delle istanze in modo che Memorystore for Valkey funzioni in modo efficiente per la tua applicazione.

Concetti di gestione della memoria

• Utilizzo della memoria: la quantità di memoria utilizzata dall'istanza. Hai una capacità di memoria fissa. Puoi utilizzare le metriche per monitorare la quantità di memoria che stai utilizzando.

• Criteri di rimozione: Memorystore for Valkey utilizza i criteri di rimozione volatile-lru. Puoi utilizzare i comandi Valkey come il comando EXPIRE per impostare le espulsioni per le chiavi.

Monitorare l'utilizzo della memoria per un'istanza

Per monitorare l'utilizzo della memoria per un'istanza Memorystore for Valkey, ti consigliamo di visualizzare la metrica /instance/memory/maximum_utilization. Se l'utilizzo della memoria dell'istanza si avvicina all'80% e prevedi che l'utilizzo dei dati aumenterà, allora aumenta le dimensioni dell'istanza per fare spazio a nuovi dati.

Se l'istanza ha un utilizzo elevato della memoria, segui questi passaggi per migliorare le prestazioni:

• Aumenta le dimensioni dell'istanza.
• Diminuisci il parametro di configurazione maxmemory.

Se riscontri problemi, contatta l'Google Cloud assistenza clienti.

Scalabilità degli shard in modalità cluster abilitata

Quando aumenti il numero di shard in un'istanza, ti consigliamo di farlo durante i periodi di scrittura ridotta. Lo scaling durante i periodi di utilizzo elevato può esercitare pressione sulla memoria dell'istanza a causa del sovraccarico di memoria causato dalla replica o dalla migrazione degli slot.

Se il tuo caso d'uso di Valkey utilizza le espulsioni di chiavi, il ridimensionamento a una dimensione dell'istanza più piccola può ridurre il percentuale successi cache. In questo caso, tuttavia, non devi preoccuparti di perdere dati, poiché l'eliminazione della chiave è prevista.

Per i casi d'uso di Valkey in cui non vuoi perdere le chiavi, devi eseguire fare lo scale down solo a un'istanza più piccola che abbia ancora spazio sufficiente per i tuoi dati. Il nuovo conteggio di partizioni 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 sufficiente per 1,5 volte la quantità di dati attualmente presenti nella tua istanza. Puoi utilizzare la metrica /instance/memory/total_used_memory per visualizzare la quantità di dati archiviati nella tua istanza.

Best practice per l'utilizzo della CPU

Se si verifica un'interruzione del servizio imprevista a livello di zona, le risorse CPU per l'istanza vengono ridotte a causa della capacità persa dai nodi nella zona non disponibile. Ti consigliamo di utilizzare istanze a disponibilità elevata. L'utilizzo di due repliche per shard (anziché una replica per shard) fornisce risorse CPU aggiuntive durante un'interruzione. 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 /instance/cpu/maximum_utilization.

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

• Per le istanze con una replica per nodo, devi impostare un valore /instance/cpu/maximum_utilization di 0,5 secondi per l'istanza principale e la replica.
• Per le istanze con 2 repliche per nodo, devi impostare un valore /instance/cpu/maximum_utilization di 0,9 secondi per la replica primaria e di 0,5 secondi per le repliche.

Se i valori della metrica superano questi consigli, ti consigliamo di aumentare il numero di shard o repliche nella tua istanza.

Comandi Valkey che richiedono molte risorse

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

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

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

Category	Comando che richiede molte risorse	Alternativa efficiente in termini di risorse
Esegui per l'intero spazio delle chiavi	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	DELETE	UNLINK
Pubblica e iscriviti	PUBLISH	SPUBLISH
	SUBSCRIBE	SSUBSCRIBE

Best practice per il client Valkey

Evita il sovraccarico di connessioni su Valkey

Per ridurre l'impatto causato da un improvviso afflusso di connessioni, ti consigliamo di procedere nel seguente modo:

• Determina le dimensioni del pool di connessioni client più adatte a te. Una buona dimensione iniziale per ogni client è una connessione per nodo Valkey. Puoi quindi eseguire il benchmark per verificare se un numero maggiore di connessioni è utile senza saturare il numero massimo consentito di connessioni.

• Quando il client si disconnette dal server perché il server va in timeout, riprova con exponential backoff con jitter. In questo modo si evita che più client sovraccarichino il server contemporaneamente.

Per le istanze con modalità cluster abilitata

Quando si connette a un'istanza Memorystore per Valkey con la modalità cluster abilitata, l'applicazione deve utilizzare un client Valkey compatibile con il 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 nell'istanza per inviare le richieste ai nodi corretti. In questo modo si evita l'overhead delle prestazioni causato dai reindirizzamenti.

Mappatura client

I clienti 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 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 ripartizione 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 costantemente in timeout.

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

• Inoltre, i client devono aggiornare periodicamente la topologia per mantenerli attivi per eventuali modifiche e per conoscere quelle che potrebbero non comportare reindirizzamenti/ 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 del comando.

Ricerca di clienti

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

Le dimensioni della risposta per i comandi di rilevamento del client possono variare in base alle dimensioni e alla topologia dell'istanza. Le istanze 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 dei nodi non aumenti senza limiti.

Questi aggiornamenti della topologia dei nodi sono costosi sul server Valkey, ma sono anche importanti per la disponibilità delle applicazioni. 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 dei nodi, 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 Valkey non reattivo per un periodo di tempo prolungato, causando un utilizzo della CPU molto elevato.

Utilizza un endpoint di rilevamento per il rilevamento dei nodi

Utilizza l'endpoint di rilevamento di Memorystore for Valkey per eseguire il rilevamento dei nodi. L'endpoint di rilevamento è a disponibilità elevata e il carico è bilanciato su tutti i nodi dell'istanza. Inoltre, l'endpoint di rilevamento tenta di instradare le richieste di rilevamento dei nodi a nodi con la visualizzazione della topologia più aggiornata.

Per le istanze con modalità cluster disabilitata

Quando si connette a un'istanza con modalità cluster disattivata, l'applicazione deve connettersi all'endpoint principale per scrivere nell'istanza e recuperare le scritture più recenti. La tua applicazione può anche connettersi all'endpoint del lettore per leggere dalle repliche e isolare il traffico dal nodo primario.

Best practice per la persistenza

Questa sezione illustra le best practice per la persistenza.

Persistenza RDB

Per ottenere risultati ottimali dal backup dell'istanza con gli snapshot RDB, devi utilizzare le seguenti best practice:

Gestione della memoria

Gli snapshot RDB utilizzano un fork del 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. Nel caso peggiore, l'impronta di memoria può essere il doppio della dimensione dei dati nel nodo.

Per garantire che i nodi abbiano memoria sufficiente per completare lo snapshot, devi mantenere o impostare maxmemory all'80% della capacità del nodo, in modo che il 20% sia riservato all'overhead. Per ulteriori informazioni, vedi Monitorare l'utilizzo della memoria per un'istanza. Questo overhead di memoria, oltre agli snapshot di Monitoring, ti aiuta a gestire il carico di lavoro per avere snapshot riusciti.

Snapshot obsoleti

Il recupero di 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 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 sulle prestazioni degli snapshot RDB

A seconda del pattern del carico di lavoro, gli snapshot RDB possono influire sul rendimento dell'istanza e aumentare la latenza delle applicazioni. Se accetti snapshot meno frequenti, puoi ridurre al minimo l'impatto sul rendimento degli snapshot RDB pianificandone l'esecuzione durante i periodi di basso traffico delle istanze.

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

Scegli un'istanza a zona singola se la tua istanza non utilizza repliche

Quando configuri un'istanza senza repliche, ti consigliamo un'architettura a zona singola per una maggiore affidabilità. Ecco perché:

Ridurre al minimo l'impatto dell'interruzione del servizio

È meno probabile che le interruzioni a livello di zona influiscano sulla tua istanza. 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%. Questo perché c'è una probabilità del 33% che la zona in cui si trova la tua istanza non sia disponibile, rispetto al 100% di probabilità che i nodi che si trovano nella zona non disponibile siano interessati.

Recupero rapido

In caso di interruzione a livello di zona, il ripristino viene semplificato. Puoi rispondere eseguendo rapidamente il provisioning di una nuova istanza in una zona funzionante e reindirizzando l'applicazione per operazioni con interruzioni minime.