Scelta delle dimensioni dei nodi - Amazon ElastiCache
Dimensione del nodo (Valkey e RedisOSS)Dimensione del nodo (Memcached)

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Scelta delle dimensioni dei nodi

La dimensione del nodo selezionata per il ElastiCache cluster influisce sui costi, sulle prestazioni e sulla tolleranza agli errori.

Dimensione del nodo (Valkey e RedisOSS)

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 di Valkey o Redis: OSS

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

    Se questo è il caso e stai utilizzando la OSS versione Redis 5.0.6 o successiva, puoi ottenere velocità e latenza migliori con la nostra funzionalità di I/O avanzata, se disponibile, utilizzata per scaricare CPUs le connessioni client, per conto del motore Redis. OSS Se utilizzi la OSS versione Redis 7.0.4 o successiva, oltre all'I/O avanzato, otterrai un'accelerazione aggiuntiva con il multiplexing I/O avanzato, in cui ogni thread IO di rete dedicato trasferisce i comandi di più client nel OSS motore Redis, sfruttando la capacità di OSS Redis di elaborare in modo efficiente i comandi in batch. In ElastiCache (RedisOSS) 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 OSS binario Redis, 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 OSS del motore Redis, puoi sfruttare il tiering dei dati scegliendo il tipo di nodo r6gd. Con il tiering dei dati, i dati utilizzati meno di recente vengono archiviati in. SSD Quando vengono recuperati, è previsto un piccolo costo di latenza, bilanciato dai risparmi sui costi. Per ulteriori informazioni, consulta Suddivisione dei dati su più livelli in ElastiCache.

    Per ulteriori informazioni, consulta 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?

    OSSLe versioni di Redis 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.

    La OSS versione Redis 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:

  • 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 Ad esempio quando si scatta un'istantanea, si sincronizza un cluster primario con una replica in un cluster e quando si abilita la funzionalità append-only file (). AOF 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 Valkey o Redis OSS.

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

    Cluster Valkey o Redis (modalità cluster disabilitata) OSS

    Se stai implementando un cluster Valkey o 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 bullet precedente.

    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.

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

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

    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 del nodo diversa con specifiche di memoria più grandiCPU.

Quando monitorate CPU l'utilizzo, ricordate che Valkey e Redis OSS sono a thread singolo. Pertanto, moltiplica l'CPUutilizzo riportato per il numero di CPU core per ottenere l'utilizzo effettivo. Ad esempio, un core a quattro core che CPU riporta un tasso di utilizzo del 20% è in realtà l'unico core che OSS Redis utilizza con un utilizzo dell'80%.

Dimensione del nodo (Memcached)

I cluster Memcached possono contenere uno o più nodi, tra i quali ripartire i propri dati. Per questo motivo, le esigenze di memoria del cluster e la memoria di un nodo sono correlate, ma non corrispondenti. La necessaria capacità di memoria del cluster può contare su pochi nodi grandi o molti nodi piccoli. Inoltre, in base alle mutevoli esigenze, è possibile aggiungere nodi al cluster o rimuoverli in qualunque momento, pagando solo ciò che occorre.

La capacità di memoria totale del cluster viene calcolata moltiplicando il numero di nodi del cluster per la RAM capacità di ciascun nodo al netto del sovraccarico del sistema. La capacità di un nodo dipende dalla sua tipologia.

cluster_capacity = number_of_nodes * (node_capacity - system_overhead)

Il numero dei suoi nodi è un fattore determinante per la disponibilità di un cluster che esegue Memcached. Il fallimento di un solo nodo può influire sulla disponibilità dell'applicazione e sul carico sul database back-end. In tal caso, ElastiCache effettua il provisioning di un nodo sostitutivo per un nodo guasto e il nodo viene ripopolato. Per ridurre questo potenziale impatto sulla disponibilità, basta distribuire la memoria e la capacità di calcolo su più nodi a capacità ridotta, anziché su meno nodi ad ampia capacità.

Se, ad esempio, occorrono 35 GB di memoria cache, è possibile impostare una qualsiasi delle seguenti configurazioni:

  • 11 nodi cache.t2.medium, ciascuno con 3,22 GB di memoria e 2 thread = 35,42 GB e 22 thread.

  • 6 nodi cache.m4.large, ciascuno con 6,42 GB di memoria e 2 thread = 38,52 GB e 12 thread.

  • 3 nodi cache.r4.large, ciascuno con 12,3 GB di memoria e 2 thread = 36,90 GB e 6 thread.

  • 3 nodi cache.m4.xlarge, ciascuno con 14,28 GB di memoria e 4 thread = 42,84 GB e 12 thread.

Opzioni disponibili per i nodi a confronto
Tipo di nodo Memoria (in GB) Core Costo orario* Nodi necessari Memoria totale (in GiB) Core totali Costo mensile
cache.t2.medium 3.22 2 0,068 $ 11 35,42 22 538,56 $
cache.m4.large 6,42 2 0,156 $ 6 38,52 12 673,92 $
cache.m4.xlarge 14,28 4 0,311 $ 3 42,84 12 671,76 $
cache.m5.xlarge 12,93 4 0,311 $ 3 38,81 12 671,76 $
cache.m6g.large 6,85 2 $0,147 6 41,1 12 $635
cache.r4.large 12.3 2 0,228 $ 3 36,9 6 492,48 $
cache.r5.large 13,07 2 0,216 $ 3 39,22 6 466,56 $
cache.r6g.large 13,07 2 $0,205 3 42,12 6 $442
* Costo orario per nodo dall’8 ottobre 2020.
† Costo mensile al 100% di utilizzo per 30 giorni (720 ore).

Ognuna di queste opzioni offre una disponibilità di memoria simile, ma capacità e costi di elaborazione diversi. Per confrontare i costi delle tue opzioni specifiche, consulta la pagina ElastiCache dei prezzi di Amazon.

Nel caso dei cluster che eseguono Memcached, parte della memoria disponibile su ciascun nodo viene utilizzata per la gestione della connessione. Per ulteriori informazioni, consulta Sovraccarico delle connessioni Memcached

L'utilizzo di più nodi richiede la distribuzione delle chiavi tra gli stessi. Ogni nodo dispone del proprio endpoint. Per una gestione semplificata degli endpoint, puoi utilizzare ElastiCache la funzionalità Auto Discovery, che consente ai programmi client di identificare automaticamente tutti i nodi di un cluster. Per ulteriori informazioni, consulta Identifica automaticamente i nodi del cluster (Memcached).

In alcuni casi, è possibile non essere sicuri di quanta capacità è necessaria. In caso affermativo, per i test consigliamo di iniziare con un cache.m5.large nodo. Quindi monitora l'utilizzo della memoria, CPU l'utilizzo e la frequenza di accesso alla cache con le ElastiCache metriche pubblicate su Amazon. CloudWatch Per ulteriori informazioni sulle CloudWatch metriche per ElastiCache, consulta. Monitoraggio dell'utilizzo con CloudWatch Metrics Per la produzione e i carichi di lavoro più grandi, i nodi R5 offrono le migliori prestazioni e RAM il miglior rapporto qualità-prezzo.

Se il cluster non garantisce l'hit rate desiderato, basta aggiungere più nodi, aumentando così la memoria totale in esso disponibile.

Se il cluster è vincolato CPU ma ha una frequenza di successo sufficiente, configura un nuovo cluster con un tipo di nodo che fornisca maggiore potenza di calcolo.