Балансировка нагрузки в Nginx: методы и веса серверов

Если один сервер получает больше запросов, чем остальные, не всегда нужно добавлять ещё один узел: сначала проверьте алгоритм балансировки и веса в Nginx. В Nginx Open Source 1.26.x доступны несколько способов выбора сервера, но вес задаёт долю запросов, а не обещает одинаковое время ответа или одинаковую загрузку CPU.

Что означают веса серверов

В директиве weight указывают относительный приоритет узла. Если в группе два сервера с весами 3 и 1, алгоритм с распределением по кругу будет направлять на первый примерно три запроса на каждый запрос ко второму. Это пропорция внутри группы, а не точный прогноз на любой интервал: соединения могут жить разное время, а запросы — требовать разный объём ресурсов.

Пример для Nginx Open Source 1.26.x:

http {
    upstream app_backend {
        server 10.0.0.11:8080 weight=3;
        server 10.0.0.12:8080 weight=1;
    }

    server {
        listen 80;

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

Здесь Nginx использует алгоритм round robin, если вы не указали другой. Директива upstream объявляет группу серверов, а proxy_pass передаёт ей запросы. Перед применением проверьте конфигурацию командой nginx -t, затем перечитайте конфигурацию штатным способом, принятым в вашей системе.

Вес — это доля выбора, а не измеритель мощности. Если сервер с весом 3 отвечает в пять раз медленнее, сама балансировка это не исправит.

Четыре алгоритма и их цена

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

Когда оставить round robin

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

Когда нужен least_conn

Добавьте least_conn, когда длительность соединений сильно различается: например, один запрос ждёт внешний сервис, а другой быстро возвращает страницу. Тогда простой круговой порядок может отправить новый запрос на узел, где уже накопились долгие соединения.

upstream app_backend {
    least_conn;
    server 10.0.0.11:8080 weight=3;
    server 10.0.0.12:8080 weight=1;
}

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

Когда оправданы ip_hash и hash

Для приложений с локальной сессией можно использовать ip_hash, но сначала оцените, сколько клиентов приходит с общих IP-адресов. В офисе, мобильной сети или за корпоративным прокси множество пользователей может выглядеть для Nginx как один клиент. Итог — не равномерность, а закрепление большой группы за одним узлом.

Если нужно привязать запросы по другому признаку, задайте ключ явно. Например, для кеша по URI в Nginx 1.26.x:

upstream app_backend {
    hash $request_uri consistent;
    server 10.0.0.11:8080 weight=3;
    server 10.0.0.12:8080 weight=1;
}

Такой ключ подходит только если одинаковый URI должен попадать на один сервер независимо от пользователя. Если кеш зависит от языка, заголовка или авторизации, одного URI недостаточно. Состав ключа должен соответствовать правилам самого кеша; не добавляйте персональные данные в него без необходимости.

Отказ узла и временное исключение

Директивы max_fails и fail_timeout позволяют учитывать неудачные попытки соединения: после заданного числа ошибок Nginx временно считает сервер недоступным. Их значения нужно подбирать под приложение и характер сбоев, а не копировать как универсальную пару. Эти параметры не заменяют проверку здоровья приложения: успешное TCP-соединение ещё не означает, что backend способен корректно обработать запрос.

Важная граница: при единственном сервере в upstream параметры пассивного учёта ошибок не дают того же эффекта, что при нескольких узлах. Кроме того, поведение зависит от типа ошибки и конфигурации проксирования. Для критичного сервиса проверьте конкретный сценарий отказа на тестовом стенде, а не только факт успешного nginx -t.

Как выбрать и проверить метод

1. Опишите перекос. Это очередь долгих соединений, разные по мощности серверы или необходимость удерживать клиента на одном узле? Зафиксируйте один симптом и метрику.
2. Начните с простого алгоритма. Для однородных backend оставьте round robin; для долгих соединений проверьте least_conn. Не меняйте сразу и метод, и веса.
3. Проверьте конфигурацию и отказ. Запустите nginx -t, затем проверьте, куда идут запросы при недоступности одного backend. Убедитесь, что приложение не теряет сессии и корректно повторяет запросы, если они допускают повтор.
4. Сравните нагрузку до и после. На одинаковом профиле запросов измерьте задержку, долю ошибок, активные соединения и загрузку каждого сервера. Указывайте длительность теста, число клиентов и состав запросов: без этих условий результаты нельзя сравнивать.

Что обычно ломается

• Вес воспринимают как лимит. Вес 3 не запрещает серверу получить много запросов подряд и не ограничивает число соединений.
• Для ip_hash берут общую аудиторию за одним IP. Проверьте адреса клиентов и распределение по узлам; иначе привязка превращается в перекос.
• Хешируют неподходящий ключ. Один популярный URI может стать «горячим», а разные варианты одного ресурса — разойтись по серверам.
• Смотрят только на число запросов. Сопоставьте его с задержкой, активными соединениями, ошибками и ресурсами backend.

Термин: consistent hashing — хеширование с минимизацией переназначений. При изменении состава серверов оно обычно меняет владельца меньшего числа ключей, чем обычная схема хеширования, но не гарантирует равную нагрузку.

Что делать дальше

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