Создание и управление Auto Scaling Group (ASG) в AWS

Ключевые понятия

• ASG (Auto Scaling Group): логическая группа EC2‑инстансов для автоматического масштабирования и восстановления. Однострочное определение: автоматическая система поддержания и масштабирования набора инстансов по заданным правилам.
• Launch Configuration: шаблон запуска инстанса (AMI, тип инстанса, ключ, security group и т. д.).
• Scaling policy: правило масштабирования, основанное на метриках (например, среднее использование CPU).

Важно: Auto Scaling не стоит денег сам по себе — вы платите за EC2, другие ресурсы и мониторинг CloudWatch.

Содержание

1. Цель и краткий обзор процесса
2. Требования перед началом
3. Пошаговая инструкция
   • Вход в AWS
   • Создание Launch Configuration
   • Создание Auto Scaling Group
   • Тест 1: завершение инстанса и восстановление
   • Тест 2: увеличение нагрузки и масштабирование
   • Удаление ASG
4. Рекомендации безопасности и очистки ресурсов
5. Когда ASG может не сработать
6. Альтернативные подходы
7. Ментальные модели и факт‑бокс
8. SOP / Playbook — пошаговый чеклист
9. Роль‑ориентированные чеклисты
10. Критерии приёмки и тесты
11. План действий при инциденте и rollback
12. Шпаргалка команд и полезные сниппеты
13. Заключение

1. Цель и краткий обзор процесса

Цель — научиться создавать ASG, понять, как оно поддерживает желаемое количество инстансов и как автоматически масштабирует их при росте нагрузки. Показаны два реальных сценария проверки: ручное завершение инстанса и искусственное повышение CPU.

2. Требования перед началом

• Учётная запись AWS (создать при необходимости).
• Права IAM: возможность создавать/удалять EC2, security groups, key pairs и Auto Scaling группы.
• Базовые знания EC2 и подключения по SSH.

3. Пошаговая инструкция

Вход в AWS

1. Перейдите на страницу входа в AWS.

2. Введите учётные данные. После успешного входа откроется основная консоль со списком сервисов.

Создание Launch Configuration

1. В верхнем меню нажмите «Services» → «EC2» чтобы перейти в консоль EC2.

2. В навигационной панели слева под разделом «Auto Scaling» выберите «Launch Configurations».

3. Нажмите «Create launch configuration».

4. На странице выбора AMI выберите подходящий образ (например, Ubuntu Server 18.04 LTS для Free Tier).

5. Выберите тип инстанса (например, t2.micro для Free Tier) и нажмите “Next: Configure”.

6. Дайте имя Launch Configuration и нажмите “Next: Add storage”.

7. Укажите размер диска (storage) и нажмите «Next: Configure Security Group».

8. Создайте или выберите Security Group. В примере выбран новый security group с правилом SSH (0.0.0.0/0) для тестирования (в проде ограничьте доступ).

9. На странице Review нажмите «Create launch configuration».

10. Выберите существующую key pair или создайте новую, подтвердите и снова нажмите «Create launch configuration».

Создание Auto Scaling Group

1. После создания Launch Configuration нажмите «Create an Auto Scaling Group using this launch configuration».

2. Укажите имя группы и выберите подсети (subnets) в VPC для обеспечения высокой доступности.

3. На шаге конфигурации scaling policies выберите «use scaling policies to adjust the capacity of this group», укажите минимальное, желаемое и максимальное число инстансов. Тип метрики — “Average CPU utilization” и задайте target value (например, 40%).

4. Настройка уведомлений — опционально (SNS). Если нужно получать оповещения, укажите SNS topic.

5. Добавьте теги при необходимости (опционально) и нажмите Review.

6. На странице Review нажмите «Create Auto Scaling group».

7. Если при создании появится ошибка “Failed to create Auto Scaling group”, нажмите Retry — в примере это помогло.

8. Перейдите на страницу Auto Scaling и откройте Activity History, чтобы отслеживать события группы.

9. В разделе Instances можно посмотреть состояние инстансов и их количество.

Тест 1: Завершение инстанса и проверка восстановления

1. Выберите один из инстансов группы и выполните Actions → Instance State → Terminate. Подтвердите “Yes, Terminate”.

