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

Быстрые ссылки

How NGINX Load Balancing Works
Proxying to the Backend

Логотип NGINX

Как работает балансировка нагрузки в NGINX

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

Типичная схема балансировщика NGINX, направляющего трафик на несколько бэкендов

Бóльшая часть конфигурации связана с тем, как NGINX выбирает сервер для каждого запроса. По умолчанию используется round‑robin: запросы отправляются по очереди, что даёт равномерное распределение нагрузки.

Однако не всегда всё так просто. Многие веб‑приложения требуют сохранения сессии (session persistence) — пользователь должен оставаться на одном и том же сервере в течение сессии. Например, корзина покупок может храниться локально на одном приложении, и если пользователь переключится на другой сервер, поведение может стать некорректным. Многие такие проблемы решаются централизованными хранилищами (Redis, базы данных), но session persistence всё ещё востребована.

В NGINX набор серверов, к которым вы направляете запросы, называется upstream и задаётся как перечисление адресов:

upstream backend {
    server backend1.example.com weight=5;
    server backend2.example.com;
}

В upstream можно задать вес (weight) — сервер с большим весом будет получать больше запросов. Также доступны параметры max_conns и таймауты. В NGINX Plus можно подключать health checks, чтобы не отправлять трафик на недоступные инстансы.

IP‑hash — простая сессия по IP

Самая базовая форма привязки сессии — ip_hash. NGINX использует IP клиента для выбора бэкенда и старается держать одного пользователя на одном сервере:

upstream backend {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
}

ip_hash полезен для socket‑подобных приложений и случаев, где нужна привязка по IP. Если вы не хотите использовать IP, можно задать свою хеш‑функцию:

upstream backend {
    hash $scheme$request_uri consistent;
    server backend1.example.com;
    server backend2.example.com;
}

Least connections и latency‑aware выбор

Если сессии не нужны, можно отдавать предпочтение серверам с наименьшим числом текущих подключений:

upstream backend {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
}

Или выбирать по задержке ответа (для новых версий NGINX/Plus):

upstream backend {
    least_time header;
    server backend1.example.com;
    server backend2.example.com;
}

NGINX Plus предлагает дополнительные варианты балансировки и более продвинутые health checks, но для большинства сценариев ip_hash или least_conn достаточно.

Важно: если у вас есть прокси или балансировщик перед NGINX (например, облачный LB), ip_hash может «ломаться», так как видимый IP клиента будет адрес прокси.

Проксирование запросов к бэкенду

После настройки upstream внутри location‑блоков вы направляете трафик с помощью proxy_pass:

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;
    }
}

Если вы используете HTTPS, proxy_pass должен указывать на https:// и сервер должен уметь устанавливать SSL‑сессии к бэкендам:

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /etc/ssl/certs/server.crt;
    ssl_certificate_key /etc/ssl/certs/server.key;
    ssl_client_certificate /etc/ssl/certs/ca.crt;

    location / {
        proxy_pass https://backend;
    }
}

Полезные директивы proxy_*

proxy_set_header — переопределяет заголовки, например X‑Forwarded‑For.
proxy_connect_timeout, proxy_read_timeout — таймауты соединения/чтения.
proxy_buffers — настройки буферов ответа от бэкенда.

Когда такая балансировка не подходит (контрпримеры)

Если ваши пользователи имеют динамические IP (мобильные сети, NAT) и вы полагаетесь на ip_hash, привязка может меняться.
Для строго консистентных данных одной сессии лучше централизовать состояние (Redis, внешняя БД), а не полагаться на привязку к конкретному инстансу.
При использовании глобального CDN или облачных балансировщиков прямой ip_hash может работать неправильно — видимый адрес клиента будет адрес прокси.

Альтернативные подходы

Использовать слой хранения сессий (Redis, Memcached) и ставить приложения за stateless‑балансировщик.
Sticky‑cookies на уровне приложения или на уровне балансировщика (если он поддерживает sticky‑сессии).
Сервер‑мерчантинг: использовать сервис mesh (Envoy, Istio) для более гибкой маршрутизации.

Ментальные модели и эвристики

«Upstream = пул серверов» — думайте об upstream как о группе взаимозаменяемых инстансов.
Round‑robin — хорош как старт. Least_conn — когда у вас длинные удерживаемые соединения.
IP‑hash — простая привязка, но ненадёжна при проксировании через NAT/облако.

Чек‑лист для ролей

SRE/DevOps:
- Проверить health checks в NGINX Plus или внешние проверки.
- Настроить логирование upstream ошибок и таймаутов.
- Протестировать поведение при отключении инстанса.
Разработчик:
- Убедиться, что приложение может работать в stateless‑режиме.
- Реализовать централизованное хранилище сессий, если нужно.
Безопасность:
- Включить TLS между балансировщиком и бэкендами при передаче секретных данных.
- Настроить HSTS и проверку клиентских сертификатов, когда требуется.

Сниппет‑шпаргалка (cheat sheet)

Быстрая конфигурация upstream с весом и least_conn:

upstream backend {
    least_conn;
    server backend1.example.com weight=3;
    server backend2.example.com weight=1;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_connect_timeout 5s;
        proxy_read_timeout 30s;
    }
}

Минимальные шаги для HTTPS между NGINX и бэкендом:

Убедитесь, что бэкенд слушает на HTTPS.
proxy_pass указывает на https://backend.
Настройте верификацию сертификатов (proxy_ssl_verify).

Безопасность и рекомендации по жёсткой настройке

Всегда использовать TLS между системами, если передаётся чувствительная информация.
Включить проверку клиентских сертификатов, если требуется доверенная аутентификация между компонентами.
Ограничить максимальное число соединений и задать разумные таймауты, чтобы избежать исчерпания ресурсов.
Логи и метрики: экспортируйте показатели upstream (latency, errors, active connections).

Краткий глоссарий (1 строка на термин)

upstream — определённая группа бэкенд‑серверов в конфигурации NGINX.
ip_hash — алгоритм выбора сервера по IP клиента.
least_conn — выбор сервера с меньшим числом активных соединений.
proxy_pass — директива для проксирования запроса к upstream или внешнему URL.

Критерии приёмки

NGINX корректно распределяет запросы по upstream согласно выбранному алгоритму.
В случае падения бэкенда трафик перестаёт направляться к нему (через health checks или ручное исключение).
TLS между балансировщиком и бэкендом настроен и проверен (если требуется).

Итог

NGINX предоставляет гибкие способы балансировки трафика: от простого round‑robin до привязки сессий и выбора по задержке. Выбор подхода зависит от характера приложения: предпочитайте stateless‑архитектуру и централизованное хранение состояния, а ip_hash используйте как быстрый и простой способ привязки, понимая его ограничения.

Важно: тестируйте поведение при падении инстансов и при наличии прокси/облачных балансировщиков в цепочке.