Настройка балансировки нагрузки бэкенда мобильного приложения
Балансировщик нагрузки — не просто «раздать запросы по двум серверам». Неправильная настройка сессий, sticky sessions или healthcheck'ов приводит к тому, что пользователь получает 401 Unauthorized после успешного логина, потому что запрос попал на другой инстанс.
Где конкретно ломается без правильной балансировки
Мобильный клиент логинится, получает JWT. Следующий запрос попадает на другой под — если токены в памяти, а не в Redis, пользователь разлогинен. Это реальный сценарий при stateful-сессиях без централизованного хранилища.
Другая проблема: WebSocket-соединения. Долгое соединение для чата или live-трекинга должно всегда попадать на один и тот же под. Если балансировщик разорвёт WebSocket при деплое нового пода — все активные соединения упадут одновременно.
Конфигурация под мобильный трафик
L7 балансировка (HTTP/HTTPS). Для большинства REST API — достаточно. Nginx, HAProxy, AWS ALB, Google Cloud Load Balancing. Алгоритм — Round Robin для stateless сервисов, Least Connections если есть тяжёлые запросы (загрузка файлов, сложные агрегаты).
Sticky sessions — избегать. Привязка пользователя к поду через SERVERID cookie или IP hash — это потеря горизонтальной масштабируемости. Если под упал, пользователь отвалился. Правильнее: stateless сервис + JWT + Redis для shared state.
WebSocket. Nginx: proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade";. AWS ALB поддерживает WebSocket нативно. Timeout для WebSocket-соединений — выставить явно (proxy_read_timeout 3600s), иначе Nginx закроет idle-соединение через 60 секунд.
Health check. Не GET / — там может быть HTML страница «сервис запущен», но не значит что БД доступна. Отдельный endpoint /health/ready: проверяет коннект к БД, Redis, внешним зависимостям. Балансировщик исключает под из ротации при двух последовательных ошибках, возвращает при двух успешах.
Kubernetes Ingress как балансировщик
В Kubernetes-среде балансировка происходит на уровне Service (kube-proxy, iptables / IPVS) + Ingress-контроллер для внешнего трафика. Ingress-NGINX — стандарт де-факто: поддерживает WebSocket, rate limiting через nginx.ingress.kubernetes.io/limit-rps аннотацию, upstream hashing для нужных эндпоинтов.
IPVS-режим kube-proxy вместо iptables: при 1000+ сервисов iptables-правила становятся линейными по времени обработки, IPVS — O(1). Включается через --proxy-mode=ipvs в kube-proxy ConfigMap.
Кейс: мобильное приложение для доставки, пиковая нагрузка 8000 rps в обеденное время. Один инстанс бэкенда — 80% CPU в пик. Добавили балансировку на 3 пода через AWS ALB, настроили /api/health/ready с проверкой PostgreSQL-коннекта. После первого же деплоя без балансировщика: 20 секунд downtime (старый под убили, новый ещё не прошёл health check). После настройки minReadySeconds: 30 и rolling update стратегии с maxUnavailable: 0 — нулевой downtime на следующих 50+ деплоях.
Сроки: базовая настройка Nginx/HAProxy балансировки с health check — 1–2 дня. Полноценная Kubernetes Ingress конфигурация с mTLS, rate limiting, zero-downtime deploys — 1–2 недели.