Auto Scaling y balanceo de carga de servicios de ECS

Un desired count fijo en un servicio de ECS no puede responder a las fluctuaciones del tráfico: puede aprovisionar recursos en exceso (desperdiciando dinero) o por defecto (degradando el rendimiento). ECS Service Auto Scaling ajusta automáticamente el número deseado de tareas en respuesta a las métricas de CloudWatch. Internamente utiliza el servicio Application Auto Scaling, el mismo framework que usan DynamoDB, Aurora y ElastiCache. El autoescalado de servicios de ECS admite políticas de seguimiento de objetivos, escalado por pasos y escalado programado.

Antes de añadir políticas de escalado, registre el servicio de ECS como un scalable target en Application Auto Scaling. Especifique el número mínimo y máximo de tareas, el nombre del clúster y el nombre del servicio como ID del recurso. Esto crea los límites dentro de los cuales operará el autoescalado. El número mínimo garantiza que siempre haya capacidad base; el máximo evita que un escalado descontrolado agote la capacidad de Fargate o las instancias EC2.

Target Tracking es la política de autoescalado recomendada para la mayoría de los servicios de ECS. La métrica objetivo más común es ECSServiceAverageCPUUtilization: establezca un objetivo del 50-70 % y ECS añadirá o eliminará tareas para mantener ese nivel de CPU. Otra métrica muy útil es ALBRequestCountPerTarget: realiza un seguimiento del número de solicitudes del ALB por tarea y escala para mantener una tasa objetivo de solicitudes por instancia. AWS gestiona automáticamente el escalado horizontal hacia arriba y hacia abajo, con periodos de espera adecuados.

Asociar un Application Load Balancer (ALB) a un servicio de ECS distribuye el tráfico HTTP/HTTPS entre todas las tareas en ejecución. El grupo de destinos del ALB registra la IP de cada tarea (para Fargate/awsvpc) o el puerto del contenedor (para el modo bridge). ECS registra automáticamente las tareas nuevas en el grupo de destinos cuando se inician y las elimina del registro cuando se detienen. El ALB realiza comprobaciones de estado en cada tarea; las tareas que no están saludables se ponen en proceso de drenaje (las conexiones se cierran correctamente) antes de que el servicio las termine.

Un patrón muy útil consiste en enrutar distintas rutas URL a diferentes servicios de ECS mediante el ALB path-based routing. Un único ALB con un listener HTTPS puede enrutar: /api/orders/* al servicio Orders de ECS, /api/users/* al servicio Users de ECS y /api/products/* al servicio Products de ECS; cada uno respaldado por su propio servicio de ECS con escalado independiente. Esto elimina la necesidad de utilizar balanceadores de carga independientes para cada microservicio, lo que reduce los costes y simplifica la gestión de DNS.

Cuando una tarea de ECS va a terminar (durante un escalado hacia abajo o un despliegue), el ALB la marca como draining y deja de enrutarle solicitudes nuevas, pero permite que finalicen las solicitudes en curso. El deregistration delay (300 segundos de forma predeterminada, configurable entre 0 y 3600 segundos) indica cuánto tiempo espera el ALB antes de cerrar las conexiones por la fuerza. Para ECS con solicitudes de corta duración, establezca un retraso de eliminación del registro menor (30-60 segundos) para acelerar los despliegues y las operaciones de escalado hacia abajo. Para conexiones largas (WebSocket, cargas de archivos), mantenga un retraso mayor.

Además de la CPU y la memoria, publique custom CloudWatch metrics desde su aplicación (profundidad de la cola, sesiones activas, KPI empresariales) y utilícelas para controlar el escalado. Por ejemplo, si cada tarea de ECS puede gestionar 50 mensajes de cola simultáneamente, publique la profundidad de la cola de SQS como métrica personalizada y cree una política de seguimiento de objetivos cuyo objetivo sea 50 mensajes por tarea. Así se consigue un escalado impulsado directamente por la lógica empresarial, en lugar de depender de métricas de infraestructura que quizá no se correlacionen con la carga de la aplicación.

Al igual que EC2 Auto Scaling, ECS admite la task scale-in protection. Una tarea en ejecución puede establecer su propia marca de protección frente al escalado hacia abajo mediante la API de ECS para evitar que se termine durante dicho escalado mientras procesa un trabajo crítico. Esto resulta útil para las tareas de ECS que actúan como trabajadores de SQS: un trabajador que acaba de extraer un trabajo largo de la cola puede protegerse, completarlo y eliminar después la protección. Sin esta medida, el escalado hacia abajo podría terminar una tarea en mitad del procesamiento y provocar la duplicación del trabajo o la pérdida de datos.

Elija cuidadosamente la métrica de escalado. CPU utilisation es la opción predeterminada y funciona para cargas de trabajo limitadas por la capacidad de cómputo. Memory utilisation (ECSServiceAverageMemoryUtilization) resulta útil para aplicaciones limitadas por la memoria, pero aumentar la memoria requiere añadir tareas. Si su tarea está limitada por la memoria asignada por tarea y no por el procesamiento simultáneo, puede ser mejor corregir la asignación de memoria de la definición de tarea. ALBRequestCountPerTarget se correlaciona directamente con la experiencia del usuario y es la métrica más útil para las API web: escale en función de la tasa real de solicitudes por tarea.

El ECS Deployment Circuit Breaker detecta automáticamente los despliegues fallidos y revierte a la última versión estable. Sin él, un despliegue incorrecto (por ejemplo, un contenedor que no supera las comprobaciones de estado) haría que ECS intentara iniciar tareas nuevas indefinidamente. Con el disyuntor habilitado, si un determinado porcentaje de las tareas recién iniciadas no supera las comprobaciones de estado dentro de una ventana de detección, ECS marca el despliegue como FAILED y revierte automáticamente a la revisión anterior de la definición de tarea. Esto evita una degradación prolongada del servicio debido a despliegues incorrectos.

Una arquitectura de API web en contenedores preparada para producción: Route 53 resuelve el dominio al nombre DNS de un ALB; el ALB termina HTTPS (certificado de ACM), aplica reglas de WAF y enruta las solicitudes a un ECS service target group; las tareas de Fargate en subredes privadas de 3 AZ gestionan las solicitudes; ECS Service Auto Scaling, mediante el seguimiento de objetivos en ALBRequestCountPerTarget, ajusta el número de tareas de 2 a 50; las tareas se conectan a RDS Aurora y ElastiCache en subredes privadas. Todos los registros se envían a CloudWatch Logs; las métricas alimentan los paneles y las alarmas de CloudWatch.

Compruebe su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección ha aprendido que ECS Service Auto Scaling utiliza Application Auto Scaling con seguimiento de objetivos (CPU, solicitudes del ALB o métricas personalizadas) para ajustar el número de tareas entre los límites mínimo y máximo configurados; que ALB path-based routing permite que un único balanceador de carga atienda varios microservicios de ECS al enrutar las rutas URL a distintos grupos de destinos; y que Deployment Circuit Breaker revierte automáticamente los despliegues fallidos antes de que provoquen una degradación prolongada del servicio. Con esto concluye el módulo de ECS y contenedores; a continuación exploraremos Amazon EKS para Kubernetes en AWS.