Yandex Cloud
  • Сервисы
  • Решения
  • Почему Yandex Cloud
  • Сообщество
  • Тарифы
  • Документация
  • Связаться с нами
Подключиться
Language / Region
Проект Яндекса
© 2023 ООО «Яндекс.Облако»
Yandex Application Load Balancer
  • Начало работы
  • Пошаговые инструкции
    • Все инструкции
    • Целевые группы
      • Создать целевую группу
      • Изменить целевую группу
      • Удалить целевую группу
    • Группы бэкендов
      • Создать группу бэкендов
      • Изменить группу бэкендов
      • Удалить группу бэкендов
    • HTTP-роутеры
      • Создать HTTP-роутер для HTTP-трафика
      • Создать HTTP-роутер для gRPC-трафика
      • Изменить HTTP-роутер
      • Удалить HTTP-роутер
    • L7-балансировщики
      • Создать L7-балансировщик
      • Изменить L7-балансировщик
      • Посмотреть статистику L7-балансировщика
      • Посмотреть логи L7-балансировщика
      • Получить идентификатор лог-группы L7-балансировщика
      • Остановить и запустить L7-балансировщик
      • Удалить L7-балансировщик
    • Инструменты для Managed Service for Kubernetes
      • Установить Ingress-контроллер
      • Установить Gateway API
      • Создать или изменить ресурсы по конфигурации
  • Практические руководства
    • Все практические руководства
    • Организация виртуального хостинга
    • Создание балансировщика с защитой от DDoS
    • Интеграция L7-балансировщика с CDN и Object Storage
    • Сине-зеленое и канареечное развертывание версий сервиса
    • Терминирование TLS-соединений
    • Запись логов балансировщика в PostgreSQL
    • Развертывание и нагрузочное тестирование gRPC-сервиса с масштабированием
  • Концепции
    • Обзор
    • Балансировщики нагрузки
    • HTTP-роутеры
    • Группы бэкендов
    • Целевые группы
    • Квоты и лимиты
  • Инструменты для Managed Service for Kubernetes
    • Ingress-контроллер
      • Обзор
      • Принципы работы
    • Gateway API
    • Необходимые настройки
      • Группы безопасности
      • Сервисный аккаунт
  • Управление доступом
  • Правила тарификации
  • Справочник API
    • Аутентификация в API
    • gRPC (англ.)
      • Overview
      • BackendGroupService
      • HttpRouterService
      • LoadBalancerService
      • TargetGroupService
      • VirtualHostService
      • OperationService
    • REST (англ.)
      • Overview
      • BackendGroup
        • Overview
        • addBackend
        • create
        • delete
        • get
        • list
        • listOperations
        • removeBackend
        • update
        • updateBackend
      • HttpRouter
        • Overview
        • create
        • delete
        • get
        • list
        • listOperations
        • update
      • LoadBalancer
        • Overview
        • addListener
        • addSniMatch
        • create
        • delete
        • get
        • getTargetStates
        • list
        • listOperations
        • removeListener
        • removeSniMatch
        • start
        • stop
        • update
        • updateListener
        • updateSniMatch
      • TargetGroup
        • Overview
        • addTargets
        • create
        • delete
        • get
        • list
        • listOperations
        • removeTargets
        • update
      • VirtualHost
        • Overview
        • create
        • delete
        • get
        • list
        • removeRoute
        • update
        • updateRoute
  • Справочники инструментов для Managed Service for Kubernetes
    • Обзор
    • Ingress-контроллер
      • Ingress
      • HttpBackendGroup
    • Gateway API
      • Gateway
      • HTTPRoute
    • Service
  • Справочник логов
  1. Концепции
  2. Балансировщики нагрузки

Балансировщики нагрузки

Статья создана
Yandex Cloud
  • Группы безопасности
  • Расположение балансировщика
  • Автомасштабирование и ресурсные единицы
    • Настройки автомасштабирования
    • Рекомендуемые размеры подсетей
  • Обработчик
    • Пример
  • Статистика
  • Логирование

Балансировщик нагрузки служит для приема входящего трафика и передачи его на эндпоинты бэкендов. Маршрутизация запросов происходит по настройкам обработчиков балансировщика. Подача трафика на бэкенды настраивается в группах бэкендов.

Балансировщик хранит список эндпоинтов, куда должен направляться поступающий трафик и снимает 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), в подсе́ти или группы безопасности, содержащие ВМ.
  • Группы безопасности ВМ бэкендов должны разрешать получение входящего трафика от балансировщика на портах, указанных в группах бэкендов. Например, любые входящие соединения из подсетей, в которых расположен балансировщик, или хотя бы из одной из его групп безопасности.

Расположение балансировщика

При создании балансировщика указываются сеть и подсети в зонах доступности. В этих подсетях будут располагаться узлы балансировщика нагрузки. Трафик на бэкенды приложения будет поступать от узлов балансировщика в этих подсетях.

О рекомендуемом размере подсетей для балансировщика см. ниже.

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

Автомасштабирование и ресурсные единицы

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

Одна ресурсная единица рассчитана на следующие максимальные показатели:

  • 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.

Была ли статья полезна?

Language / Region
Проект Яндекса
© 2023 ООО «Яндекс.Облако»
В этой статье:
  • Группы безопасности
  • Расположение балансировщика
  • Автомасштабирование и ресурсные единицы
  • Настройки автомасштабирования
  • Рекомендуемые размеры подсетей
  • Обработчик
  • Пример
  • Статистика
  • Логирование