Настройка автоскейлинга серверов мобильного приложения
Мы знаем, как выглядит 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 в месяц для среднего проекта.