Компьютерные сети
Load Balancing: основы
Цели урока
- Понимать зачем нужен LB: distribution, health, отказоустойчивость, удаление SPOF
- Различать L4 (TCP/UDP) и L7 (HTTP) балансировку, и когда какой нужен
- Знать алгоритмы: round-robin, least-conn, weighted, consistent hashing
- Понимать active health checks vs passive (out-of-band ping vs реальный трафик)
- Применять sticky sessions осознанно: нужны только для stateful-серверов
Один сервер обрабатывает 1000 запросов в секунду. Пришло 2000 - он упал. Добавили второй сервер - но как разделить трафик? Load Balancer - диспетчер, который решает, кому работать.
- **Netflix** - сотни тысяч серверов, балансировка на нескольких уровнях (DNS, L4, L7)
- **Kubernetes** - Service + kube-proxy реализуют внутреннюю балансировку между pod'ами
- **AWS ELB/ALB** - managed load balancer, миллионы запросов в секунду
Предварительные знания
Зачем нужна балансировка нагрузки
Один сервер обрабатывает ограниченное число запросов. Когда нагрузка растёт - добавляют серверы. Но как направить трафик на несколько серверов? **Load Balancer** - компонент, который распределяет запросы между backend-серверами.
**Преимущества Load Balancer**: высокая доступность (один сервер упал - остальные работают), масштабируемость (добавить сервер = увеличить мощность), гибкость (обновления без простоя).
Алгоритм балансировки определяет, какой сервер получит следующий запрос. Выбор зависит от характера нагрузки: одинаковые короткие запросы, длинные соединения, требования к сессиям.
Какую проблему НЕ решает Load Balancer?
Round Robin и Weighted Round Robin
**Round Robin** - простейший алгоритм: запросы распределяются по очереди. Первый запрос → Server 1, второй → Server 2, третий → Server 3, четвёртый → снова Server 1. Не учитывает нагрузку серверов.
**Weighted Round Robin** добавляет веса серверам. Если Server 1 мощнее в 2 раза - даём ему вес 2, остальным по 1. Теперь S1 получает 2 запроса на каждый запрос S2 и S3.
**Когда использовать Round Robin?** Для stateless-сервисов с однородными запросами. Если запросы сильно различаются по времени выполнения - Round Robin создаст дисбаланс.
Сервер с weight=3 в конфигурации Nginx получит:
Least Connections и адаптивные алгоритмы
**Least Connections** - запрос идёт на сервер с минимальным числом активных соединений. Учитывает реальную загрузку: медленный запрос держит соединение дольше - сервер получит меньше новых.
**Weighted Least Connections** - комбинация весов и подсчёта соединений. Формула: соединения / вес. Мощный сервер (вес 3) с 6 соединениями = 2, слабый (вес 1) с 3 соединениями = 3. Запрос пойдёт на мощный.
**Least Response Time** - ещё умнее: учитывает не только число соединений, но и время отклика сервера. Если сервер начал тормозить - он получит меньше запросов автоматически.
Для какого сценария Least Connections лучше Round Robin?
Health Checks: проверка живучести
Балансировщик должен знать, какие серверы работают. **Health Check** - периодические проверки доступности серверов. Если сервер не отвечает - он исключается из ротации.
**Типы health checks**: TCP (порт открыт?), HTTP (статус 200?), глубокий (проверка БД, зависимостей). Глубокие проверки надёжнее, но дороже.
**Passive health checks** - отслеживание реальных запросов. Если N запросов подряд вернули ошибку - сервер помечается нездоровым. Активные и пассивные проверки часто комбинируют.
**Graceful shutdown** - сервер сообщает, что скоро выключится. Health check начинает возвращать 503, LB перестаёт слать новые запросы, но текущие завершаются нормально.
Health check достаточно делать раз в минуту
Интервал 5-10 секунд оптимален - быстрое обнаружение проблем при разумной нагрузке
При интервале в минуту падение сервера означает до 60 секунд ошибок у пользователей. 5-секундный интервал + 2 fails = обнаружение за 10 секунд. Слишком частые проверки (1 сек) создают лишнюю нагрузку на серверы.
Почему глубокий health check (проверка БД) лучше простого TCP?
Итоги
- **Round Robin** - по очереди, просто, но не учитывает нагрузку. Weighted RR добавляет веса серверам
- **Least Connections** - на сервер с минимумом активных соединений, адаптируется к реальной нагрузке
- **Health Checks** - периодические проверки живучести (TCP/HTTP/deep), исключение упавших серверов из ротации
Связанные темы
Load Balancing - ключевой компонент современной инфраструктуры:
- L4 vs L7 балансировка — Разные уровни работы LB - TCP vs HTTP
- Reverse Proxy — Nginx/HAProxy часто совмещают роль proxy и LB
Вопросы для размышления
- Почему Round Robin может создать дисбаланс при разных временах обработки запросов?
- Как бы вы реализовали graceful shutdown сервера за балансировщиком?
- Какие проблемы возникают с сессиями пользователей при балансировке?