Load Balancers: следующий шаг после освоения Docker

Когда одного контейнера уже мало

Помните тот день, когда вы запустили первое приложение в Docker и почувствовали себя DevOps-богом? docker run, docker-compose up — и всё работает. Красота. Но потом приходит настоящая нагрузка: один контейнер начинает задыхаться, пользователи жалуются на тормоза, а вы понимаете, что надо как-то масштабироваться.

Запускаете второй контейнер. Третий. И тут возникает вопрос: а как трафик распределять между ними? Какому контейнеру отдать следующий запрос? Что делать, если один упал? Вот тут и появляется Load Balancer — инструмент, который знает ответы на эти вопросы.

Зачем это нужно в реальной жизни

Давайте без теории. Вот три сценария из практики, когда балансировщик решает ваши проблемы:

Сценарий 1: Магазин в пятницу вечером

У вас интернет-магазин. В будни — 100 RPS, справляется один контейнер. В пятницу вечером — 800 RPS, и ваш единственный контейнер ложится. С балансировщиком вы запускаете 5 копий приложения, и он распределяет нагрузку. Результат: магазин работает, вы зарабатываете.

Сценарий 2: Обновление без простоя

Вам нужно обновить код. Без балансировщика: останавливаете контейнер → деплоите новую версию → запускаете. Сайт лежит 30-60 секунд. С балансировщиком: запускаете новые контейнеры → проверяете → переключаете трафик → убиваете старые. Простой = 0.

Сценарий 3: Отказоустойчивость из коробки

Один из контейнеров упал (OOM, сетевой сбой, космические лучи). Без балансировщика — пользователи видят 502. С балансировщиком — он отправляет запросы только на живые инстансы, проблема невидима снаружи.

Как это работает изнутри

Представьте Load Balancer как умного диспетчера такси. К нему приходят клиенты (запросы), а он решает, какому водителю (контейнеру) отдать следующий заказ. При этом он:

1. Проверяет здоровье водителей (health checks) — не отправит клиента к машине, которая сломалась
2. Распределяет по справедливости — не даст одному водителю 10 заказов, пока другие простаивают
3. Помнит контекст (session affinity) — если клиент начал диалог с одним водителем, доведёт его до конца с ним же

Технически это выглядит так:

Пользователь → Load Balancer (порт 80/443) → Backend серверы (контейнеры)
                    ↓
            Health checks каждые N секунд
                    ↓
            Маршрутизация по алгоритму

Стратегии балансировки (какую выбрать)

Балансировщики используют разные алгоритмы распределения нагрузки. Выбор зависит от вашего сценария:

Round Robin (по кругу)

Что: Запросы идут по очереди: 1-й контейнер → 2-й → 3-й → снова 1-й.

Когда использовать: Все контейнеры одинаковые, запросы примерно одинаковые по сложности. Самый простой и популярный вариант.

Пример: API для мобильного приложения, где каждый запрос — примерно одна и та же нагрузка.

Least Connections (наименьшее количество соединений)

Что: Новый запрос идёт на контейнер с наименьшим количеством активных соединений.

Когда использовать: Запросы разной сложности — одни отрабатывают за 50ms, другие за 5 секунд.

Пример: SaaS-платформа, где у вас есть быстрые GET-запросы и тяжёлые POST с обработкой данных.

IP Hash (по IP клиента)

Что: IP клиента хешируется, и запросы с одного IP всегда идут на один и тот же контейнер.

Когда использовать: У вас есть состояние на уровне приложения (in-memory кеш, сессии), и хочется минимизировать проблемы с ним.

Пример: Легаси-приложение с сессиями в памяти (хотя лучше вынести сессии в Redis).

Weighted Round Robin (взвешенный round robin)

Что: Как round robin, но одни контейнеры получают больше запросов, чем другие.

Когда использовать: У вас контейнеры на разном железе (например, 1 мощный сервер + 2 слабых), или вы делаете canary deployment (новая версия получает 10% трафика).

