Балансировщик нагрузки распределяет входящие запросы между серверами, держит сервис на плаву при отказе одного из них и позволяет масштабировать инфраструктуру горизонтально.
Что такое балансировщик нагрузки
Распределение запросов между серверами
Балансировщик стоит перед группой одинаковых backend-серверов и раскладывает входящие запросы между ними. Клиент обращается к одному адресу, а за ним работает пул машин — нагрузка делится, и ни один сервер не перегружается, пока есть свободные. Это основа любой масштабируемой архитектуры.
Отказоустойчивость и масштабирование
Две главные выгоды идут вместе. Отказоустойчивость: если backend упал, балансировщик перестает слать на него запросы, и сервис продолжает работать на остальных. Масштабирование: выросла нагрузка — добавили сервер в пул, и балансировщик сразу начал его использовать. Горизонтальный рост вместо замены одной большой машины.
Чем балансировщик отличается от обычного прокси
Обычный reverse proxy просто передает запросы одному backend. Балансировщик — это прокси, который распределяет запросы между многими по алгоритму и следит за их здоровьем. Грань тонкая: тот же Nginx работает и как простой прокси, и как балансировщик — зависит от конфигурации.
Когда один сервер перестает справляться
Порог, за которым нужен балансировщик, у каждого приложения свой, но ориентиры назвать можно. Для типового веб-сайта один сервер уверенно держит сотни запросов в секунду; задумываться о распределении стоит, когда счет идет на тысячи RPS или когда процессор и память backend регулярно уходят за 70-80% в пике.
Второй триггер не связан с нагрузкой вовсе: балансировщик нужен ради отказоустойчивости, даже если трафик скромный. Если простой сервиса недопустим, два backend за балансировщиком ставят не из-за объема запросов, а чтобы поломка одной машины не остановила работу. Это и есть два разных повода: рост нагрузки и требование непрерывности.
L4 и L7: уровни модели OSI
L4: балансировка по портам и IP
L4-балансировщик работает на транспортном уровне — с TCP и UDP. Он видит адреса и порты, но не заглядывает внутрь запроса. Это быстро: пакеты перенаправляются почти без обработки. Подходит для любых протоколов, но не умеет маршрутизировать по содержимому.
L7: балансировка с учетом контента
L7-балансировщик работает на прикладном уровне — с HTTP и HTTPS. Он разбирает запрос и может направлять его по URL, заголовкам или cookie: статику на одни серверы, API на другие. Маршрутизирует по содержимому запроса, но обрабатывает каждый запрос медленнее за счет разбора HTTP.
Когда L4 быстрее, когда L7 умнее
Выбор по задаче. Нужна максимальная скорость и протокол не HTTP — берят L4. Нужна маршрутизация по содержимому, терминация TLS, работа с веб-логикой — берют L7. На практике часто комбинируют: L4 на входе для скорости, L7 глубже для умной маршрутизации.
Алгоритмы балансировки
Round-robin: по очереди
Round robin раздает запросы по кругу: первый серверу A, второй B, третий C, и снова по кругу. Простой и эффективный метод для однородных backend одинаковой мощности. Это вариант по умолчанию в большинстве балансировщиков.
Least connections: на наименее загруженный
Least connections отправляет очередной запрос туда, где меньше активных соединений. Это лучше round-robin для долгих сессий — баз данных, WebSocket, потоковых ответов, где соединения держатся подолгу и распределяются неравномерно.
IP-hash: один клиент — один backend
Ip-hash вычисляет хеш от адреса клиента и всегда направляет его на один и тот же backend. Это нужно, когда приложение хранит сессию локально на сервере, а не в общем хранилище.
Weighted: с весами по мощности
Weighted-варианты round-robin и least connections учитывают вес сервера: более мощный backend получает больше запросов. Удобно, когда пул собран из машин разной производительности.
Consistent hashing: для кэширования
Consistent hashing раскладывает запросы так, что при добавлении или удалении сервера перераспределяется лишь малая часть ключей. Это критично для кэширующих кластеров, где массовое перераспределение обнулило бы кэш.
Health checks и Failover
Пассивные проверки здоровья
Пассивный health check считает ошибки в реальном трафике: если backend несколько раз подряд ответил сбоем или не ответил, балансировщик исключает его из пула. Просто и без лишней нагрузки, но реакция наступает только после реальных ошибок у клиентов.
Активные проверки здоровья
Активный health check сам периодически опрашивает backend отдельным запросом и снимает с ротации мертвый сервер до того, как на него попадет клиент. Это правильнее, но в Nginx OSS активные проверки недоступны — они есть только в Nginx Plus или бесплатно в Angie.
Backup-серверы и плавная деградация
Часть backend помечают как backup: они принимают трафик, только когда основные недоступны. Так строят плавную деградацию — при массовом отказе сервис переходит на резерв, а не падает целиком.
Аппаратные и программные балансировщики
Выбор между железом и софтом определяет и стоимость, и гибкость. Программные балансировщики ставят на обычные серверы; аппаратные привязаны к конкретному сетевому оборудованию — коммутаторам и маршрутизаторам с поддержкой нужных режимов.
Аппаратные
F5 BIG-IP, Citrix ADC, A10 Networks — специализированные устройства с аппаратным ускорением. Мощные и быстрые, но дорогие, а F5 и Citrix в РФ официально не продаются с 2022 года. Существующие инсталляции работают, новые закупки идут в сторону софта.
Программные
HAProxy, Nginx, Angie, Envoy — балансировщики, которые ставят на обычные серверы. Гибкие, бесплатные в базовых версиях, масштабируются добавлением узлов. Для большинства задач программное решение закрывает потребности не хуже железа.
Облачные
Yandex Application Load Balancer, VK Cloud Load Balancer, SberCloud — управляемые балансировщики в облаке. Платят по трафику и числу запросов, зато не нужно обслуживать собственные узлы.
Что выбирают в РФ в 2026
После ухода F5 и Citrix российские компании массово переходят на программные решения: HAProxy и Nginx как базу, Angie как отечественный форк с активными проверками. Angie входит в реестр Минцифры. Как строится стек без западного ПО — в разделе импортозамещения серверов. Аппаратные балансировщики остаются в legacy-инсталляциях.
HAProxy как промышленный стандарт
HAProxy — де-факто стандарт программной балансировки в DevOps; под него подбирают надежный сервер. Что проверяют в конфигурации при независимом разборе инфраструктуры — покажет аудит ИТ-инфраструктуры.
Установка и базовый конфиг
HAProxy ставится из штатных репозиториев, текущая LTS-ветка — 2.8 с поддержкой до 2028 года. Конфигурация лаконична и читаема: один файл описывает, что слушать и куда распределять.
Frontend, backend, listen
Логика строится из блоков. Frontend описывает, что и на каком порту принимать. Backend — пул серверов и алгоритм распределения. Блок listen объединяет оба в одном месте для простых случаев. Этой структуры хватает на большинство сценариев.
Stats-страница и наблюдение
У HAProxy есть встроенная страница статистики: состояние backend, число соединений, отклоненные запросы — все в реальном времени. Ее заводят сразу: без наблюдения за балансировщиком слепо реагируешь только на жалобы.
Nginx и Angie как балансировщики
Если в инфраструктуре уже есть Nginx, отдельный балансировщик может и не понадобиться. Типовые конфигурации под фронт и backend — в каталоге серверов.
Блок upstream и алгоритмы
В Nginx пул backend описывают в блоке upstream, а proxy_pass направляет на него запросы. Поддерживаются round robin, least connections и ip-hash — базового набора хватает для типового веб-фронта.
Активные проверки в Angie
Angie — российский форк Nginx из реестра Минцифры. Он совместим по конфигурации, но добавляет активные health checks, расширенную статистику в JSON и боевой HTTP/3 — то, за что у Nginx просили платную подписку Plus.
SSL termination и проксирование
Балансировщик берет на себя SSL termination: расшифровывает HTTPS на входе и общается с backend по простому протоколу. Это снимает с серверов нагрузку шифрования и упрощает управление сертификатами в одной точке.
Высокая доступность самого балансировщика
Keepalived и VRRP
Сам балансировщик не должен стать единой точкой отказа. Два узла объединяют через keepalived по протоколу VRRP: они делят один virtual IP, и при падении активного резервный мгновенно подхватывает адрес. Клиенты ничего не замечают.
Active/passive и active/active
В схеме active/passive один узел работает, второй ждет в резерве. В active/active оба обрабатывают трафик одновременно, что добавляет и производительности. Выбор зависит от нагрузки и сложности, которую готова держать команда.
DNS round-robin и GeoDNS
На уровне DNS трафик грубо распределяют через round robin по нескольким адресам, а GeoDNS направляет клиента на ближайшую площадку. Это дополняет, но не заменяет настоящий балансировщик: DNS не знает о здоровье серверов.
Безопасность
Балансировщик — точка входа всего трафика. Что проверяют в его конфигурации при независимой оценке — в разделе аудита безопасности.
TLS-терминация и шифрование к backend
TLS терминируют на балансировщике, а до backend трафик идет либо по внутренней доверенной сети, либо повторно шифруется. Сертификатами управляют в одной точке, что упрощает их продление и ротацию.
Rate limiting и защита от DDoS
На уровне балансировщика включают ограничение частоты запросов с одного адреса — 10-20 req/s для страниц, 1-2 req/s для форм авторизации. Это первая линия обороны до того, как нагрузка дойдет до приложения.
WAF
Перед backend ставят WAF — ModSecurity или NAXSI: он отсекает типовые атаки на веб-приложения на уровне балансировщика, до того как вредоносный запрос дойдет до сервера.
Сравнение программных балансировщиков
Типовые ошибки при внедрении
Один балансировщик без HA-пары
Единственный балансировщик сам становится точкой отказа: его падение роняет весь сервис, сколько бы backend ни стояло за ним. HA-пару с keepalived закладывают сразу, а не после первого простоя.
Health check только по TCP
Проверка лишь TCP-порта показывает, что сервис слушает, но не что он отвечает корректно. Приложение может принять соединение и отдавать ошибки. Для L7 проверяют именно HTTP-ответ, а не просто открытый порт.
Sticky session везде на всякий случай
Привязку клиента к серверу включают только там, где приложение хранит сессию локально. Sticky session везде подряд ломает равномерность распределения и мешает отказоустойчивости: упал сервер — потерялись сессии его клиентов.
Часто задаваемые вопросы (FAQ)
Что такое балансировщик нагрузки простыми словами?
Это узел, который распределяет входящие запросы между несколькими серверами. Он повышает отказоустойчивость и позволяет масштабироваться: клиент обращается к одному адресу, а работает пул машин за ним.
Чем L4 отличается от L7 балансировки?
L4 работает на уровне TCP и UDP, видит адреса и порты, быстро перенаправляет пакеты. L7 разбирает HTTP и маршрутизирует по URL, заголовкам, cookie — медленнее, но умеет маршрутизировать по содержимому запроса.
Какой алгоритм балансировки выбрать?
Round-robin для однородных серверов, least connections для долгих соединений вроде баз и WebSocket, ip-hash для приложений с локальной сессией. Для разных по мощности машин — weighted-варианты.
Что лучше: HAProxy или Nginx?
HAProxy сильнее как выделенный балансировщик с богатой статистикой. Nginx удобнее, когда он уже стоит фронтом и балансировка — дополнительная роль. Для импортозамещения берят Angie.
Нужны ли два балансировщика?
Для продакшена — да. Один балансировщик сам по себе единая точка отказа. HA-пара с keepalived и virtual IP держит сервис, даже если один узел вышел из строя.
Что такое sticky session?
Это привязка клиента к одному backend по cookie или адресу. Нужна, когда сессия хранится локально на сервере. Без необходимости ее не включают — она мешает равномерному распределению.
Когда оправдан аппаратный балансировщик?
При экстремальных нагрузках и наличии бюджета на железо с аппаратным ускорением. В РФ после ухода F5 и Citrix новые проекты почти всегда выбирают программные решения.
Как защититься от DDoS на уровне балансировщика?
Включить rate limiting по адресам, поставить WAF перед backend и терминировать TLS в одной точке. Это отсекает массу простых атак уровня L7 до того, как они дойдут до приложения.
Четыре вопроса перед запуском
Прежде чем запускать балансировщик в продакшен, стоит ответить на несколько вопросов, которые не очевидны на этапе проектирования. Первое: как балансировщик передает реальный IP клиента на backend — без заголовка X-Forwarded-For приложение видит только адрес балансировщика, и логи становятся бесполезными. Второе: как приложение ведет себя под canary-деплоем — если один backend получает 10% трафика на новую версию, нужна ли sticky session или достаточно весового round-robin. Третье: есть ли у backend единое внешнее хранилище сессий (Redis, Memcached) — если нет, ip-hash обязателен, а горизонтальное масштабирование ограничено. Четвертое: настроены ли алерты на ключевые метрики — conn_queue (очередь соединений), response_time P99 и доля 5xx ответов от каждого backend; без них о деградации узнают от пользователей, не от мониторинга.
Спроектируем балансировку нагрузки
Внедряете балансировщик для веб-фронта, API или 1С? Инженеры Serverzilla подберут программное решение на HAProxy, Nginx или Angie, спроектируют HA-пару с keepalived и virtual IP, настроят health checks и TLS-терминацию. Рассчитаем серверы под задачу под фронт и backend. Оставьте заявку.
