Amazon SOA-C02: Вычислительные ресурсы и автоматическое масштабирование — Руководство по подготовке

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Часть AWS SysOps Administrator Associate SOA-C02 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Amazon, или пройдите тесты на время на ExamRoll.io.

Этот раздел охватывает управление инстансами EC2 и Auto Scaling для предоставления надежных и экономически эффективных вычислительных мощностей. Основное внимание уделяется операциям жизненного цикла инстансов, стратегиям масштабирования, интеграции с балансировщиками нагрузки, размещению для обеспечения производительности и отказоустойчивости, а также поведению при обслуживании/завершении, влияющему на доступность и состояние. Операционное мастерство означает выбор правильных типов инстансов, шаблонов конфигурации запуска, политик масштабирования и интеграции проверок работоспособности для соблюдения SLA при контроле затрат.

Жизненный цикл и управление инстансами EC2

Управление жизненным циклом EC2 начинается с настройки конфигурации запуска: используйте шаблоны запуска (Launch Templates) (

undefined

/ консоль), чтобы определить AMI, тип инстанса, профиль инстанса IAM, user-data, сетевые интерфейсы, сопоставление EBS и параметры метаданных; шаблоны поддерживают версионирование, что упрощает неизменяемые (immutable) развертывания. Неизменяемые развертывания используют новую версию шаблона запуска (или новый шаблон запуска) и либо создают новую группу Auto Scaling, либо используют обновление инстансов ASG для замены инстансов; избегайте обновлений на работающих инстансах, когда изменения затрагивают поведение при загрузке или патчи на уровне AMI.

Операционные шаблоны использования CLI/консоли включают

undefined

для единичных запусков и

undefined

для запусков под управлением ASG. Выбирайте между подготовкой AMI («baking») (с помощью Packer/CodeBuild) и стартовыми скриптами user-data в зависимости от времени загрузки: включайте («запекайте») тяжелые зависимости в AMI, чтобы сократить время загрузки; используйте user-data для настроек, специфичных для окружения. Для эфемерного хранилища помните, что тома instance store теряются при завершении работы инстанса; настройте корневые тома и тома с данными с параметром

undefined

, если вам требуется сохранение томов EBS после завершения работы инстанса.

Группы Auto Scaling, политики и хуки жизненного цикла

Группы Auto Scaling (ASG) настраиваются с помощью шаблона запуска или конфигурации запуска и контролируют желаемую/минимальную/максимальную емкость в нескольких Зонах доступности. Выбирайте шаблон запуска +

undefined

для оптимизированных по стоимости флотов, которые сочетают инстансы On-Demand и Spot со списком типов инстансов; используйте взвешивание инстансов (instance weighting) и стратегии распределения, оптимизированные по емкости (capacity-optimized), для предсказуемой емкости. Для развертываний предпочитайте неизменяемые шаблоны: создайте новую версию шаблона запуска и выполните обновление инстансов ASG (instance refresh) или развертывание по схеме «синий/зеленый» (blue/green) вместо перенастройки существующих инстансов.

Политики масштабирования выражаются как:

• Отслеживание целевого значения (Target tracking) (

undefined

): установите предопределенную метрику, такую как ALB RequestCountPerTarget или средняя загрузка CPU в ASG, и целевое значение; ASG автоматически выполняет корректировки.

• Пошаговое масштабирование (Step scaling) (

undefined

): определите алармы CloudWatch, которые запускают определенные шаги корректировки (например, +2, +4) в зависимости от серьезности нарушения; полезно для нагрузок с резкими всплесками.

• Простое масштабирование (Simple scaling) (устаревший тип): одношаговые корректировки с периодом восстановления (cooldown); в основном заменены отслеживанием целевого значения или пошаговым масштабированием.

Используйте хуки жизненного цикла (lifecycle hooks) (

undefined

), чтобы приостановить запуск или завершение инстанса. Хуки жизненного цикла позволяют вам завершить текущие соединения, реплицировать состояние (в S3/RDS) или уведомить системы оркестрации через SNS/SQS/Lambda перед завершением; всегда устанавливайте

undefined

и действие по умолчанию, чтобы избежать «зависших» состояний.

Типы Elastic Load Balancing и проверки работоспособности

