Відзначимо: коли ваш веб-сервіс раптово отримує пікове навантаження — наприклад, після успішної email-розсилки або рекламної кампанії, — сервери можуть лягти, а користувачі підуть до конкурентів. Ви додаєте потужності вручну, але це повільно та дорого. Автоскейлінг вирішує проблему, але його неправильне налаштування призводить до thrashing та перевитрати коштів. Ми, команда інженерів з багаторічним досвідом в інфраструктурі, допомогли більш ніж 50 проектам впровадити горизонтальне масштабування з економією до 30–40% на хмарних ресурсах. Ми гарантуємо, що ви будете платити лише за реально використані ресурси, а користувачі не помітять піків. Отримайте консультацію — ми оцінимо ваш проект та запропонуємо оптимальну архітектуру.
Чому простого скейлінгу за CPU недостатньо?
CPU-метрика запізнюється: сервер спочатку гальмує, потім скейлиться. Для типового веб-додатку комбінують CPU та кількість запитів на секунду (RPS). Це дає швидшу реакцію на сплески трафіку та запобігає простоям. Правильний вибір метрик — основа ефективного автоскейлінгу, і саме на цьому етапі багато хто припускається помилок, що ведуть до перевитрати або падіння продуктивності.
Як вибрати метрики для автоскейлінгу?
| Метрика | Коли використовувати | Поріг |
|---|---|---|
| CPU Utilization | CPU-intensive додатки | 60–70% |
| Request Count (RPS) | Stateless HTTP-сервіси | за бізнес-тестом |
| Memory Utilization | Memory-intensive | 70–80% |
| Queue Depth (SQS/RabbitMQ) | Worker-процеси | 100–500 повідомлень |
| Custom metric (p95 latency) | Latency-sensitive API | 200–500 мс |
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
- Створіть Launch Template з AMI, типом інстанса та user-data для розгортання додатку.
- Налаштуйте Auto Scaling Group: вкажіть VPC, subnet, target group для ALB, задайте min, max, desired.
- Додайте політики Target Tracking по CPU та RPS, встановіть cooldown.
- Налаштуйте health checks: ELB health check, grace period.
- Увімкніть Instance Refresh для rolling-оновлень.
- Перевірте 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 днів після впровадження.
Чек-лист для підготовки до автоскейлінгу
- Визначте ключові метрики (CPU, RPS, черга).
- Переконайтеся, що додаток stateless або вміє graceful shutdown.
- Налаштуйте health checks та readiness probes.
- Встановіть мінімальну та максимальну кількість екземплярів.
- Протестуйте на навантажувальному стенді.
- Впровадьте моніторинг та алерти.
Орієнтовні терміни
| Конфігурація | Термін |
|---|---|
| EC2 ASG + ALB + CPU scaling | 2–3 дні |
| ECS Fargate + target tracking | 1–2 дні |
| Kubernetes HPA | 1 день |
| KEDA + зовнішні метрики | 2–3 дні |
| Scheduled scaling + Warm Pool | +1–2 дні |
Ми маємо сертифікати AWS та Kubernetes, багаторічний досвід на ринку та більше 50 реалізованих проектів. Зв'яжіться з нами, щоб обговорити ваш проект. Ми підготуємо комерційну пропозицію з точними термінами та вартістю.