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.
Políticas de escalado de seguimiento de destino
Las políticas de escalado de seguimiento de destino le permiten seleccionar una métrica y establecer un valor de destino. El escalado automático de ElastiCache para Valkey y Redis OSS crea y administra las alarmas de CloudWatch que desencadenan la política de escalado y calcula el ajuste de escalado en función de la métrica y el valor de destino. La política de escalado agrega o elimina las particiones en función de las necesidades para mantener la métrica en el valor objetivo especificado o en un valor próximo. Además de mantener la métrica próxima al valor de destino, la política de escalado de seguimiento de destino también se ajusta a las fluctuaciones de la métrica producidas por patrones de carga fluctuante y minimiza las fluctuaciones rápidas de la capacidad de la flota.
Por ejemplo, considere una política de escalado que utilice la métrica ElastiCachePrimaryEngineCPUUtilization media predefinida con el valor objetivo configurado. Esta política puede mantener la utilización de la CPU en el valor objetivo especificado o en un valor próximo.
Métricas predefinidas
Una métrica predefinida es una estructura que hace referencia a un nombre, una dimensión y una estadística (average) específicos de una métrica de CloudWatch determinada. La política de escalado automático define una de las siguientes métricas predefinidas para el clúster:
| Nombre de métrica predefinido | Nombre de métrica de CloudWatch | Dimensión de métricas de CloudWatch | Tipos de instancia no aptos |
|---|---|---|---|
ElastiCachePrimaryEngineCPUUtilization |
|
ReplicationGroupId, Role = Principal |
Ninguno |
ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage |
|
Métricas de grupo de replicación de Valkey o Redis OSS |
Ninguno |
ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage |
|
Métricas de grupo de replicación de Valkey o Redis OSS |
R6gd |
Los tipos de instancias con niveles de datos no pueden utilizar ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage, ya que estos tipos de instancias almacenan datos en la memoria y SSD. El caso de uso esperado para las instancias con niveles de datos es tener un uso de memoria del 100 por ciento y llenar el SSD según sea necesario.
Criterios de Auto Scaling para particiones
Cuando el servicio detecta que la métrica predefinida es igual o mayor que la configuración del objetivo, aumentará la capacidad de las particiones de forma automática. ElastiCache para Valkey y Redis OSS escala horizontalmente las particiones del clúster en una cantidad equivalente al mayor de dos números: la variación del porcentaje del objetivo y el 20 % de las particiones actuales. En el caso de la reducción horizontal, ElastiCache no se reduce horizontalmente de forma automática a menos que el valor total de la métrica sea inferior al 75 % del objetivo definido.
Para un ejemplo de escalado horizontal, si tiene 50 particiones y
-
si su objetivo sufre una interrupción del 30 %, ElastiCache escala horizontalmente un 30 %, lo que da como resultado 65 particiones por clúster.
-
si su objetivo sufre una interrupción del 10 %, ElastiCache escala horizontalmente de forma predeterminada un mínimo de 20 %, lo que da como resultado 60 particiones por clúster.
Para un ejemplo de reducción horizontal, si ha seleccionado un valor objetivo del 60 %, ElastiCache no se reducirá horizontalmente de forma automática hasta que la métrica sea inferior o igual al 45 % (25 % por debajo del objetivo de 60 %).
Consideraciones de Auto Scaling
Tenga en cuenta las siguientes consideraciones:
-
En las políticas de escalado de seguimiento de destino, se presupone que el escalado ascendente se lleva a cabo cuando la métrica está por encima del valor de destino. No puede utilizar una política de escalado de seguimiento de destinos si la métrica especificada está por debajo del valor de destino. ElastiCache para Valkey y Redis OSS escala horizontalmente las particiones con una desviación mínima del 20 % del objetivo de las particiones existentes en el clúster.
-
Las políticas de escalado de seguimiento de destino no realizan el escalado cuando la métrica especificada no tiene datos suficientes. No realiza la reducción horizontalmente porque la carencia de datos no se interpreta como una infrautilización de recursos.
-
Es posible que haya diferencias entre el valor de destino y los puntos de datos de la métrica real. Esto se debe a que el escalado automático de ElastiCache siempre actúa de forma conservadora y redondea hacia arriba o hacia abajo a la hora de determinar la cantidad de capacidad que se debe añadir o quitar. Con esto se evita que se agrega capacidad insuficiente o se elimine demasiada capacidad.
-
Para garantizar la disponibilidad de la aplicación, el servicio se escala horizontalmente en proporción a la métrica tan rápido como puede, pero se reduce horizontalmente de forma más gradual.
-
Puede tener varias políticas de escalado de seguimiento de destino en un clúster de ElastiCache para Valkey y Redis OSS, siempre que cada uno de ellos utilice una métrica diferente. El objetivo del escalado automático de ElastiCache siempre es dar prioridad a la disponibilidad, por lo que su comportamiento varía en función de si las políticas de seguimiento del objetivo están listas para el escalado o la reducción horizontales. Realizará un escalado horizontal del servicio si cualquiera de las políticas de seguimiento de destino está lista para el escalado horizontal, pero solo realizará la reducción horizontal si todas las políticas de seguimiento de destino (que tienen la parte de reducción horizontal habilitada) están listas para la reducción horizontal.
-
No modifique ni elimine las alarmas de CloudWatch que administra el escalado automático de ElastiCache para las políticas de escalado de seguimiento de destino. El escalado automático de ElastiCache elimina de forma automática las alarmas cuando se elimina la política de escalado.
-
El escalado automático de ElastiCache no le impide modificar de forma manual las particiones del clúster. Estos ajustes manuales no afectan a las alarmas de CloudWatch existentes adjuntas a la política de escalado, pero pueden afectar a las métricas que pueden activar estas alarmas de CloudWatch.
-
Estas alarmas de CloudWatch administradas por Auto Scaling se definen a través de la métrica AVG (Promedio) en todas las particiones del clúster. Por lo tanto, tener particiones activas puede resultar en cualquiera de los siguientes escenarios:
-
escalado cuando no es necesario debido a la carga en algunas particiones activas que desencadenan una alarma de CloudWatch
-
no escalar cuando sí sea necesario debido a un AVG (Promedio) agregado en todas las particiones que causa que la alarma se interrumpa.
-
-
Siguen aplicándose los límites predeterminados de ElastiCache en nodos por clúster. Por lo tanto, al optar por Auto Scaling y, si espera que los nodos máximos sean superiores al límite predeterminado, solicite un aumento del límite en AWS Service Limits y elija el tipo de límite Nodes per cluster per instance type (Nodos por clúster por tipo de instancias).
-
Asegúrese de tener suficientes ENI (interfaces de red elásticas) disponibles en su VPC, que son necesarias durante el escalado horizontal. Para obtener más información, consulte Interfaces de red elástica.
-
Si no hay suficiente capacidad disponible desde EC2, el escalado automático de ElastiCache no se escala en forma horizontal y se retrasa hasta que haya capacidad.
-
El escalado automático de ElastiCache para Redis OSS durante la reducción horizontal no eliminará las particiones con ranuras que tengan un tamaño de elemento superior a 256 MB después de la serialización.
-
Durante la reducción horizontal, no se eliminarán particiones si no se encuentra disponible la memoria suficiente en la configuración de particiones resultante.
