Équilibrage de charge

🌐 Cet article est en russe. Lire via Google Traduction →

Load Balancer (LB) — это сервер (или сервис), который распределяет входящие запросы между несколькими бэкенд-серверами. Зачем:

Масштабирование — один сервер не справляется с 100К запросов/сек. 10 серверов по 10К — справляются.
Отказоустойчивость — если один сервер упал, LB перекидывает трафик на другие. Пользователь не замечает.
Гибкость — добавили серверы — увеличили ёмкость. Убрали — уменьшили расходы.
SSL-терминация — LB расшифровывает HTTPS, бэкенды работают по HTTP (дешевле).

Algorithmes

Пользователи
   ↓
[Cloudflare / CDN]
   ↓
[Load Balancer]   ← здесь
   ↓ ↓ ↓
[Server 1] [Server 2] [Server 3]
   ↓
[Database]

Round Robin

Самый простой: запрос 1 → server 1, запрос 2 → server 2, запрос 3 → server 3, запрос 4 → server 1, ...

Плюсы: простой, предсказуемый.

Минусы: не учитывает нагрузку. Если server 1 — мощный, а server 3 — слабый, нагрузка неравномерна.

Weighted Round Robin

Учитывает вес сервера: server 1 (weight=5) получает 5 запросов, server 2 (weight=3) — 3, server 3 (weight=2) — 2. Затем цикл.

Least Connections

Запрос идёт на сервер с наименьшим количеством активных соединений. Хорошо для долгих соединений (WebSocket, загрузка файлов).

Least Response Time

На сервер с минимальным временем отклика. Адаптивный — учитывает реальную скорость серверов.

IP Hash

Хеш от IP клиента определяет сервер. Один пользователь всегда попадает на один сервер. Полезно для кэша сессий.

Random

Случайный сервер. Простой, но неравномерный при малом числе запросов. Улучшение: Power of Two Choices — выбрать 2 случайных сервера, отправить на тот, у кого меньше нагрузка.

Consistent Hashing

Для распределённых кэшей (Redis, Memcached). Хеш ключа определяет ноду. Добавление/удаление ноды — перебалансирует минимум ключей.

Moins de connexions

L4 (Transport Layer)

Балансирует на уровне TCP/UDP. Смотрит только на IP:port, не на содержимое. Очень быстро (миллионы запросов/сек).

Примеры: HAProxy (TCP mode), AWS NLB, Linux Virtual Server (LVS), NGINX stream module.

Когда использовать: высокая производительность, не нужна маршрутизация по URL/заголовкам.

L7 (Application Layer)