2. ASG был настроен на желаемое/минимальное количество 2. После завершения ASG подождёт период ожидания (например, 300 с), указанный в scaling policy, затем запустит новый инстанс для восстановления желаемого состояния.

3. Событие запуска нового инстанса будет видно в Activity history.

Тест 2: Увеличение нагрузки и масштабирование

1. Подключитесь по SSH к каждому инстансу группы (см. инструкцию по созданию и подключению к EC2).

2. Установите утилиту для создания нагрузки (пример для Ubuntu/Debian):

sudo apt-get update

sudo apt-get install stress

3. Запустите тест нагрузки: команда ниже загружает CPU на 50% в течение 400 секунд.

stress --cpu 50 --timeout 400

Примечание: поведение нагрузки зависит от числа потоков и ядер. Для точного достижения процента используйте профилирование или дополнительные инструменты.

4. ASG настроен с целевой средней загрузкой 40%. Когда средняя загрузка превысит этот порог и выдержит период оценки (например, 300 с), ASG запустит дополнительный инстанс.

5. В списке инстансов можно увидеть, как их количество увеличилось.

Удаление Auto Scaling Group

Удаление всех инстансов недостаточно: ASG будет пытаться вернуть желаемое состояние и воссоздаст инстансы. Чтобы полностью очистить ресурсы, удалите саму Auto Scaling Group.

1. Перейдите к созданной ASG → Actions → Delete → подтвердите “Yes, Delete”.

2. Удалите связанные ресурсы при необходимости: Launch Configuration, security groups, key pairs, и другие вспомогательные объекты.

4. Рекомендации по безопасности и очистке ресурсов

• Никогда не оставляйте правило SSH (0.0.0.0/0) в production. Ограничьте доступ по IP или используйте VPN/Bastion host.
• Удаляйте ASG и Launch Configuration после тестирования, чтобы избежать случайных расходов.
• Настройте lifecycle hooks и health checks для корректного завершения инстансов при обновлениях.

5. Когда ASG может не сработать (типы отказов и причины)

• Нехватка ресурсов в зоне: если в выбранных подсетях/зонах нет доступных физических ресурсов, запуск нового инстанса может провалиться.
• Ошибки AMI или Launch Configuration: некорректная AMI, скрипты userdata, или отсутствие сетевых настроек приведут к нездоровому инстансу.
• Неправильные health checks: если health check настроен слишком агрессивно, ASG может бесконечно перезапускать инстансы.
• Недостаточные IAM‑права: если роль или учётные данные не позволяют создавать EC2 или привязывать ресурсы, создание провалится.
• Ограничения квот (quotas): достигнут лимит EC2 для аккаунта.

6. Альтернативные подходы и когда их выбирать

• ECS / Fargate: выбирайте, если у вас контейнеризованные приложения и вы хотите управлять масштабированием на уровне сервисов.
• EKS / Kubernetes: для сложных сценариев оркестрации и автоскейлинга подов/нод.
• Lambda (serverless): для событийных/кратковременных задач, без управления инстансами.
• Spot instances + mixed instances policy: для уменьшения стоимости при допущении прерываний.

7. Ментальные модели и факт‑бокс

Ментальная модель: ASG — это «самовосстанавливающийся и реагирующий на нагрузку оркестр инстансов». Представляйте его как контроллер состояния: желаемое количество (desired) — это целевой уровень, а политика масштабирования служит реактивной частью.

Факт‑бокс (важные числа и понятия):

• Минимум / Желаемое / Максимум — ключевые параметры ASG.
• Health check grace period — время ожидания перед проверкой статуса (обычно в сотнях секунд).
• Target tracking — автоматическая стратегия по метрике (например, средний CPU).

8. Мини‑методология: как подойти к внедрению ASG на проекте

1. Оцените метрики нагрузки (CPU, RPS, latency).
2. Выберите разумный минимум при старте (надежный запас для отказоустойчивости).
3. Настройте Target Tracking с постепенным уменьшением чувствительности (evaluation periods).
4. Протестируйте: завершение инстанса и искусственная нагрузка.
5. Настройте оповещения и lifecycle hooks для graceful shutdown.
6. Проведите пост‑мортем после каждого инцидента масштабирования.

9. SOP / Playbook — пошаговый чеклист (короткая версия)

Перед созданием:

