Налаштування автоскейлінгу серверів веб-додатку

Відзначимо: коли ваш веб-сервіс раптово отримує пікове навантаження — наприклад, після успішної email-розсилки або рекламної кампанії, — сервери можуть лягти, а користувачі підуть до конкурентів. Ви додаєте потужності вручну, але це повільно та дорого. Автоскейлінг вирішує проблему, але його неправильне налаштування призводить до thrashing та перевитрати коштів. Ми, команда інженерів з багаторічним досвідом в інфраструктурі, допомогли більш ніж 50 проектам впровадити горизонтальне масштабування з економією до 30–40% на хмарних ресурсах. Ми гарантуємо, що ви будете платити лише за реально використані ресурси, а користувачі не помітять піків. Отримайте консультацію — ми оцінимо ваш проект та запропонуємо оптимальну архітектуру.

Чому простого скейлінгу за CPU недостатньо?

CPU-метрика запізнюється: сервер спочатку гальмує, потім скейлиться. Для типового веб-додатку комбінують CPU та кількість запитів на секунду (RPS). Це дає швидшу реакцію на сплески трафіку та запобігає простоям. Правильний вибір метрик — основа ефективного автоскейлінгу, і саме на цьому етапі багато хто припускається помилок, що ведуть до перевитрати або падіння продуктивності.

Як вибрати метрики для автоскейлінгу?

CPU-метрика запізнюється — сервер спочатку гальмує, потім скейлиться. RPS-метрика реагує швидше. Для типового веб-додатку комбінують CPU + Request Count.

Налаштування в хмарних платформах

AWS Auto Scaling Group

Найпоширеніший сценарій — EC2 ASG з Application Load Balancer. В одному конфігу об'єднуємо Launch Template, ASG та політики цільового відстеження:

# Terraform: Launch Template + ASG + Target Tracking Policies resource "aws_launch_template" "app" { name_prefix = "myapp-" image_id = data.aws_ami.ubuntu.id instance_type = "t3.medium" user_data = base64encode(<<-EOF #!/bin/bash cd /var/www/myapp git pull origin main systemctl restart php8.3-fpm systemctl reload nginx EOF ) network_interfaces { associate_public_ip_address = false security_groups = [aws_security_group.app.id] } iam_instance_profile { name = aws_iam_instance_profile.app.name } lifecycle { create_before_destroy = true } } resource "aws_autoscaling_group" "app" { name = "myapp-asg" vpc_zone_identifier = aws_subnet.private[*].id target_group_arns = [aws_lb_target_group.app.arn] health_check_type = "ELB" health_check_grace_period = 300 min_size = 2 max_size = 20 desired_capacity = 2 launch_template { id = aws_launch_template.app.id version = "$Latest" } instance_refresh { strategy = "Rolling" preferences { min_healthy_percentage = 50 } } tag { key = "Name" value = "myapp-app" propagate_at_launch = true } } # Target Tracking Policy: CPU resource "aws_autoscaling_policy" "cpu" { name = "myapp-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 = 65.0 scale_in_cooldown = 300 scale_out_cooldown = 60 } } # Target Tracking Policy: ALB Request Count per Target resource "aws_autoscaling_policy" "rps" { name = "myapp-rps-tracking" autoscaling_group_name = aws_autoscaling_group.app.name policy_type = "TargetTrackingScaling" target_tracking_configuration { predefined_metric_specification { predefined_metric_type = "ALBRequestCountPerTarget" resource_label = "${aws_lb.main.arn_suffix}/${aws_lb_target_group.app.arn_suffix}" } target_value = 1000.0 } } 

ECS Fargate Auto Scaling

Для контейнерних додатків ECS Fargate простіше — немає EC2, лише задачі. Налаштовуємо цільовий ресурс та політику за CPU та довжиною черги SQS:

resource "aws_appautoscaling_target" "ecs" { max_capacity = 50 min_capacity = 2 resource_id = "service/${aws_ecs_cluster.main.name}/${aws_ecs_service.app.name}" scalable_dimension = "ecs:service:DesiredCount" service_namespace = "ecs" } resource "aws_appautoscaling_policy" "ecs_cpu" { name = "myapp-ecs-cpu" policy_type = "TargetTrackingScaling" resource_id = aws_appautoscaling_target.ecs.resource_id scalable_dimension = aws_appautoscaling_target.ecs.scalable_dimension service_namespace = aws_appautoscaling_target.ecs.service_namespace target_tracking_scaling_policy_configuration { predefined_metric_specification { predefined_metric_type = "ECSServiceAverageCPUUtilization" } target_value = 60.0 scale_in_cooldown = 300 scale_out_cooldown = 30 } } # Scale by SQS queue depth (worker service) resource "aws_appautoscaling_policy" "ecs_sqs" { name = "myapp-worker-sqs" policy_type = "TargetTrackingScaling" resource_id = aws_appautoscaling_target.worker.resource_id scalable_dimension = aws_appautoscaling_target.worker.scalable_dimension service_namespace = aws_appautoscaling_target.worker.service_namespace target_tracking_scaling_policy_configuration { customized_metric_specification { metric_name = "ApproximateNumberOfMessagesNotVisible" namespace = "AWS/SQS" statistic = "Sum" dimensions { name = "QueueName" value = aws_sqs_queue.jobs.name } } target_value = 100.0 } } 

