Scelta delle dimensioni dei nodi

La scelta delle dimensioni dei nodi per un cluster influisce sui costi, le prestazioni e la tolleranza ai guasti.

Scelta delle dimensioni dei nodi

Per informazioni sui vantaggi dei processori Graviton, vedere Processore AWS  Graviton.

Rispondere alle seguenti domande può aiutarvi a determinare il tipo di nodo minimo necessario per l'implementazione Redis OSS:

• Si prevedono carichi di lavoro legati al velocità di trasmissione effettiva con più connessioni client?

  Se questo è il caso e utilizzi Redis OSS versione 5.0.6 o successiva, puoi ottenere velocità e latenza migliori con la nostra funzionalità I/O avanzata, in cui vengono utilizzate le CPU disponibili per l'offload delle connessioni client, per conto del motore Redis OSS. Se utilizzi Redis OSS versione 7.0.4 o successiva, oltre all'I/O avanzato, otterrai un'ulteriore accelerazione con il multiplexing I/O avanzato, in cui ogni thread IO di rete dedicato trasferisce i comandi da più client nel motore Redis OSS, sfruttando la capacità di Redis di elaborare in modo efficiente i comandi in batch. ElastiCache Per Redis OSS v7.1 e versioni successive, abbiamo esteso la funzionalità avanzata dei thread di I/O per gestire anche la logica del livello di presentazione. Per livello di presentazione, ciò che intendiamo è che i thread di I/O avanzati ora non solo leggono l'input del client, ma lo analizzano anche nel formato di comando binario Redis OSS, che viene quindi inoltrato al thread principale per l'esecuzione, garantendo un aumento delle prestazioni. Per ulteriori dettagli, consulta il post del blog e la pagina delle versioni supportate.

• Si dispone di carichi di lavoro che accedono regolarmente a una piccola percentuale dei dati?

  Se questo è il caso e utilizzi la versione 6.2 o successiva del motore Redis OSS, puoi sfruttare il tiering dei dati scegliendo il tipo di nodo r6gd. Con il tiering di dati, i dati utilizzati meno di recente vengono archiviati su SSD. Quando vengono recuperati, è previsto un piccolo costo di latenza, bilanciato dai risparmi sui costi. Per ulteriori informazioni, consulta Tiering di dati.

  Per ulteriori informazioni, consultare Tipi di nodi supportati.

• Di quanta memoria in totale necessiti per i tuoi dati?

  Per ottenere una stima generale, prendere la dimensione degli elementi che si desidera memorizzare nella cache. Moltiplicare questa dimensione per il numero degli elementi da conservare nella cache contemporaneamente. Per ottenere una stima veritiera delle dimensioni degli elementi, serializza gli elementi della cache e contane i caratteri. Poi dividi questo numero per il numero delle partizioni nel cluster.

  Per ulteriori informazioni, consulta Tipi di nodi supportati.

• Quale versione di Redis OSS stai utilizzando?

  Le versioni di Redis OSS precedenti alla 2.8.22 richiedono di riservare più memoria per il failover, le istantanee, la sincronizzazione e la promozione di una replica alle operazioni principali. Occorre infatti disporre di una quantità di memoria sufficiente per tutte le operazioni di scrittura necessarie, affinché il processo vada a buon fine.

  Redis OSS versione 2.8.22 e successive utilizzano un processo di salvataggio senza forkless che richiede meno memoria disponibile rispetto al processo precedente.

  Per ulteriori informazioni, consulta gli argomenti seguenti:

  • Modalità di implementazione di sincronizzazione e backup

  • Assicurarsi di disporre di memoria sufficiente per creare un'istantanea Redis OSS

