Балансировка трафика

Балансировка трафика перестаёт быть просто прокси перед сервисом, как только начинаются деградации, релизы и переключение на резерв.

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

На интервью и в архитектурных обсуждениях такой взгляд помогает объяснять не только схему распределения трафика, но и то, как система переживает релизы, сбои и рост нагрузки.

Практическая польза главы

Путь запроса

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

Выбор уровня

Разводите задачи L4 и L7 по характеру трафика, требованиям к маршрутизации и цене дополнительной логики.

Операционная устойчивость

Заранее продумывайте плавный ввод инстансов, вывод соединений и переключение на резерв, чтобы релизы не превращались в инциденты.

Аргументация на интервью

Связывайте бизнес-требование с конкретной схемой балансировки и объясняйте, какие сбои она должна переживать.

Reference

Envoy LB Overview

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

Открыть источник

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

Точка принятия решения

Заранее определите, где именно балансировщик должен принимать решение о маршрутизации: на транспортном или прикладном уровне.

Контроль состояния

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

Безопасный выпуск

Плавный ввод в трафик и плавный вывод соединений должны быть частью каждого релиза, а не только аварийного сценария.

Глобальная маршрутизация

Разделяйте выбор региона и балансировку внутри него: это два разных уровня архитектурного решения.

Практический план в 4 шага

Определите уровень балансировки

Шаг 1

Для каждого входного потока решите, нужен ли прикладной контроль маршрутизации на L7 или важнее минимальная цена обработки на L4.

Опишите контракт состояния

Шаг 2

Задайте активные проверки, пассивные сигналы и критерии вывода инстанса из ротации, чтобы ловить деградацию до массовых 5xx.

Подготовьте безопасный выпуск

Шаг 3

Используйте плавный ввод в трафик, проверки готовности и плавный вывод соединений, чтобы релизы не ломали долгоживущий трафик.

Разведите глобальную и локальную балансировку

Шаг 4

GSLB и anycast выбирают регион, а локальный балансировщик или сервисная сетка управляют трафиком уже внутри него.

L4 и L7: как выбрать уровень балансировки

Про что это: про выбор уровня, на котором принимается решение о маршрутизации: на транспортном уровне (L4) или на прикладном (L7).

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

Для каких сценариев подходит: L4 чаще для TCP-сервисов с сохранением состояния вроде БД, кэша или брокера, а L7 — для HTTP/gRPC API и продуктовых сценариев, где нужно тонкое управление политиками маршрутизации.

Критерий	L4	L7
Уровень модели	L4 (TCP/UDP): маршрутизация по IP и порту без анализа содержимого HTTP-запроса.	L7 (HTTP/gRPC): маршрутизация по пути, хосту, заголовкам и cookie-файлам.
Гибкость роутинга	Ниже: обычно простые алгоритмы вроде хеширования по ключу, leastconn и round-robin без правил по содержимому запроса.	Выше: канареечные запуски, A/B-сценарии, липкие сессии и маршрутизация по правилам приложения.
Производительность	Ниже накладные расходы по CPU и задержке, хорошо подходит для TCP-нагрузки с высокой пропускной способностью.	На каждый запрос приходится больше логики, зато контроль трафика становится точнее.
Типовые сценарии	Базы данных, Redis, MQTT, бинарные протоколы и TCP-сценарии, где критична минимальная задержка.	Шлюзы API, веб-приложения, gRPC и прикладные правила маршрутизации.

Пример L4 (HAProxy, TCP)

Подходит для PostgreSQL, Redis и других TCP-сервисов с сохранением состояния, где не нужны правила на уровне HTTP.

frontend ft_postgres
  bind *:5432
  mode tcp
  default_backend bk_postgres

backend bk_postgres
  mode tcp
  balance leastconn
  option tcp-check
  default-server inter 2s fall 3 rise 2
  server pg-1 10.0.1.11:5432 check
  server pg-2 10.0.1.12:5432 check

Пример L7 (Nginx, HTTP)

Подходит для шлюзов API, маршрутизации по пути и правил, которые применяются на уровне запроса.

upstream api_pool {
  least_conn;
  server 10.0.2.11:8080 max_fails=3 fail_timeout=10s;
  server 10.0.2.12:8080 max_fails=3 fail_timeout=10s;
}

server {
  listen 80;

  location /api/ {
    proxy_pass http://api_pool;
    proxy_set_header X-Request-Id $request_id;
  }

  location /static/ {
    proxy_pass http://static-service:8080;
  }
}

Проверки состояния и безопасный вывод инстансов

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

Зачем это нужно: даже идеальный алгоритм не спасёт, если трафик продолжает идти на деградировавшие или ещё не прогретые инстансы. Здесь сходятся , , , , , а также сценарии и .

