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

Самый простой класс методов — статические алгоритмы. Круговое распределение передает запросы серверам по очереди. Взвешенное круговое распределение добавляет веса: более мощный сервер получает больше запросов, чем слабый. Эти методы просты в настройке и хорошо подходят для однородных экземпляров, которые выполняют похожие операции. В документации NGINX круговое распределение указано как базовый метод балансировки группы вышестоящих серверов, а метод наименьшего числа соединений и привязка по IP-адресу рассматриваются как альтернативы для других сценариев [1]. Ограничение статического подхода состоит в том, что он слабо учитывает текущую занятость сервера. Если один запрос обрабатывается 10 мс, а другой запускает долгую операцию, простая очередь распределения перестает отражать фактическую нагрузку.

Динамические алгоритмы учитывают состояние серверных узлов. Метод наименьшего числа соединений выбирает сервер с меньшим числом активных соединений. Такой подход полезен там, где длительность запросов заметно различается: долгие соединения не должны случайно накапливаться на одном экземпляре. HAProxy также поддерживает несколько алгоритмов распределения: круговое распределение, метод наименьшего числа соединений и привязку к источнику запроса, а выбор зависит от типа трафика и требований к привязке клиента [2]. Однако динамический метод сам создает накладные расходы: балансировщик должен хранить состояние соединений, обновлять счетчики и корректно реагировать на закрытие долгих запросов.

Отдельно стоит выделить алгоритм выбора из двух случайных вариантов. Его идея проста: балансировщик случайно выбирает два сервера и отправляет запрос к менее загруженному из них. В классической работе Mitzenmacher показано, что такая схема резко уменьшает дисбаланс по сравнению с полностью случайным выбором [5]. Для веб-систем это важно потому, что алгоритм не требует полного глобального знания о состоянии всех узлов, но снижает риск отправить запрос на перегруженный экземпляр. Такой компромисс полезен в крупных кластерах, где полное измерение состояния каждого серверного узла становится дорогим.

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

Балансировка на четвертом уровне модели OSI (модель взаимодействия открытых систем) работает с TCP (протокол управления передачей) или UDP (протокол пользовательских датаграмм). Она быстрее, потому что не анализирует HTTP-содержимое запроса. Такой слой подходит для высоконагруженных входных точек, где нужно распределить поток соединений и сохранить малую задержку. Балансировка на седьмом уровне анализирует HTTP-заголовки, адрес запроса, клиентские файлы с данными сеанса и иногда тело запроса. Это позволяет направлять `/api` к одному пулу сервисов, статические файлы — к другому, а административные запросы — к третьему. Цена прикладного подхода состоит в большем объеме обработки: балансировщик становится частью маршрута приложения и требует аккуратной настройки таймаутов, заголовков и правил безопасности.

В распределенной системе балансировка нагрузки неотделима от проверок состояния. Если балансировщик не проверяет состояние серверного узла, он может продолжать отправлять запросы на процесс, который уже не принимает соединения или отвечает с ошибкой. Проверка может быть сетевой, например открытие TCP-соединения, или прикладной, например HTTP-запрос к `/health`. Прикладная проверка точнее, но ее нужно проектировать аккуратно: если конечная точка проверки обращается к базе данных и внешним сервисам, то временная проблема зависимого сервиса может вывести из пула все экземпляры приложения. Поэтому проверка состояния должна отражать способность экземпляра принять запрос, но не превращаться в тяжелый тест всей системы.

Состояние пользователя усложняет балансировку. Если веб-приложение хранит сессию в памяти процесса, повторный запрос того же клиента должен попасть на тот же экземпляр. Для этого используют привязку сессии: балансировщик привязывает клиента к серверному узлу по клиентскому файлу с данными сеанса, IP-адресу или другому признаку. В Kubernetes для службы также предусмотрены механизмы распределения трафика и политики, влияющие на то, как запрос попадает к контейнерным группам [3]. Но привязка сессии снижает свободу балансировщика: перегруженный сервер нельзя так же легко разгрузить, если к нему уже привязаны активные пользователи. Более устойчивый вариант — вынести состояние сессии во внешнее хранилище или использовать токены без состояния, когда это допустимо по требованиям безопасности.

Крупные системы используют несколько слоев балансировки. В работе Google Maglev описан программный балансировщик нагрузки, рассчитанный на высокую пропускную способность, отказоустойчивость и согласованное распределение трафика между серверными узлами [4]. Практический вывод из таких архитектур состоит в том, что балансировщик — не одиночный компонент перед приложением, а часть цепочки: глобальная система доменных имен или единый сетевой адрес направляет пользователя в регион, региональный балансировщик выбирает кластер, а внутренний прокси маршрутизирует запрос к сервису. Каждый слой решает свою задачу и имеет собственный сценарий отказа.

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

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

Литература:

1. NGINX Documentation. HTTP Load Balancing // NGINX. — 2026. — URL: https://nginx.org/en/docs/http/load_balancing.html (дата обращения: 05.07.2026).
2. HAProxy Technologies. HAProxy Configuration Manual. Load balancing algorithms // HAProxy Documentation. — 2026. — URL: https://docs.haproxy.org/ (дата обращения: 05.07.2026).
3. Kubernetes Documentation. Services, Load Balancing, and Networking // Kubernetes. — 2026. — URL: https://kubernetes.io/docs/concepts/services-networking/ (дата обращения: 05.07.2026).
4. Eisenbud D. E., Yi C., Contavalli C., Smith C., Kononov R., Mann-Hielscher E., Cilingiroglu A., Cheyney B., Shang W., Hosein J. D. Maglev: A Fast and Reliable Software Network Load Balancer. — 2016. — URL: https://research.google/pubs/maglev-a-fast-and-reliable-software-network-load-balancer/.
5. Mitzenmacher M. The Power of Two Choices in Randomized Load Balancing. — 2001. — URL: https://www.eecs.harvard.edu/~michaelm/postscripts/mythesis.pdf.
6. Dean J., Barroso L. A. The Tail at Scale. — 2013. — URL: https://research.google/pubs/the-tail-at-scale/.
7. Cloudflare Docs. Load Balancing // Cloudflare. — 2026. — URL: https://developers.cloudflare.com/load-balancing/ (дата обращения: 05.07.2026).
8. Yandex Cloud Documentation. Network Load Balancer // Yandex Cloud. — 2026. — URL: https://yandex.cloud/ru/docs/network-load-balancer/ (дата обращения: 05.07.2026).