Шаблоны запуска и настройка ASG

Шаблон запуска — это версионируемая схема, которая указывает группам Auto Scaling (и EC2 напрямую), как запускать экземпляры. В одном повторно используемом документе он содержит идентификатор AMI, тип экземпляра, пару ключей, группы безопасности и необязательные данные пользователя. В отличие от старой конфигурации запуска, шаблон запуска поддерживает несколько версий и может обновляться без замены ASG.

Вы можете создать шаблон запуска с помощью AWS CLI, используя create-launch-template. Параметр --launch-template-data принимает объект JSON, определяющий все настройки экземпляра. Версионирование позволяет дорабатывать шаблон, не затрагивая работающие экземпляры, пока Вы не будете готовы развернуть изменения.

Каждый шаблон запуска начинается с версии 1. При создании новой версии можно переопределить только изменившиеся поля — все остальные настройки наследуются из исходной версии. Для ASG можно указать использование версии $Latest (всегда самой новой) или версии $Default (явно назначенной версией по умолчанию). Использование $Default обеспечивает контролируемое развертывание, а $Latest удобно в средах разработки.

Группа Auto Scaling (ASG) поддерживает набор экземпляров EC2 в заданных пределах: минимальной ёмкости (нижней границы), максимальной ёмкости (верхней границы) и желаемой ёмкости (целевого количества в каждый момент времени). Когда экземпляры не проходят проверки работоспособности или срабатывает политика масштабирования, ASG автоматически запускает или завершает работу экземпляров, чтобы поддерживать нужное количество в пределах от минимального до максимального.

При создании ASG Вы указываете шаблон запуска (а не конкретный AMI напрямую). Также необходимо указать подсети VPC, в которых будут запускаться экземпляры. Размещение экземпляров в нескольких подсетях (по одной в каждой AZ) обеспечивает встроенную отказоустойчивость между AZ: если одна AZ выйдет из строя, ASG автоматически запустит экземпляры взамен неё в оставшихся AZ.

По умолчанию ASG использует проверки работоспособности EC2: экземпляр помечается как неисправный только в том случае, если он остановлен, завершён или гипервизор сообщает о его сбое. При подключении балансировщика нагрузки следует переключиться на проверки работоспособности ELB, чтобы ASG заменяла экземпляры, которые работают, но возвращают ошибки HTTP 5xx. Это распространённый вопрос на экзамене: если в архитектуре есть балансировщик нагрузки, всегда выбирайте проверки работоспособности ELB.

Правильная настройка границ ёмкости имеет решающее значение. Минимальная ёмкость гарантирует, что приложение всегда сможет обслуживать трафик (ниже этого значения группа не опускается). Максимальная ёмкость предотвращает неконтролируемое масштабирование, которое может исчерпать лимиты сервисов или бюджет. Желаемая ёмкость — это исходная цель; политики масштабирования изменяют её динамически. Если задать одинаковые значения min=max=desired, ASG будет работать как группа фиксированного размера, что удобно для развёртываний с использованием шаблона запуска или для закреплённой ёмкости.

Для приложений веб-уровня подключите ASG к целевой группе Application Load Balancer. Каждый новый экземпляр, запущенный ASG, автоматически регистрируется в целевой группе, а завершённые экземпляры автоматически удаляются из неё. Это гарантирует, что трафик направляется только к работоспособным запущенным экземплярам. Также необходимо задать тип проверки работоспособности ELB, чтобы ASG учитывала сбои на уровне балансировщика нагрузки.

Пользовательские данные — это сценарий оболочки (закодированный в Base64), который выполняется один раз при первом запуске экземпляра. В шаблоне запуска это подходящее место для установки пакетов, настройки агентов (CloudWatch, SSM) и получения кода приложения. Пользовательские данные должны быть идемпотентными: сценарии, которые можно безопасно запускать несколько раз, предотвращают проблемы при обновлении экземпляров. Для сложных конфигураций вместо встраивания больших сценариев вызывайте AWS Systems Manager или используйте инструмент управления конфигурацией.

Тёплый пул заранее инициализирует набор остановленных (или работающих) экземпляров EC2 в состоянии готовности за пределами ASG. Когда ASG требуется увеличить ёмкость, она берёт экземпляры из тёплого пула вместо запуска экземпляров с нуля, значительно сокращая время добавления ёмкости. Экземпляры в тёплом пуле облагаются расходами за остановленное состояние (только EBS, без платы за CPU), поэтому это намного дешевле, чем содержать полностью работающие резервные экземпляры.

При уменьшении ASG должна решить, какие экземпляры завершить. Политика завершения по умолчанию сначала выбирает AZ с наибольшим количеством экземпляров (для повторной балансировки), затем самый старый шаблон запуска, а потом экземпляр, который ближе всего к началу следующего платёжного часа. Этот порядок можно изменить — например, выбрать OldestLaunchTemplate, чтобы сначала удалить экземпляры с устаревшими конфигурациями. ASG также автоматически выполняет повторную балансировку между AZ после того, как подсеть становится доступной, или после ручных изменений.

Проверьте своё понимание понятий AWS Solutions Architect (SAA-C03) из этого урока.

В этом уроке Вы узнали, что шаблоны запуска предоставляют версиюемый многоразовый шаблон экземпляра, поддерживающий несколько версий и указатели версий $Latest/$Default; границы ёмкости ASG (минимальная, максимальная и желаемая) управляют размером набора экземпляров с автоматическим распределением между AZ по подсетям; а проверки работоспособности ELB необходимо включать, когда за ASG находится балансировщик нагрузки, чтобы сбои на уровне приложения запускали замену экземпляров. Далее мы рассмотрим политики масштабирования, включая отслеживание цели и пошаговое масштабирование.