Что такое auto-scaling

Auto-scaling — это механизм автоматического изменения вычислительных ресурсов (числа экземпляров, контейнеров или их размеров) в зависимости от нагрузки или заранее заданного расписания. Цель — обеспечить требуемую производительность и доступность при минимальных затратах.

Виды масштабирования

• Горизонтальное (scale-out / scale-in) — добавление/удаление экземпляров или подов.

• Вертикальное (scale-up / scale-down) — увеличение/уменьшение ресурсов одного экземпляра (CPU/RAM). Вертикальное чаще ручное или управляется VPA в Kubernetes.

• Предсказуемое (scheduled) — по расписанию (на выходные/ночь).

• Событийное — на события (очередь сообщений, длина очереди).

Компоненты системы авто-скейлинга

• Шаблон образа/launch template (AMI/instance template, контейнерный образ).

• Группа авто-масштабирования (ASG, VMSS, managed instance group) с min/max/desired capacity.

• Триггеры/политики: метрики (CPU, latency), кастомные метрики, целевые политики (target tracking), step policies, scheduled actions.

• Балансировщик нагрузки + health checks.

• Метрики и мониторинг (metrics server, CloudWatch/Stackdriver/Azure Monitor).

• Жизненный цикл (lifecycle hooks) для корректной инициализации/завершения.

Как настроить (шаги, универсально)

1. Проектирование: определите SLA, целевые метрики (например, CPU 50% или 1000 RPS на инстанс), min/max нужных инстансов, время отклика на масштабирование (RTO).

2. Подготовка образа/шаблона: сделайте образ/контейнер с быстрым стартом, автоматической регистрацией в сервисе/балансировщике.

3. Создание группы авто-масштабирования: укажите шаблон, VPC/subnet, балансировщик, min/desired/max.

4. Настройка health checks: балансировщик проверяет инстансы; при провале инстанс заменяется. Учитывайте warm-up.

5. Определение политик масштабирования:

   • Target tracking: платформа автоматически держит метрику (например, CPU target = 50%).

   • Step scaling: при достижении порога добавлять N инстансов.

   • Scheduled: на вечер уменьшать до X.

6. Настройка cooldown/warm-up и scale-in protection: задайте окно, чтобы избежать «качаний» (thrashing) и защитить важные инстансы от немедленного удаления.

7. Тестирование: нагрузочное тестирование, проверка scale-out и scale-in, наблюдение за временем запуска и health checks.

8. Наблюдение и оптимизация: метрики, алерты по затратам, rightsizing шаблонов, использование spot/preemptible для некритичных задач.

Пример: Kubernetes HPA (короткий YAML)

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: web-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web
minReplicas: 2
maxReplicas: 20
metrics:
\- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50

Нужен metrics-server; можно использовать кастомные метрики (Prometheus Adapter) или KEDA для событийного скейлинга (очереди).

Практические советы и подводные камни

• Учитывайте cold starts/warm-up: медленные образы → медленное масштабирование → пропуск пиков.

• Избегайте слишком агрессивных порогов и маленьких cooldown → «качание».

• Для stateful-сервисов применяйте осторожность: корректное завершение, drain connections.

• Combine scheduled + reactive policies: заранее увеличивать capacity перед ожидаемыми пиками.

• Экономика: для стабильной нагрузки резервируйте/коммитите ресурсы; для переменной используйте target tracking + spot для дешёвых слотов.

• Включайте lifecycle hooks для выполнения конфигурации перед доступностью инстанса (например, загрузка конфигурации, миграции, pre-warm кеша).

Как тестировать

• Имитируйте нагрузку (load test) и смотрите реакцию: время добавления инстанса, время до стабильного состояния, error rates.

• Проверьте поведение при уменьшении: корректное завершение запросов, drain и сохранение состояния.

• Мониторьте метрики затрат и latency во время тестов.