Optimización de la capacidad y disponibilidad de Amazon ECS

La disponibilidad de las aplicaciones es fundamental para ofrecer una experiencia sin errores y minimizar la latencia de las aplicaciones. La disponibilidad depende de que los recursos sean accesibles y tengan la capacidad suficiente para satisfacer la demanda. AWS proporciona varios mecanismos para administrar la disponibilidad. En el caso de las aplicaciones alojadas en Amazon ECS, estas incluyen el escalado automático y las zonas de disponibilidad (AZ). El escalado automático administra la cantidad de tareas o instancias en función de las métricas que defina, mientras que las zonas de disponibilidad le permiten alojar la aplicación en ubicaciones aisladas pero cercanas geográficamente.

Al igual que ocurre con el tamaño de las tareas, la capacidad y la disponibilidad presentan ciertas desventajas que debe tener en cuenta. Lo ideal sería que la capacidad estuviera perfectamente alineada con la demanda. Siempre habría suficiente capacidad para atender las solicitudes y procesar los trabajos a fin de cumplir los objetivos de nivel de servicio (SLO), lo que incluye una latencia y una tasa de errores bajas. La capacidad nunca sería demasiado alta, lo que generaría un costo excesivo; tampoco sería demasiado baja, lo que generaría una latencia y una tasa de errores altas.

El escalado automático es un proceso latente. En primer lugar, las métricas en tiempo real deben enviarse a CloudWatch. A continuación, es necesario agregarlas para analizarlas, lo que puede tardar varios minutos en función de la granularidad de la métrica. CloudWatch compara las métricas con los umbrales de alarma para identificar la escasez o el exceso de recursos. Para evitar la inestabilidad, configure las alarmas para que requieran que se supere el umbral establecido durante unos minutos antes de que suene la alarma. También lleva tiempo aprovisionar nuevas tareas y terminar las tareas que ya no son necesarias.

Debido a estos posibles retrasos en el sistema que se describen, es importante mantener cierto margen de maniobra mediante el aprovisionamiento excesivo. Esto puede ayudar a adaptarse a las ráfagas de demanda a corto plazo. Esto también ayuda a la aplicación a atender solicitudes adicionales sin saturarse. Como práctica recomendada, puede establecer su objetivo de escalado entre el 60 y el 80 % de utilización. Esto ayuda a la aplicación a gestionar mejor las ráfagas de demanda adicional mientras aún se está aprovisionando capacidad adicional.

Otro motivo por el que recomendamos aprovisionar en exceso es para poder responder rápidamente a los errores en las zonas de disponibilidad. AWS recomienda que las cargas de trabajo de producción se atiendan desde varias zonas de disponibilidad. Esto se debe a que, si se produce un error en una zona de disponibilidad, las tareas que se ejecutan en las zonas de disponibilidad restantes pueden seguir satisfaciendo la demanda. Si la aplicación se ejecuta en dos zonas de disponibilidad, debe duplicar el número normal de tareas. Esto es para que pueda proporcionar capacidad inmediata en caso de que se produzca un posible error. Si la aplicación se ejecuta en tres zonas de disponibilidad, le recomendamos que ejecute 1,5 veces el número normal de tareas. Es decir, ejecute tres tareas por cada dos que se necesiten para un servicio normal.

Maximización de la velocidad de escalado

El escalado automático es un proceso reactivo que tarda en surtir efecto. Sin embargo, hay algunas maneras de ayudar a minimizar el tiempo necesario para escalar horizontalmente.

Minimice el tamaño de la imagen. Las imágenes más grandes tardan más en descargarse de un repositorio de imágenes y descomprimirse. Por lo tanto, al reducir el tamaño de las imágenes, se reduce el tiempo necesario para que se inicie un contenedor. Para reducir el tamaño de la imagen, puede seguir estas recomendaciones específicas:

• Si puede crear un binario estático o usar Golang, cree la imagen FROM desde cero e incluya solo la aplicación binaria en la imagen resultante.

• Utilice imágenes base minimizadas de proveedores de distribuciones ascendentes, como Amazon Linux o Ubuntu.

• No incluya ningún artefacto de compilación en la imagen final. El uso de compilaciones en varias etapas puede ayudar en este sentido.

