Автоматичне масштабування ресурсів за навантаженням

Уявіть: ваш інтернет-магазин у п'ятницю ввечері під навантаженням — CPU на 90%, latency зростає, а ви не встигаєте додати сервери вручну. Або навпаки: у будній день сервери простоюють, а ви платите за 80% невикористовуваної потужності. Автомасштабування вирішує обидві проблеми. Ми налаштували autoscaling для 20+ проєктів — від стартапів до enterprise. Нижче — реальний код, конфіги та типові помилки.

Проблеми, які вирішуємо

Переплата за ресурси у спокійний час

Середнє завантаження CPU веб-серверів — 15-20%. Тримати capacity під пік — платити за 80% невикористовуваної потужності. Autoscaling утримує мінімум інстансів і додає нові при зростанні. Наприклад, e-commerce сайт з піковим навантаженням 20k RPS тримає 10 серверів, хоча середнє навантаження 2k RPS. Autoscaling дозволяє тримати 2 сервери і додавати по мірі зростання. Економія на інфраструктурі становить 30-40% від бюджету. Для одного з клієнтів (e-commerce з піковим навантаженням 20k RPS) впровадження скоротило щомісячні витрати на $4500.

Падіння при різких сплесках

DDoS або вірусний пост — навантаження зростає в 10 разів за хвилини. Без масштабування сайт падає. Наше рішення реагує за секунди, використовуючи Target Tracking і scale-out cooldown 60s.

Складність ручного керування

Навіть досвідчений адмін не встигає вручну додавати сервери. Автоматизація виключає людський фактор.

Як ми це робимо: стек і кейс

AWS Auto Scaling Group з Target Tracking

Використовуємо Terraform для опису інфраструктури як коду. Приклад конфігурації:

resource "aws_autoscaling_group" "app" { name = "app-asg" min_size = 2 max_size = 20 desired_capacity = 3 vpc_zone_identifier = var.private_subnet_ids launch_template { id = aws_launch_template.app.id version = "$Latest" } health_check_type = "ELB" health_check_grace_period = 60 target_group_arns = [aws_lb_target_group.app.arn] } # Target Tracking: тримати CPU на 60% resource "aws_autoscaling_policy" "cpu_tracking" { name = "cpu-tracking" autoscaling_group_name = aws_autoscaling_group.app.name policy_type = "TargetTrackingScaling" target_tracking_configuration { predefined_metric_specification { predefined_metric_type = "ASGAverageCPUUtilization" } target_value = 60.0 scale_in_cooldown = 300 scale_out_cooldown = 60 } } 

Scale-out cooldown (60s) менший за scale-in (300s) — швидко реагуємо на зростання, повільно прибираємо ресурси.

Kubernetes HPA з кастомними метриками

Horizontal Pod Autoscaler у поєднанні з Prometheus Adapter дозволяє масштабувати за кастомними метриками:

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: app-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: app minReplicas: 2 maxReplicas: 50 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60 - type: Pods pods: metric: name: http_requests_per_second target: type: AverageValue averageValue: "100" 

Метрика http_requests_per_second надходить з Prometheus через kube-state-metrics та Prometheus Adapter.

KEDA: масштабування за зовнішніми джерелами

KEDA (Kubernetes Event-Driven Autoscaling) масштабує поди за довжиною черги RabbitMQ, Kafka, SQS:

apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: queue-processor spec: scaleTargetRef: name: worker-deployment minReplicaCount: 1 maxReplicaCount: 30 triggers: - type: rabbitmq metadata: host: amqp://rabbitmq:5672/ queueName: tasks queueLength: "50" 

Масштабування до нуля при порожній черзі — економить ресурси.

Predictive Scaling

AWS Predictive Scaling передбачає навантаження на основі історичних даних (мінімум 14 днів) і завчасно додає ресурси:

resource "aws_autoscaling_policy" "predictive" { name = "predictive" autoscaling_group_name = aws_autoscaling_group.app.name policy_type = "PredictiveScaling" predictive_scaling_configuration { mode = "ForecastAndScale" scheduling_buffer_time = 300 max_capacity_breach_behavior = "IncreaseMaxCapacity" metric_specification { target_value = 60 predefined_scaling_metric_specification { predefined_metric_type = "ASGAverageCPUUtilization" } predefined_load_metric_specification { predefined_metric_type = "ASGTotalNetworkIn" } } } } 

Порівняння методів масштабування

Як обрати правильну метрику?

Метрика — ключ до ефективного масштабування. CPU запізнюється, Request Rate потребує baseline, P95 — найточніший, але складний. На практиці використовуємо комбінацію CPU + Request Rate. Для async-обробників — Queue Depth. Згідно з Amazon EC2 Auto Scaling підтримує кілька метрик в одній політиці. Вартість утримання інфраструктури знижується на 35% при правильно підібраних метриках.

Що робити, якщо масштабування не спрацьовує вчасно?

Перевірте cooldown (scale-out швидше за scale-in), health check grace period. Іноді метрика не встигає оновитися. Рекомендуємо навантажувальний тест з k6: k6 run --vus 1000 --duration 10m script.js.

Процес роботи

1. Аналітика: вивчаємо профіль навантаження, історичні дані, обираємо метрики.
2. Проєктування: визначаємо тип масштабування, інструменти (AWS ASG, K8s HPA, KEDA).
3. Реалізація: пишемо IaC (Terraform/Pulumi), налаштовуємо моніторинг (CloudWatch, Prometheus).
4. Тестування: навантажувальне тестування, перевірка часу відгуку та downtime.
5. Деплой: впровадження в продакшен, алерти (SNS, PagerDuty).
6. Підтримка: моніторинг ефективності, коригування порогів.

Що входить в роботу

• Архітектурна документація
• Код інфраструктури (Terraform/Helm)
• Моніторинг та алерти
• Навантажувальний тест-кейс
• Навчання команди (1 сесія)

Строки реалізації

Вартість розраховується індивідуально після аудиту навантаження. Для розрахунку точної вартості та строків зв'яжіться з нами.

Наш досвід

Більше 5 років займаємося інфраструктурою високого навантаження. Реалізували autoscaling для 20+ проєктів — від стартапів до enterprise (e-commerce, fintech). Використовуємо перевірені рішення з гарантією SLA. Хочете налаштувати autoscaling? Отримайте консультацію — оцінимо ваш проєкт і запропонуємо оптимальне рішення.