Для каких сценариев подходит: кластеры с в Kubernetes,, и долгоживущие соединения вроде WebSocket или gRPC-stream, где резкий обрыв особенно болезнен.

Активные проверки состояния

Балансировщик сам опрашивает эндпоинт состояния или проверяет TCP-рукопожатие. Можно настроить интервал, тайм-аут, пороги восстановления и заранее исключать деградирующие инстансы.

Пассивные проверки состояния

Решение о деградации принимается по живому трафику: 5xx, тайм-аутам, разрывам соединений и росту задержки. Это помогает увидеть проблему, когда эндпоинт формально жив, но сервис уже не справляется с нагрузкой.

Плавный ввод инстанса в трафик

Новый инстанс сначала получает небольшую долю запросов. Это снижает риск холодного старта и даёт прогреть кэши, JIT и пул соединений до полной нагрузки.

Плавный вывод соединений

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

HAProxy: плавный ввод и политика проверки состояния

backend app
  balance leastconn
  option httpchk GET /healthz
  http-check expect status 200
  default-server inter 2s fall 3 rise 2 slowstart 30s
  server app-1 10.0.3.11:8080 check
  server app-2 10.0.3.12:8080 check

Kubernetes: пробы готовности и аккуратное завершение

spec:
  terminationGracePeriodSeconds: 40
  containers:
    - name: app
      readinessProbe:
        httpGet:
          path: /readyz
          port: 8080
      lifecycle:
        preStop:
          exec:
            command: ["/bin/sh", "-c", "sleep 20"]

Глобальная балансировка между регионами (GSLB)

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

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

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

GSLB на основе DNS

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

Плюсы: Простая интеграция и хороший базовый вариант для поэтапного развития схемы с несколькими регионами.

Ограничения: Скорость реакции ограничена TTL и кэшами DNS у клиентов и резолверов, поэтому переключение не всегда происходит мгновенно.

Когда использовать: Веб- и API-трафик, для которого допустимо переключение в пределах секунд или десятков секунд.

Anycast

Один и тот же IP объявляется из нескольких точек присутствия и регионов, а маршрутизация направляет трафик в топологически ближайшую точку.

Плюсы: Быстрое глобальное распределение трафика и высокая устойчивость внешнего контура.

Ограничения: На уровне DNS-ответа здесь меньше L7-контроля; нужна зрелая сеть, хорошая наблюдаемость и аккуратная работа с колебаниями маршрутов.

Когда использовать: Edge-уровень, L4-вход, DNS и глобальные API, где особенно важна минимальная задержка.

Сервисная сетка (service mesh) в Kubernetes

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

Как этот блок связан с предыдущими: после L4/L7, контроля состояния и GSLB логично показать, как те же принципы масштабируются внутрь Kubernetes-кластера через прокси рядом с сервисом, и .

Для каких сценариев подходит: десятки/сотни сервисов, единые правила маршрутизации, канареечные выкатывания и дробление трафика, и необходимость централизованно применять .

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

Istio DestinationRule

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: payments
spec:
  host: payments.default.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 5s
      baseEjectionTime: 30s

Istio locality failover

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: checkout-locality
spec:
  host: checkout.default.svc.cluster.local
  trafficPolicy:
    localityLbSetting:
      enabled: true
      failover:
        - from: us-east1
          to: us-central1

Частые ошибки

Ограничиваться одним round-robin без проверки профиля трафика, 99-го перцентиля и длительности соединений.
Считать пробы readiness и liveness в Kubernetes полноценной заменой пассивным проверкам состояния на L7.
Ставить длинный DNS TTL и при этом ожидать быстрого переключения между регионами во время инцидента.
Игнорировать плавный вывод соединений при релизе и получать всплеск 5xx из-за обрыва долгоживущих запросов.

Источники

Связанные главы

Принципы проектирования масштабируемых систем - даёт базовый контекст про компромиссы масштабирования, на который опираются решения по балансировке.
Алгоритмы балансировки - детально сравнивает Round Robin, Least Connections и Consistent Hashing для разных профилей нагрузки.
Обнаружение сервисов (service discovery) - объясняет, как поддерживать актуальный список живых инстансов, без которого балансировщик быстро теряет точность.
Архитектура сервисной сетки (service mesh) - показывает, как L7-балансировка, повторные попытки и выявление аномальных инстансов работают внутри сервисной сетки.
Multi-region / Global Systems - углубляет глобальную маршрутизацию и переключение между регионами, дополняя часть про GSLB.
DNS - объясняет ограничения DNS-маршрутизации: TTL, кэши резолверов и задержку переключения между регионами.
Kubernetes Fundamentals - даёт операционный контекст для проверок готовности, хуков жизненного цикла и безопасного смещения трафика во время релизов.
API Gateway - показывает прикладной L7-сценарий, где правила маршрутизации становятся частью продуктовой архитектуры.