Clústeres de escalado automático de Valkey y Redis OSS - Amazon ElastiCache
Requisitos previosAdministración automática de la capacidad con el escalado automático de ElastiCache con Valkey o Redis OSSPermisos de IAM requeridos para el escalado automático Rol vinculado al servicioPrácticas recomendadas de Auto Scaling

Clústeres de escalado automático de Valkey y Redis OSS

Requisitos previos

El escalado automático de ElastiCache se encuentra limitado a lo siguiente:

  • Clústeres de Valkey o Redis OSS (modo de clúster habilitado) que ejecutan Valkey 7.2 en adelante posteriores, o que ejecutan el motor de Redis OSS versión 6.0 en adelante

  • Clústeres de organización de datos en niveles (modo de clúster habilitado) que ejecutan Valkey 7.2 en adelante, o que ejecutan el motor de Redis OSS versión 7.0.7 en adelante

  • Tamaños de instancia: Large, XLarge, 2XLarge

  • Familias de tipos de instancia: R7g, R6g, R6gd, R5, M7g, M6g, M5, C7gn

  • El escalado automático en ElastiCache no es compatible con clústeres que se ejecutan en almacenes de datos globales, Outposts o zonas locales.

Administración automática de la capacidad con el escalado automático de ElastiCache con Valkey o Redis OSS

El escalado automático de ElastiCache con Valkey o Redis OSS es la capacidad de aumentar o disminuir las particiones o réplicas deseadas en el servicio de ElastiCache de forma automática. ElastiCache utiliza el servicio de Auto Scaling de aplicaciones para proporcionar esta funcionalidad. Para obtener más información, consulte Auto Scaling de aplicaciones. Para utilizar el escalado automático, defina y aplique una política de escalado que utilice valores de destino y métricas de CloudWatch que asigne. El escalado automático de ElastiCache utiliza la política para aumentar o disminuir el número de instancias en respuesta a las cargas de trabajo reales.

Puede usar la AWS Management Console para aplicar una política de escalado en función de una métrica predefinida. Se define una predefined metric en una enumeración, de manera que puede especificarla por el nombre en el código o utilizarla en la AWS Management Console. Las métricas personalizadas no se pueden seleccionar utilizando la AWS Management Console. También puede utilizar la API de Auto Scaling de aplicaciones o la AWS CLI para aplicar una política de escalado basada en una métrica predefinida o personalizada.

ElastiCache con Valkey o Redis OSS admite el escalado para las siguientes dimensiones:

  • Particiones: agregar/eliminar de forma automática particiones en el clúster de forma similar al cambio de particiones manual en línea. En este caso, el escalado automático de ElastiCache desencadena el escalado en su nombre.

  • Réplicas: agregar/eliminar de forma automática réplicas en el clúster de manera similar a las operaciones manuales de aumento/reducción de réplicas. El escalado automático de ElastiCache con Valkey o Redis OSS añade o elimina réplicas uniformemente en todas las particiones del clúster.

ElastiCache con Valkey o Redis OSS admite los siguientes tipos de políticas de escalado automático:

Imagen de escalado automático para ElastiCache con Valkey o Redis OSS

En los siguientes pasos, se resume el proceso de escalado automático de ElastiCache con Valkey o Redis OSS que se muestra en el diagrama anterior:

  1. Crea una política de escalado automático de ElastiCache para su grupo de replicación.

  2. El escalado automático de ElastiCache con Valkey or Redis OSS crea un par de alarmas de CloudWatch en su nombre. Cada par representa los límites superiores e inferiores de las métricas. Estas alarmas de CloudWatch se activan cuando la utilización real del clúster se desvía del objetivo de utilización durante un periodo de tiempo prolongado. Puede ver las alarmas en la consola.

  3. Si el valor de la métrica configurado supera el objetivo de utilización (o no lo alcanza) durante un periodo específico, CloudWatch activa una alarma que invoca el escalado automático para evaluar la política de escalado.

  4. El escalado automático de ElastiCache con Valkey o Redis OSS emite una solicitud de modificación para ajustar la capacidad del clúster.

  5. ElastiCache con Valkey o Redis OSS procesa la solicitud de modificación, al aumentar (o reducir) dinámicamente la capacidad de las particiones/réplicas del clúster para que sea similar al objetivo de utilización.

