Amazon DOP-C02: Высокая доступность, отказоустойчивость и аварийное восстановление — Руководство по подготовке

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

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

Обзор

Высокая доступность и аварийное восстановление в AWS нацелены на сокращение времени простоя (RTO) и потерь данных (RPO) при сбоях компонентов, зон доступности (AZ) или регионов. Архитектуры Multi-AZ позволяют пережить сбой AZ без потери данных и с минимальным влиянием на сервис; архитектуры Multi-Region предназначены для противодействия сбоям на уровне регионов и крупномасштабным инцидентам. Выбор между стратегиями «активный/активный», «активный/пассивный» (горячий резерв) и «пилотный свет» определяется бизнес-целями по RTO/RPO, требованиями к согласованности данных и стоимостью. Достижение этих целей требует целостного проектирования, охватывающего DNS-маршрутизацию, эластичность вычислений, балансировку нагрузки, репликацию/переключение баз данных при сбое, надежное объектное хранилище с репликацией/версионированием, централизованное резервное копирование и непрерывную проверку отказоустойчивости с помощью внедрения сбоев.

Архитектуры для RTO/RPO и интеллектуальной маршрутизации

Multi-AZ и Multi-Region:

Multi-AZ: Размещайте избыточные инстансы как минимум в двух подсетях в разных AZ за балансировщиком нагрузки. Используйте управляемые базы данных с синхронной репликацией (RDS Multi-AZ, Aurora Multi-AZ/кластер). RPO обычно равен нулю для синхронного хранилища; целевые значения RTO варьируются от менее минуты (Aurora) до нескольких минут (переключение при сбое RDS Single-Instance Multi-AZ).
Multi-Region: Выбирайте архитектуру «активный/активный» для минимального RTO с региональной изоляцией и низкой задержкой, или «горячий резерв»/«пилотный свет» для DR, оптимизированного по стоимости. Репликация данных должна соответствовать RPO: асинхронные реплики БД, Aurora Global Database (типичное RPO <1 с), глобальные таблицы DynamoDB (multi-Region, multi-active) и S3 Cross-Region Replication (CRR) с опциональным Replication Time Control (RTC) для репликации с гарантией SLA.

Политики маршрутизации Route 53 и проверки работоспособности:

Маршрутизация для переключения при сбое: Создайте две записи с одинаковым именем: Primary (основная) и Secondary (вторичная). Свяжите проверку работоспособности с основной записью (или используйте “Evaluate Target Health” для псевдонима к ALB/NLB). При сбое трафик переключается на вторичную запись. Устанавливайте низкое значение TTL (например, 60 с), чтобы уменьшить задержку из-за кэширования DNS, и отслеживайте состояние проверок работоспособности с помощью CloudWatch Alarms.
Маршрутизация на основе задержки: Направляйте пользователей в регион с наименьшей измеренной задержкой. Свяжите проверки работоспособности с каждой записью, чтобы трафик получали только работоспособные конечные точки. Используйте в паре с multi-Region стеками и региональными хранилищами данных, которые поддерживают согласованность в конечном счете или строгую согласованность по мере необходимости.
Взвешенная маршрутизация: Распределяйте трафик в процентном соотношении для поддержки канареечных развертываний, A/B-тестирования или «постепенной» проверки готовности к DR (например, 1% трафика постоянно направляется на вторичную систему). Комбинируйте с проверками работоспособности, чтобы неработоспособные веса исключались. Используйте постепенное изменение весов для миграции трафика во время эвакуации региона.
Проверки работоспособности: Проверяйте конечные точки HTTP(S)/TCP или CloudWatch Alarms. Для псевдонимов ALB/NLB включите “Evaluate Target Health”, чтобы унаследовать состояние целевой группы. Проектируйте конечные точки для проверок так, чтобы они отражали реальную готовность (доступность зависимостей, примененные миграции). Для приложений с отслеживанием состояния включайте проверки зависимостей (база данных, кэш), чтобы избежать маршрутизации на частично работоспособные инстансы.

Отказоустойчивые шаблоны по целям:

