Налаштування Auto Scaling Groups в AWS
Ми налаштовуємо групи автоматичного масштабування (ASG) в AWS, щоб ваше застосування витримувало пікові навантаження без простоїв та переплат. Помилки в конфігурації — десятки тисяч доларів на місяць або години даунтайму. Правильне налаштування ASG з використанням predictive scaling та Mixed Instance Policy знижує витрати на 60–70%. Наш досвід — понад 50 успішних проєктів з масштабування, сертифіковані інженери та гарантія результату. Зв'яжіться з нами для оцінки вашої інфраструктури.
Типова історія: ASG налаштована з policy по CPU. Навантаження зростає — CPU піднімається до 70%, ASG запускає новий інстанс. Інстанс запускається 5 хвилин, проходить health check ще 3 хвилини — разом 8 хвилин до того, як новий інстанс починає приймати трафік. За ці 8 хвилин CPU на існуючих інстансах вже давно перевалив за 90%, і користувачі бачать таймаути.
Рішення — в predictive scaling та правильній warmup конфігурації. Але про все по порядку.
Launch Templates замість Launch Configurations
Launch Configurations — legacy. Вже кілька років AWS офіційно рекомендує Launch Templates для всього нового. Launch Templates підтримують versioning (можна відкотитися до попередньої конфігурації інстанса), mixed instance policies (комбінування різних типів в одній ASG), T-instance unlimited mode та інші нові фічі.
Приклад Launch Template через Terraform
resource "aws_launch_template" "app" {
name_prefix = "myapp-"
image_id = data.aws_ami.app.id
instance_type = "t3.medium"
iam_instance_profile {
name = aws_iam_instance_profile.app.name
}
user_data = base64encode(templatefile("${path.module}/userdata.sh", {
environment = var.environment
}))
tag_specifications {
resource_type = "instance"
tags = {
Name = "myapp-${var.environment}"
}
}
lifecycle {
create_before_destroy = true
}
}Які політики масштабування обрати?
Target Tracking — найпростіший і рекомендований. Вказуємо цільове значення метрики, ASG сам рахує, скільки інстансів потрібно. Для CPU target 50% — ASG тримає середнє CPU близько 50%, автоматично додаючи або прибираючи інстанси.
resource "aws_autoscaling_policy" "cpu_target" {
name = "cpu-target-tracking"
autoscaling_group_name = aws_autoscaling_group.app.name
policy_type = "TargetTrackingScaling"
target_tracking_configuration {
predefined_metric_specification {
predefined_metric_type = "ASGAverageCPUUtilization"
}
target_value = 50.0
}
}Step Scaling — для більш точного контролю. Різні кроки масштабування залежно від величини перевищення порогу. CPU 60–75% → додати 1 інстанс, CPU 75–90% → додати 3 інстанси, CPU >90% → додати 5 інстансів.
Scheduled Scaling — за розкладом, для передбачуваних піків. Комбінуючи ці підходи, можна досягти оптимальної реакції на навантаження.
| Тип політики | Коли використовувати | Переваги |
|---|---|---|
| Target Tracking | Типові web-навантаження | Простота, автоматична корекція |
| Step Scaling | Нерівномірні піки з критичністю | Гнучкість, точне управління |
| Scheduled Scaling | Передбачувані події (робочий час, акції) | Ресурси готові до початку піку |
Як налаштувати health check grace period?
ASG перевіряє здоров'я інстансів через EC2 status checks або через ALB health checks. ALB health checks — найкращий варіант для веб-сервісів: перевіряють реальну віддачу застосунку, а не просто доступність гіпервізора.
health_check_grace_period — час, який ASG дає новому інстансу на ініціалізацію, перш ніж почне перевіряти health checks. Якщо grace period занадто малий — інстанс буде визнаний нездоровим до того, як застосунок стартував, і ASG його вб'є. Якщо занадто великий — реально зламаний інстанс довго залишається в ротації.
Для застосунків з довгим cold start (Spring Boot, JVM) — grace period 300–600 секунд. Для легких Go/Node сервісів — 60–120 секунд.
Lifecycle Hooks для деплоїв
Lifecycle Hooks — механізм виконання дій при запуску або завершенні інстансу, з паузою процесу ASG до завершення хука. Згідно з документацією AWS, AWS Lifecycle Hooks дозволяють:
-
autoscaling:EC2_INSTANCE_LAUNCHING: дочекатися повної ініціалізації застосунку, зареєструвати інстанс в consul/etcd, завантажити конфігурацію з S3. -
autoscaling:EC2_INSTANCE_TERMINATING: дочекатися завершення поточних запитів, дереєстрація з service discovery, відправка метрик останнього стану.
Без terminating хука — при scale-in ALB отримує сигнал прибрати інстанс з rotation, але сам інстанс вже вбивається ASG через 30 секунд. Активні з'єднання обриваються. З хуком — інстанс спочатку drain connections (до 5 хвилин), потім сигналить хуку про завершення.
Як заощадити з Mixed Instance Policy?
Для зниження вартості — Mixed Instance Policy: частина capacity на On-Demand (base), решта на Spot. Spot інстанси до 10 разів дешевші за On-Demand при правильному виборі стратегії. Наприклад, заміна 10 інстансів t3.medium (On-Demand ~$0.0416/год) на Spot заощаджує близько $2500 на місяць.
mixed_instances_policy {
instances_distribution {
on_demand_base_capacity = 1
on_demand_percentage_above_base_capacity = 20
spot_allocation_strategy = "price-capacity-optimized"
}
launch_template {
launch_template_specification {
launch_template_id = aws_launch_template.app.id
version = "$Latest"
}
override {
instance_type = "t3.medium"
}
override {
instance_type = "t3a.medium"
}
override {
instance_type = "t2.medium"
}
}
}Стратегія price-capacity-optimized — Spot інстанси з пулів з найбільшою доступністю та мінімальною ціною. Знижує ймовірність переривання. Правильне поєднання On-Demand та Spot може скоротити витрати на 60-70% порівняно з повним On-Demand. Крім того, predictive scaling дозволяє реагувати на навантаження вдвічі швидше за звичайне target tracking.
| Характеристика | On-Demand | Spot (Mixed Instance Policy) |
|---|---|---|
| Ціна | 100% | до 10% від On-Demand |
| Гарантія доступності | 99.99% | до 99.5% (залежить від типу) |
| Переривання | ні | можливо (при високому попиті) |
| Використання | критичні сервіси | відмовостійкі, batch, stateless |
Як налаштувати Auto Scaling Group? Покрокова інструкція
- Створіть Launch Template з вказанням AMI, типу інстанса, user data та тегів.
- Створіть Auto Scaling Group, обравши Launch Template та вказавши VPC і підмережі.
- Налаштуйте політику масштабування: Target Tracking для CPU або Request Count.
- Підключіть ALB та налаштуйте health check grace period (300–600 с для важких застосунків).
- Додайте Lifecycle Hooks для graceful shutdown (EC2_INSTANCE_TERMINATING).
- Налаштуйте Mixed Instance Policy для економії.
- Протестуйте масштабування за допомогою навантажувального тестування.
Що входить в роботу
- Аудит поточної конфігурації ASG та рекомендації
- Проектування Launch Templates з урахуванням security та user data
- Налаштування однієї або кількох політик масштабування (target tracking, step, scheduled)
- Інтеграція з ALB та налаштування health checks
- Реалізація Lifecycle Hooks для graceful shutdown
- Mixed Instance Policy для оптимізації вартості
- Моніторинг (CloudWatch, Prometheus) та алерти
- Документація та навчання вашої команди
- Гарантія на налаштування — 1 місяць
Терміни та вартість
Базова конфігурація ASG з target tracking policy та ALB інтеграцією — від $500. Повна конфігурація з lifecycle hooks, mixed instances, scheduled scaling та моніторингом — $1500–$3000. Вартість розраховується індивідуально після аналізу вашої інфраструктури.
Замовте аудит поточної конфігурації ASG — заощадьте до 70% на хмарних витратах. Отримайте консультацію інженера AWS з 7+ років досвіду. Ми гарантуємо, що ваше масштабування буде надійним, економічним та керованим.
