Elección del tamaño del nodo - Amazon ElastiCache
Tamaño del nodo (Valkey y Redis OSS)Tamaño del nodo (Memcached)

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Elección del tamaño del nodo

El tamaño de nodo que seleccione para su ElastiCache clúster afecta a los costes, el rendimiento y la tolerancia a errores.

Tamaño del nodo (Valkey y Redis OSS)

Para obtener información sobre las ventajas de los procesadores Graviton, consulte Procesador AWS  Graviton.

Responder las siguientes preguntas puede ayudar a determinar el tipo de nodo mínimo que necesita para su implementación de Valkey o Redis OSS:

  • ¿Espera cargas de trabajo limitadas por el rendimiento con múltiples conexiones de cliente?

    Si este es el caso y utiliza la versión 5.0.6 o superior de Redis OSS, puede mejorar el rendimiento y la latencia con nuestra I/O función mejorada, si está disponible, CPUs se utiliza para reducir la carga de las conexiones de los clientes, en beneficio del motor OSS de Redis. Si está ejecutando la versión 7.0.4 o superior de Redis OSS, los I/O, you will get additional acceleration with enhanced I/O multiplexing, where each dedicated network IO thread pipelines commands from multiple clients into the Redis OSS engine, taking advantage of Redis OSS' ability to efficiently process commands in batches. In ElastiCache for Redis OSS v7.1 and above, we extended the enhanced I/O threads functionality to also handle the presentation layer logic. By presentation layer, what we mean is that Enhanced I/O subprocesos mejorados ahora no solo leen la entrada del cliente, sino que también la analizan en el formato de comando binario de Redis OSS, que luego se reenvía al hilo principal para su ejecución, lo que proporciona un aumento de rendimiento. Consulte la entrada de blog y la página de versiones compatibles para obtener más información.

  • ¿Tiene cargas de trabajo que acceden regularmente a un pequeño porcentaje de sus datos?

    Si este es el caso y está ejecutando en el motor de Redis OSS versión 6.2 o posteriores, puede aprovechar la organización de datos en niveles eligiendo el tipo de nodo r6gd. Con la organización de datos en niveles, los datos menos usados recientemente se almacenan en SSD. Cuando se recupera, hay un pequeño costo de latencia, que se equilibra con el ahorro de costos. Para obtener más información, consulte Organización de datos por niveles en ElastiCache.

    Para obtener más información, consulte Tipos de nodos compatibles.

  • ¿Cuánta memoria total necesita para sus datos?

    Para obtener una estimación general, tome el tamaño de los elementos que desea almacenar en la caché. Multiplique este tamaño por el número de elementos que desea conservar en la caché al mismo tiempo. Para obtener una estimación razonable del tamaño de los elementos, serialice los elementos de la caché y cuente los caracteres. A continuación, divida esto entre el número de particiones de su clúster.

    Para obtener más información, consulte Tipos de nodos compatibles.

  • ¿Qué versión de Redis OSS está ejecutando?

    Las versiones de Redis OSS anteriores a la 2.8.22 requieren que reserve más memoria para la conmutación por error, la sincronización de instantáneas y la promoción de réplicas a operaciones principales. Este requisito se debe a que debe disponer de suficiente memoria disponible para todas las operaciones de escritura que se producen durante el proceso.

    La versión 2.8.22 de Redis OSS y las versiones posteriores usan un proceso de guardado sin ramificaciones que requiere menos memoria disponible que el proceso anterior.

    Para obtener más información, consulte los siguientes temas:

  • ¿Qué volumen de operaciones de escritura realiza su aplicación?

    Las aplicaciones que realizan un elevado volumen de operaciones de escritura pueden requerir un mayor volumen de memoria disponible (memoria no usada por los datos) a la hora de tomar instantáneas o en casos de conmutación por error. Cuando se aplica el proceso BGSAVE, debe tener suficiente memoria que no sea utilizada por los datos para alojar todas las escrituras que se producen durante el proceso BGSAVE. Algunos ejemplos son: tomar una instantánea, sincronizar un clúster principal con una réplica en un clúster y habilitar la característica de archivo de solo anexado (AOF). Otro ejemplo es cuando se promueve una réplica a principal (si tiene habilitado Multi-AZ). El peor de los casos es cuando todos los datos se reescriben durante el proceso. En este caso, necesita un tamaño de instancia de nodo con el doble de la memoria necesaria solo para los datos.

    Para obtener información más detallada, consulte Forma de garantizar que dispone de memoria suficiente para crear una instantánea de Valkey o Redis OSS.

  • ¿Su implementación será un clúster de Valkey o Redis OSS independiente (modo de clúster deshabilitado) o un clúster de Valkey o Redis OSS (modo de clúster habilitado) con varias particiones?

    Clúster de Valkey o Redis OSS (modo de clúster deshabilitado)

    Si va a implementar un clúster de Valkey o Redis OSS (modo de clúster deshabilitado), su tipo de nodo debe tener capacidad para todos los datos más una capacidad adicional, tal como se describe en el punto anterior.

    Por ejemplo, supongamos que estima que el tamaño total de todos los elementos es de 12 GB. En este caso, puede utilizar un nodo de cache.m3.xlarge con 13.3 GB de memoria o un nodo de cache.r3.large con 13.5 GB de memoria. Sin embargo, es posible que necesite más memoria para las operaciones BGSAVE. Si la aplicación tiene un gran volumen de operaciones de escritura, duplique los requisitos de memoria a 24 GB como mínimo. Por lo tanto, utilice un cache.m3.2xlarge con 27.9 GB de memoria o un cache.r3.xlarge con 30.5 GB de memoria.

    Valkey o Redis OSS (modo de clúster habilitado) con varias particiones

    Si va a implementar un clúster de Valkey o Redis OSS (modo de clúster habilitado) con varias particiones, el tipo de nodo debe tener capacidad para bytes-for-data-and-overhead / number-of-shards bytes de datos.

    Por ejemplo, suponga que estima que el tamaño total de todos los elementos es de 12 GB y tiene dos particiones. En este caso, puede utilizar un nodo de cache.m3.large con 6.05 GB de memoria (12 GB/2). Sin embargo, es posible que necesite más memoria para las operaciones BGSAVE. Si la aplicación tiene un gran volumen de operaciones de escritura, duplique los requisitos de memoria a 12 GB por partición como mínimo. Por lo tanto, utilice un cache.m3.xlarge con 13.3 GB de memoria o un cache.r3.large con 13.5 GB de memoria.

  • ¿Utiliza Local Zones?

    Las Zonas Locales le permiten colocar recursos, como un ElastiCache clúster, en varias ubicaciones cercanas a sus usuarios. Sin embargo, cuando elija el tamaño del nodo, tenga en cuenta que, independientemente de los requisitos de capacidad, los tamaños de nodo disponibles tienen los siguientes límites en este momento:

    • Generación actual:

      Tipos de nodos M5: cache.m5.large, cache.m5.xlarge, cache.m5.2xlarge, cache.m5.4xlarge, cache.m5.12xlarge, cache.m5.24xlarge

      Tipos de nodos R5: cache.r5.large, cache.r5.xlarge, cache.r5.2xlarge, cache.r5.4xlarge, cache.r5.12xlarge, cache.r5.24xlarge

      Tipos de nodos T3: cache.t3.micro, cache.t3.small, cache.t3.medium

