Best practice generali

Questa pagina fornisce indicazioni per utilizzare al meglio 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

  • Carico di scrittura: il volume e la velocità con cui aggiungi o aggiorni le chiavi nell'istanza Valkey. Il carico di scrittura può variare da normale a molto elevato, a seconda del caso d'uso di Valkey e dei pattern di utilizzo dell'applicazione.

  • Criterio di espulsione: Memorystore for Valkey utilizza il criterio di espulsione volatile-lru. Puoi utilizzare i comandi Valkey, come il comando EXPIRE, per impostare gli sgomberi per le chiavi.

Monitoraggio di un'istanza con un normale carico di scrittura

Visualizza la metrica /instance/cpu/maximum_utilization. Se /instance/cpu/maximum_utilization è inferiore o uguale al 100%, l'istanza Valkey funziona bene quando utilizzi un normale carico di scrittura.

Tuttavia, se l'utilizzo della memoria si avvicina al 100% e prevedi che l'utilizzo dei dati aumenterà, devi aumentare le dimensioni dell'istanza per fare spazio ai nuovi dati.

Monitoraggio di un'istanza con un carico di scrittura elevato

Visualizza la metrica /instance/memory/maximum_utilization. A seconda della gravità del carico di scrittura elevato, l'istanza può presentare problemi di prestazioni alle seguenti soglie:

  • I carichi di scrittura molto elevati possono causare problemi se /instance/memory/maximum_utilization raggiunge il 65% o più.

  • I carichi di scrittura moderatamente elevati possono causare problemi se /instance/memory/maximum_utilization raggiunge l'85% o più.

In questi scenari, devi aumentare le dimensioni dell'istanza per migliorare il rendimento.

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

Shard di scalabilità

Quando esegui la scalabilità del numero di shard in un'istanza, devi eseguire la scalabilità durante i periodi di scrittura ridotta. Il ridimensionamento durante periodi di elevato carico di scrittura può causare una pressione sulla memoria dell'istanza a causa dell'overhead della memoria causato dalla replica o dalla migrazione degli slot.

Se il caso d'uso Valkey utilizza l'espulsione delle chiavi, la scalabilità a una dimensione dell'istanza più piccola può ridurre il percentuale successi cache. In questa circostanza, però, non devi preoccuparti di perdere dati, poiché l'espulsione delle chiavi è 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 numero di shard target deve consentire almeno 1,5 volte la memoria utilizzata dai dati. In altre parole, devi eseguire il provisioning di frammenti sufficienti per 1,5 volte la quantità di dati attualmente presente 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 del servizio in una zona imprevista, le risorse della 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 due repliche per shard (anziché una) fornisce risorse CPU aggiuntive durante un'interruzione del servizio. 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 derivante dalla perdita di capacità in caso di interruzione zonale imprevista. Devi monitorare l'utilizzo della CPU per le principali e le repliche utilizzando la metrica Secondi CPU thread principale /instance/cpu/maximum_utilization.

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

  • Per le istanze con una replica per nodo, devi scegliere come target un valore /instance/cpu/maximum_utilization di 0,5 secondi per la principale e la replica.
  • Per le istanze con due repliche per nodo, devi scegliere come target un valore /instance/cpu/maximum_utilization di 0,9 secondi per la principale e 0,5 secondi per le repliche.

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

Comandi Valkey che richiedono molta CPU

Evita di utilizzare comandi Valkey che sono costosi da eseguire per vari motivi. Questa sezione fornisce esempi di motivi per cui alcuni comandi sono costosi, ma questo elenco non è esaustivo.

Comandi che operano sull'intero spazio delle chiavi

  • KEYS

Comandi che operano su un insieme di chiavi di lunghezza variabile

  • LRANGE
  • ZRANGE
  • HGETALL

Comandi che si bloccano durante l'esecuzione di uno script

  • EVAL
  • EVALSHA

Rischi dell'utilizzo di comandi costosi

  • Latenza elevata e timeout del client.
  • Carico della memoria causato da comandi che aumentano l'utilizzo della memoria.
  • Perdita di dati durante la replica e la sincronizzazione dei nodi a causa del blocco del thread principale di Valkey.
  • Controlli di integrità, osservabilità e replica inutilizzati.

Best practice per i client Valkey

L'applicazione deve utilizzare un client Valkey consapevole del cluster quando si connette a un'istanza Memorystore for Valkey. Per esempi di client consapevoli del 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 giusti ed evitare il sovraccarico delle prestazioni causato dai reindirizzamenti.

Mappatura dei 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 dello slot ai nodi.

  • Quando viene ricevuto un reindirizzamento MOVED dal server, ad esempio in caso di failover quando tutti gli slot gestiti dall'ex nodo principale vengono rilevati dalla replica o di sharding quando gli slot vengono spostati dal principale di origine al nodo principale di destinazione.

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

  • Quando viene ricevuto un errore READONLY dal server. Ciò può accadere quando un database principale viene retrocesso a replica.

  • Inoltre, i client devono aggiornare periodicamente la topologia per mantenere attivo il warm-up dei client per eventuali modifiche e conoscere le modifiche che potrebbero non comportare reindirizzamenti/errori dal server, ad esempio quando vengono aggiunti nuovi nodi replica. Tieni presente che anche le connessioni non aggiornate devono essere chiuse nell'ambito dell'aggiornamento della topologia per ridurre la necessità di gestire le connessioni non riuscite durante l'esecuzione del comando.