• Проверить IAM‑права.
• Подготовить AMI/скрипт userdata.
• Определить минимум/желаемое/максимум инстансов.
• Определить метрику и целевое значение.

При создании:

• Создать Launch Configuration (AMI, тип, key pair, SG).
• Создать ASG с выбранными подсетями.
• Настроить scaling policy (target tracking или step policy).
• Настроить SNS для уведомлений.

Проверка и тестирование:

• Завершить инстанс и убедиться в восстановлении.
• Запустить нагрузку и проверить масштабирование.
• Проверить логи и Activity History.

Очистка:

• Удалить ASG.
• Удалить Launch Configuration и ненужные ресурсы.

10. Роль‑ориентированные чеклисты

DevOps инженер:

• Убедиться в правильной настройке сети и подсетей.
• Настроить health checks и lifecycle hooks.
• Настроить мониторинг CloudWatch и оповещения.

Разработчик:

• Убедиться, что приложение корректно стартует и завершается.
• Логирование для быстрого выявления причин нездоровья.

Секьюрити инженер:

• Проверить security groups, IAM роли.
• Убедиться в закрытом доступе к SSH в production.

11. Критерии приёмки и тесты

Критерии приёмки:

• ASG поддерживает желаемое число инстансов в устойчивом режиме.
• При завершении инстанса ASG восстанавливает количество до desired в заданный SLA.
• При превышении порога метрики ASG масштабирует вверх в пределах max.
• События масштабирования документируются в Activity History и оповещаются.

Тестовые сценарии:

• Завершить инстанс и ожидать восстановления (проверить within grace period + provisioning).
• Искусственно поднять CPU и проверить увеличение инстансов.
• Ввести ошибочный AMI в Launch Configuration и проверить поведение здоровых/нездоровых инстансов.

12. План действий при инциденте и rollback

1. Если ASG запускает некорректные инстансы — остановить создание: уменьшить desired до 0 и pause scaling policies.
2. Вернуть предыдущий рабочий Launch Configuration или AMI.
3. Провести диагностику health check и userdata.
4. Восстановить desired в рабочее значение и мониторить.

13. Шпаргалка команд и конфигураций

Установка и тест нагрузки (Ubuntu/Debian):

sudo apt-get update
sudo apt-get install -y stress
stress --cpu 50 --timeout 400

Примеры полезных AWS CLI команд:

• Создать ASG (пример синтаксиса — адаптировать под свои значения):

aws autoscaling create-auto-scaling-group --auto-scaling-group-name MyASG --launch-configuration-name MyLaunchConfig --min-size 2 --max-size 5 --desired-capacity 2 --vpc-zone-identifier "subnet-xxxx,subnet-yyyy"

• Удалить ASG:

aws autoscaling delete-auto-scaling-group --auto-scaling-group-name MyASG --force-delete

• Просмотреть историю активности ASG:

aws autoscaling describe-scaling-activities --auto-scaling-group-name MyASG

14. Мермайд — рекомендованное дерево решений при выборе стратегии масштабирования

flowchart TD
  A[Нужен автоскейлинг?] -->|Нет| B[Оставить ручное управление]
  A -->|Да| C[Контейнеризовано?]
  C -->|Да| D[Использовать ECS/EKS/Fargate]
  C -->|Нет| E[Использовать EC2 ASG]
  E --> F{Требуется минимальная стоимость или стабильность}
  F -->|Стоимость| G[Добавить Spot + mixed instances]
  F -->|Стабильность| H[On‑Demand + устойчивые зоны]
  G --> I[Настроить биндинги, fallback на on‑demand]
  H --> I

15. Заключение

В этой статье вы узнали, как создать Launch Configuration и Auto Scaling Group в AWS, проверить её реакцию при удалении инстанса и при увеличении нагрузки, а также как корректно удалить ASG. ASG — надёжный инструмент для поддержания доступности и масштабирования, но требует правильной настройки health checks, метрик и безопасных правил доступа.

Ключевые рекомендации: тестируйте на отдельных средах, ограничивайте доступ по SSH, настраивайте оповещения и lifecycle hooks, и всегда очищайте ресурсы после экспериментов.

Дополнительные ресурсы и ссылки

• Официальная документация AWS Auto Scaling: посетите сайт AWS для актуальной информации и примеров.