Mientras el clúster está en ejecución, puede supervisar las métricas de uso de memoria, uso del procesador, aciertos y errores de caché publicadas en ellas. CloudWatch Es posible que observe que el clúster no tiene la tasa de aciertos que desea o que las claves se expulsan con demasiada frecuencia. En estos casos, puede elegir un tamaño de nodo diferente con mayores especificaciones de memoria y CPU.

Cuando supervise el uso de la CPU, recuerde que Valkey y Redis OSS tienen un subproceso único. Por lo tanto, multiplique el uso de la CPU por el número de núcleos de CPU para obtener el uso real. Por ejemplo, una CPU de cuatro núcleos cuya tasa de uso es del 20 % indica que el núcleo de Redis OSS se encuentra en uso al 80 %.

Tamaño del nodo (Memcached)

Los clústeres de Memcached contienen uno o varios nodos entre los que se particionan los datos del clúster. Por ello, las necesidades de memoria del clúster y la memoria de un nodo están relacionadas, pero no son la misma cosa. Puede alcanzar la capacidad de memoria del clúster necesaria con varios nodos de gran tamaño o varios nodos más pequeños. Además, a medida que cambien sus necesidades, puede agregar nodos al clúster o eliminarlos y, por lo tanto, pagar solo por aquello que necesite.

