Налаштування балансування навантаження серверної частини мобільного додатку
Балансування навантаження — це не просто розподіл запитів на два сервери. Неправильна конфігурація сесій, sticky sessions або health check'ів приводить до того, що користувач отримує 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 для спільного стану.
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 закриє неактивні з'єднання через 60 секунд.
Health check'и. Не GET / — це може повернути HTML сторінку «сервіс запущено» без перевірки доступності бази даних. Використовуйте спеціальну точку /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 режим замість iptables в kube-proxy: з 1000+ сервісами правила iptables стають лінійними за часом обробки; IPVS — O(1). Увімкніть через --proxy-mode=ipvs в ConfigMap kube-proxy.
Реальний приклад: мобільний додаток доставки з піковим навантаженням 8000 rps опівдні. Один екземпляр серверної частини використовує 80% CPU на піку. Після додавання балансування на 3 поди через AWS ALB з перевіркою PostgreSQL підключення на /api/health/ready, перше розгортання без цієї установки спричинило 20 секунд простою (старий під видалено, новий ще не готовий). Після налаштування minReadySeconds: 30 і rolling update стратегії з maxUnavailable: 0, наступні 50+ розгортань досягли нульового часу простою.
Час реалізації: базова конфігурація балансування Nginx/HAProxy з health check'ами — 1–2 дні. Повна конфігурація Kubernetes Ingress з mTLS, rate limiting та zero-downtime розгортаннями — 1–2 тижні.