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

Коли навантаження на сервіс стрибає — від нічного затишшя до пікових сплесків, ручне керування ресурсами призводить до простоїв або переплат. Ми налаштовуємо автоматичне масштабування, яке адаптує інфраструктуру під реальні потреби в реальному часі. Наша команда реалізує проєкт під ключ — від аудиту та налаштування до навантажувального тестування та подальшої підтримки, забезпечуючи стабільну роботу без зриву термінів.

Розробка та обслуговування будь-яких видів сайтів:

Інформаційні сайти або веб-програми
Сайти візитки, landing page, корпоративні сайти, онлайн каталоги, квіз, промо-сайти, блоги, ресурси новин, інформаційні портали, форуми, агрегатори
Сайти або веб-програми електронної комерції
Інтернет-магазини, B2B-портали, маркетплейси, онлайн-обмінники, кешбек-сайти, біржі, дропшиппінг-платформи, парсери товарів
Веб-програми для управління бізнес-процесами
CRM-системи, ERP-системи, корпоративні портали, системи управління виробництвом, парсери інформації
Сайти або веб-програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, конструктори сайтів, портали надання електронних послуг, відеохостинги, тематичні портали

Це лише деякі з технічних типів сайтів, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
Автоматичне масштабування ресурсів за навантаженням
Складний
~3-5 днів
Часті запитання

Уявіть: ваш інтернет-магазин у п'ятницю ввечері під навантаженням — 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"
      }
    }
  }
}

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

Метод Метрики Швидкість реакції Складність
AWS ASG + Target Tracking CPU, Network, Request Count 1-2 хвилини Низька
Kubernetes HPA CPU, Memory, Custom 30-60 секунд Середня
KEDA Queue Length, External 10-30 секунд Середня
Predictive Scaling Історичні тренди Завчасно Висока

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

Метрика — ключ до ефективного масштабування. 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 сесія)

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

Компонент Строк
ASG + Target Tracking (AWS) 2-3 дні
HPA + Prometheus Adapter (K8s) 3-5 днів
KEDA для queue-based workloads 2-3 дні
Predictive Scaling 1-2 дні (після 14 днів даних)
Навантажувальне тестування + тюнінг 2-3 дні

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

Типові помилки (натисніть, щоб розгорнути)
  • Неправильні cooldown (flapping)
  • Масштабування тільки по CPU (ігноруємо memory/network)
  • Відсутність health check при scale-in (обрив активних сесій)
  • Занадто широкий діапазон min/max (ризик нескінченного масштабування)

Наш досвід

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

Наші компетенції:

Останні роботи

  • Розробка сайту компанії B2B ADVANCE
    Розробка сайту компанії B2B ADVANCE
    1542
  • Розробка веб-додатків для компанії FEEDME
    Розробка веб-додатків для компанії FEEDME
    1394
  • Розробка веб-сайту для компанії БЕЛФІНГРУП
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    1081
  • Розробка інтернет магазину для компанії FURNORO
    Розробка інтернет магазину для компанії FURNORO
    1369
  • Розробка веб-додатків для компанії Enviok
    Розробка веб-додатків для компанії Enviok
    1142
  • Розробка веб-сайту для компанії ФІКСПЕР
    Розробка веб-сайту для компанії ФІКСПЕР
    1060