• Quant'è consistente il carico di lavoro in scrittura della tua applicazione?

  Le applicazioni caratterizzate da elevata attività di scrittura possono richiedere molta più memoria disponibile, non occupata dai dati, per acquisire snapshot o per il failover. Ogni volta che viene svolto il processo BGSAVE, è necessario disporre di memoria sufficiente che non viene utilizzata dai dati per contenere tutte le scritture che avvengono durante il processo BGSAVE Esempi sono quando si esegue uno snapshot, quando si sincronizza un cluster primario con una replica in un cluster e quando si abilita la caratteristica AOF (Append-only File). Un altro è la promozione di una replica al ruolo di nodo primario (se la funzione Multi-AZ è abilitata). Il caso peggiore è quando tutti i tuoi dati vengono riscritti durante il processo. In questo caso, è necessaria una dimensione di istanza di nodo con il doppio della memoria necessaria per i soli dati.

  Per informazioni più dettagliate, consulta Assicurarsi di disporre di memoria sufficiente per creare un'istantanea Redis OSS.

• L'implementazione sarà un cluster Redis OSS autonomo (modalità cluster disabilitata) o un cluster Redis OSS (modalità cluster abilitata) con più shard?

  Cluster Redis OSS (modalità cluster disabilitata)

  Se stai implementando un cluster Redis OSS (modalità cluster disabilitata), il tipo di nodo deve essere in grado di ospitare tutti i tuoi dati più l'overhead necessario, come descritto nel precedente bullet.

  Si supponga, ad esempio, di stimare che la dimensione totale di tutti gli articoli sia di 12 GB. In questo caso, puoi usare un cache.m3.xlarge nodo con 13,3 GB di memoria o un cache.r3.large con 13,5 GB di memoria. Tuttavia, potrebbe occorrere più memoria per le operazioni di BGSAVE. Se l'applicazione è pesante da scrivere, raddoppiare i requisiti di memoria fino ad almeno 24 GB. Quindi, usa un cache.m3.2xlarge con 27,9 GB di memoria ocache.r3.xlarge con 30,5 GB di memoria.

  Redis OSS (modalità cluster abilitata) con più shard

  Se stai implementando un cluster Redis OSS (modalità cluster abilitata) con più shard, il tipo di nodo deve essere in grado di contenere bytes-for-data-and-overhead / number-of-shards byte di dati.

  Se, ad esempio, stimi in 12 GB la dimensione totale di tutti gli elementi e disponi di due partizioni. In questo caso, puoi usare un nodo cache.m3.large con 6,05 GB di memoria (12 GB/2). Tuttavia, potrebbe occorrere più memoria per le operazioni di BGSAVE. Se l'applicazione è pesante da scrivere, raddoppiare i requisiti di memoria fino ad almeno 12 GB per partizioni. Quindi, usa un cache.m3.xlarge con 13,3 GB di memoria o cache.r3.large con 13,5 GB di memoria.

• Stai usando Local Zones?

  Le Local Zones ti consentono di collocare risorse come un ElastiCache cluster in più posizioni vicine ai tuoi utenti. Tuttavia, quando si sceglie la dimensione del nodo, tenere presente che le dimensioni dei nodi disponibili sono limitate alle seguenti al momento, indipendentemente dai requisiti di capacità:

  • Generazione attuale:

    Tipi di nodi M5: cache.m5.large, cache.m5.xlarge, cache.m5.2xlarge, cache.m5.4xlarge, cache.m5.12xlarge, cache.m5.24xlarge

    Tipi di nodi R5: cache.r5.large, cache.r5.xlarge, cache.r5.2xlarge, cache.r5.4xlarge, cache.r5.12xlarge, cache.r5.24xlarge

    Tipi di nodo T3: cache.t3.micro, cache.t3.small, cache.t3.medium

Mentre il cluster è in esecuzione, è possibile monitorare l'utilizzo della memoria, l'utilizzo del processore, gli accessi alla cache e le metriche relative agli errori di cache pubblicati su. CloudWatch È possibile notare che il cluster non ha la frequenza di accessi desiderata o che le chiavi vengono espulse troppo spesso. In questi casi, puoi scegliere una dimensione di nodi diversa con specifiche di memoria e CPU maggiori.

Quando monitorate l'utilizzo della CPU, ricordate che l'OSS Redis è a thread singolo. Pertanto, moltiplica l'utilizzo della CPU segnalato per il numero di core CPU per ottenere l'effettivo utilizzo. Ad esempio, una CPU a quattro core che riporta un tasso di utilizzo del 20% è in realtà l'OSS Redis a un core in esecuzione con un utilizzo dell'80%.