Балансировка в Nginx: как распределять нагрузку правильно

Сначала решите, что именно балансировать

Балансировка в Nginx не ускорит приложение сама по себе: она распределяет запросы между несколькими серверами и помогает пережить отказ части из них. Для обычного веб-приложения начните с round robin — Nginx выберет узлы по очереди. Если запросы сильно различаются по длительности, рассмотрите least_conn. Ни один из этих режимов не заменяет мониторинг, проверку отказов и тестирование поведения приложения без сессий на локальном диске.

Примеры ниже рассчитаны на Nginx Open Source 1.26 и новее. Директивы upstream и proxy_pass доступны и в более ранних версиях, но перед применением проверьте конфигурацию именно вашей сборки командой nginx -t.

Три способа распределить запросы

По умолчанию Nginx использует round robin: передаёт запросы серверам по очереди, не пытаясь оценить их текущую загрузку. Это хороший первый выбор, если узлы примерно одинаковы, а запросы занимают сопоставимое время.

При least_conn следующий запрос получает сервер с наименьшим количеством активных соединений. Это полезно, когда часть запросов долго ждёт базу или выполняет тяжёлую работу. Но число соединений — лишь косвенный показатель нагрузки: оно не учитывает загрузку CPU, очередь задач или насыщение диска.

ip_hash старается отправлять клиента на один и тот же сервер по IP-адресу. Такой выбор может помочь приложениям, которые хранят сессию в памяти узла, но распределение становится неравномерным, если много клиентов выходят в интернет через один NAT или прокси. Для надёжной работы лучше хранить сессии вне узлов приложения.

Активное соединение — запрос, который Nginx уже передал серверу и для которого ещё не завершилась обработка. Это не то же самое, что число пользователей: один пользователь может открыть несколько соединений.

Базовая конфигурация

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

http {
    upstream app_pool {
        least_conn;
        server 10.0.0.11:8080 max_fails=2 fail_timeout=10s;
        server 10.0.0.12:8080 max_fails=2 fail_timeout=10s;
        keepalive 32;
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://app_pool;
            proxy_http_version 1.1;
            proxy_set_header Connection "";
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
}

Если ваш основной файл уже содержит блок http, не добавляйте второй: поместите upstream и server внутрь существующего. Заголовки передают приложению исходные сведения о запросе; настройте доверие к ним на стороне приложения и не принимайте произвольные forwarded-заголовки от внешних клиентов как достоверные.

Директива keepalive 32 задаёт число неактивных соединений к upstream, которые каждый рабочий процесс Nginx может держать в кэше. Это не общий предел соединений с сервером. Значение подбирают по числу процессов, доступным ресурсам и лимитам приложения, а не копируют без проверки.

Что происходит при отказе узла

В Nginx Open Source проверки узлов пассивные: балансировщик делает вывод об ошибке по результатам обычных запросов. Параметры max_fails и fail_timeout задают, сколько неудач учитывать и на какой период считать сервер недоступным. Это не отдельная проверка готовности приложения: если на узел никто не обращается, Nginx может не узнать о проблеме заранее.

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

Два сервера не дают отказоустойчивость, если оба зависят от одной базы данных, одного диска или одного сетевого канала.

Когда настройка ломается

• Клиент получает 502. Проверьте доступность адреса и порта upstream с машины Nginx, журнал ошибок и состояние самого приложения. Убедитесь, что узел слушает нужный интерфейс, а не только localhost.
• Запросы иногда попадают на нездоровый сервер. Пассивная проверка обнаруживает проблему через реальные запросы, а не заранее. Если нужна активная проверка HTTP-ответа, выясните, поддерживает ли её ваша редакция Nginx: возможности Nginx Plus и Open Source различаются.
• Пользователя выбрасывает из сессии. Запросы могли попасть на разные узлы, а состояние сессии хранится локально. Перенесите его в общее хранилище или осознанно настройте привязку, учитывая риск неравномерной нагрузки.
• Один сервер перегружен, другой простаивает. Проверьте, одинаковы ли узлы по мощности и нет ли перекоса из-за долгих запросов или IP-привязки. Round robin не оценивает фактическую загрузку CPU и приложения.
• После изменения Nginx не принимает конфигурацию. Сначала запустите nginx -t. Если проверка прошла, примените конфигурацию штатным для вашей системы способом и проверьте журналы и ответы через балансировщик.

Как выбрать режим и проверить результат

1. Начните с round robin, если серверы одинаковы и запросы похожи по длительности. Проверьте распределение запросов и долю ошибок в журналах.
2. Переключитесь на least_conn, если долгие запросы создают очереди и число активных соединений помогает распределять работу. Сравните задержку и ошибки до и после на одинаковом профиле нагрузки.
3. Используйте ip_hash только при конкретной необходимости закрепить клиента за узлом. Проверьте сценарии за NAT и поведение при отключении сервера.
4. Отключите один узел в тестовой среде и убедитесь, что трафик продолжает обслуживаться, а оставшийся сервер выдерживает нагрузку. Затем верните узел и проверьте восстановление.

Не называйте тест успешным только потому, что главная страница открылась. Сравнивайте одинаковые запросы при одинаковой параллельности: измеряйте задержку, долю ответов 5xx, загрузку узлов и активные соединения. Без данных о железе, приложении и профиле трафика универсальных чисел для такой проверки нет.

Что проверить перед выкладкой

Следующий шаг — провести тест с отключением одного backend и посмотреть, как меняются ошибки и задержки. Затем настройте мониторинг каждого узла и алерт на рост 5xx. Если приложению нужна активная проверка готовности, отдельно сравните возможности вашей редакции Nginx с требованиями: не подменяйте такую проверку параметрами пассивной балансировки.

Смежная тема — балансировка WebSocket и настройка таймаутов для долгих запросов; здесь разобрана только базовая схема HTTP-проксирования.