Выбирайте тип балансировщика нагрузки в зависимости от характера трафика: Application Load Balancer (ALB) для трафика HTTP/HTTPS с маршрутизацией на основе содержимого и правил по хосту/пути; Network Load Balancer (NLB) для экстремальной производительности и статических IP-адресов для трафика TCP/UDP; Classic Load Balancer (CLB) только для устаревших стеков. Создавайте ALB и целевые группы с помощью

undefined

и

undefined

; регистрируйте целевые объекты ASG, используя ассоциацию целевой группы с ASG для автоматической интеграции с проверками работоспособности в жизненном цикле.

Интеграция проверок работоспособности требует согласования проверок ASG и ELB: установите

undefined

для ASG в

undefined

(

undefined

), чтобы инстанс считался работоспособным только после того, как балансировщик нагрузки пометит его целевой объект как работоспособный. Типы проверок работоспособности и их последствия:

• Проверка работоспособности целевой группы ALB/NLB: поддерживает HTTP/HTTPS/TCP и измеряет готовность на уровне приложения; рекомендуется для веб-приложений.
• Только проверки работоспособности ASG: используйте для простых проверок на уровне хоста (например, проверки статуса EC2).

undefined

дайте новым инстансам время на загрузку, выполнение user-data и прохождение проверок на уровне приложения.

Последствия использования «прилипания» сессий (stickiness): «прилипание» в целевой группе ALB использует привязку на основе cookie приложения (на основе длительности), что может улучшить аффинность сессий, но ухудшает равномерность распределения и усложняет плавающие обновления (rolling updates). NLB поддерживает аффинность по IP-адресу клиента; используйте «прилипание» только тогда, когда состояние сессии невозможно вынести во внешнее хранилище.

Размещение экземпляров, планирование ёмкости и метрики масштабирования

Решения о размещении влияют на задержку и домены отказа: группы размещения (placement groups) предлагают стратегии cluster (сеть с низкой задержкой), spread (один экземпляр на стойку для критически важных экземпляров) и partition (изолированные от сбоев разделы). ASG по умолчанию распределяют экземпляры между зонами доступности (AZ); предпочитайте планирование ёмкости с учётом AZ, чтобы избежать перегрузки одной зоны. Для CLI: aws ec2 create-placement-group –strategy cluster|spread|partition.

Планирование ёмкости учитывает типы экземпляров, варианты закупки и метрики:

• Типы экземпляров: выбирайте семейства, оптимизированные для CPU/памяти/сети (M/C/R/T/D/I) в зависимости от рабочей нагрузки; измеряйте производительность с помощью репрезентативных нагрузочных тестов.
• Варианты закупки: On-Demand для предсказуемости, Reserved или Savings Plans для снижения затрат при постоянной нагрузке, Spot для экономии на временных задачах; используйте MixedInstancesPolicy для комбинирования типов экземпляров и вариантов закупки.
• Метрики масштабирования: метрики ASG по умолчанию используют среднюю загрузку CPU по группе; для целевого отслеживания (target tracking) предпочитайте метрики уровня приложения, такие как ALB RequestCountPerTarget или пользовательские метрики CloudWatch (например, глубина очереди). Распространённые паттерны:
• Используйте целевое отслеживание (target tracking) с ALB/request-count-per-target, когда вам нужно поддерживать постоянное количество запросов на экземпляр.
• Используйте пошаговое масштабирование (step scaling) для резких, больших всплесков с определёнными шагами восстановления.
• Рассмотрите предиктивное масштабирование (Predictive Scaling) для ежедневных циклических нагрузок.

Восстановление экземпляров, поведение при завершении и обслуживание

Планируйте сбои и обслуживание экземпляров, включив автоматическое восстановление при аппаратных проблемах (сигнал CloudWatch с действием EC2 Recover) и обрабатывая запланированные события (describe-instance-status). Настройте флаги instance-initiated-shutdown-behavior и EBS DeleteOnTermination для управления жизненным циклом томов; для настройки используйте aws ec2 modify-instance-attribute –instance-id i-xxx –block-device-mappings.

Поведение при завершении в ASG: политики завершения (termination policies) ASG решают, какой экземпляр завершить первым (по умолчанию: самый старый шаблон запуска или эвристики на основе состояния экземпляра и балансировки по AZ). Важные операционные детали:

