Реальні сценарії відмови без балансування
Уявіть: у день пікового навантаження ваш мобільний додаток обробляє 10 000 запитів на секунду. Один сервер не справляється, користувачі масово отримують 401 після логіну, а в чаті розриваються з'єднання. Швидше за все, проблема не в коді, а в балансуванні навантаження між інстансами бекенду. Неправильне налаштування сесій, healthcheck'ів або WebSocket-проксі призводить до розлогіну, обриву з'єднань і падіння продуктивності. Ми, як інженери з 5+ річним досвідом у мобільній розробці, бачимо цю проблему на кожному другому проєкті. Без грамотного балансування навіть добре написаний бекенд не витримає пікового навантаження. У цій статті розберемо реальні сценарії та дамо робочу конфігурацію.
Чому налаштування балансування навантаження важливе для мобільного бекенду?
Мобільні додатки особливо чутливі до затримок і розривів з'єднань. Балансування навантаження дозволяє рівномірно розподіляти трафік, уникаючи перевантаження окремих серверів. Для мобільних сценаріїв критична підтримка WebSocket для чатів і live-оновлень, а також stateless архітектура для безперебійної роботи при масштабуванні. Без правильного налаштування користувачі стикаються з розлогінами та втратою даних.
Як уникнути втрати сесій при балансуванні?
Мобільний клієнт логіниться, отримує JWT. Наступний запит потрапляє на інший под — якщо токени в пам'яті, а не в Redis, користувач розлогінений. Це реальний сценарій при stateful-сесіях без централізованого сховища. Рішення: stateless сервіс + JWT + Redis для shared state.
Інша проблема: WebSocket-з'єднання. Довге з'єднання для чату або live-трекінгу має завжди потрапляти на один і той самий под. Якщо балансувальник розірве WebSocket при деплої нового пода — всі активні з'єднання впадуть одночасно.
Як балансувати REST API і WebSocket?
Для більшості REST API достатньо L7 балансування (HTTP/HTTPS). Використовуємо 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 нативно. Таймаут виставляємо явно (proxy_read_timeout 3600s), інакше Nginx закриє idle-з'єднання через 60 секунд.
Чому health check має перевіряти базу даних?
Окремий endpoint /health/ready перевіряє коннект до БД, Redis, зовнішніх залежностей. Балансувальник виключає под із ротації при двох послідовних помилках, повертає при двох успішних відповідях.
Чому health check має бути готовим?
Одна з причин: GET / може повертати 200, коли БД вже не відповідає. Відсутність перевірки залежностей веде до каскадних відмов. Приклад: пікове навантаження 8000 rps в обідній час, один інстанс — 80% CPU. Додали балансування на 3 пода через AWS ALB, налаштували /api/health/ready з перевіркою PostgreSQL. Після першого деплою без балансувальника: 20 секунд простою (старий под вбили, новий ще не пройшов health check). Після налаштування minReadySeconds: 30 та rolling update з maxUnavailable: 0 — нульовий downtime на наступних 50+ деплоях.
Налаштування балансування навантаження через 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. За даними Kubernetes documentation, IPVS забезпечує краще масштабування при великій кількості сервісів.
Порівняння інструментів балансування
| Інструмент | Протоколи | Sticky sessions | WebSocket | Health check |
|---|---|---|---|---|
| Nginx | L4/L7 | Так (cookie/IP hash) | Так | Так (активний) |
| HAProxy | L4/L7 | Так (cookie) | Так | Так (активний) |
| AWS ALB | L7 | Так (cookie) | Так | Так (активний) |
| GCP LB | L7 | Так (cookie) | Так | Так (активний) |
Порівняння алгоритмів балансування
| Алгоритм | Особливості | Коли використовувати | Пропускна здатність |
|---|---|---|---|
| Round Robin | Рівномірний розподіл | Stateless сервіси, короткі запити | 10 000 rps на под |
| Least Connections | Віддає на найменш завантажений | Нерівномірне навантаження, важкі запити | 8 000 rps на под |
| IP Hash / Sticky | Прив'язка до IP | Legacy, stateful | 5 000 rps на под |
Round Robin обробляє запити в 1.5 рази швидше Least Connections при рівномірному навантаженні.
Що входить у налаштування під ключ
- Аудит поточної архітектури бекенду.
- Вибір і розгортання балансувальника (Nginx/HAProxy/Ingress).
- Налаштування health check endpoint'ів.
- Конфігурація WebSocket-проксі.
- Оптимізація алгоритмів розподілу.
- Документація з експлуатації та моніторингу.
- Гарантія zero-downtime деплою при дотриманні рекомендацій.
Терміни: базове налаштування — 1–2 дні. Повноцінне рішення з Kubernetes Ingress і mTLS — 1–2 тижні. Оцінимо ваш проєкт безкоштовно. Зв'яжіться з нами для консультації.
За 5+ років ми налаштували балансування для 50+ мобільних проєктів із піковим навантаженням до 10 000 rps. Використовуємо сертифіковані інструменти та гарантуємо uptime 99.9%. Nginx — один із найпопулярніших балансувальників. Отримайте безкоштовну консультацію прямо зараз.