La capacidad total de memoria de su clúster se calcula multiplicando el número de nodos del clúster por la capacidad de RAM de cada nodo, tras haberle restado la carga general del sistema. La capacidad de cada nodo depende del tipo de nodo.

cluster_capacity = number_of_nodes * (node_capacity - system_overhead)

El número de nodos del clúster es un factor clave para la disponibilidad de su clúster con Memcached. El error de un único nodo puede repercutir en la disponibilidad de su aplicación y en la carga de la base de datos de backend. En tal caso, proporciona ElastiCache un reemplazo para un nodo defectuoso y este se rellena. Para reducir este impacto en la disponibilidad, distribuya su memoria y su capacidad informática en un mayor número de nodos, cada uno con menos capacidad, en lugar de usar menos nodos de mayor capacidad.

En un escenario en el que desea disponer de 35 GB de memoria caché, puede realizar cualquiera de las siguientes configuraciones:

  • 11 cache.t2.medium nodos con 3,22 GB de memoria y 2 subprocesos en cada uno = 35,42 GB y 22 subprocesos.

  • 6 cache.m4.large nodos con 6,42 GB de memoria y 2 subprocesos en cada uno = 38,52 GB y 12 subprocesos.

  • 3 cache.r4.large nodos con 12,3 GB de memoria y 2 subprocesos en cada uno = 36,90 GB y 6 subprocesos.

  • 3 cache.m4.xlarge nodos con 14,28 GB de memoria y 4 subprocesos en cada uno = 42,84 GB y 12 subprocesos.

Comparación de opciones de nodos
Tipo de nodo Memoria (en GiB) Núcleos Costo por horas* Nodos necesarios Memoria total (en GiB) Núcleos totales Costo mensual 
cache.t2.medium 3.22 2 0,068 USD 11 35,42 22 538,56 USD
cache.m4.large 6.42 2 0,156 USD 6 38,52 12 673,92 USD
cache.m4.xlarge 14.28 4 0,311 USD 3 42.84 12 671,76 USD
cache.m5.xlarge 12.93 4 0,311 USD 3 38,81 12 671,76 USD
cache.m6g.large 6.85 2 0,147$ 6 41,1 12 635$
cache.r4.large 12.3 2 0,228 USD 3 36,9 6 492,48 USD
cache.r5.large 13.07 2 0,216 USD 3 39,22 6 466,56 USD
cache.r6g.large 13.07 2 0,205$ 3 42.12 6 442$
* Costo por hora por nodo al 8 de octubre de 2020.
Costo mensual con un 100 % de uso durante 30 días (720 horas).

Estas opciones proporcionan una capacidad de memoria similar pero con diferencias de costo y capacidad de cómputo. Para comparar los costes de tus opciones específicas, consulta los ElastiCache precios de Amazon.

Para clústeres que ejecutan Memcached, parte de la memoria disponible en cada nodo se usa para la conexión. Para obtener más información, consulte Capacidad adicional para conexiones de Memcached.

El uso de varios nodos requiere distribuir las claves entre ellos. Cada nodo tiene su propio punto de conexión. Para facilitar la administración de los puntos finales, puede utilizar ElastiCache la función de detección automática, que permite a los programas cliente identificar automáticamente todos los nodos de un clúster. Para obtener más información, consulte Identificación automática de los nodos en el clúster (Memcached).

En algunos casos, es posible que no se encuentre seguro de cuánta capacidad necesita. Si es así, para las pruebas recomendamos comenzar con un nodo cache.m5.large. A continuación, supervise el uso de la memoria, el uso de la CPU y la tasa de aciertos de la memoria caché con ElastiCache las métricas que se publican en Amazon CloudWatch. Para obtener más información sobre CloudWatch las métricas de ElastiCache, consulteSupervisión del uso con CloudWatch métricas. Para las cargas de trabajo de mayor tamaño y de producción, los nodos R5 ofrecen el mejor rendimiento y el precio de RAM más ajustado.

Si su clúster no tiene la tasa deseada, podrá agregar más nodos fácilmente para aumentar la memoria total disponible en el clúster.

Si el clúster se encuentra limitado por la CPU pero tiene una tasa suficiente, configure un clúster nuevo con un tipo de nodo que ofrezca mayor potencia informática.