Kubernetes HPA та KEDA

Horizontal Pod Autoscaler працює з CPU та Memory з коробки. KEDA додає зовнішні метрики (SQS, RabbitMQ, Kafka).

Приклад HPA з CPU та Memory, стабілізацією та поведінкою:

# HPA по CPU + Memory apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: myapp-hpa namespace: myapp spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: myapp-web minReplicas: 2 maxReplicas: 50 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 65 - type: Resource resource: name: memory target: type: Utilization averageUtilization: 75 behavior: scaleUp: stabilizationWindowSeconds: 30 policies: - type: Pods value: 4 periodSeconds: 60 scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 25 periodSeconds: 60 

Детальніше читайте в офіційній документації HorizontalPodAutoscaler. KEDA ScaledObject для RabbitMQ:

# KEDA ScaledObject — RabbitMQ queue apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: myapp-worker-scaler namespace: myapp spec: scaleTargetRef: name: myapp-worker minReplicaCount: 1 maxReplicaCount: 30 pollingInterval: 10 cooldownPeriod: 60 triggers: - type: rabbitmq metadata: host: amqp://rabbitmq.myapp.svc.cluster.local queueName: email-queue mode: QueueLength value: "50" 

Graceful Shutdown

При scale-in інстанс отримує сигнал завершення. Додаток повинен встигнути обробити поточні запити. Приклад для Node.js Express:

// Node.js Express const server = app.listen(3000); process.on('SIGTERM', () => { console.log('SIGTERM received, shutting down gracefully'); server.close(() => { console.log('HTTP server closed'); process.exit(0); }); setTimeout(() => { console.error('Forced shutdown'); process.exit(1); }, 30000); }); 

Додатково налаштовуємо lifecycle hook в AWS для виконання команд перед завершенням інстанса. Детальніше — в документації AWS по Lifecycle Hooks.

Типові проблеми та їх вирішення

При впровадженні автоскейлінгу команди часто стикаються з thrashing — частим додаванням та видаленням інстансів через занадто короткі cooldown. Рішення — збільшити scale_in_cooldown до 300–600 секунд та використовувати stabilizationWindowSeconds в HPA. Інша проблема — повільний старт додатку: новий інстанс створено, але трафік іде до його готовності. Допомагають health check grace period, readiness probe та Warm Pool. Також дорогий scale-in виникає, якщо видаляється інстанс з незавершеними фоновими завданнями. Тут виручає lifecycle hook з drain черги перед CONTINUE. І нарешті, неправильна метрика — наприклад, CPU 20%, але додаток гальмує через I/O wait. У таких випадках використовуйте custom метрики, наприклад p95 latency через CloudWatch або Prometheus.

Покрокове налаштування автоскейлінгу в AWS

1. Створіть Launch Template з AMI, типом інстанса та user-data для розгортання додатку.
2. Налаштуйте Auto Scaling Group: вкажіть VPC, subnet, target group для ALB, задайте min, max, desired.
3. Додайте політики Target Tracking по CPU та RPS, встановіть cooldown.
4. Налаштуйте health checks: ELB health check, grace period.
5. Увімкніть Instance Refresh для rolling-оновлень.
6. Перевірте graceful shutdown: lifecycle hook + drain.

Обсяг робіт з налаштування автоскейлінгу

• Аналіз поточної архітектури та профілю навантаження.
• Проектування політик масштабування (CPU, RPS, черга).
• Налаштування AWS Auto Scaling Group, ECS Service Auto Scaling або Kubernetes HPA/KEDA.
• Конфігурація health checks та graceful shutdown.
• Налаштування моніторингу (CloudWatch, Grafana) та алертів.
• Документація з архітектури та інструкції для команди.
• Навчання команди (1–2 сесії).
• Підтримка протягом 30 днів після впровадження.

Орієнтовні терміни

Ми маємо сертифікати AWS та Kubernetes, багаторічний досвід на ринку та більше 50 реалізованих проектів. Зв'яжіться з нами, щоб обговорити ваш проект. Ми підготуємо комерційну пропозицію з точними термінами та вартістю.