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 dell'istanza 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.

  • Policy di sfratto: Memorystore for Valkey utilizza la policy di sfratto volatile-lru. Puoi utilizzare comandi Valkey come EXPIRE per impostare gli sfratti 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 fai lo scale up delle dimensioni dell'istanza per fare spazio a nuovi dati.

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

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 una 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 l'eliminazione delle chiavi, il ridimensionamento a una dimensione dell'istanza più piccola può ridurre la 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 solo scalare a un'istanza più piccola che abbia ancora spazio sufficiente per i tuoi dati. Il nuovo conteggio dei 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 nella tua istanza. Puoi utilizzare la metrica /instance/memory/total_used_memory per vedere quanti dati sono archiviati nella tua istanza.

Best practice per l'utilizzo della CPU

Se si verifica un'interruzione 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 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 della CPU sufficiente a 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, scegli come target un valore /instance/cpu/maximum_utilization di 0,5 secondi per la replica primaria e 0,5 secondi per la replica.
  • Per le istanze con due o più repliche per nodo, scegli un valore di /instance/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 suggerimenti, ti consigliamo di fare lo scale up del numero di shard nell'istanza. Se hai meno di cinque repliche per l'istanza, puoi anche aumentare il numero di repliche fino a un massimo di cinque.

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 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 Valkey è bloccato
  • Controlli di integrità, osservabilità e replica inattivi

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 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 DELETE UNLINK
Pubblica e sottoscrivi 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 benchmarking per verificare se un maggior numero 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 il backoff esponenziale con jitter. In questo modo si evita che più client sovraccarichino il server contemporaneamente.

Per le istanze con modalità cluster abilitata

Quando ci si connette a un'istanza Memorystore for 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 delle librerie 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.

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 viene ricevuto un errore READONLY dal server. Ciò può verificarsi 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

La scoperta del client viene solitamente eseguita inviando un comando SLOTS, NODES o CLUSTER SHARDS al server Valkey. Ti consigliamo di utilizzare il comando CLUSTER SHARDS, che sostituisce il comando SLOTS (ritirato) fornendo una rappresentazione più efficiente ed estensibile dell'istanza.CLUSTER SHARDS

Le dimensioni della risposta per i comandi di rilevamento dei client possono variare in base alle dimensioni e alla topologia dell'istanza. 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 il risultato nella 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 bilanciamento del carico viene eseguito su tutti i nodi dell'istanza. Inoltre, l'endpoint di rilevamento tenta di indirizzare le richieste di rilevamento dei nodi ai 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. L'applicazione può anche connettersi all'endpoint di lettura per leggere dalle repliche e isolare il traffico dal nodo principale.

Se utilizzi la strategia create-before-destroy quando esegui la manutenzione dell'istanza, potresti ricevere il seguente messaggio di errore:

READONLY You can't write against a read only replica.

Per risolvere il problema, interrompi la connessione all'istanza. Quindi, ricrea la connessione.

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 snapshot RDB o dall'aggiunta di repliche all'istanza, utilizza 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 le pagine toccate dalle scritture vengono copiate. 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 l'utilizzo della memoria per un'istanza.

Snapshot obsoleti

Il recupero di nodi da uno snapshot obsoleto può causare problemi di prestazioni 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 acquisito uno snapshot al successivo intervallo di snapshot pianificato.

Impatto sul rendimento degli snapshot RDB

A seconda del pattern del workload, 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 preferisci snapshot meno frequenti.

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, ti consigliamo di valutare attentamente l'impatto sulle prestazioni e di 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'istanza a una sola zona

Se configuri un'istanza in modo che non utilizzi repliche, ti consigliamo di utilizzare un'istanza 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 clienti che si trovano nella stessa regione, ti consigliamo di scegliere un'istanza a zona singola.

Ridurre al minimo l'impatto dell'interruzione

Quando scegli un'istanza a zona singola, è meno probabile che le interruzioni zonali 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%. Esiste una probabilità del 33% che la zona in cui si trova la tua istanza 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 zonale per un'istanza a zona singola, Memorystore for Valkey semplifica il recupero dei dati. Puoi eseguire il provisioning di una nuova istanza in una zona funzionante rapidamente e reindirizzare l'applicazione per operazioni con interruzioni minime.

Abilita Transport Layer Security (TLS)

Questa sezione illustra i vantaggi in termini di sicurezza e le implicazioni sulle prestazioni dell'utilizzo di Transport Layer Security (TLS), nonché i 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 host che agli stack di rete di Google. Sebbene questa crittografia sia trasparente e attivata 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 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 la procedura a elevato consumo di risorse per stabilire la connessione tra il client e il server. 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 Valkey 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à dell'istanza e aumentare la latenza dell'istanza.

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 il sovraccarico per stabilire le connessioni. Una connessione tra il client e il server è necessaria solo per la connessione iniziale. Tuttavia, un'improvvisa espansione delle dimensioni dell'istanza 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à nelle tue istanze.