Para comprender cómo funciona el escalado automático de ElastiCache con Valkey o Redis OSS, supongamos que tiene un clúster denominado UsersCluster. Mediante el monitoreo de las métricas de CloudWatch para UsersCluster, determinará el máximo de particiones que requiere el clúster cuando el tráfico se encuentra en su punto máximo, y el mínimo de particiones cuando el tráfico se encuentra en su punto más bajo. También decide un valor objetivo para la utilización de la CPU para el clúster UsersCluster. El escalado automático de ElastiCache utiliza el algoritmo de seguimiento de destino para asegurarse de que las particiones aprovisionadas de UsersCluster se ajusten de acuerdo a las necesidades, de tal forma que la utilización permanezca en el valor de objetivo o próxima a él.

nota

El escalado puede tardar un tiempo notable y requerirá recursos adicionales del clúster para que las particiones se reequilibren. El escalado automático de ElastiCache con Valkey or Redis OSS solo modifica la configuración de recurso cuando la carga de trabajo real se mantiene elevada (o reducida) durante un periodo de varios minutos seguidos. El algoritmo de seguimiento de destino del escalado automático intenta mantener el objetivo de utilización en el valor elegido o en valores próximos a él a largo plazo.

Permisos de IAM requeridos para el escalado automático

El escalado automático de ElastiCache con Valkey o Redis OSS es posible gracias a una combinación de las API de ElastiCache, CloudWatch y Application Auto Scaling. Los clústeres se crean y se actualizan con ElastiCache (Redis OSS), las alarmas se crean con CloudWatch y las políticas de escalado se crean con Application Auto Scaling. Además de los permisos estándar de IAM para la creación y actualización de los clústeres, el usuario de IAM que accede a la configuración de escalado automático de ElastiCache debe tener los permisos adecuados para los servicios que admiten el escalado dinámico. Los usuarios de IAM deben contar con los permisos necesarios para utilizar las acciones que se muestran en la siguiente política de ejemplo: 

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "application-autoscaling:*",
                "elasticache:DescribeReplicationGroups",
                "elasticache:ModifyReplicationGroupShardConfiguration",
                "elasticache:IncreaseReplicaCount",
                "elasticache:DecreaseReplicaCount",
                "elasticache:DescribeCacheClusters",
                "elasticache:DescribeCacheParameters",
                "cloudwatch:DeleteAlarms",
                "cloudwatch:DescribeAlarmHistory",
                "cloudwatch:DescribeAlarms",
                "cloudwatch:DescribeAlarmsForMetric",
                "cloudwatch:GetMetricStatistics",
                "cloudwatch:ListMetrics",
                "cloudwatch:PutMetricAlarm",
                "cloudwatch:DisableAlarmActions",
                "cloudwatch:EnableAlarmActions",
                "iam:CreateServiceLinkedRole",
                "sns:CreateTopic",
                "sns:Subscribe",
                "sns:Get*",
                "sns:List*"
            ],
            "Resource": "arn:aws:iam::123456789012:role/autoscaling-roles-for-cluster"
        }
    ]
}

Rol vinculado al servicio

El servicio de escalado automático de ElastiCache con Valkey o Redis OSS también necesita permiso para describir sus clústeres y las alarmas de CloudWatch, así como permisos para modificar el objetivo de capacidad de ElastiCache en su nombre. Si habilita el escalado automático para su clúster, crea un rol vinculado a servicios denominado AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG. Este rol vinculado a servicios concede al escalado automático de ElastiCache permiso para describir las alarmas de sus políticas y para supervisar y modificar la capacidad actual de la flota. El rol vinculado a servicios es el rol predeterminado para el escalado automático de ElastiCache. Para obtener más información, consulte Service-linked roles for ElastiCache (Redis OSS) auto scaling en la Guía del usuario de Application Auto Scaling.

Prácticas recomendadas de Auto Scaling