• Comprima las etapas de RUN siempre que sea posible. Cada etapa de RUN crea una nueva capa de imagen, lo que implica un proceso adicional de ida y vuelta para descargar la capa. Una sola etapa de RUN que tiene varios comandos unidos por && tiene menos capas que una con varias etapas de RUN.

• Si desea incluir datos, como datos de inferencia de ML, en la imagen final, incluya solo los datos necesarios para iniciar y empezar a atender el tráfico. Si obtiene datos bajo demanda de Amazon S3 u otro tipo de almacenamiento sin que ello afecte al servicio, almacene los datos en esos lugares.

Mantenga las imágenes cerca. Cuanto más alta sea la latencia de red, mas tardará en descargarse la imagen. Aloje sus imágenes en un repositorio en la misma región de AWS en la que se encuentra su carga de trabajo. Amazon ECR es un repositorio de imágenes de alto rendimiento que está disponible en todas las regiones en las que está disponible Amazon ECS. Evite utilizar Internet o un enlace de VPN para descargar imágenes de contenedores. El alojamiento de las imágenes en la misma región mejora la fiabilidad general. Mitiga el riesgo de problemas de conectividad de red y de disponibilidad en una región diferente. Como alternativa, también puede implementar la replicación entre regiones de Amazon ECR a modo de ayuda.

Reduzca los umbrales de comprobación de estado del equilibrador de carga. Los equilibradores de carga realizan comprobaciones de estado antes de enviar tráfico a la aplicación. La configuración de comprobación de estado predeterminada para un grupo de destino puede tardar 90 segundos o más. Durante este proceso, el equilibrador de carga comprueba el estado y recibe las solicitudes. Reducir el intervalo de comprobación de estado y el recuento de umbrales puede hacer que la aplicación acepte el tráfico más rápido y reducir la carga de otras tareas.

Considere el rendimiento de arranque en frío. Algunas aplicaciones utilizan tiempos de ejecución como Java para realizar la compilación Just-In-Time (JIT). El proceso de compilación, al menos cuando se inicia, puede mostrar el rendimiento de la aplicación. Una solución alternativa consiste en reescribir las partes de la carga de trabajo que son fundamentales para la latencia en lenguajes que no supongan una penalización del rendimiento al arrancar en frío.

Utilice políticas de escalado por pasos y escalado no centrado en el seguimiento de destino. Dispone de varias opciones de escalado automático de aplicaciones para las tareas de Amazon ECS. El seguimiento de destinos es el modo más fácil de utilizar. Con él, todo lo que necesita hacer es establecer un valor objetivo para una métrica, como la utilización media de la CPU. Luego, el escalador automático administra de forma automática la cantidad de tareas necesarias para alcanzar ese valor. Con el escalado por pasos, puede reaccionar más rápidamente a los cambios en la demanda, ya que define los umbrales específicos para sus métricas de escalado y cuántas tareas agregar o eliminar cuando se superen los umbrales. Y, lo que es más importante, puede reaccionar muy rápidamente ante los cambios en la demanda al minimizar el tiempo que una alarma supera el umbral. Para obtener más información, consulte Servicio de escalado automático en la Guía para desarrolladores de servicio de contenedor elástico de Amazon.

Si utiliza instancias de Amazon EC2 para proporcionar la capacidad del clúster, considere las recomendaciones siguientes:

Utilice instancias de Amazon EC2 más grandes y volúmenes de Amazon EBS más rápidos. Puede mejorar las velocidades de descarga y preparación de imágenes mediante el uso de una instancia de Amazon EC2 más grande y un volumen de Amazon EBS más rápido. Dentro de una familia de instancias de Amazon EC2 determinada, el rendimiento máximo de la red y de Amazon EBS aumenta a medida que aumenta el tamaño de la instancia (por ejemplo, de m5.xlarge a m5.2xlarge). Además, también puede personalizar los volúmenes de Amazon EBS para aumentar el rendimiento y las IOPS. Por ejemplo, si utiliza volúmenes gp2, utilice volúmenes más grandes que ofrezcan más rendimiento de referencia. Si utiliza volúmenes gp3, especifique el rendimiento y las IOPS al crear el volumen.

