Балансировка нагрузки
Тема дорожной карты · Backend разработчик
Балансировка нагрузки — практика распределения входящего сетевого трафика между несколькими экземплярами бэкенд-сервиса, предотвращающая превращение любого из них в узкое место и обеспечивающая высокую доступность, отказоустойчивость и оптимальное использование ресурсов. Балансировщики нагрузки уровня 4 (TCP), такие как HAProxy, маршрутизируют пакеты на основе IP и порта без инспекции HTTP-содержимого, тогда как балансировщики уровня 7 (HTTP), такие как NGINX, AWS ALB или Kubernetes Ingress-контроллеры, могут маршрутизировать по префиксу пути, заголовку host или cookie, обеспечивая сложное формирование трафика для микросервисов и канареечных деплоев. Алгоритмы балансировки нагрузки: round-robin (равномерное распределение), least-connections (маршрутизация к наименее загруженному бэкенду) и IP-hash (согласованная маршрутизация на одного клиента, необходимая для WebSocket upgrade-соединений) — каждый подходит для разных характеристик нагрузки. Проверки состояния (health check) являются неотъемлемой частью балансировки нагрузки — бэкенды, не прошедшие пробы GET /health, автоматически исключаются из ротации, обеспечивая деплои без простоя и автоматический переход при отказе экземпляра в Kubernetes. Конфигурация балансировки нагрузки управляется как Infrastructure as Code (IaC) через Terraform или YAML-манифесты Kubernetes; пропускная способность балансировщика, частота ошибок и количество соединений мониторятся через Prometheus и визуализируются в дашбордах Grafana.
Как это работает
Балансировка нагрузки бывает вертикальным (более мощная машина) — до лимитов одной, потом горизонтальным (больше машин за балансировщиком). Stateless-сервисы масштабируются горизонтально тривиально; stateful (БД, очереди) — через primary-replica репликацию, шардинг или оба. Read-реплики поглощают read-нагрузку; write-throughput требует либо больший primary, либо шардинг, либо хитрости (CQRS + eventual-consistency reads). Агрессивно кешируйте на границе (CDN), на app-слое (Redis), внутри процесса.
Когда применять
Сначала вертикально — самое дешёвое и наименее болезненное операционно. Read-реплики — когда primary DB тратит > 50% CPU на чтения. Шардируйте только когда ни один primary не справляется с write rate (эта точка дальше, чем думают — Postgres держит 10k+ writes/sec с тюнингом). CDN — для любого публичного статичного или редко-меняющегося контента; выигрыш в latency обычно 5-10×.
Типичные ошибки
Ловушки Балансировка нагрузки: расчёт, что горизонтальное масштабирование решит всё (нет для stateful); преждевременный шардинг (необратимо без огромных миграций); игнор pooling — 1000 app-pod'ов по 10 соединений валят БД; не нагружаете до решений о масштабе (тюните не тот слой). Сначала меряйте, потом масштабируйте, потом документируйте.