Políticas de escalado y seguimiento de objetivos para Amazon EC2 Auto Scaling - Amazon EC2 Auto Scaling

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 y seguimiento de objetivos para Amazon EC2 Auto Scaling

Una política de escalado de seguimiento de objetivo escala automáticamente la capacidad del grupo de escalado automático en función de un valor de métrica de destino. Se adapta automáticamente a los patrones de uso únicos de sus aplicaciones individuales. Esto permite que su aplicación mantenga un rendimiento óptimo y una alta utilización de sus EC2 instancias a fin de lograr una mayor rentabilidad sin intervención manual.

Con el seguimiento de objetivo, seleccione una métrica y un valor objetivo para representar el nivel ideal de utilización promedio o rendimiento para su aplicación. Amazon EC2 Auto Scaling crea y administra las CloudWatch alarmas que invocan eventos de escalado cuando la métrica se desvía del objetivo. Para ejemplificar, esto es similar a cómo un termostato mantiene una temperatura objetivo.

Por ejemplo, supongamos que actualmente tiene una aplicación que se ejecuta en dos instancias y desea que la CPU utilización del grupo Auto Scaling se mantenga en torno al 50 por ciento cuando cambie la carga de la aplicación. De este modo dispone de capacidad adicional para gestionar picos de tráfico sin mantener una cantidad excesiva de recursos inactivos.

Puede satisfacer esta necesidad creando una política de escalado y seguimiento de objetivos que tenga como objetivo una CPU utilización media del 50 por ciento. Luego, su grupo de Auto Scaling se ampliará o aumentará la capacidad cuando CPU supere el 50 por ciento para gestionar el aumento de carga. Se ampliará o disminuirá la capacidad cuando CPU caiga por debajo del 50 por ciento para optimizar los costos durante los períodos de baja utilización.

Políticas de escalado de seguimiento de destino

Puede tener varias políticas de escalado de seguimiento de destino juntas que le ayuden a optimizar su rendimiento, siempre que cada una de ellas use una métrica diferente. Por ejemplo, la utilización y el rendimiento pueden influir mutuamente. Cada vez que una de estas métricas cambia, normalmente implica que otras métricas también se verán afectadas. Por lo tanto, el uso de varias métricas proporciona información adicional sobre la carga a la que se encuentra el grupo de escalado automático. Esto puede ayudar a Amazon EC2 Auto Scaling a tomar decisiones más informadas a la hora de determinar cuánta capacidad añadir a su grupo.

La intención de Amazon EC2 Auto Scaling es priorizar siempre la disponibilidad. Escalará horizontalmente el grupo de escalado automático si cualquiera de las políticas de seguimiento de objetivo está lista para el escalado horizontal. Solo realizará una reducción horizontal si todas las políticas de seguimiento de objetivo (que tienen habilitada la reducción horizontal) estén listas para la reducción horizontal.

Elección de métricas

Puede crear políticas de escalado de seguimiento de destino con métricas predefinidas o personalizadas. Las métricas predefinidas le proporcionan un acceso más fácil a las métricas más utilizadas para el escalado. Las métricas personalizadas te permiten escalar en función de otras CloudWatch métricas disponibles, incluidas las métricas de alta resolución que se publican en intervalos más precisos en cuestión de segundos. Puedes publicar tus propias métricas de alta resolución o las que publiquen otros AWS servicios.

Para obtener más información sobre la creación de políticas de seguimiento de segmentación mediante métricas de alta resolución, consulteCree una política de seguimiento de objetivos utilizando métricas de alta resolución para una respuesta más rápida.

El seguimiento de Target admite las siguientes métricas predefinidas:

  • ASGAverageCPUUtilizationCPU—Utilización media del grupo Auto Scaling.

  • ASGAverageNetworkIn: número promedio de bytes recibidos en todas las interfaces de red por el grupo de Auto Scaling.

  • ASGAverageNetworkOut: número promedio de bytes enviados en todas las interfaces de red por el grupo de Auto Scaling.

  • ALBRequestCountPerTarget: recuento medio de solicitudes de Application Load Balancer por destino para su grupo de Auto Scaling.

importante

Puede encontrar más información valiosa sobre las métricas de CPU utilización, las E/S de la red y el recuento de solicitudes de Application Load Balancer por objetivo en el tema Enumere las métricas CloudWatch disponibles para sus instancias de la Guía del usuario de EC2 Amazon y en el tema sobre CloudWatch las métricas de su Application Load Balancer de la Guía del usuario de Application Load Balancers, respectivamente.

Puede elegir otras CloudWatch métricas disponibles o las suyas propias CloudWatch especificando una métrica personalizada. Para ver un ejemplo que especifique una especificación de métrica personalizada para una política de escalado de seguimiento de objetivos mediante la AWS CLI, consultePolíticas de escalado de ejemplo de la AWS CLI.

