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. ElastiCache con Valkey o Redis, OSS Auto Scaling crea y gestiona las CloudWatch alarmas que activan la política de escalado y calcula el ajuste de escalado en función de la métrica y el valor objetivo. 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 CPU la utilización en el valor objetivo especificado o cerca de él.
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 CloudWatch métrica 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 | CloudWatch Nombre de la métrica | CloudWatch Dimensión métrica | Tipos de instancia no aptos |
|---|---|---|---|
ElastiCachePrimaryEngineCPUUtilization |
|
ReplicationGroupId, Función = principal |
Ninguna |
ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage |
|
Métricas del grupo de OSS replicación de Valkey o Redis |
Ninguna |
ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage |
|
Métricas del grupo de replicación de Valkey o Redis OSS |
R6gd |
Los tipos de instancias con niveles de datos no se pueden usarElastiCacheDatabaseMemoryUsageCountedForEvictPercentage, ya que estos tipos de instancias almacenan datos tanto en la memoria como en. SSD El caso de uso previsto para las instancias con niveles de datos es utilizar la memoria al 100 por ciento y llenarla según sea necesario. SSD
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 con Valkey o Redis, OSS amplía los fragmentos del clúster mediante un recuento igual al mayor de los dos números: una variación porcentual con respecto a Target y un 20 por ciento de los fragmentos actuales. En el caso de la ampliación, ElastiCache no se ampliará automáticamente a menos que el valor general de la métrica esté por debajo del 75 por ciento del objetivo definido.
Para un ejemplo de escalado horizontal, si tiene 50 particiones y
-
Si su Target se infringe un 30 por ciento, ElastiCache con Valkey o Redis se OSS amplía un 30 por ciento, lo que da como resultado 65 fragmentos por clúster.
-
Si su objetivo se infringe en un 10 por ciento, ElastiCache con Valkey o Redis se OSS amplía de forma predeterminada un mínimo del 20 por ciento, lo que se traduce en 60 fragmentos por clúster.
Por ejemplo, si ha seleccionado un valor objetivo del 60 por ciento, ElastiCache Valkey o Redis OSS no escalarán automáticamente hasta que la métrica sea inferior o igual al 45 por ciento (un 25 por ciento por debajo del 60 por ciento objetivo).
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 realiza cuando la métrica está por encima del valor objetivo. No puede utilizar una política de escalado de seguimiento objetivo para escalar de forma horizontal cuando la métrica especificada esté por debajo del valor objetivo. ElastiCache con Valkey o Redis, OSS escala los fragmentos con una desviación mínima del 20 por ciento con respecto al objetivo de los fragmentos 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 objetivo y los puntos de datos de la métrica real. Esto se debe a que, ElastiCache con Valkey o Redis, OSS Auto Scaling siempre actúa de forma conservadora al redondear hacia arriba o hacia abajo cuando determina la cantidad de capacidad que se debe añadir o eliminar. 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 y seguimiento de objetivos para un ElastiCache OSS clúster de Valkey o Redis, siempre que cada una de ellas utilice una métrica diferente. La intención de Auto Scaling ElastiCache (RedisOSS) es priorizar siempre la disponibilidad, por lo que su comportamiento varía según si las políticas de seguimiento de los objetivos están listas para ampliarse o ampliarse. 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 edite ni elimine las CloudWatch alarmas que OSS Auto Scaling gestiona ElastiCache con Valkey o Redis para una política de escalado de seguimiento de objetivos. ElastiCache Auto Scaling elimina las alarmas automáticamente al eliminar la política de escalado.
-
ElastiCache Auto Scaling no le impide modificar manualmente los fragmentos del clúster. Estos ajustes manuales no afectan a ninguna de CloudWatch las alarmas existentes asociadas a la política de escalado, pero pueden afectar a las métricas que podrían activar estas CloudWatch alarmas.
-
Estas CloudWatch alarmas administradas por Auto Scaling se definen sobre la AVG métrica en todos los fragmentos del clúster. Por lo tanto, tener particiones activas puede resultar en cualquiera de los siguientes escenarios:
-
escalando cuando no es necesario debido a la carga de algunos fragmentos calientes, lo que desencadena una alarma CloudWatch
-
no se escalan cuando es necesario debido a la agregación de AVG todos los fragmentos, lo que impide que la alarma se rompa.
-
-
ElastiCache con Valkey o Redis, se siguen OSS aplicando los límites predeterminados de 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 ENIs (interfaces de red elásticas) disponibles en su dispositivoVPC, que son necesarias durante el escalado horizontal. Para obtener más información, consulte Interfaces de red elástica.
-
Si no hay suficiente capacidad disponibleEC2, ElastiCache Auto Scaling no escalará y se retrasará hasta que la capacidad esté disponible.
-
ElastiCache (RedisOSS) El Auto Scaling durante el escalado interno no eliminará los fragmentos con ranuras con 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.
