CORE 24/7
/
Блог
/
Балансировщики нагрузки

Всё о балансировке трафика между серверами

Балансировка помогает разделять трафик, масштабировать приложения, улучшать производительность и доступность

Что такое балансировщик нагрузки

Балансировщик нагрузки (load balancer) — распределяет входящий трафик между несколькими серверами. Без него один сервер получает всё: растёт задержка, падает доступность, выходит из строя вся система.

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

Где применяется балансировка трафика

Балансировка нагрузки нужна везде, где трафик нельзя обработать одним сервером или где критична доступность 24/7.

Финансовый сектор

Банки и платёжные системы используют L7-балансировщики с sticky sessions — один клиент привязывается к одному серверу на время транзакции. F5 BIG-IP и Citrix ADC — стандарт для Kaspi, Bereke Bank, крупных телекомов. Требования: задержка ниже 50 мс, 99,99% uptime, поддержка PCI DSS.

E-commerce и маркетплейсы

Пиковая нагрузка во время акций — в 10–50 раз выше обычной. Nginx или AWS ALB с автоскейлингом справляются без ручного вмешательства. IP Hash используют там, где корзина хранится на сервере, а не в Redis.

Стриминг и медиа

Netflix, YouTube, Twitch — Geographic/DNS-балансировка плюс CDN. Запрос уходит на ближайший POP-сервер. GSLB-решения (Cloudflare, A10) снижают latency для конечного пользователя на 30–70 мс по сравнению с одним датацентром.

Kubernetes и микросервисы

Traefik и Ingress Nginx — стандартные балансировщики для k8s-кластеров. Traefik автоматически читает конфиги из Kubernetes API без перезапуска. Weighted Round Robin распределяет трафик при canary-деплоях: 10% трафика на новую версию, 90% — на стабильную.

SaaS и B2B-платформы

Least Connections работает когда сессии живут долго — видеоконференции, IDE в браузере, длинные GraphQL-запросы. Сервер с 1000 активными соединениями не получит новый запрос, пока освободит место.

Получите бесплатную консультацию по вашему проекту

Настроим вашу Highload систему

Узнать больше

Виды балансировщиков и анализ рынка

Рынок делится на четыре сегмента: аппаратные, программные, облачные и GSLB (глобальная балансировка). Ниже — сравнение ключевых игроков.

Как выбирать балансировщик нагрузки

HAProxy — первый выбор для высоконагруженных систем. Держит 1 млн одновременных соединений, конфигурируется через текстовый файл, работает на любом Linux. Активно используется в проектах с микросервисами.

Nginx — универсальный вариант: и веб-сервер, и балансировщик, и reverse proxy. Простая конфигурация, большая документация, дешевле в обслуживании.

Traefik — выигрывает в Kubernetes-среде. Автоматически подхватывает новые сервисы без перезапуска. Хорошо интегрируется с Let's Encrypt и Docker Compose.

AWS ALB / ELB — если инфраструктура уже в AWS. Платишь за использование, не за настройку. Интегрируется с Auto Scaling Groups и AWS WAF.

F5 BIG-IP — enterprise-уровень с аппаратным SSL-терминатором и встроенным WAF. Стоит дорого, но в банках и телекоме часто требуется регулятором.

Алгоритмы балансировки

Алгоритм выбирает, на какой сервер уйдёт следующий запрос. Выбор зависит от архитектуры приложения и характера нагрузки.

Round Robin

Запросы идут по очереди: сервер A → B → C → A → ... Подходит, если серверы одинаковые по мощности, а запросы примерно равной длительности. REST API без состояния — типичный кейс.

Stickу Round Robin

Sticky Round Robin — это Round Robin с памятью. Sticky добавляет привязку: первый запрос от клиента распределяется по Round Robin, но потом все следующие его запросы идут на тот же сервер. Обычно через cookie или IP.

Нужно там, где сессия хранится на сервере — старые PHP-приложения, корзины без Redis, любой стейт in-memory. Если такого клиента пустить на другой сервер, он потеряет сессию и вылетит из-под авторизации.

Weighted Round Robin

То же, что Round Robin, но с весами. Сервер с весом 0,8 получает 80% запросов. Используют при постепенном масштабировании: новый сервер входит с весом 0,1, растёт по мере проверки.

IP / URL Hash

Клиент по IP-адресу привязывается к конкретному серверу. Пока IP не меняется — пользователь всегда попадает на один бэкенд. Нужен, если сессия хранится in-memory (старые PHP-приложения, некоторые WebSocket-серверы).

У URL Hash та же логика, но хэш считается по URL. Полезно для кэширующих серверов: один и тот же URL всегда идёт на один сервер — кэш не дублируется.

Least Connections

Новый запрос идёт на сервер с наименьшим числом активных соединений. Работает там, где запросы живут по-разному: один занимает 10 мс, другой — 30 секунд. WebSocket-соединения, SSH-туннели — сюда.

Least Response Time

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

Как понять, что балансировка работает нормально

Балансировщик работает правильно, если нагрузка распределена равномерно и система держит заданный SLA. Для этого смотрят на шесть групп метрик.

Трафик

• Request Rate — запросов в секунду на каждый бэкенд. Если один получает в 5 раз больше других — алгоритм или конфигурация неправильные.
• Total Connections — общее число активных соединений.

Безопасность

• TLS Handshake Time — рост говорит о перегрузке SSL-терминатора или устаревшем cipher suite.
• TLS Error Rates — сертификатные ошибки или несовместимость клиентов.

Производительность

• Response Time (P95, P99) — 95% запросов должны укладываться в заданный порог. Среднее врёт: один тормозящий запрос не портит среднее, но портит опыт.
• Latency — задержка на уровне балансировщика. Должна быть ниже 1 мс для L4, до 5 мс для L7.
• Throughput — мегабит в секунду через балансировщик.

Здоровье бэкендов

• Health Check Success Rate — какой процент бэкендов проходит healthcheck. Ниже 100% — кто-то уже выключен из ротации.
• Failed Health Checks — число неудачных проверок. Рост → нестабильный бэкенд.

Ошибки

• HTTP 5xx Rate — серверные ошибки. Пропорция выше 0,1% требует внимания.
• Dropped Connections — сброшенные соединения. Могут говорить о перегрузке или неправильном таймауте.

Нагрузка на серверы

• CPU Utilization per backend — если один сервер на 90% CPU, а другие на 30%, нужно пересмотреть веса или алгоритм.
• Memory Utilization — критично для long-lived соединений.

Получите бесплатную консультацию по вашему проекту

Настроим вашу Highload систему

Узнать больше