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

Когда одного сервера недостаточно, приложение запускают в нескольких экземплярах. Клиенты при этом должны обращаться к одному адресу, а не выбирать сервер сами. Эту роль играет балансировщик нагрузки: он принимает запросы и раздаёт их серверам пула. Задач две: распределить нагрузку и сохранить работоспособность сервиса при отказе части машин.

Реализации бывают программные, такие как nginx и HAProxy, аппаратные и облачные, предоставляемые как готовая услуга.

Round robin выдаёт запросы серверам по кругу, это самый простой вариант, подходящий при равной мощности машин. Weighted round robin учитывает веса: более мощному серверу достаётся больше запросов. Least connections отправляет новое соединение туда, где сейчас меньше активных, что полезно при долгих запросах разной длительности.

Хеширование по IP клиента или по идентификатору сессии закрепляет клиента за сервером, что нужно при хранении состояния на самом сервере. Существуют и более сложные алгоритмы, учитывающие время отклика.

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

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

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

Существуют пассивные проверки: балансировщик наблюдает за реальными запросами и, заметив множество ошибок от сервера, временно снижает его приоритет. Такой подход реагирует на сбои быстрее, чем периодический опрос.

Балансировщик уровня L4 работает с TCP и UDP, ориентируясь на адреса и порты. Он быстр и не смотрит на содержимое. Балансировщик уровня L7 понимает HTTP: может направлять запросы по адресу страницы, заголовкам или кукам, завершать TLS и добавлять заголовки. Он гибче, но потребляет больше ресурсов.

Из-за завершения TLS на L7 реальный IP клиента серверам обычно передаётся в заголовке вроде X-Forwarded-For, иначе приложение видит только адрес балансировщика.

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

Когда нужна именно скорость обработки, L4 выигрывает, а если требуется разбор заголовков, перезапись адресов и работа с куки, применяют L7.

Сам балансировщик может стать единственной точкой отказа, поэтому его дублируют. Ещё частая проблема — сессии: если данные пользователя хранятся в памяти конкретного сервера, при переключении он окажется разлогинен, и состояние выносят в общее хранилище.

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

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

Самый простой сценарий: три одинаковых веб-сервера за nginx или HAProxy. Балансировщик получает запросы на публичном адресе и отправляет их на внутренние по алгоритму round robin. Если один сервер выйдет из строя, проверка здоровья исключит его в течение нескольких секунд.

Более сложный вариант — географическое распределение. DNS-балансировка возвращает разные адреса в зависимости от расположения клиента или доступности площадки, а внутри каждой площадки работает собственный балансировщик. Её недостаток — кэширование DNS: пока записи не устарели, клиенты продолжают ходить по старому адресу, о чём говорит страница про TTL.

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