Налаштування автоскейлінгу серверів мобільного додатку
Ми знаємо, як виглядає 503 на екрані користувача після push-розсилки. Коли 3000 rps б'ють в один под — сервер падає, рейтинг в store летить вниз. Автоскейлінг вирішує цю проблему, але його налаштування потребує розуміння архітектури. У нашій практиці — 50+ проєктів, де правильно налаштований HPA та KEDA скоротили витрати на інфраструктуру на 30–50%. У цьому матеріалі розбираємо, як досягти zero-downtime для мобільного API з гарантією SLA.
Як вибрати між HPA та KEDA?
| Тип | Опис | Коли використовувати |
|---|---|---|
| HPA | Scale за CPU/пам'яттю | Передбачуване навантаження, стандартні метрики |
| VPA | Зміна requests/limits | JVM-сервіси з ростом heap |
| Cluster Autoscaler | Додавання нод | Нестача ресурсів кластера |
| KEDA | Scale за зовнішніми подіями | Черги, Kafka lag, push-сповіщення |
Для мобільного API з push-сповіщеннями KEDA реагує на зміни навантаження в 2–3 рази швидше, ніж HPA за CPU, тому що скейлінг запускається до приходу трафіку.
Види автоскейлінгу і коли що застосовувати
Horizontal Pod Autoscaler в Kubernetes — додає поди при зростанні навантаження, прибирає при спаді. Базова метрика — CPU utilization, але для мобільного API краще: latency p99, кількість запитів у черзі, або custom metric з Prometheus.
Vertical Pod Autoscaler — змінює requests/limits пода. Корисно для JVM-сервісів, де memory зростає в міру прогріву heap. Але VPA потребує рестарту пода при зміні ресурсів — не підходить для stateful сервісів.
Cluster Autoscaler — додає/прибирає Kubernetes nodes у хмарі (AWS EC2, GCP GKE, Azure AKS). Працює спільно з HPA: HPA хоче 5 подів, але немає місця — Cluster Autoscaler додає ноду.
KEDA — скейлінг за зовнішніми метриками: довжина черги в RabbitMQ, Kafka lag, кількість повідомлень у Redis Streams. Для мобільного додатку з чергою push-сповіщень: воркери масштабуються за кількістю задач у черзі, а не за CPU.
Налаштування HPA для мобільного API
Проблема стандартного CPU-скейлінгу: при піку запитів CPU спочатку зростає, потім HPA вирішує додати под (15–30 секунд), под стартує (ще 10–30 секунд), проходить readiness probe. Разом: 30–60 секунд поки новий под почне приймати трафік. За цей час частина мобільних клієнтів отримала 503.
Рішення:
- Predictive scaling — заздалегідь масштабуємося перед очікуваним піком (відправка пуша → одразу scale out)
- ScaleUp faster, ScaleDown slower —
scaleUp.stabilizationWindowSeconds: 0(миттєво масштабуємося вгору),scaleDown.stabilizationWindowSeconds: 300(чекаємо 5 хвилин перед зменшенням, щоб не пиляти) - MinReplicas: 2 — ніколи не опускатися до 1 пода, щоб rolling update не давав downtime
spec: minReplicas: 2 maxReplicas: 20 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60 behavior: scaleUp: stabilizationWindowSeconds: 0 policies: - type: Pods value: 4 periodSeconds: 60 scaleDown: stabilizationWindowSeconds: 300 Покрокова інструкція з налаштування HPA:
- Визначте метрику (CPU, memory або custom).
- Встановіть target utilization (50–70% для CPU).
- Налаштуйте behavior для scaleUp (швидко) та scaleDown (повільно).
- Вкажіть minReplicas >= 2.
- Протестуйте з навантажувальним тестуванням.
- Моніторте latency та помилки.
Чому CPU-based scaling не підходить для мобільного API?
CPU зростає із затримкою відносно запитів — це факт. Поки HPA виявить пік і додасть под, частина клієнтів вже бачить 503. Для мобільного API краще використовувати метрики p99 latency або request queue depth. У нашому кейсі з новинним додатком iOS ми вирішили це через KEDA з чергою SQS — масштабування починалося до приходу трафіку, і 503 зникли.
Cold start проблема для мобільного трафіку
Go та Node.js стартують за 1–3 секунди — прийнятно. JVM-додатки (Spring Boot) — 10–20 секунд. Lambda (serverless) — cold start 500ms–3 секунди залежно від runtime та розміру пакета.
Для JVM: тримати мінімум 2 поди завжди гарячими. GraalVM Native Image — старт 0.1–0.3 секунди, але потребує налаштування reflection конфігурації. Spring Boot 3 + GraalVM Native — робоча комбінація в production.
Для serverless (AWS Lambda, Google Cloud Functions): Provisioned Concurrency тримає N інстансів прогрітими. Дорожче, але cold start зникає для цих інстансів.
Кейс: новинний додаток iOS. Після публікації редакційного пуша — 40 000 одночасних відкриттів за 2 хвилини. Один под на 2 vCPU справлявся з 400 rps. HPA налаштований на CPU 60% — до моменту додавання пода пікове навантаження вже минуло. Рішення: KEDA з метрикою з CloudWatch (кількість повідомлень у SQS-черзі пушів) — при відправці пуша автоматично додавалося 8 подів ще до приходу трафіку. Нуль 503 при наступних трьох розсилках.
| Рішення | Час старту | Підходить для | Вартість |
|---|---|---|---|
| Стандартний JVM | 10–20 с | Stateful, великі сервіси | Базова |
| GraalVM Native | 0.1–0.3 с | Мікросервіси, serverless | Середня |
| Provisioned Concurrency | 0 (прогріті) | Критичні шляхи | Висока |
Що входить у налаштування під ключ
- Аудит поточної архітектури та навантажувального тестування.
- Налаштування HPA, VPA, Cluster Autoscaler або KEDA.
- Конфігурація custom metrics (Prometheus, CloudWatch, Datadog).
- Оптимізація cold start (GraalVM, Provisioned Concurrency).
- Документація зі схем масштабування.
- Моніторинг та алерти на основі SLO.
- Навчання вашої команди (1 сесія).
- Підтримка 2 тижні після здачі.
Замовте налаштування під ключ: терміни від 2 до 14 днів залежно від складності. Отримайте консультацію з масштабування — наші інженери сертифіковані AWS/GCP та мають 10+ років досвіду. Зв'яжіться з нами, щоб обговорити ваш сценарій — ми допоможемо підібрати оптимальну схему.
Офіційна документація Kubernetes по HPA
З правильною конфігурацією економія на хмарних ресурсах досягає 40%, а вартість експлуатації знижується на $500–2000 на місяць для середнього проєкту.