Низкий RPO, RTO менее минуты в глобальном масштабе: Архитектура «активный/активный» с маршрутизацией на основе задержки и проверками работоспособности в Route 53, локальные в регионе вычислительные ресурсы без отслеживания состояния, глобальные таблицы DynamoDB или Aurora Global Database, S3 CRR с RTC для критически важных объектов.
Умеренный RPO (≤15 мин), RTO ≤4 часов: Горячий резерв с уменьшенной вторичной инфраструктурой, асинхронная реплика БД (межрегиональная реплика чтения RDS или Aurora Global), маршрутизация для переключения при сбое в Route 53, планы выполнения (runbooks) или автоматизация для масштабирования и повышения роли при переключении.
DR, оптимизированный по стоимости: «Пилотный свет» только для основных сервисов данных, инфраструктура как код для развертывания уровня приложений при активации, RPO определяется частотой репликации, RTO — временем развертывания и синхронизации данных.

Хаос-инжиниринг и AWS Fault Injection Simulator (FIS)

Эксперименты по хаос-инжинирингу подтверждают, что механизмы высокой доступности (HA) и аварийного восстановления (DR) работают так, как задумано. AWS FIS организует контролируемые сбои с использованием защитных механизмов (guardrails):

Шаблоны экспериментов (Experiment templates) определяют действия (например, остановка или перезагрузка процента инстансов EC2 в ASG, создание нагрузки на CPU или память через SSM, добавление сетевой задержки/потери пакетов на инстансах, уничтожение подов EKS, остановка задач ECS, запуск аварийного переключения RDS/Aurora) и цели (теги ресурсов, ARN).
Механизмы безопасности: Укажите условия остановки по тревогам CloudWatch, ограничения по времени, ограничения радиуса поражения (blast radius) через теги/фильтры и предварительные проверки. Сначала запускайте в непроизводственной среде, а затем в производственной с жесткими защитными механизмами и после одобрения со стороны бизнеса.
Наблюдаемость (Observability): Отслеживайте KPI (уровень ошибок, хвостовую задержку (tail latency), возраст очереди, задержку репликации) и проверяйте автоматические реакции, включая срабатывание Auto Scaling, сходимость проверок состояния балансировщика нагрузки, аварийное переключение Route 53, повышение роли базы данных и поведение механизма “автоматического выключателя” (circuit breaker).
Непрерывная отказоустойчивость: Интегрируйте эксперименты в конвейеры/учения (gamedays), чтобы предотвратить снижение отказоустойчивости из-за дрейфа конфигурации. Используйте Parameter Store или AppConfig для управления флагами функций (toggles) и координации безопасных развертываний.

Практический сценарий

Expedia Group управляет глобальным API для поиска путешествий, который должен обеспечивать RTO менее 60 секунд и RPO, близкий к нулю, для критически важных данных бронирования, сохраняя при этом низкую задержку для пользователей в Северной Америке и Европе. Команда сталкивается с периодическими частичными сбоями в регионах (brownouts) и нестабильностью, вызванной развертываниями, а аудиторы требуют наличия кросс-аккаунтных неизменяемых резервных копий и документированных учений по аварийному восстановлению.

Пошаговый подход:

Создание мультирегиональных стеков в режиме active/active

Разверните стеки stateless API в регионах us-east-1 и eu-west-1 в нескольких зонах доступности (AZ) за балансировщиками ALB. Используйте маршрутизацию Route 53 на основе задержки (latency-based routing) с проверками состояния и опцией Evaluate Target Health для записей-псевдонимов (alias records). Это обеспечивает маршрутизацию с низкой задержкой и автоматический обход региона, если конечная точка неработоспособна.

Глобальное хранилище данных с низким RPO

Перенесите данные бронирования и сессий в Amazon Aurora Global Database (совместимую с MySQL), где us-east-1 будет основным регионом, а eu-west-1 — вторичным. Типичные показатели RPO < 1 с и RTO < 1 мин соответствуют целевым требованиям. Используйте конечные точки кластера и чтения (cluster and reader endpoints) в конфигурации приложения с повторными попытками и экспоненциальной задержкой (retry/backoff) для устойчивости к аварийным переключениям.