Antes de registrarse en Auto Scaling, recomendamos lo siguiente:

  1. Utilizar solo una métrica de seguimiento: identifique si el clúster tiene CPU o cargas de trabajo intensivas de datos y utilice una métrica predefinida correspondiente para definir la política de escalado.

    • CPU del motor: ElastiCachePrimaryEngineCPUUtilization (dimensión de partición) o ElastiCacheReplicaEngineCPUUtilization (dimensión de réplica)

    • Uso de bases de datos: ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage Esta política de escalado funciona mejor si la política maxmemory está configurada como noeviction en el clúster.

    Le recomendamos que evite tener varias políticas por dimensión en el clúster. El escalado automático de ElastiCache con Valkey o Redis OSS realizará un escalado horizontal del destino escalable si alguna política 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 habilitada la parte de reducción horizontal) están listas para la reducción horizontal. Si varias políticas indican al destino escalable que se realice una reducción o escalado horizontal al mismo tiempo, se escala en función de la política que proporciona la mayor capacidad para la reducción o el escalado horizontal.

  2. Métricas personalizadas para el seguimiento de destinos: tenga cuidado al utilizar métricas personalizadas para el seguimiento de destinos, ya que el escalado automático es la característica más adecuada para el escalado horizontal en proporción a los cambios en las métricas elegidas para la política. Si esas métricas no cambian proporcionalmente a las acciones de escalado usadas para la creación de políticas, es posible que den lugar a acciones continuas de escalar horizontalmente o reducir horizontalmente que es posible que afecten a la disponibilidad o el costo.

    En el caso de los clústeres de datos por niveles (tipos de instancias de la familia r6gd), evite utilizar métricas basadas en memoria para escalar.

  3. Escalado programado: si identifica que su carga de trabajo es determinista (alcance alto/bajo en un momento específico), recomendamos utilizar el escalado programado y configurar su capacidad objetivo según la necesidad. El seguimiento de destino es el más adecuado para las cargas de trabajo no determinista y para que el clúster funcione con la métrica de destino requerida al escalar horizontalmente cuando necesite más recursos y reducir horizontalmente cuando necesite menos.

  4. Deshabilitar la reducción horizontal: el Auto Scaling del seguimiento de destino es el más adecuado para clústeres con aumento/disminución gradual de las cargas de trabajo, ya que los picos o la disminución de las métricas pueden desencadenar oscilaciones consecutivas de reducción o escalado horizontal. Para evitar tales oscilaciones, puede comenzar con la reducción horizontal deshabilitada y luego siempre puede reducir horizontalmente de forma manual según sus necesidades.

  5. Probar la aplicación: recomendamos que pruebe la aplicación con las cargas de trabajo mínimas y máximas estimadas a fin de determinar las particiones o réplicas mínimas y máximas necesarias para el clúster mientras crea políticas de escalado a fin de evitar problemas de disponibilidad. Auto Scaling puede escalar horizontalmente hasta el máximo y reducir horizontalmente en el umbral mínimo configurado para el destino.

  6. Definición del valor de destino: puede analizar las métricas correspondientes de CloudWatch para la utilización del clúster durante un periodo de cuatro semanas a fin de determinar el umbral del valor objetivo. Si aún no se encuentra seguro de qué valor elegir, se recomienda comenzar con el valor mínimo admitido de métrica predefinida.

  7. Auto Scaling del seguimiento de destino es la característica más adecuada para clústeres con distribución uniforme de las cargas de trabajo entre las dimensiones de particiones/réplicas. Tener una distribución no uniforme puede conducir a:

    • Escalado cuando no es necesario debido a un pico/caída de la carga de trabajo en algunas particiones o réplicas en almacenamiento activo.

    • Falta de escalado cuando sí es necesario debido a que la carga de trabajo media general se encuentra próxima al objetivo aunque tenga particiones o réplicas en el almacenamiento activo.

nota

Al escalar horizontalmente el clúster, ElastiCache replicará automáticamente las funciones cargadas en uno de los nodos existentes (seleccionadas de forma aleatoria) en los nuevos nodos. Si el clúster tiene Valkey o Redis 7.0 o una versión posterior y la aplicación usa funciones, le recomendamos que cargue todas las funciones en todas las particiones antes de escalar horizontalmente para que el clúster no termine con diferentes funciones en distintas particiones.

Después de registrarse en Auto Scaling, tenga en cuenta lo siguiente:

  • Existen limitaciones en las configuraciones compatibles con Auto Scaling, por lo que recomendamos no cambiar la configuración de un grupo de reproducción que se haya registrado para Auto Scaling. A continuación se muestran algunos ejemplos:

    • Modificación manual del tipo de instancias a tipos no admitidos.

    • Asociación del grupo de reproducción a un almacén de datos global.

    • Cambio del parámetro ReservedMemoryPercent.

    • Aumento/disminución manual de particiones/réplicas más allá de la capacidad mínima y máxima configurada durante la creación de políticas.