Best practice generali

Questa pagina fornisce indicazioni su come utilizzare in modo ottimale Memorystore for Valkey. In questa pagina vengono inoltre evidenziati 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 rimozione: Memorystore for Valkey utilizza il criterio di eliminazione 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 la memoria utilizzata si avvicina al 100% e prevedi che l'utilizzo dei dati aumenterà, devi fare lo scale up delle 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ù.

  • Caricamenti di scrittura moderatamente elevati possono causare problemi se /instance/memory/maximum_utilization raggiunge l'85% o un valore superiore.

In questi scenari, devi fare lo scale up della dimensione dell'istanza per migliorare le prestazioni.

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

Scalabilità degli shard

Quando esegui la scalabilità del numero di shard in un'istanza, devi eseguire la scalabilità durante i periodi di scrittura ridotta. La scalabilità durante i periodi di carico in scrittura elevato può sottoporre l'istanza a limiti di memoria a causa dell'overhead della memoria causato dalla replica o dalla migrazione degli slot.

Se il tuo caso d'uso Valkey utilizza l'eliminazione delle chiavi, la scalabilità a una dimensione dell'istanza più piccola può ridurre la 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 il ridimensionamento 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 un numero sufficiente di shard per 1,5 volte la quantità di dati attualmente presenti nella tua istanza. Puoi utilizzare la metrica /instance/memory/total_used_memory per vedere quanti dati sono archiviati nell'istanza.

Best practice per l'utilizzo della CPU

Se si verifica un'interruzione imprevista a livello di zona, si verifica una riduzione delle risorse della CPU per l'istanza a causa della perdita di capacità dai nodi nella zona non disponibile. Consigliamo di utilizzare istanze a disponibilità elevata. L'utilizzo di due repliche per shard (anziché una replica per shard) fornisce risorse di 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 traffico aggiuntivo dovuto alla perdita di capacità in caso di interruzione imprevista nella zona. 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 suggerimenti, ti consigliamo di aumentare lo scale up del numero di shard o repliche nella tua 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

  • VAL
  • EVALSHA

Rischi dell'utilizzo di comandi costosi

  • 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 a causa del blocco del thread principale di Valkey.
  • Controlli di integrità, osservabilità e replica affamati.

Best practice per i client Valkey

L'applicazione deve utilizzare un client Valkey sensibile al cluster quando si connette a un'istanza Memorystore for Valkey. Per esempi di client sensibili al cluster e configurazioni di esempio, consulta Esempi di codice delle librerie client. Il client deve mantenere una mappa degli slot di hash ai nodi corrispondenti dell'istanza per inviare le richieste ai nodi giusti ed evitare il sovraccarico delle prestazioni causato dai reindirizzamenti.

Mappatura dei client

I client devono ottenere un elenco completo degli slot e dei nodi mappati nella le 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 dalle connessioni a un determinato server, si verificano costantemente timeout.

  • Quando viene ricevuto un errore READONLY dal server. Questo può accadere quando un'istanza principale viene retrocesso a replica.

  • Inoltre, i client devono aggiornare periodicamente la topologia per mantenere attivo il preriscaldamento 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 client

In genere, il rilevamento dei client viene 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 (non più supportato) 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 generano una risposta più ampia. Di conseguenza, è importante garantire che il numero di client che eseguono il rilevamento della topologia dei nodi non aumenti 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 cliente invii una singola richiesta di scoperta in un determinato momento (e memorizzi nella cache il risultato in memoria) e che il numero di clienti 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. Questo può far sì che il server Valkey non risponda per un periodo di tempo prolungato, causando un utilizzo molto elevato della CPU.

Evita il sovraccarico del rilevamento su Valkey

Per mitigare l'impatto causato da un improvviso afflusso di connessioni e scoperte richieste, consigliamo quanto segue:

  • Implementa un pool di connessioni client di dimensioni limitate e ridotte per ha vincolato il numero di connessioni in entrata simultanee dal client un'applicazione.

  • Quando il client si disconnette dal server a causa di un timeout, riprova con il backoff esponenziale con il jitter. In questo modo si evita che più client sovraccarichino il server contemporaneamente.

  • Utilizza l'endpoint predittivo di Memorystore for Valkey per eseguire il nodo scoperta. L'endpoint di rilevamento è ad alta disponibilità ed è con bilanciamento del carico in 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 fork del processo e "copy-on-write" per acquisire 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 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 saperne di più, consulta Monitorare un'istanza con un carico di scrittura elevato. Questo overhead della memoria, oltre agli snapshot di Monitoring, ti aiuta a gestire il carico di lavoro per creare snapshot riusciti.

Snapshot inattivi

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 ti preoccupa il ripristino da uno snapshot inattivo, puoi disabilitare la funzionalità di persistenza RDB. Una volta riattivata la persistenza, viene acquisito uno snapshot al successivo intervallo di snapshot pianificato.

Impatto sulle prestazioni degli snapshot RDB

A seconda del modello di carico di lavoro, gli snapshot RDB possono influire sulle prestazioni dell'istanza e aumentare la latenza per le applicazioni. Se non ti dispiace avere snapshot meno frequenti, puoi ridurre al minimo l'impatto sul rendimento degli snapshot RDB pianificandone 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 sulle prestazioni e valutare i vantaggi dell'utilizzo di 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, è consigliabile utilizzare un'architettura a zona singola per una maggiore affidabilità. Ecco alcuni dei motivi:

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 di zona colpisca il 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 zonale, 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.