System Design
Load Balancer
2021 год, инцидент Facebook. Ошибка в BGP-конфигурации вывела из строя DNS-серверы - весь трафик ударил в несколько оставшихся точек входа. За 6 часов компания потеряла ~$60M выручки. Один узел без резервирования превратился в катастрофу. Load Balancer существует именно для того, чтобы такого не было.
- **Nginx** - de-facto стандарт L7 LB для большинства веб-серверов, от стартапов до крупных сервисов
- **AWS ALB (Application Load Balancer)** - managed L7 LB в облаке, автоматически реплицируется по зонам доступности
- **Cloudflare** - глобальная сеть из 300+ точек присутствия, каждая работает как LB с GeoDNS и Anycast
Цели урока
- Понимать роль Load Balancer в архитектуре
- Различать L4 и L7 балансировку
- Знать основные алгоритмы: Round Robin, Least Connections, IP Hash
- Понимать важность Health Checks и их типы
- Знать как обеспечить HA для самого LB
- Понимать trade-offs SSL Termination vs Passthrough
Предварительные знания
- Оценка нагрузки (QPS)
- Базовое понимание HTTP и TCP
Что такое Load Balancer
**Load Balancer** - это точка входа, которая распределяет входящий трафик между несколькими серверами. Без него один сервер становится узким местом (bottleneck).
Сервис стал популярным. Один сервер уже не справляется с нагрузкой. Что делать?
- Масштабирование: один сервер не вытягивает 10K QPS
- Отказоустойчивость: сервер может упасть, нужен резерв
- Zero-downtime deploys: обновляем серверы по очереди
Load Balancer решает две проблемы: **масштабирование** (горизонтальное добавление серверов) и **отказоустойчивость** (automatic failover).
Какие две основные проблемы решает Load Balancer?
L4 vs L7 балансировка
Load Balancer может работать на разных уровнях сетевой модели OSI. Два основных варианта: **Layer 4** (транспортный) и **Layer 7** (прикладной).
Layer 4 Load Balancer
L4 работает с TCP/UDP пакетами. Он видит только IP-адрес и порт, но не содержимое запроса.
- **Преимущества**: Очень быстрый, низкая latency, работает с любым протоколом
- **Недостатки**: Не видит HTTP-заголовки, не может роутить по URL, нет sticky sessions по cookie
Layer 7 Load Balancer
L7 понимает HTTP протокол. Он может принимать решения на основе URL, headers, cookies.
- **Преимущества**: Роутинг по URL/headers, SSL termination, сжатие, A/B testing
- **Недостатки**: Медленнее (парсит HTTP), требует больше ресурсов, только HTTP/HTTPS
| Критерий | L4 | L7 |
|---|---|---|
| Скорость | Быстрее | Медленнее |
| Протоколы | Любой TCP/UDP | HTTP/HTTPS |
| Роутинг | IP + Port | URL, Headers, Cookies |
| SSL | Passthrough | Termination |
| Use case | Databases, Games | Web apps, APIs |
Какой LB нужен для роутинга запросов /api/users/* на Users сервис?
Алгоритмы балансировки
Как LB решает, на какой сервер отправить следующий запрос? Есть несколько алгоритмов с разными trade-offs.
Round Robin
Weighted Round Robin
Least Connections
IP Hash
| Алгоритм | Лучше всего для | Недостаток |
|---|---|---|
| Round Robin | Stateless API, равные серверы | Не учитывает нагрузку |
| Weighted RR | Серверы разной мощности | Ручная настройка |
| Least Connections | WebSocket, долгие запросы | Не учитывает latency |
| IP Hash | Sticky sessions нужны | Проблемы с NAT |
| Least Response Time | Критичная latency | Сложнее реализовать |
**Рекомендация**: начни с Round Robin. Если есть long-lived connections - Least Connections. Если нужны sticky sessions - IP Hash или cookies.
Какой алгоритм лучше для WebSocket соединений, которые держатся долго?
Health Checks
Load Balancer должен знать, какие серверы живы, а какие упали. **Health Check** - периодическая проверка состояния backend-ов.
**Опасность Deep Health Check**: если /health проверяет БД, то при падении БД все серверы станут "нездоровыми" и LB выведет их всех. Cascade failure!
Параметры Health Check
| Параметр | Значение | Описание |
|---|---|---|
| Interval | 5-10 сек | Как часто проверять |
| Timeout | 2-3 сек | Сколько ждать ответа |
| Unhealthy threshold | 2-3 | Провалов до 'мёртв' |
| Healthy threshold | 2 | Успехов до 'жив' |
Пример: AWS ALB Health Check
Типичная конфигурация для production
Interval = 10 секунд Timeout = 5 секунд Unhealthy threshold = 2 Healthy threshold = 2 Сценарий падения: • t=0: Сервер упал • t=10: Первая проверка - FAIL • t=20: Вторая проверка - FAIL • t=20: Сервер выведен из ротации Итого: 20 секунд на обнаружение
Почему Deep Health Check (проверка БД в /health) может быть опасен?
High Availability Load Balancer
Load Balancer сам может стать single point of failure. Если LB упадёт - весь сервис недоступен. Решение: **Active-Passive** или **Active-Active** пара.
Active-Active Setup
**В облаках HA встроен**: AWS ALB, GCP Load Balancer, CloudFlare автоматически реплицируются. Не нужно настраивать Active-Passive руками.
Что такое Virtual IP (VIP) в контексте HA Load Balancer?
SSL Termination
Где обрабатывать SSL/TLS - на Load Balancer или на backend серверах? Это важное архитектурное решение.
SSL Termination на LB
SSL Passthrough
| Критерий | SSL Termination | SSL Passthrough |
|---|---|---|
| Шифрование | До LB | End-to-end |
| Управление сертами | Централизованное | На каждом сервере |
| L7 features | Да | Нет (только L4) |
| CPU на backend | Меньше | Больше |
| Compliance | Зависит | Строгий (PCI DSS) |
**Рекомендация**: SSL Termination для большинства случаев. SSL Passthrough только при строгих compliance требованиях или для mTLS между сервисами.
Что теряется при использовании SSL Passthrough вместо SSL Termination?
Ключевые выводы
- **L4** - быстрый, для TCP/UDP. **L7** - умный, для HTTP
- **Round Robin** - просто, но Least Connections лучше для долгих соединений
- **Health Checks** - обязательны. Shallow лучше Deep (избегай cascade failures)
- **HA** - пара LB с Virtual IP или managed облачный LB
- **SSL Termination** - на LB для простоты, Passthrough для строгого compliance
Связанные темы
Load Balancer - часть инфраструктуры
- Кэширование — Снижает нагрузку на backend, работает вместе с LB
- CDN — Географическое распределение + edge LB
- API Gateway — L7 LB + аутентификация + rate limiting
Вопросы для размышления
- Сервис обрабатывает 50K RPS через AWS ALB. Три backend-сервера с Round Robin. Один сервер обрабатывает тяжёлые ML-запросы (5 сек), остальные - лёгкие API (50 мс). Как изменить архитектуру балансировки, чтобы ML-запросы не занимали обычные серверы и не тормозили весь сервис?