Best practice per Memorystore for Valkey

Questa pagina fornisce indicazioni sull'utilizzo ottimale di Memorystore for Valkey. 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 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 eliminazione: Memorystore for Valkey utilizza la volatile-lru policy di eliminazione. Puoi utilizzare i comandi Valkey come il comando EXPIRE per impostare le eliminazioni 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 ai nuovi dati.

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

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

Scalare gli shard in modalità cluster abilitata

Quando aumenti il numero di shard in un'istanza, ti consigliamo di farlo durante i periodi di bassa scrittura. La scalabilità durante i periodi di utilizzo elevato può 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 Valkey utilizza le eliminazioni delle chiavi, la scalabilità a una dimensione dell'istanza più piccola può ridurre la percentuale successi cache. In questo caso, tuttavia, non devi preoccuparti di perdere i dati, poiché l'eliminazione delle chiavi è prevista.

Per i casi d'uso di Valkey in cui non vuoi perdere le chiavi, devi ridurre le dimensioni dell'istanza solo a una più piccola che abbia 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 nell'istanza. Puoi utilizzare la metrica /instance/memory/total_used_memory per vedere la quantità di dati archiviati nell'istanza.

Best practice per l'utilizzo della CPU

Se si verifica un'interruzione zonale imprevista, le risorse CPU dell'istanza vengono ridotte a causa della perdita di capacità dei 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 di CPU sufficiente per gestire il traffico aggiuntivo dovuto alla perdita di capacità in caso di interruzione zonale imprevista. Devi monitorare l'utilizzo della CPU per i nodi primari e le repliche utilizzando la metrica Secondi CPU del thread principale /instance/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 /instance/cpu/maximum_utilization:

  • Per le istanze con una replica per nodo, imposta un valore /instance/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 /instance/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.

Se l'istanza presenta un utilizzo elevato della CPU o le risorse dell'istanza si esauriscono (ad esempio, a causa di un numero eccessivo di connessioni), l'istanza potrebbe non funzionare correttamente e le metriche esterne potrebbero mancare.

Comandi Valkey che richiedono molte risorse

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

La tabella seguente elenca alcuni esempi di comandi Valkey 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 DELETE UNLINK
Publish and subscribe PUBLISH SPUBLISH
SUBSCRIBE SSUBSCRIBE

Best practice per il client Valkey

Evitare il sovraccarico di connessioni su Valkey

Per mitigare l'impatto causato da un improvviso afflusso di connessioni, ti consigliamo di:

  • 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 numero maggiore di connessioni è utile senza saturare il numero massimo di connessioni consentite.

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

Rilevare e gestire le connessioni che non rispondono

Ti consigliamo vivamente di configurare l'applicazione client in modo che rilevi le connessioni che non rispondono a Memorystore for Valkey. 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 di keep-alive TCP: imposta i parametri TCP keepalive time, TCP keepalive interval e TCP keepalive probes in modo che i client rilevino e abbandonino in modo proattivo le connessioni che non rispondono, 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 con richieste in sospeso dopo 15 secondi.

Per le istanze con modalità cluster abilitata

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

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 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 vanno in 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 mantenerli 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 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 (deprecato) fornendo una rappresentazione più efficiente ed estensibile dell'istanza.

Le dimensioni della risposta per i comandi di rilevamento 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 il rilevamento 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à 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 viene avviata 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 un 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.

Utilizzare 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 è ad alta disponibilità e il carico è bilanciato su tutti i nodi dell'istanza. Inoltre, l'endpoint di rilevamento tenta di instradare le richieste di rilevamento dei nodi ai nodi con la visualizzazione della topologia più aggiornata.

Per le istanze con modalità cluster disabilitata

Quando ti connetti a un'istanza con modalità cluster disabilitata, l'applicazione deve connettersi all'endpoint primario 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 primario.

Se utilizzi la strategia creazione prima dell'eliminazione 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 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 'copy-on-write' mechanism 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 ulteriori informazioni, consulta Monitorare l'utilizzo della memoria per un'istanza.

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

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

Ridurre al minimo l'impatto delle interruzioni

Quando scegli un'istanza a zona singola, è meno probabile che le interruzioni zonali influiscano sull'istanza. Se posizioni tutti i nodi all'interno di una singola zona, la probabilità che un'interruzione zonale influisca sul server scende dal 100% al 33%. Esiste una probabilità del 33% che la zona in cui si trova l'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 rapidamente il provisioning di una nuova istanza in una zona funzionante e reindirizzare l'applicazione per operazioni con interruzioni minime.

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), nonché i 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 all'host sia agli stack 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 di stabilire la connessione tra il client e il server, che richiede molte risorse. 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 sia per quelle esistenti, molte connessioni tra il client e il server potrebbero causare timeout di connessione. Questo può causare un effetto a catena perché Memorystore for Valkey tenta di ristabilire le connessioni in 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 sia sul server. Ciò può ridurre la capacità dell'istanza e aumentare la latenza dell'istanza.

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 di connessioni. È necessaria una connessione tra il client e il server solo per la connessione iniziale. Tuttavia, un'espansione improvvisa 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.