Tenga en cuenta las siguientes consideraciones al elegir una métrica:

  • Le recomendamos que utilice únicamente las métricas que estén disponibles en intervalos de un minuto o menos para ayudarle a escalar más rápido en respuesta a los cambios de uso. Las métricas que se publican a intervalos más bajos permiten que la política de seguimiento de objetivos detecte y responda más rápido a los cambios en la utilización del grupo de Auto Scaling.

  • Si eliges métricas predefinidas publicadas por AmazonEC2, como la CPU utilización, te recomendamos que habilites la supervisión detallada. De forma predeterminada, todas EC2 las métricas de Amazon se publican en intervalos de cinco minutos, pero se pueden configurar en un intervalo inferior de un minuto al permitir una supervisión detallada. Para obtener información sobre cómo habilitar la supervisión detallada, consulteConfiguración de la supervisión para instancias de Auto Scaling.

  • No todas las métricas personalizadas funcionan para el seguimiento de destino. La métrica debe ser una métrica de utilización válida y describir el nivel de actividad de una instancia. El valor de la métrica debe aumentar o disminuir proporcionalmente al número de instancias del grupo de escalado automático. De esta forma, los datos de las métricas se pueden utilizar para ampliar o reducir proporcionalmente el número de instancias. Por ejemplo, la CPU utilización de un grupo de Auto Scaling funciona (es decir, la EC2 métrica de Amazon CPUUtilization con la dimensión métricaAutoScalingGroupName) si la carga del grupo de Auto Scaling se distribuye entre las instancias.

  • Las siguientes métricas no sirven para hacer un seguimiento de destino:

    • El número de solicitudes recibidas por el balanceador de carga frente al grupo de escalado automático (es decir, la métrica Elastic Load Balancing de RequestCount). El número de solicitudes recibidas por el balanceador de carga no cambia en función de la utilización del grupo de escalado automático.

    • La latencia de las solicitudes del balanceador de carga (es decir, la métrica Latency de Elastic Load Balancing). La latencia de las solicitudes puede aumentar si lo hace la utilización, pero el cambio no tiene que ser necesariamente proporcional.

    • La métrica CloudWatch ApproximateNumberOfMessagesVisible de SQS colas de Amazon. El número de mensajes de una cola no tiene por qué cambiar en proporción al tamaño del grupo de escalado automático que procesa los mensajes de la cola. Sin embargo, puede funcionar una métrica personalizada que mida el número de mensajes en la cola por EC2 instancia del grupo Auto Scaling. Para obtener más información, consulte Política de escalado basada en Amazon SQS.

  • Para utilizar la métrica ALBRequestCountPerTarget, debe especificar el parámetro ResourceLabel para identificar el grupo de destino del balanceador de carga asociado a la métrica. Para ver un ejemplo que especifique el ResourceLabel parámetro de una política de escalado de seguimiento de objetivos mediante el AWS CLI, consultePolíticas de escalado de ejemplo de la AWS CLI.

  • Cuando una métrica emite valores 0 reales a CloudWatch (por ejemplo,ALBRequestCountPerTarget), un grupo de Auto Scaling puede escalar a 0 cuando no haya tráfico en su aplicación durante un período prolongado de tiempo. Para que el grupo de escalado automático se reduzca horizontalmente a 0 cuando no se envíen solicitudes, la capacidad mínima del grupo debe ser de 0.

  • En lugar de publicar métricas nuevas para utilizarlas en su política de escalado, puede utilizar la matemáticas métricas para combinar las métricas existentes. Para obtener más información, consulte Creación de una política de escalado de seguimiento de destino con cálculos métricos.

Definición del valor de destino

Al crear una política de escalado de seguimiento de destino, debe especificar un valor de destino. El valor objetivo representa la utilización o el rendimiento promedio óptimo para el grupo de escalado automático. Para usar los recursos de manera rentable, establezca el valor objetivo lo más alto posible con un búfer razonable para aumentos inesperados de tráfico. Cuando la aplicación se escala horizontalmente de manera óptima para un flujo de tráfico normal, el valor de la métrica real debe ser igual al valor de destino, o estar justo por debajo de él.

Cuando una política de escalado se basa en el rendimiento, como el recuento de solicitudes por objetivo para un equilibrador de carga de aplicación, E/S de red u otras métricas de recuento, el valor objetivo representa el rendimiento promedio óptimo de una sola instancia, para un periodo de un minuto.

Definición del tiempo de preparación de la instancia

Puede especificar el número de segundos que se tarda en preparar una instancia recién lanzada. Hasta que haya expirado el tiempo de calentamiento especificado, una instancia no se cuenta para las métricas de EC2 instancia agregadas del grupo Auto Scaling.