• Локальное состояние эфемерно: тома instance store и кэши в памяти теряются при завершении. Не предполагайте, что замена экземпляра сохранит локальное состояние; сохраняйте критически важные данные на EBS (с соответствующими снимками/резервными копиями), S3 или во внешнем кэше (ElastiCache).
• Используйте хуки жизненного цикла (lifecycle hooks) для отвода трафика и выгрузки состояния перед завершением.
• Используйте обновление экземпляров (instance refresh) или развёртывание blue/green для безопасной замены экземпляров во время обслуживания; aws autoscaling start-instance-refresh –auto-scaling-group-name my-asg –preferences file://prefs.json.

Распространённые ошибки и критерии принятия решений

• Полагаться на стандартные периоды восстановления (cooldowns) и метрики только по CPU: выбирайте метрики, соответствующие поведению приложения (ALB RequestCountPerTarget, глубина очереди); устанавливайте cooldowns с учётом времени запуска и HealthCheckGracePeriod, чтобы избежать колебаний.
• Не использовать хуки жизненного цикла для корректного завершения: без хуков запросы в обработке и локальные кэши теряются; реализуйте хуки с помощью SNS/SQS/Lambda для отвода трафика и сохранения состояния.
• Предполагать, что замена экземпляра сохраняет локальное состояние: локальные тома instance store и кэши в памяти эфемерны; проектируйте stateless-экземпляры или реплицируйте состояние в надёжные хранилища.
• Злоупотребление привязкой сессий (stickiness): привязка сессий усиливает неравномерное распределение нагрузки и усложняет масштабирование и обновления; для горизонтального масштабирования предпочитайте внешние хранилища сессий (ElastiCache, DynamoDB).
• Игнорирование балансировки по AZ и групп размещения: размещение слишком большого количества экземпляров в одной AZ или группе cluster может создать единую точку отказа; используйте распределение ASG по нескольким AZ и соответствующие стратегии групп размещения.
• Неправильная настройка интеграции проверок состояния: тип проверки состояния ASG (health-check-type) должен соответствовать проверкам состояния ELB/целевой группы, а HealthCheckGracePeriod должен быть достаточно длинным для инициализации приложения, иначе здоровые экземпляры будут завершены.

Практическая задача: Сценарий использования

Компания StreamingCo управляет API для создания миниатюр видео, который испытывает ежедневные всплески трафика и использует локальные дисковые кэши на экземплярах EC2; в последнее время горизонтальное масштабирование происходит медленно, а завершённые экземпляры теряют кэш, что приводит к увеличению времени ответа.

1. Перенесите конфигурацию запуска (launch configuration) в шаблон запуска (Launch Template) и создайте легковесный AMI с зависимостями времени выполнения; используйте aws ec2 create-launch-template и версионирование для неизменяемых (immutable) развёртываний.
2. Настройте ASG с MixedInstancesPolicy, в которой перечислены несколько типов экземпляров и распределение Spot + On-Demand для балансировки затрат и ёмкости.
3. Подключите ALB и используйте TargetTrackingScaling по метрике ALB RequestCountPerTarget, установив HealthCheckGracePeriod равным времени начальной загрузки приложения.
4. Реализуйте хуки жизненного цикла (lifecycle hooks) при завершении экземпляров в ASG для отвода соединений и запуска потока Lambda/SNS для сохранения необходимых ключей кэша в ElastiCache или S3 перед завершением.
5. Вынесите состояние сессий и кэша во внешние сервисы, такие как ElastiCache или S3, и используйте группы размещения/распределение по AZ для соответствия требованиям к задержке и доменам отказа.

Обоснование: Использование шаблонов запуска и неизменяемых развёртываний снижает вариативность времени загрузки; целевое отслеживание, ориентированное на ALB, привязывает масштабирование к нагрузке по запросам, а не к CPU; хуки жизненного цикла предотвращают потерю данных при завершении; вынос кэша вовне устраняет зависимость от эфемерного локального состояния, обеспечивая быстрое, безопасное масштабирование и снижение затрат за счёт смешанных стратегий выбора экземпляров/закупки.

← Хранение и управление данными · Все домены · Базы данных и кэширование →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Amazon →