Балансирует на уровне HTTP. Может смотреть на URL, заголовки, cookies, метод. Может маршрутизировать: /api/* → api-серверы, /static/* → static-серверы.

Примеры: HAProxy (HTTP mode), Nginx, AWS ALB, Envoy, Traefik, Caddy.

Когда использовать: нужна умная маршрутизация, A/B тесты, sticky sessions по cookie.

Hachage IP

LB периодически проверяет, жив ли бэкенд. Если нет — исключает из пула.

GET /health HTTP/1.1
Host: server1.example.com

→ 200 OK
→ Сервер здоров, в пуле

→ Timeout / 500 Error
→ Сервер исключён, трафик не идёт

Активный (LB опрашивает) и пассивный (LB видит ошибки от клиентов).

Nginx équilibreur

Для приложений, которые хранят сессию в памяти (а не в Redis): один пользователь всегда на одном сервере.

Методы:

Cookie-based — LB ставит cookie с server ID, браузер отправляет обратно.
IP Hash — хеш от IP (неточно, NAT, прокси).

Лучше всё-таки хранить сессии в Redis — stateless-архитектура проще.

HAProxy

LB расшифровывает HTTPS, бэкенды общаются с LB по HTTP (без шифрования внутри сети — если доверенная).

Плюсы:

Бэкенды не тратят CPU на TLS.
Сертификаты в одном месте (на LB), а не на каждом сервере.
Проще обновлять.

Минус: трафик между LB и бэкендами без шифрования. В публичных сетях — небезопасно. В VPC (AWS) — обычно приемлемо.

Équilibreurs cloud

Решение	Уровень	Для кого	Стоимость
HAProxy	L4, L7	High-load веб	Бесплатно (open source)
Nginx	L7 (и L4 stream)	Веб-сервер + LB	Бесплатно (NGINX Plus — платный)
Envoy	L7	Service mesh, микросервисы	Бесплатно
Traefik	L7	Docker/Kubernetes	Бесплатно
Caddy	L7	Простые сайты	Бесплатно
AWS ALB	L7	AWS	Pay-as-you-go
AWS NLB	L4	AWS, высокая нагрузка	Pay-as-you-go
Cloudflare	L7	Глобальный LB + CDN	Бесплатно / платные планы
Yandex ALB	L7	Yandex Cloud	Pay-as-you-go

Vérifications de santé

global
    maxconn 50000
    log /dev/log local0

defaults
    mode http
    timeout connect 5s
    timeout client 30s
    timeout server 30s

frontend web
    bind *:80
    bind *:443 ssl crt /etc/ssl/cert.pem
    redirect scheme https if !{ ssl_fc }
    default_backend servers

backend servers
    balance roundrobin
    option httpchk GET /health
    server web1 10.0.1.10:8080 check
    server web2 10.0.1.11:8080 check
    server web3 10.0.1.12:8080 check

Conclusion

upstream backend {
    least_conn;
    server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.12:8080 max_fails=3 fail_timeout=30s;
}

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;
    }
}

Масштабирование

Горизонтальное (scale out)

Добавляем серверы. 1 → 10 → 100. LB автоматически распределяет нагрузку.

Главное: stateless-приложение (сессии в Redis, файлы в S3, БД отдельно).

Вертикальное (scale up)

Увеличиваем ресурсы существующего сервера (CPU, RAM, диск). До какого-то предела — потом упираемся.

Auto-scaling

Автоматическое добавление/удаление серверов по нагрузке (CPU > 70% — добавить, < 30% — убрать). AWS Auto Scaling, Kubernetes HPA, GCP Managed Instance Groups.

Blue-Green и Canary

Blue-Green Deployment

Два идентичных окружения — Blue (текущая версия) и Green (новая). LB переключает 100% трафика на Green. Если проблема — мгновенный rollback на Blue.

Canary Deployment

Новая версия получает 1-5% трафика. Мониторим ошибки. Если ОК — увеличиваем до 50%, потом до 100%. Если проблема — откат.

Идеально для zero-downtime deployments.

FAQ

Что такое Load Balancing? Load Balancer (LB) — сервер/сервис, который распределяет входящие запросы между несколькими бэкенд-серверами. Зачем: масштабирование (1 сервер не справляется — 10 серверов справляются), отказоустойчивость (если один упал, LB перекидывает трафик на другие), гибкость (добавили серверы — увеличили ёмкость), SSL-терминация (LB расшифровывает HTTPS, бэкенды работают по HTTP).

Какие алгоритмы балансировки? Round Robin — по очереди. Weighted Round Robin — с учётом весов серверов. Least Connections — на сервер с наименьшим числом активных соединений. Least Response Time — на самый быстрый сервер. IP Hash — по хешу IP клиента (для sticky sessions). Random — случайный. Consistent Hashing — для распределённых кэшей (Redis).

Чем L4 отличается от L7? L4 (Transport Layer) — балансирует на уровне TCP/UDP, смотрит только на IP:port, не на содержимое. Очень быстро (миллионы запросов/сек). Примеры: HAProxy TCP mode, AWS NLB. L7 (Application Layer) — балансирует на уровне HTTP, может смотреть на URL, заголовки, cookies, метод. Может маршрутизировать: /api/* → api-серверы, /static/* → static-серверы. Примеры: HAProxy HTTP mode, Nginx, AWS ALB.

Что такое Health Check в Load Balancer? LB периодически проверяет, жив ли бэкенд: GET /health. Если нет (timeout или 500) — исключает из пула, трафик не идёт на мёртвый сервер. Активный (LB опрашивает) и пассивный (LB видит ошибки от клиентов).

Что такое Sticky Sessions? Один пользователь всегда попадает на один сервер. Нужно для приложений, которые хранят сессию в памяти (а не в Redis). Методы: cookie-based (LB ставит cookie с server ID), IP Hash (хеш от IP, неточно из-за NAT). Лучше всё-таки хранить сессии в Redis — stateless-архитектура проще.

👉 Site Analyzer → — проверьте, есть ли CDN, WAF и балансировщик на вашем сайте.