Что такое балансировка нагрузки и как работает балансировщик

Короткий ответ

Балансировщик нагрузки (load balancer) — это точка входа, которая стоит перед группой одинаковых серверов и решает, какому из них отдать очередной запрос. Клиент видит один адрес, а за ним работают два, десять или сто экземпляров приложения.

Он решает три задачи:

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

Где балансировщик находится в архитектуре

Типичный путь запроса в веб-приложении:

1. Пользователь → DNS → CDN (опционально).
2. → Балансировщик (облачный LB, nginx, HAProxy, Traefik).
3. → Несколько экземпляров приложения.
4. → База данных, кеш, очереди.

Часто на балансировщике же завершают TLS (HTTPS-сертификат живет здесь), сжимают ответы и ограничивают частоту запросов. Балансировщики бывают и внутри системы: например, между микросервисами или перед репликами базы для чтения.

Важно: сам балансировщик тоже может стать единой точкой отказа. Облачные балансировщики резервируются провайдером, а для своего nginx или HAProxy делают пару узлов с общим плавающим IP.

L4 и L7: в чем разница

L4 подходит для любых TCP-протоколов: базы данных, MQTT, игровые серверы. L7 нужен, когда маршрутизация зависит от содержимого запроса: разные домены, версии API, canary-релизы.

Health checks

Балансировщик регулярно проверяет каждый сервер:

• пассивные проверки — сервер исключается, если на реальные запросы он отвечает ошибками или таймаутами;
• активные проверки — балансировщик сам опрашивает специальный адрес, например GET /health, с заданным интервалом.

Хороший health check проверяет, что приложение действительно может обслуживать запросы, но не тянет за собой все зависимости. Если /health падает при любой задержке базы, балансировщик может выкинуть из ротации сразу все серверы.

Привязка сессий (session persistence)

Иногда нужно, чтобы один пользователь все время попадал на один и тот же сервер — например, если сессия хранится в памяти процесса. Это называют sticky sessions. Варианты:

• по cookie, которую ставит балансировщик;
• по хешу IP-адреса клиента.

Минусы: нагрузка распределяется хуже, а при падении сервера пользователи теряют сессию. Надежнее хранить сессии во внешнем хранилище (Redis, база) или в токене, и тогда привязка не нужна.

Пример на nginx

upstream app {
    server 10.0.0.11:3000 max_fails=3 fail_timeout=30s;
    server 10.0.0.12:3000 max_fails=3 fail_timeout=30s;
}

server {
    listen 80;
    location / {
        proxy_pass http://app;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Здесь nginx работает как L7-балансировщик с пассивными проверками: после нескольких неудачных попыток сервер временно исключается.

Частые ошибки

• Один балансировщик без резерва — отказоустойчивость приложения есть, а входа нет.
• Слишком «умный» health check, который зависит от всего подряд.
• Потеря реального IP клиента — забыли передать X-Forwarded-For или включить proxy protocol.
• Таймауты балансировщика короче, чем долгие запросы приложения: загрузки файлов, отчеты, WebSocket.