Rilevamento dei clienti

La ricerca dei client viene solitamente eseguita emettendo un comando SLOTS, NODES o CLUSTER SHARDS al server Valkey. Ti consigliamo di utilizzare il comando CLUSTER SHARDS. CLUSTER SHARDS sostituisce il comando SLOTS (non più supportato) fornendo una rappresentazione più efficiente ed estensibile dell'istanza.

Le dimensioni della risposta per i comandi di rilevamento dei client possono variare in base alle dimensioni e alla topologia dell'istanza. Le istanze più grandi con più nodi producono una risposta più ampia. Di conseguenza, è importante assicurarsi che il numero di client che eseguono la scoperta della topologia dei nodi non cresca in modo illimitato.

Questi aggiornamenti della topologia dei nodi sono costosi sul server Valkey, ma sono importanti anche per la disponibilità delle applicazioni. Pertanto, è importante assicurarsi che ogni client invii una singola richiesta di scoperta in un determinato momento (e memorizzi il risultato in memoria) e che il numero di client che inviano 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 dei nodi, un errore comune è che l'applicazione client invia diverse richieste di ricollegamento e rilevamento senza aggiungere il backoff esponenziale al successivo tentativo. Ciò può rendere il server Valkey non rispondente per un periodo di tempo prolungato, causando un utilizzo molto elevato della CPU.

Evitare il sovraccarico di discovery su Valkey

Per ridurre l'impatto causato da un improvviso afflusso di richieste di connessione e rilevamento, consigliamo quanto segue:

  • Implementa un pool di connessioni client di dimensioni ridotte e limitate 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 un backoff esponenziale con jitter. In questo modo si evita che più client sovraccarichino il server contemporaneamente.

  • Utilizza l'endpoint di rilevamento di Memorystore for Valkey per eseguire il rilevamento dei nodi. L'endpoint di rilevamento è altamente disponibile 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.

Best practice per la persistenza

Questa sezione illustra le best practice per la persistenza.

Persistenza RDB

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

Gestione della memoria

Gli snapshot RDB utilizzano un processo di fork e un meccanismo di "copia su scrittura" per acquisire uno snapshot dei dati del nodo. A seconda del pattern di scrittura nei nodi, la memoria utilizzata dai nodi aumenta man mano che le pagine interessate dalle scritture vengono copiate. Nel peggiore dei casi, l'impronta in memoria può essere il doppio delle dimensioni dei dati nel nodo.

Per assicurarti che i nodi dispongano di memoria sufficiente per completare lo snapshot, devi mantenere o impostare maxmemory all'80% della capacità del nodo in modo che il 20% sia riservato per l'overhead. Per scoprire di più, consulta Monitorare un'istanza con un carico di scrittura elevato. Questo overhead di memoria, oltre agli snapshot di monitoraggio, ti aiuta a gestire il tuo carico di lavoro per ottenere snapshot efficaci.

Istantanee obsolete

Il recupero dei nodi da uno snapshot non aggiornato può causare problemi di prestazioni per l'applicazione mentre tenta di riconciliare una quantità significativa di chiavi non aggiornate o altre modifiche al database, ad esempio una modifica dello schema. Se temi di non riuscire a recuperare da uno snapshot non aggiornato, puoi disattivare la funzionalità di persistenza RDB. Una volta riattivata la persistenza, viene acquisito uno snapshot all'intervallo di snapshot pianificato successivo.

Impatto sulle prestazioni degli snapshot RDB

A seconda del pattern di lavoro, gli snapshot RDB possono influire sulle prestazioni dell'istanza e aumentare la latenza per le applicazioni. Se non ti dispiace eseguire snapshot meno frequenti, puoi ridurne al minimo l'impatto sul rendimento pianificandoli per l'esecuzione durante i periodi di traffico ridotto dell'istanza.

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

Se il sistema ha un carico costante e richiede snapshot frequenti, devi valutare attentamente l'impatto sul rendimento e valutare i vantaggi dell'utilizzo degli snapshot RDB per il carico di lavoro.

Scegli un'istanza a zona singola se l'istanza non utilizza repliche

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

Ridurre al minimo l'impatto dell'interruzione

Le interruzioni zonali hanno meno probabilità di influire sulla tua istanza. Se posizioni tutti i nodi all'interno di un'unica zona, la probabilità che un'interruzione di servizio nella zona influisca sul tuo server si riduce dal 100% al 33%. Questo perché esiste una probabilità del 33% che la zona in cui si trova l'istanza non sia disponibile, rispetto alla probabilità del 100% che i nodi situati nella zona non disponibile siano interessati.

Recupero rapido

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