Mientras las instancias se encuentran en el periodo de preparación, las políticas de escalado solo escalan horizontalmente si el valor de la métrica de las instancias que no están en preparación es mayor que la utilización objetivo de la política.

Si el grupo se vuelve a escalar horizontalmente, las instancias que aún estén en preparación se considerarán parte de la capacidad deseada para la siguiente actividad de escalado horizontal. La intención es realizar continuamente (pero no excesivamente) un escalado ascendente.

Mientras la actividad de escalado horizontal está en curso, todas las actividades de reducción horizontal iniciadas por las políticas de escalado se bloquean hasta que las instancias terminen de prepararse. Cuando las instancias terminen de prepararse, si se produce un evento de reducción horizontal, cualquier instancia que se encuentre actualmente en proceso de terminación se tendrá en cuenta para la capacidad actual del grupo al calcular la nueva capacidad deseada. Por lo tanto, no se eliminan más instancias del grupo de Auto Scaling que las necesarias.

Valor predeterminado

Si no se establece ningún valor, la política de escalado utilizará el valor predeterminado, que es el valor de la preparación de instancias por defecto definido para el grupo. Si la preparación predeterminada de instancias es nula, se revertirá al valor de recuperación predeterminado. Recomendamos usar la preparación de instancias predeterminada para facilitar la actualización de todas las políticas de escalado cuando cambie el tiempo de preparación.

Consideraciones

Las siguientes consideraciones se aplican al trabajar con las políticas de escalado de seguimiento de destino:

  • No cree, edite ni elimine las CloudWatch alarmas que se utilizan con una política de escalado y seguimiento de Target. Amazon EC2 Auto Scaling crea y administra las CloudWatch alarmas asociadas a sus políticas de escalado de seguimiento de objetivos y puede editarlas, sustituirlas o eliminarlas cuando sea necesario para personalizar la experiencia de escalado de sus aplicaciones y sus patrones de utilización cambiantes.

  • Una política de escalado de seguimiento de objetivos prioriza la disponibilidad durante los períodos de niveles de tráfico fluctuantes al reducir horizontalmente de forma más gradual cuando el tráfico disminuye. Si desea tener un mayor control, una política de escalado escalonado podría ser la mejor opción. Puedes deshabilitar temporalmente la parte escalable de una política de seguimiento de objetivos. Esto ayuda a mantener un número mínimo de instancias para que las implementaciones se realicen correctamente.

  • Si a la métrica le faltan puntos de datos, el estado de CloudWatch alarma cambia aINSUFFICIENT_DATA. Cuando esto ocurre, Amazon EC2 Auto Scaling no puede escalar el grupo hasta que se encuentren nuevos puntos de datos.

  • Si la métrica se presenta de forma dispersa por diseño, las matemáticas métricas pueden resultar útiles. Por ejemplo, para usar los valores más recientes, utilice la función FILL(m1,REPEAT), donde m1 es la métrica.

  • Es posible que haya diferencias entre el valor objetivo y los puntos de datos de la métrica real. Esto se debe a que actuamos de forma conservadora redondeando hacia arriba o hacia abajo a la hora de determinar el número de instancias que se deben agregar o quitar. Esto impide que agreguemos un número insuficiente de instancias o eliminemos demasiadas. Sin embargo, en el caso de los grupos de Auto Scaling que son más pequeños y tienen menos instancias, la utilización del grupo puede parecer que está muy lejos del valor de destino. Por ejemplo, supongamos que ha establecido un valor objetivo del 50 por ciento para la CPU utilización y, a continuación, su grupo de Auto Scaling supera el objetivo. Podríamos determinar que añadir 1,5 instancias reducirá la CPU utilización hasta cerca del 50 por ciento. Como no es posible agregar 1,5 instancias, redondeamos hacia arriba y añadimos dos instancias. Esto podría reducir la CPU utilización a un valor inferior al 50 por ciento, pero garantiza que la aplicación cuente con recursos suficientes para respaldarla. Del mismo modo, si determinamos que la eliminación de 1,5 instancias aumenta su CPU utilización por encima del 50 por ciento, eliminaremos solo una instancia.

    En el caso de grupos de Auto Scaling más grandes con más instancias, la utilización se distribuye entre un número de instancias mayor, en cuyo caso, si se agregan o quitan instancias, la diferencia entre el valor de destino y los puntos de datos de la métrica real es menor.

  • En las políticas de escalado de seguimiento de destino, se presupone que el grupo de escalado automático debe escalarse horizontalmente cuando la métrica especificada está por encima del valor de destino. Las políticas de escalado de seguimiento de destino no pueden utilizarse para escalar horizontalmente el grupo de escalado automático si la métrica está por debajo del valor de destino.