Отказоустойчивое масштабирование и плавные переходы

Настройте отслеживание целевого значения (target tracking) Auto Scaling по метрике ALB RequestCountPerTarget с минимальной емкостью в обоих регионах. Добавьте “теплые пулы” (warm pools) такого размера, чтобы поглотить 10-кратный всплеск трафика во время крупных событий, и хуки жизненного цикла Launching:Wait, чтобы отложить регистрацию инстанса до прохождения проверок готовности приложения. Включите задержку дерегистрации ALB (deregistration delay) на 120 секунд, чтобы сохранить запросы в обработке (in-flight) во время сжатия (scale-in) и развертываний.

DR для долговечных объектов

Включите версионирование S3 и межрегиональную репликацию (CRR) с контролем времени репликации (RTC) для документов маршрутов из us-east-1 в eu-west-1. Используйте выделенную IAM-роль для репликации и ключи KMS в обоих регионах, предоставляя права kms:Decrypt в исходном регионе и kms:Encrypt в целевом. Метрики и оповещения RTC обеспечивают уверенность в соблюдении SLA репликации.

Управление DNS для канареечных развертываний и аварийного переключения

Добавьте взвешенные записи (weighted records) в Route 53 (постоянный поток 1% трафика в eu-west-1), чтобы постоянно проверять вторичный путь. В сочетании с проверками состояния это гарантирует, что резервная среда готова к работе, и позволяет выявить дрейф конфигурации до возникновения кризисной ситуации.

Централизованные, неизменяемые резервные копии

В аккаунте, принадлежащем отделу безопасности, создайте хранилища AWS Backup с функцией Vault Lock и ключами KMS CMK. Определите политики резервного копирования на уровне организации для планирования ежедневных бэкапов и их копирования в другие аккаунты для RDS, DynamoDB, EFS и EBS. Назначайте ресурсы с помощью тега Backup_Frequency. Это обеспечивает устойчивость к программам-вымогателям и разделение обязанностей.

Автоматизированная оркестрация аварийного переключения

Реализуйте правило EventBridge для обнаружения сигналов сбоя основного кластера Aurora и вызова Lambda-функции, которая повышает роль вторичного региона и обновляет конечную точку приложения, хранящуюся в Parameter Store. Приложения загружают эту конечную точку при запуске и обновляют ее при ошибках подключения, что минимизирует ручные действия.

Проверка с помощью хаос-инжиниринга с AWS FIS

Создайте шаблоны экспериментов FIS для: завершения 10% инстансов ASG, внесения задержки 150 мс и потери 1% пакетов на EC2 через SSM, а также для запуска аварийного переключения Aurora. В качестве защитного механизма используйте условия остановки по тревогам CloudWatch для 95-го перцентиля задержки (p95 latency) и уровня ошибок. Проводите ежемесячные учения (gamedays) для проверки скорости аварийного переключения Route 53, восстановления ASG, сходимости проверок состояния ALB и RTO при повышении роли Aurora.

Почему выбраны именно эти сервисы:

Маршрутизация Route 53 на основе задержки и взвешенная маршрутизация обеспечивают как оптимальную задержку для пользователей, так и контролируемое формирование трафика для готовности к DR.
Связка ALB и ASG с “теплыми пулами” и хуками жизненного цикла обеспечивает быстрое, плавное масштабирование без штрафов за “холодный старт” и без прерывания работы пользователей.
Aurora Global Database уникальным образом обеспечивает RPO, близкий к нулю, и RTO менее минуты между регионами с минимальными изменениями в приложении.
Версионирование S3 и CRR с RTC обеспечивают аудируемую репликацию критически важных артефактов с поддержкой SLA.
AWS Backup с кросс-аккаунтными хранилищами и Vault Lock создает неизменяемые, централизованно управляемые резервные копии, соответствующие требованиям комплаенса.
AWS FIS предоставляет безопасное, автоматизированное внесение сбоев для постоянной проверки уровня отказоустойчивости и предотвращения подрыва плана DR из-за дрейфа конфигурации.

← Контейнеры и бессерверные операции · Все домены · Событийно-ориентированные архитектуры и автоматизация →

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