Веб-разработка

AWS ELB: выбрать балансировщик и проверить targets

Elastic Load Balancing — семейство балансировщиков AWS, которое распределяет трафик между зарегистрированными целями. Оно масштабирует возможности самого балансировщика при изменении нагрузки. Запуск и замену EC2-инстансов обычно организуют отдельно, например через EC2 Auto Scaling: проверка здоровья сама по себе не создаёт новый сервер.

Какой тип нужен

Тип	Задача
Application Load Balancer	HTTP/HTTPS-приложение; правила по hostname, пути и другим условиям запроса.
Network Load Balancer	Сетевой трафик на транспортном уровне; подходящий listener и протокол выбираются по требованиям сервиса.
Gateway Load Balancer	Распределение IP-трафика между сетевыми устройствами обработки, например firewall appliances.
Classic Load Balancer	Предыдущее поколение. Для нового решения сначала рассматривайте современные типы.

Поддержка target types, TLS, sticky sessions и интеграций зависит от конкретного типа и конфигурации. Список возможностей ALB нельзя автоматически приписывать NLB или GWLB. Наличие ELB также не означает, что приложение уже защищено WAF.

Путь запроса в ALB

Клиент → listener (протокол и порт)
       → подходящее правило
       → target group
       → зарегистрированный target

У listener есть правило по умолчанию; дополнительные правила обрабатываются по приоритету. Например, /api/* и остальные пути могут вести в разные target groups. Health checks настраиваются для каждой группы, а не заменяют проверку маршрута целиком.

Проверить здоровье существующей группы

Если AWS CLI уже авторизован в нужном аккаунте и регионе, прочитайте состояние, подставив реальный ARN своей группы:

aws elbv2 describe-target-health \
  --target-group-arn 'ARN_ВАШЕЙ_TARGET_GROUP' \
  --query 'TargetHealthDescriptions[].{Target:Target.Id,State:TargetHealth.State,Reason:TargetHealth.Reason}' \
  --output table

Это чтение состояния уже существующей инфраструктуры. initial означает регистрацию или начальную проверку, healthy — успешную проверку, unhealthy — ошибку проверки. unused указывает на цель, которая не используется для маршрутизации, а draining — на прекращение её обслуживания. Причина вроде Target.Timeout или Target.ResponseCodeMismatch помогает выбрать следующий шаг.

Почему одного healthy мало

Health endpoint должен показывать готовность обслуживать запрос, а не только наличие процесса. Проверьте протокол, порт, путь и ожидаемый HTTP-код.
Пройдите реальный URL через listener: правильный target может быть привязан к неверному правилу.
Проверьте сеть между балансировщиком и приложением, сертификат и поведение таймаутов.
Отдельно проверьте отказ одного target и восстановление. Держать единственный сервер за балансировщиком недостаточно для отказоустойчивости приложения.

Важное исключение для ALB: когда все зарегистрированные targets в группе нездоровы, он может работать в режиме fail-open и направлять запросы к ним. Поэтому обещание «любой трафик всегда идёт только к здоровым узлам» неверно. Sticky sessions также не заменяют общее хранилище состояния и план отказа узла.

До создания ресурсов оцените стоимость выбранного типа, трафика и связанных сервисов. Универсальной гарантии задержки или равномерного числа запросов на каждый backend нет: результат зависит от алгоритма, протокола и длительности соединений.