Utilice el modo de red bridge para las tareas que se ejecutan en las instancias de Amazon EC2. Las tareas que utilizan el modo de red bridge en Amazon EC2 se inician más rápido que las tareas que utilizan el modo de red awsvpc. Cuando se utiliza el modo de red awsvpc, Amazon ECS conecta una interfaz de red elástica (ENI) a la instancia antes de lanzar la tarea. Esto introduce una latencia adicional. Sin embargo, el uso de redes bridge tiene varias desventajas. Estas tareas no tienen su propio grupo de seguridad y el equilibrio de carga tiene algunas implicaciones. Para obtener más información, consulte Load balancer target groups en la Guía del usuario de Elastic Load Balancing.

Gestión de crisis de demanda

Algunas aplicaciones experimentan grandes crisis de demanda repentinas. Esto ocurre por diversas razones: una noticia, una gran venta, un evento mediático o algún otro evento que se vuelva viral y provoque un aumento rápido y significativo del tráfico en muy poco tiempo. Si no se planifica, esto puede provocar que la demanda supere rápidamente los recursos disponibles.

La mejor manera de gestionar las crisis de demanda es anticiparse a ellas y planificar en consecuencia. Como el escalado automático puede llevar tiempo, le recomendamos que escale horizontalmente la aplicación antes de que comience la crisis de demanda. Para obtener los mejores resultados, recomendamos tener un plan empresarial que implique una estrecha colaboración entre los equipos que utilicen un calendario compartido. El equipo que planifique el evento debe trabajar en estrecha colaboración con el equipo a cargo de la aplicación con antelación. Esto le da al equipo tiempo suficiente para tener un plan de programación claro. Pueden programar el escalado horizontal de la capacidad antes del evento y la reducción horizontal después del evento. Para obtener más información, consulte Escalado programado en la Guía del usuario de Auto Scaling de aplicaciones.

Si tiene el plan Enterprise Support, asegúrese de trabajar también con su administrador técnico de cuentas (TAM). El TAM puede verificar sus cuotas de servicio y asegurarse de que se aumenten las cuotas necesarias antes de que comience el evento. De esta forma, no alcanza accidentalmente ninguna cuota de servicio. También puede ayudarlo con servicios de precalentamiento, como los equilibradores de carga, para garantizar que el evento se desarrolle sin problemas.

Gestionar las crisis no programadas de demanda es un problema más difícil. Las crisis no programadas, si son lo suficientemente grandes en amplitud, pueden provocar rápidamente que la demanda supere a la capacidad. También puede superar la capacidad de reacción del escalado automático. La mejor manera de prepararse para las crisis no programadas es aprovisionar recursos en exceso. Debe disponer de recursos suficientes para gestionar la máxima demanda de tráfico prevista en cualquier momento.

Mantener la máxima capacidad para anticiparse a las crisis no programadas de demanda puede resultar costoso. Para mitigar el impacto en los costos, busque un indicador, métrica o evento principal que prediga la inminencia de una gran crisis de demanda. Si la métrica o el evento avisan de forma fiable y con suficiente antelación, comience el proceso de escalado horizontal inmediatamente cuando se produzca el evento o cuando la métrica supere el umbral específico que haya establecido.

Si su aplicación es propensa a sufrir crisis repentinas y no programadas de demanda, considere la posibilidad de agregar un modo de alto rendimiento a la aplicación que sacrifique la funcionalidad no crítica pero que conserve la funcionalidad crucial para un cliente. Por ejemplo, supongamos que su aplicación puede pasar de generar costosas respuestas personalizadas a ofrecer una página de respuestas estática. En este escenario, puede aumentar el rendimiento de manera significativa sin escalar la aplicación en absoluto.

Por último, puede considerar la posibilidad de separar los servicios monolíticos para hacer frente mejor a las crisis de demanda. Si su aplicación es un servicio monolítico cuya ejecución es costosa y su escalado es lento, es posible que pueda extraer o reescribir las partes fundamentales para el rendimiento y ejecutarlas como servicios independientes. De este modo, estos nuevos servicios se pueden escalar de forma independiente de los componentes menos críticos. Disponer de la flexibilidad necesaria para escalar horizontalmente las funciones esenciales para el rendimiento de forma independiente de otras partes de la aplicación puede reducir el tiempo que se tarda en agregar capacidad y ayudar a ahorrar costos.