Целевые группы и проверки работоспособности

Целевая группа — это логическая совокупность целей, к которым балансировщик нагрузки направляет запросы. У каждой целевой группы есть тип цели, протокол/порт и конфигурация проверки работоспособности. Балансировщик нагрузки распределяет запросы между зарегистрированными целями целевой группы, которые успешно проходят проверки работоспособности.

Целевые группы связываются с прослушивателями балансировщика нагрузки через правила прослушивателя. Один прослушиватель может направлять запросы в несколько целевых групп на основе атрибутов запроса. Это основной механизм маршрутизации по пути и хосту в ALB.

Целевые группы поддерживают три типа целей:

• instance: направляет запросы к экземплярам EC2 по идентификатору экземпляра; балансировщик нагрузки отправляет трафик на основной сетевой интерфейс экземпляра через указанный порт
• ip: направляет запросы к частным IP-адресам — это удобно для целей в контейнерах (ECS/EKS), локальных серверов, доступных через VPN/Direct Connect, или дополнительных IP-адресов экземпляров EC2
• lambda: направляет запросы к одной функции Lambda (только ALB); ALB преобразует HTTP-запрос в событие JSON и синхронно вызывает функцию

Тип цели IP необходим для задач ECS с сетевым режимом awsvpc (каждая задача получает собственный IP-адрес), для модулей EKS и для гибридных архитектур с локальными целями.

Вы регистрируете цели в группе целей вручную (в консоли или через CLI) или автоматически (при подключении Auto Scaling Group или настройке сервиса ECS). Цели, зарегистрированные вручную, остаются в группе, пока вы явно не отмените их регистрацию.

Для ASG вы подключаете ASG к группе целей, после чего ASG автоматически регистрирует вновь запущенные экземпляры и отменяет регистрацию завершённых. Такая тесная интеграция с ASG является стандартным подходом для эластичных вычислительных уровней: новые экземпляры становятся доступными и начинают получать трафик сразу после успешного прохождения проверки работоспособности.

С каждой группой целей связана проверка работоспособности, которую балансировщик нагрузки использует, чтобы определить, исправна ли цель и может ли она получать трафик. Проверка работоспособности периодически отправляет запросы каждой цели и оценивает ответ:

• Protocol: HTTP, HTTPS или TCP (для NLB)
• Путь: путь URL, который нужно запросить (например, /health или /ping)
• Port: проверяемый порт (по умолчанию используется порт группы целей)
• Порог исправности: число последовательных успешных проверок до признания цели исправной
• Порог неисправности: число последовательных неудачных проверок до признания цели неисправной
• Интервал: количество секунд между проверками работоспособности (5–300)
• Тайм-аут: количество секунд ожидания ответа

Для проверок работоспособности HTTP/HTTPS вы указываете, какие коды ответа HTTP означают, что цель исправна. По умолчанию используется 200, но можно настроить диапазоны, например 200-299, или значения, разделённые запятыми, например 200,301,302.

Рекомендуется создать в приложении отдельную конечную точку /health, которая возвращает 200 только тогда, когда доступны все критически важные зависимости (подключение к базе данных, кэш, нижестоящий сервис). Не используйте корневой URL (/) в качестве пути проверки работоспособности, если его обработка требует значительных ресурсов или аутентификации.

После регистрации цель проходит следующие состояния:

• начальное: ELB выполняет первые проверки работоспособности
• исправна: цель прошла необходимое количество последовательных проверок; получает трафик
• неисправна: цель не прошла необходимое количество последовательных проверок; исключена из распределения
• освобождение: выполняется отмена регистрации; существующим соединениям разрешено завершиться, но новые соединения не направляются
• не используется: цель зарегистрирована в группе, но ни одно правило прослушивателя в данный момент не направляет трафик в эту группу

Следите за метриками CloudWatch UnHealthyHostCount и HealthyHostCount, чтобы выявлять проблемы в пуле целей.

Задержка отмены регистрации (ранее называлась освобождением соединений) — это время, в течение которого ELB ожидает завершения существующих соединений, прежде чем окончательно отменить регистрацию цели. Значение по умолчанию — 300 секунд (5 минут). В этот период новые запросы не направляются к цели, регистрацию которой отменяют, но уже выполняющиеся запросы могут завершиться.

Для быстрых развёртываний и завершения работы экземпляров при автоматическом масштабировании можно уменьшить это значение до 30–60 секунд, если приложение быстро обрабатывает запросы. Для длительных операций (загрузки файлов, обработка видео) оставьте достаточно времени, чтобы эти операции завершились без прерывания.

Группы целей поддерживают разные алгоритмы балансировки нагрузки:

• Циклическое распределение (алгоритм ALB по умолчанию): запросы равномерно распределяются по очереди; оптимально, когда все цели равноценны
• Наименьшее число незавершённых запросов (ALB): каждый новый запрос направляется к цели с наименьшим числом выполняющихся запросов; лучше подходит для рабочих нагрузок с переменной длительностью, когда одни запросы выполняются дольше других
• Хеш потока (NLB): распределение выполняется на основе протокола, IP-адресов источника и назначения, Port источника и назначения, а также порядкового номера TCP; это гарантирует, что все пакеты одного потока TCP/UDP попадут к одной цели

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

Одно правило прослушивателя ALB может распределять трафик между несколькими группами целей с помощью групп целей с весами. Например, можно направить 90% трафика в стабильную группу целей и 10% — в канареечную группу для сине-зелёных развёртываний, не используя распределение по весам Route 53.

Группы целей с весами настраиваются на уровне правила прослушивателя. Веса являются относительными: соотношение 90/10 направляет 90% трафика в первую группу и 10% — во вторую. Это отличается от распределения по весам между несколькими ALB: здесь распределение выполняется внутри одного правила прослушивателя ALB.

При развёртывании сервисов ECS за ALB каждая задача ECS регистрируется в группе целей ALB с использованием типа цели ip (для сетевого режима awsvpc). Сервис ECS автоматически управляет регистрацией и отменой регистрации: новые задачи регистрируются после успешного прохождения проверок работоспособности, а остановка задач запускает задержку отмены регистрации перед завершением работы.

Каждый сервис ECS может регистрироваться с отдельным переопределением порта, что позволяет нескольким сервисам ECS совместно использовать один ALB через разные правила прослушивателя (на основе пути или узла) с разными группами целей — это распространённый шаблон микросервисной архитектуры.

Поведение проверок работоспособности NLB отличается от ALB:

• NLB поддерживает протоколы проверок работоспособности TCP, HTTP и HTTPS независимо от протокола прослушивателя
• Проверки работоспособности NLB отправляются с IP-адресов NLB в каждой AZ; убедитесь, что группы безопасности разрешают трафик с IP-адресов подсетей NLB, или используйте группу безопасности самого NLB
• При проверках работоспособности TCP NLB считает цель исправной, если она принимает TCP-соединение на указанном порту
• Цели NLB, не прошедшие проверки работоспособности, исключаются в соответствующей AZ; если все цели в AZ неисправны, NLB может выполнять межзонную балансировку нагрузки на исправные цели в других AZ (если межзонная балансировка LB включена)

В этом уроке вы узнали, что группы целей содержат исправные зарегистрированные цели типа экземпляр, IP или Lambda, проверки работоспособности периодически проверяют цели, чтобы исключать неисправные из распределения, а задержка отмены регистрации обеспечивает корректное освобождение выполняющихся запросов перед удалением цели. Далее мы рассмотрим правила прослушивателя и маршрутизацию на основе пути в ALB.