Пример: Постепенный переход на новую версию: старая версия получает 90% запросов, новая — 10%.

Популярные балансировщики: какой выбрать

Nginx — швейцарский нож

Плюсы:

• Быстрый, проверенный годами
• Можно использовать как HTTP-сервер + балансировщик + reverse proxy
• Огромное community, тонна гайдов
• Умеет отдавать статику, кешировать, терминировать SSL

Минусы:

• Конфигурация через текстовые файлы (не самая удобная для автоматизации)
• Для live reload конфига нужен nginx -s reload

Когда выбирать: Дефолтный выбор для большинства задач. Проверенное решение, которое работает везде.

Минимальный пример конфига:

upstream backend {
    server app1:8000;
    server app2:8000;
    server app3:8000;
}
 
server {
    listen 80;
    server_name example.com;
 
    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

HAProxy — когда нужна мощь

Плюсы:

• Экстремально быстрый (выдерживает 100k+ RPS на одной машине)
• Продвинутые алгоритмы балансировки и health checks
• TCP и HTTP балансировка (можно балансировать PostgreSQL, Redis, не только HTTP)
• Детальная статистика и метрики из коробки

Минусы:

• Только балансировщик, не умеет отдавать статику или терминировать SSL (ну, умеет, но это не его основная роль)
• Синтаксис конфига специфичный, сложнее для новичков

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

Пример конфига:

frontend http_front
    bind *:80
    default_backend app_servers
 
backend app_servers
    balance roundrobin
    option httpchk GET /health
    server app1 app1:8000 check
    server app2 app2:8000 check
    server app3 app3:8000 check

Traefik — современный и cloud-native

Плюсы:

• Автоматическое обнаружение сервисов (integration с Docker, Kubernetes)
• Автоматические SSL сертификаты через Let's Encrypt
• Красивый веб-интерфейс с реалтайм статистикой
• Конфигурация через labels в Docker или Kubernetes annotations

Минусы:

• Тяжелее Nginx/HAProxy по ресурсам
• Может быть избыточным для простых задач
• Меньше туториалов и статей, чем для Nginx

Когда выбирать: Микросервисная архитектура, Docker Swarm, Kubernetes. Когда хочется автоматизации и не хочется руками редактировать конфиги.

Пример с Docker Compose:

version: "3"
 
services:
  traefik:
    image: traefik:v2.10
    command:
      - "--providers.docker=true"
      - "--entrypoints.web.address=:80"
    ports:
      - "80:80"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
 
  app:
    image: myapp:latest
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.app.rule=Host(`example.com`)"
    deploy:
      replicas: 3

Практический пример: запускаем Nginx + 3 контейнера

Давайте руками соберём минимальный setup с Nginx и тремя копиями приложения.

docker-compose.yml:

version: "3.8"
 
services:
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    depends_on:
      - app1
      - app2
      - app3
 
  app1:
    image: hashicorp/http-echo
    command: ["-text", "Hello from app1"]
    expose:
      - "5678"
 
  app2:
    image: hashicorp/http-echo
    command: ["-text", "Hello from app2"]
    expose:
      - "5678"
 
  app3:
    image: hashicorp/http-echo
    command: ["-text", "Hello from app3"]
    expose:
      - "5678"

nginx.conf:

events {
    worker_connections 1024;
}
 
http {
    upstream backend {
        server app1:5678;
        server app2:5678;
        server app3:5678;
    }
 
    server {
        listen 80;
 
        location / {
            proxy_pass http://backend;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
 
        location /health {
            access_log off;
            return 200 "OK\n";
            add_header Content-Type text/plain;
        }
    }
}

Запуск:

docker-compose up

Проверка:

# Делаем несколько запросов
curl http://localhost
# Hello from app1
 
curl http://localhost
# Hello from app2
 
curl http://localhost
# Hello from app3
 
curl http://localhost
# Hello from app1 (цикл пошёл заново)

Health Checks — как балансировщик узнаёт о проблемах

Балансировщик не экстрасенс. Ему нужно явно сказать, как проверять здоровье бэкендов. Обычно это HTTP-endpoint, который возвращает 200 OK, если всё хорошо.

Простой health check endpoint (Python/FastAPI):

from fastapi import FastAPI
 
app = FastAPI()
 
@app.get("/health")
async def health():
    # Здесь можно проверить БД, Redis и т.д.
    return {"status": "ok"}

Конфигурация в Nginx:

upstream backend {
    server app1:8000 max_fails=3 fail_timeout=30s;
    server app2:8000 max_fails=3 fail_timeout=30s;
}

Конфигурация в HAProxy (более продвинутая):

backend app_servers
    option httpchk GET /health
    http-check expect status 200
    server app1 app1:8000 check inter 5s fall 3 rise 2
    server app2 app2:8000 check inter 5s fall 3 rise 2

Расшифровка:

• check inter 5s — проверять каждые 5 секунд
• fall 3 — считать сервер недоступным после 3 неудачных проверок
• rise 2 — считать сервер восстановленным после 2 успешных проверок

Типичные ошибки и как их избежать

Ошибка 1: Забыли про sticky sessions

Проблема: Пользователь авторизовался на app1, следующий запрос пошёл на app2, сессии там нет → логаут.

Решение: Либо используйте IP Hash / Cookie-based sticky sessions, либо (правильнее) вынесите сессии в Redis/PostgreSQL.

Ошибка 2: Неправильные заголовки

Проблема: Приложение не видит реальный IP клиента, видит IP балансировщика. Аналитика и логирование ломаются.

Решение: Настройте proxy headers правильно:

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

И научите приложение читать X-Real-IP или X-Forwarded-For.

Ошибка 3: Нет мониторинга балансировщика

Проблема: Балансировщик упал, и вы узнали об этом от пользователей.

Решение: Мониторьте:

• Доступность балансировщика (uptime check)
• Количество здоровых бэкендов
• Latency и error rate
• Throughput (RPS)

Используйте Prometheus + Grafana или cloudwatch/datadog, если в облаке.

Когда НЕ нужен Load Balancer

Балансировщик — не серебряная пуля. Вот когда он избыточен:

1. У вас один контейнер и нагрузка стабильная — зачем усложнять?
2. Локальная разработка — docker-compose up без nginx проще и быстрее
3. Stateful-сервисы без репликации — PostgreSQL, Redis master — балансировать нечего (хотя read-replicas можно)

Что дальше: путь к Kubernetes

Load Balancer — это мост между "я умею в Docker" и "я умею в продакшн". Следующие шаги:

1. Автоматизация масштабирования: сейчас вы руками пишете app1, app2, app3. В Kubernetes это replicas: 3.
2. Service Discovery: сейчас вы руками прописываете адреса бэкендов. В Kubernetes сервисы находят друг друга автоматически.
3. Rolling updates и rollbacks: сейчас вы руками переключаете версии. В Kubernetes это одна команда.

Но всё это — эволюция тех же идей, которые вы сегодня освоили. Kubernetes — это просто балансировщик + оркестратор + автоматизация на стероидах.

Выводы

Что запомнить:

1. Балансировщик — это прокси, который распределяет запросы между копиями приложения
2. Выбор алгоритма балансировки зависит от вашего сценария (round robin — дефолт для большинства)
3. Nginx — универсальный выбор, HAProxy — для высоких нагрузок, Traefik — для cloud-native
4. Health checks — обязательная часть setup'а, иначе балансировщик не узнает о проблемах
5. Это не конечная точка, а ступенька к оркестраторам (Docker Swarm, Kubernetes)

См. также:

• Нагрузочное тестирование — как проверить, что балансировка работает
• Proxmox — где развернуть свою инфраструктуру