Автоматическое масштабирование сервисов ECS и балансировка нагрузки

Фиксированное желаемое количество задач в сервисе ECS не может реагировать на колебания трафика: либо Вы выделяете слишком много ресурсов и тратите деньги впустую, либо слишком мало и снижаете производительность. Автоматическое масштабирование сервиса ECS автоматически изменяет желаемое количество задач в зависимости от метрик CloudWatch. В основе используется сервис Application Auto Scaling — тот же механизм, который применяется для DynamoDB, Aurora и ElastiCache. Автоматическое масштабирование сервиса ECS поддерживает политики отслеживания цели, пошагового и планового масштабирования.

Прежде чем добавлять политики масштабирования, зарегистрируйте сервис ECS как масштабируемую цель в Application Auto Scaling. Укажите минимальное и максимальное количество задач, имя кластера и имя сервиса в качестве идентификатора ресурса. Это задаёт границы, в пределах которых будет работать автоматическое масштабирование. Минимальное количество гарантирует наличие базовой ёмкости, а максимальное не позволяет неконтролируемому масштабированию исчерпать ёмкость Fargate или ресурсы экземпляров EC2.

Target Tracking — рекомендуемая политика автоматического масштабирования для большинства сервисов ECS. Наиболее распространённая целевая метрика — ECSServiceAverageCPUUtilization: задайте цель на уровне 50–70 %, и ECS будет добавлять или удалять задачи, поддерживая этот уровень загрузки CPU. Ещё одна эффективная метрика — количество запросов ALB на цель: отслеживайте число запросов ALB на задачу и масштабируйте сервис, поддерживая целевую частоту запросов на экземпляр. AWS автоматически выполняет масштабирование и уменьшение масштаба с подходящими периодами ожидания.

Подключение Application Load Balancer (ALB) к сервису ECS распределяет трафик HTTP/HTTPS между всеми работающими задачами. Целевая группа ALB регистрирует IP-адрес каждой задачи (для Fargate/awsvpc) или порт контейнера (для режима bridge). ECS автоматически регистрирует новые задачи в целевой группе при их запуске и удаляет их регистрацию при остановке. ALB выполняет проверки работоспособности каждой задачи; неисправные задачи переводятся в режим завершения обслуживания (соединения корректно закрываются), прежде чем сервис их остановит.

Один из эффективных подходов — направлять разные пути URL к разным сервисам ECS с помощью маршрутизации ALB по путям. Один ALB с одним прослушивателем HTTPS может направлять: /api/orders/* в сервис ECS Orders, /api/users/* в сервис ECS Users, /api/products/* в сервис ECS Products — каждый из них работает в собственном сервисе ECS с независимым масштабированием. Это устраняет необходимость в отдельных балансировщиках нагрузки для каждого микросервиса, снижает затраты и упрощает управление DNS.

Когда задача ECS завершается (при уменьшении масштаба или развёртывании), ALB помечает её как завершающую обслуживание и прекращает направлять к ней новые запросы, позволяя текущим запросам завершиться. Задержка удаления регистрации (по умолчанию 300 секунд, настраивается в диапазоне 0–3600 секунд) — это время, в течение которого ALB ожидает перед принудительным закрытием соединений. Для ECS с короткими запросами задайте меньшую задержку удаления регистрации (30–60 секунд), чтобы ускорить развёртывания и операции уменьшения масштаба. Для долгих соединений (WebSocket, загрузка файлов) оставьте более высокую задержку.

Помимо CPU и памяти, публикуйте из приложения пользовательские метрики CloudWatch (глубина очереди, активные сеансы, ключевые бизнес-показатели) и используйте их для управления масштабированием. Например, если каждая задача ECS может одновременно обрабатывать 50 сообщений очереди, публикуйте глубину очереди SQS как пользовательскую метрику и создайте политику отслеживания цели со значением 50 сообщений на задачу. Так масштабирование напрямую определяется бизнес-логикой, а не инфраструктурными метриками, которые могут не отражать нагрузку приложения.

Как и автоматическое масштабирование EC2, ECS поддерживает защиту задачи от уменьшения масштаба. Работающая задача может через API ECS установить для себя флаг защиты от уменьшения масштаба, чтобы не завершиться во время уменьшения масштаба при обработке критически важной работы. Это полезно для задач ECS, выполняющих роль обработчиков SQS: обработчик, только что извлёкший длинную задачу из очереди, может защитить себя, завершить работу, а затем снять защиту. Без этого уменьшение масштаба может завершить задачу в процессе обработки, что приведёт к дублированию работы или потере данных.

Тщательно выбирайте метрику масштабирования. Загрузка CPU используется по умолчанию и подходит для задач, ограниченных вычислительными ресурсами. Загрузка памяти (ECSServiceAverageMemoryUtilization) полезна для приложений, ограниченных объёмом памяти, но увеличение доступной памяти требует добавления задач. Если задача ограничена объёмом памяти на задачу, а не количеством одновременно обрабатываемых запросов, лучше изменить распределение памяти в определении задачи. Количество запросов ALB на цель напрямую связано с пользовательским опытом и является наиболее практичной метрикой для веб-API: масштабируйте сервис на основе фактической частоты запросов на задачу.

Автоматический выключатель развёртывания ECS автоматически обнаруживает неудачные развёртывания и выполняет откат к последней стабильной версии. Без него неудачное развёртывание (контейнер, не проходящий проверки работоспособности) заставило бы ECS бесконечно пытаться запускать новые задачи. Если выключатель включён и определённая доля недавно запущенных задач не проходит проверки работоспособности в течение окна обнаружения, ECS помечает развёртывание как FAILED и автоматически выполняет откат к предыдущей версии определения задачи. Это предотвращает длительное ухудшение работы сервиса из-за неудачных развёртываний.

Готовая для промышленной эксплуатации архитектура контейнеризированного веб-API: Route 53 разрешает домен в DNS-имя ALB; ALB завершает HTTPS (сертификат ACM), применяет правила WAF и направляет запросы в целевую группу сервиса ECS; задачи Fargate в частных подсетях трёх AZ обрабатывают запросы; автоматическое масштабирование сервиса ECS с отслеживанием цели по количеству запросов ALB на цель изменяет количество задач от 2 до 50; задачи подключаются к RDS Aurora и ElastiCache в частных подсетях. Все журналы передаются в журналы CloudWatch; метрики используются для панелей мониторинга и оповещений CloudWatch.

Проверьте, насколько хорошо Вы поняли концепции AWS Solutions Architect (SAA-C03) из этого урока.

В этом уроке Вы узнали, что автоматическое масштабирование сервиса ECS использует Application Auto Scaling с отслеживанием цели (по CPU, запросам ALB или пользовательским метрикам), чтобы изменять количество задач в заданных минимальных и максимальных границах; маршрутизация ALB по путям позволяет одному балансировщику обслуживать несколько микросервисов ECS, направляя пути URL в разные целевые группы; а автоматический выключатель развёртывания автоматически откатывает неудачные развёртывания до того, как они вызовут длительное ухудшение работы сервиса. На этом завершается модуль по ECS и контейнерам. Далее мы рассмотрим Amazon EKS для Kubernetes в AWS.