Алгоритмы балансировки нагрузки: выбор правильной стратегии

Введение

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

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

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

Категории алгоритмов

Алгоритмы балансировки нагрузки делятся на две основные категории, каждая из которых служит разным архитектурным потребностям:

Round Robin

Round Robin — простейший и наиболее широко развёрнутый алгоритм балансировки нагрузки. Работает точно так, как следует из названия: запросы распределяются по серверам в круговом, последовательном порядке. Первый запрос идёт на сервер 1, второй — на сервер 2, и так далее. После достижения последнего сервера цикл начинается заново.

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

Round Robin отлично подходит для однородных сред, где серверы имеют идентичные спецификации, а запросы относительно однородны — например, для обслуживания статического контента, простых API-эндпоинтов или stateless-микросервисов.

Weighted Round Robin

Weighted Round Robin расширяет базовый алгоритм, присваивая вес каждому серверу на основе его ёмкости. Серверы с более высокими весами получают пропорционально больше трафика. Если у сервера A вес 3, а у сервера B вес 1, сервер A обрабатывает три запроса на каждый один, обрабатываемый сервером B.

Этот алгоритм необходим для неоднородных серверных сред. Организации часто используют смесь оборудования — мощные новые серверы рядом со старыми машинами или облачные инстансы с разным количеством vCPU. Weighted Round Robin гарантирует, что 16-ядерный сервер обрабатывает больше трафика, чем 4-ядерный.

Веса обычно конфигурируются на основе ядер CPU, памяти или тестирования бенчмарками. Хотя этот алгоритм более гибкий, чем простой Round Robin, он всё же не учитывает нагрузку сервера в реальном времени — сильно взвешенный сервер под высокой нагрузкой будет продолжать получать трафик в зависимости от своего веса, а не текущей ёмкости.

Least Connection

Least Connection использует динамический подход: каждый новый запрос идёт на сервер с наименьшим количеством активных соединений в этот момент. В отличие от Round Robin, этот алгоритм адаптируется к условиям в реальном времени — если один сервер обрабатывает много медленных запросов, новые запросы маршрутизируются на менее загруженные серверы.

Этот алгоритм особенно рекомендуется для серверов, обрабатывающих длительные сессии. Соединения с базами данных (SQL), сервисы каталогов (LDAP) и приложения с персистентными соединениями значительно выигрывают от распределения Least Connection.

Балансировщик нагрузки отслеживает активные соединения с каждым серверным backend. При поступлении нового запроса он запрашивает эту таблицу соединений и выбирает сервер с наименьшим счётом. Эти небольшие накладные расходы пренебрежимо малы по сравнению с преимуществами производительности для нагрузок с большим числом соединений.

First

Алгоритм First использует уникальный подход: он отправляет весь трафик на первый сервер в пуле, пока этот сервер не достигнет своего максимального лимита соединений. Только тогда трафик идёт на следующий сервер.

Этот алгоритм полезен для конфигураций active-passive, где вы хотите, чтобы один основной сервер обрабатывал всю нагрузку, в то время как другие остаются в резерве. Он также ценен для лицензионных сценариев, где вы хотите максимально использовать один лицензированный сервер до задействования дополнительной ёмкости.

First обеспечивает предсказуемое поведение и упрощает устранение неполадок, поскольку вы знаете точно, какой сервер обрабатывает трафик. Однако он не обеспечивает преимуществ распределения нагрузки и полностью полагается на лимиты max connection для failover.

Random

Алгоритм Random выбирает серверы случайно для каждого входящего запроса. Однако, в отличие от чистой рандомизации, эта реализация учитывает как веса серверов, так и время отклика в своей вероятности выбора.

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

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

Fastest

Алгоритм Fastest маршрутизирует запросы на сервер с лучшим временем отклика. Балансировщик нагрузки непрерывно мониторит производительность сервера и направляет трафик на тот сервер, который в данный момент отвечает быстрее всего.

Этот подход оптимизирует пользовательский опыт, гарантируя, что запросы идут на самый отзывчивый сервер. Он автоматически адаптируется к изменяющимся условиям — если сервер становится медленным из-за высокого CPU, нагрузки на память или внешних зависимостей, трафик смещается на более быстрые альтернативы.

Fastest идеален для приложений, чувствительных к задержке, где время отклика напрямую влияет на пользовательский опыт или бизнес-метрики. Потоки оформления заказа e-commerce, API реального времени и интерактивные приложения — все выигрывают от маршрутизации на основе времени отклика.

Опции оптимизации Fastest+

Методы persistence (самоперсистентные)

Методы persistence гарантируют, что связанные запросы от одного клиента, сессии или контекста всегда достигают одного и того же серверного backend. Это необходимо для stateful-приложений, хранящих данные сессии локально, а не в общем хранилище.

URI (persistence по пути)

URI persistence хеширует путь URI запроса для определения маршрутизации сервера. Текст URI до указанной длины (или до символа '?', если присутствуют query-параметры) хешируется и сочетается с весами серверов. Одни и те же URI всегда маршрутизируются на один и тот же сервер.

Опции конфигурации включают длину символов URI и глубину URI (количество сегментов пути для рассмотрения). Например, при глубине 2 и «/api/users/123», и «/api/users/456» будут хешировать тот же префикс «/api/users».

Этот метод отлично подходит для сценариев кэширования, где вы хотите, чтобы все запросы на один и тот же ресурс попадали на один и тот же сервер, максимизируя эффективность кэша. Он также полезен для шардированных backend, где разные шаблоны URI соответствуют разным партициям данных.

HDR (persistence заголовка)

HDR persistence исследует указанный HTTP-заголовок в каждом запросе и маршрутизирует на основе его содержимого. Запросы с одинаковым значением заголовка всегда идут на один и тот же сервер. Вы конфигурируете, какое имя заголовка инспектировать.

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

HDR persistence особенно ценна для API-first архитектур и микросервисов, где состояние сессии управляется через заголовки, а не cookie. Она плавно интегрируется с системами аутентификации на основе токенов.

Current Cookie (отслеживание cookie приложения)

Current Cookie persistence отслеживает существующий cookie, который ваше приложение уже устанавливает. Вместо создания нового cookie балансировщик нагрузки читает указанное имя cookie из каждого запроса и использует его значение для поддержания серверной привязки. Клиенты с одинаковым значением cookie всегда маршрутизируются на один и тот же сервер.

Вы просто конфигурируете имя cookie для отслеживания — балансировщик нагрузки захватывает это значение при каждом HTTP-запросе и поддерживает persistence на его основе. Это полезно, когда ваше приложение уже управляет сессионными cookie (такими как JSESSIONID, PHPSESSID или кастомные токены).

Подобно New Cookie, этот метод работает независимо от весов серверов. Как только сопоставление persistence установлено на основе значения cookie, распределение нагрузки не влияет на маршрутизацию для этих сессий. Это гарантирует целостность сессии даже в условиях высокой нагрузки.

Строительные блоки ключа хеша

Ключ хеша может быть построен из любой комбинации этих элементов трафика:

Сравнение методов persistence

Выбор алгоритма

Часто задаваемые вопросы