Налаштування автомасштабування серверів мобільного додатку
Мобільний трафік непередбачуваний. Розсилка сповіщень на 500 000 пристроїв, виділення в App Store або згадка в телеграм-каналі з 300k підписниками — і сервер, який щойно обробляв 200 rps, отримує 3000 rps за 30 секунд. Без автомасштабування отримуєте 503 помилки та погані рецензії в магазині.
Типи автомасштабування і коли їх використовувати
Horizontal Pod Autoscaler (HPA) у Kubernetes—додає поди при зростанні навантаження, видаляє при спаді. Базова метрика — використання CPU, але для мобільних API краще: latency p99, глибина черги запитів або власні метрики Prometheus.
Vertical Pod Autoscaler (VPA)—коригує requests/limits пода. Корисно для JVM сервісів, де пам'ять зростає під час прогріву heap. Однак VPA потребує перезапуску пода при змінах ресурсів — непридатна для stateful сервісів.
Cluster Autoscaler—додає або видаляє вузли Kubernetes у хмарі (AWS EC2, GCP GKE, Azure AKS). Працює разом з HPA: HPA хоче 5 подів, але місця немає — Cluster Autoscaler провизіонує вузол.
KEDA (Kubernetes Event-Driven Autoscaling)—масштабування за зовнішніми метриками: довжина черги RabbitMQ, Kafka lag, кількість повідомлень у Redis Streams. Для мобільного додатку з чергою push-сповіщень: воркери масштабуються за кількістю завдань, не за CPU.
Конфігурація HPA для мобільних API
Проблема стандартного CPU-масштабування: під час піків запитів CPU зростає, HPA вирішує додати під (15–30 секунд), під стартує (ще 10–30 секунд), проходить readiness probe. Загалом: 30–60 секунд до обробки трафіку. За цей час деякі мобільні клієнти отримують 503.
Рішення:
- Передбачувальне масштабування—масштабуйтеся заздалегідь перед очікуваними піками (розсилка сповіщень → відразу масштабуйте)
-
Масштабуйтеся швидше, зменшуйтеся повільніше—
scaleUp.stabilizationWindowSeconds: 0(миттєве масштабування вгору),scaleDown.stabilizationWindowSeconds: 300(чекайте 5 хвилин перед зменшенням) - Minreplicas: 2—ніколи не спускайтеся нижче 2 подів, щоб rolling update не вносив простої
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
Проблеми холодного старту з мобільним трафіком
Go і Node.js стартують за 1–3 секунди — прийнятно. JVM додатки (Spring Boot) — 10–20 секунд. Lambda (serverless) — холодний старт 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 екземплярів прогрітими. Дорожче, але холодний старт зникає для цих екземплярів.
Реальний приклад: новинний iOS додаток. Після публікації редакційної розсилки — 40 000 одночасних відкриттів за 2 хвилини. Один під на 2 vCPU обробляв 400 rps. HPA налаштований на CPU 60% означав додавання пода після піку. Рішення: KEDA з метриками CloudWatch (кількість повідомлень у SQS черзі сповіщень)—при відправленні розсилки автоматично додавалось 8 подів ще перед приходом трафіку. Нуль 503 помилок у наступних трьох розсилках.
Час реалізації: конфігурація HPA + Cluster Autoscaler для одного сервісу — 2–4 дні. KEDA з власними метриками + передбачувальне масштабування — 1–2 тижні.