Балансировщики нагрузки
Балансировщик нагрузки служит для приема входящего трафика и передачи его на эндпоинты бэкендов. Маршрутизация запросов происходит по настройкам обработчиков балансировщика. Подача трафика на бэкенды настраивается в группах бэкендов.
Балансировщик хранит список эндпоинтов, куда должен направляться поступающий трафик и снимает TLS-шифрование перед отправкой трафика на бэкенды. При работе с TLS балансировщик использует современные протоколы (TLSv1.2, TLSv1.3) и шифры. Если балансировщик нагрузки будет обслуживать несколько доменов, можно сконфигурировать разные сертификаты и разные HTTP-роутеры для разных доменов, используя механизм TLS SNI.
Для удобства и безопасности можно использовать балансировщик вместе с сервисом Yandex Certificate Manager для хранения ваших TLS-сертификатов. Также можно задействовать сервисы Yandex Monitoring для мониторинга обработки запросов.
Группы безопасности
Примечание
Группы безопасности находятся на стадии Preview. Если они недоступны в вашей сети, для ресурсов будет разрешен весь входящий и исходящий трафик и дополнительной настройки не требуется.
При создании балансировщика указываются группы безопасности — они содержат набор правил, по которым балансировщик получает входящий трафик и отправляет его на виртуальные машины бэкендов. Каждой ВМ также назначены группы безопасности.
Чтобы балансировщик работал корректно:
- Группы безопасности балансировщика должны разрешать:
- Получение внешнего входящего трафика на портах, указанных в обработчике. Например, для HTTP(S)-трафика — TCP-соединения на портах
80
и443
с любых адресов (CIDR —0.0.0.0/0
). - Получение входящего трафика для проверки состояния узлов балансировщика в разных зонах доступности — TCP-соединения на порте
30080
с источникомПроверки состояния балансировщика
. - Отправку трафика на ВМ бэкендов. Например, любые исходящие соединения на внутренние адреса ВМ (CIDR —
<внутренний IP ВМ>/32
), в подсе́ти или группы безопасности, содержащие ВМ.
- Получение внешнего входящего трафика на портах, указанных в обработчике. Например, для HTTP(S)-трафика — TCP-соединения на портах
- Группы безопасности ВМ бэкендов должны разрешать получение входящего трафика от балансировщика на портах, указанных в группах бэкендов. Например, любые входящие соединения из подсетей, в которых расположен балансировщик, или хотя бы из одной из его групп безопасности.
Расположение балансировщика
При создании балансировщика указываются сеть и подсети в зонах доступности. В этих подсетях будут располагаться узлы балансировщика нагрузки. Трафик на бэкенды приложения будет поступать от узлов балансировщика в этих подсетях.
О рекомендуемом размере подсетей для балансировщика см. ниже.
Балансировщик можно отключить в выбранных зонах доступности. В этом случае внешний трафик перестанет поступать на узлы балансировщика в этих зонах доступности. При этом узлы балансировщика в других зонах продолжат подавать трафик на бэкенды в зонах, где балансировщик был отключен, если настройки локализации трафика позволяют это.
Автомасштабирование и ресурсные единицы
В каждой зоне доступности балансировщика создается внутренняя группа виртуальных машин, которые называются ресурсными единицами.
Одна ресурсная единица рассчитана на следующие максимальные показатели:
- 1000 запросов в секунду (RPS);
- 4000 одновременно активных соединений;
- 200 новых соединений в секунду;
- 22 МБ (176 Мбит) трафика в секунду.
Группа ресурсных единиц автоматически масштабируется в зависимости от внешней нагрузки на узлы балансировщика. Размер группы вычисляется таким образом, чтобы на каждую единицу приходилась нагрузка, не превышающая пороговые значения.
Например, рассмотрим следующую нагрузку:
- 6000 RPS;
- 29 000 одновременно активных соединений;
- 500 новых соединений в секунду;
- 20 МБ трафика в секунду.
Эти показатели соответствуют 8 ресурсным единицам:
- 6000 / 1000 = 6 — количество ресурсных единиц, рассчитанное на 6000 RPS.
- 29 000 / 4000 = 7,25 ~ 8 — количество единиц, рассчитанное на 30 000 активных соединений.
- 500 / 200 = 2,5 ~ 3 — количество единиц, рассчитанное на 500 новых соединений.
- 20 / 22 = 0,9090... ~ 1 — количество единиц, рассчитанное на 20 МБ трафика в секунду.
По умолчанию минимальное количество ресурсных единиц в каждой зоне доступности — 2. Его можно увеличить в настройках автомасштабирования. Подробнее см. ниже.
От количества ресурсных единиц зависит стоимость использования балансировщика. Подробнее см. в разделе Правила тарификации для Yandex Application Load Balancer.
Настройки автомасштабирования
В настройках балансировщика вы можете указать:
- Минимальное количество ресурсных единиц в каждой зоне доступности
-
Если вы ожидаете повышенную нагрузку на балансировщик, то можете заранее увеличить минимальное количество ресурсных единиц в каждой зоне, чтобы не дожидаться, когда оно увеличится вслед за нагрузкой.
По умолчанию минимум равен 2. Указать минимальное значение меньше 2 нельзя.
- Максимальное суммарное количество ресурсных единиц
-
Стоимость использования балансировщика зависит от количества его ресурсных единиц (см. правила тарификации). По умолчанию количество не ограничено. Вы можете установить ограничение, чтобы контролировать расходы.
Если указанное максимальное количество слишком мало для нагрузки, оказываемой на балансировщик, он может работать некорректно.
Значение должно быть не меньше, чем количество зон доступности балансировщика, умноженное на минимальное количество ресурсных единиц в каждой зоне.
Настроить автомасштабирование группы ресурсных единиц балансировщика можно при его создании или изменении.
Рекомендуемые размеры подсетей
Чтобы Application Load Balancer обеспечивал доступность балансировщика, как указано в документе об уровне обслуживания сервиса, в подсетях балансировщика должно быть доступно достаточное количество внутренних IP-адресов. Рекомендуется рассчитывать размер подсетей так, чтобы на каждую ресурсную единицу пикового потребления приходилось минимум по два свободных IP-адреса.
Например, если балансировщик использует в каждой зоне доступности 8 ресурсных единиц, как в примере, то в каждой подсети рекомендуется иметь хотя бы 8 × 2 = 16 свободных адресов. Для балансировщика желательно указать подсети размером не меньше /27.
Обработчик
Обработчик определяет, на каких портах, адресах и по каким протоколам балансировщик будет принимать трафик.
Принципы маршрутизации запросов к группам бэкендов зависят от типа обработчика:
- HTTP: балансировщик принимает HTTP- или HTTPS-запросы и распределяет их между группами бэкендов по правилам, описанным в HTTP-роутерах, либо перенаправляет HTTP-запросы на HTTPS. Группы бэкендов, получающие трафик, должны иметь тип HTTP или gRPC.
- Stream: балансировщик принимает входящий трафик в открытых или зашифрованных TCP-соединениях и транслирует его группам бэкендов типа Stream.
Если обработчик принимает зашифрованный трафик, для него настраиваются основной обработчик и необязательные обработчики SNI. В каждом обработчике SNI доменному имени, указанному при установке TLS-соединения как Server Name Indication (SNI), сопоставляются TLS-сертификат и HTTP-роутер (если тип обработчика — HTTP) либо группа бэкендов (если тип обработчика — Stream). Основной обработчик отвечает за TLS-соединения с доменными именами, которым не соответствует ни один обработчик SNI.
Совет
Некоторые браузеры переиспользуют TLS-соединения с одним IP-адресом, если в сертификате соединения есть нужное доменное имя. При этом обработчик SNI заново не выбирается, и трафик может направляться в неправильный HTTP-роутер. Используйте разные сертификаты в разных обработчиках SNI и в основном обработчике. Для распределения трафика между доменными именами одного сертификата настройте виртуальные хосты HTTP-роутера.
Один балансировщик может обслуживать и обычный, и шифрованный трафик на разных портах, а также иметь публичные и внутренние IP-адреса на разных обработчиках.
Пример
Обработчик может описывать прием HTTP-трафика на 80-м порту и делать перенаправление на 443 порт и протокол HTTPS. Обработчик получит HTTP-запрос от клиента и вернет ответ с HTTP-кодом 302. Дальнейшие запросы будут поступать уже на порт 443 по протоколу HTTPS.
Если используется HTTPS-обработчик, то необходимо указать сертификат из Certificate Manager который будет использоваться для терминирования TLS.
Статистика
Статистика работы балансировщика автоматически записывается в метрики сервиса Yandex Monitoring. Доступны следующие показатели:
- RPS — количество запросов к балансировщику в секунду (requests per second).
- 4XX, 5XX — количество ответов балансировщика с HTTP-кодами 4XX и 5XX и соответствующими им gRPC-кодами в секунду.
- Request size — суммарный объем запросов к балансировщику в секунду.
- Response size — суммарный объем ответов балансировщика в секунду.
- Latency — задержка ответа (время от получения балансировщиком первого байта запроса до отправки последнего байта ответа), от 50-го до 99-го перцентиля.
В Application Load Balancer доступна обобщенная статистика балансировщика. В Yandex Monitoring можно смотреть статистику с разбивкой по ресурсам, привязанным к балансировщику (HTTP-роутерам, виртуальным хостам, маршрутам и т. д.), а также создавать алерты.
Инструкции по просмотру статистики см. в разделе Посмотреть статистику L7-балансировщика.
Логирование
При создании балансировщика для него создается лог-группа, в которую записываются сообщения о входящих запросах. Логи можно посмотреть в консоли управления. Полный список параметров представлен в справочнике логов.
По практическому руководству Запись логов балансировщика в PostgreSQL можно настроить обработку логов с помощью Yandex Cloud Functions.