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 предоставляет строительные блоки для создания надежных очередей, систем pub/sub, шин событий, потоковой обработки, оркестрации и операционной автоматизации. Глубокое понимание взаимодействия между Amazon SQS, Amazon SNS, Amazon EventBridge, AWS Step Functions, сопоставлений источников событий Lambda, AWS Systems Manager Automation и OpsCenter, а также Kinesis Data Streams и Firehose, позволяет создавать масштабируемые, отказоустойчивые и аудируемые средства автоматизации и конвейеры данных.

Обмен сообщениями и прием данных: SQS, SNS, Kinesis и Firehose

Amazon SQS предоставляет надежные, масштабируемые очереди для разделения компонентов. Стандартные очереди предлагают доставку “как минимум один раз” (at-least-once) и негарантированный порядок (best-effort ordering) с практически неограниченной пропускной способностью; они подходят для параллельных обработчиков, которые могут справляться с дублирующимися и неупорядоченными сообщениями с помощью ключей идемпотентности и условных записей. Очереди FIFO обеспечивают упорядоченную доставку в рамках группы сообщений и семантику обработки “ровно один раз” (exactly-once) с дедупликацией (в пределах пятиминутного окна). Они гарантируют порядок и однократную обработку, но в ущерб абсолютной пропускной способности: используйте несколько групп сообщений для распараллеливания в рамках FIFO или включите режим FIFO с высокой пропускной способностью для обработки тысяч сообщений в секунду. Настраивайте тайм-аут видимости для очереди или для отдельного сообщения так, чтобы он превышал максимальное время обработки; при использовании Lambda в качестве потребителей установите тайм-аут видимости как минимум в шесть раз больше тайм-аута вашей функции, чтобы разрешить повторные попытки до того, как сообщение снова станет видимым. Используйте длинные опросы (long polling), чтобы сократить количество пустых получений. Очереди недоставленных сообщений (DLQ) собирают “отравленные” сообщения, когда сообщение превышает maxReceiveCount; позже можно выполнить повторную отправку (redrive) из DLQ в исходную очередь для повторной обработки с исправлениями. Отслеживайте ApproximateAgeOfOldestMessage для обнаружения накопления сообщений и для управления изменениями параллелизма/автомасштабирования.

Amazon SNS предоставляет управляемую, высокопроизводительную систему “издатель-подписчик” (pub/sub). Издатели отправляют сообщение в топик один раз; SNS рассылает его по нескольким подпискам (SQS, Lambda, HTTP/S, email, мобильные устройства). Политики фильтрации подписок используют атрибуты сообщений для маршрутизации только релевантных уведомлений каждому подписчику, что снижает затраты и нагрузку на последующие компоненты; можно задавать предикаты, такие как точное совпадение, префикс, числовые диапазоны, “все кроме” (anything-but) и проверка существования (exists). Используйте SNS для веерной рассылки (fan-out), несвязанных уведомлений и мобильных push-уведомлений. Включите повторные попытки и рассмотрите возможность использования DLQ для каждой подписки для обработки неудачных доставок. Для задач, требующих упорядоченной веерной рассылки, топики SNS FIFO с подписками в виде очередей SQS FIFO обеспечивают порядок и дедупликацию.

Kinesis Data Streams предоставляет упорядоченные потоки с низкой задержкой и параллелизмом на уровне шардов для аналитики в реальном времени и обработки событий. Производители записывают записи с ключами секционирования в шарды; потребители (Lambda, KCL, потребители Enhanced Fan-Out, Kinesis Data Analytics) читают данные в порядке поступления для каждого шарда, используя контрольные точки (checkpointing). Используйте емкость по требованию (on-demand) для непредсказуемой нагрузки или выделенные шарды с возможностью их перераспределения (resharding) для предсказуемой пропускной способности. Настраивайте ключи секционирования для балансировки нагрузки на “горячие” шарды и отслеживайте IteratorAge для выявления отставания потребителей. Режим Enhanced Fan-Out предлагает выделенную пропускную способность 2 МБ/с на каждый поток потребителя с push-доставкой с низкой задержкой по HTTP/2.

Kinesis Data Firehose — это полностью управляемый сервис доставки для приема данных почти в реальном времени в S3, Amazon OpenSearch Service, Splunk или на HTTP-эндпоинты, с опциональным преобразованием через Lambda, буферизацией (по размеру/времени), сжатием и шифрованием. Источниками данных могут быть прямые вызовы PutRecord/PutRecordBatch, Kinesis Data Streams или подписки CloudWatch Logs/Events. Используйте Firehose, когда вам нужна управляемая доставка с преобразованием и пакетированием, и вы не хотите создавать и эксплуатировать код потребителя. Динамическое секционирование позволяет маршрутизировать записи в префиксы S3 по ключам для эффективной последующей обработки.

Маршрутизация, оркестрация и планирование: EventBridge и Step Functions

Amazon EventBridge — это центральная шина событий для маршрутизации, управления и межаккаунтной интеграции, а также интеграции между доменами событий. Используйте шину по умолчанию для событий от сервисов AWS, пользовательские шины для сегментации доменов и применения разрешений, а партнерские шины — для интеграции с SaaS. Правила сопоставляют события с помощью шаблонов на основе содержимого и направляют их в более чем 200 сервисов AWS. Используйте преобразователи входных данных для формирования полезной нагрузки, а также архивацию/повторную обработку для повторной обработки исторических событий при восстановлении или подключении новых потребителей. Политики ресурсов позволяют маршрутизировать события между аккаунтами для консолидации управления в аккаунте платформы. EventBridge Pipes предоставляют настраиваемые потоки «точка-точка» от источников событий (SQS, Kinesis, DynamoDB Streams, самоуправляемый Apache Kafka на Amazon MSK и др.) к целям со встроенной фильтрацией, пакетированием, преобразованием и обогащением через Lambda или Step Functions — идеальное решение, когда вы не хотите управлять полноценным приложением-потребителем, а нуждаетесь в легковесном посредничестве. EventBridge Scheduler предоставляет однократные и cron-расписания для вызова целей с ролью выполнения, поддержкой часовых поясов и опциональными гибкими временными окнами для уменьшения «эффекта несущегося стада».

AWS Step Functions оркеструет распределенные рабочие процессы, определенные на языке Amazon States Language, с состояниями Task, Choice, Parallel, Map (включая распределенный Map), Wait, Pass, Succeed/Fail и надежными шаблонами Retry/Catch. Глубокая интеграция с сервисами устраняет необходимость в связующем коде для вызова AWS API, включая синхронные (.sync) и callback-шаблоны с токенами задач. Выбирайте стандартные рабочие процессы (Standard Workflows) для долго выполняющихся рабочих процессов с интенсивным аудитом, с семантикой перехода между состояниями «ровно один раз», длительностью до одного года и оплатой за каждый переход между состояниями; история выполнения сохраняется, обеспечивая высокую наглядность и встроенные трассировки X-Ray. Выбирайте экспресс-рабочие процессы (Express Workflows) для высокопроизводительных, короткоживущих оркестраций (от секунд до минут), где для достижения массового масштаба можно пойти на оплату за запрос + длительность и семантику выполнения «как минимум один раз»; используйте их для обогащения данных при потоковом приеме, маршрутизаторов событий и микро-оркестраций, где вы можете сделать задачи идемпотентными. Применяйте такие шаблоны, как «сага» с компенсирующими задачами и централизованная обработка ошибок; выносите повторные попытки/тайм-ауты в конечный автомат, чтобы упростить код задач.

Триггеры вычислений и противодавление: сопоставления источников событий Lambda

Сопоставления источников событий Lambda (ESM) соединяют источники, работающие по модели опроса (pull-based), с Lambda и управляют параллелизмом, пакетированием и обработкой ошибок.

• SQS: Lambda масштабируется горизонтально, опрашивая очередь и вызывая вашу функцию с пакетами (до 10 сообщений; максимальное окно пакетирования до 300 секунд). В случае стандартных очередей (Standard) масштабирование происходит агрессивно в зависимости от глубины очереди и пропускной способности; в случае очередей FIFO Lambda сохраняет порядок в пределах группы сообщений и обрабатывает по одному пакету на группу за раз. Настройте максимальный параллелизм (maximum concurrency) в ESM, чтобы ограничить масштабирование обработчиков и защитить нижестоящие системы; комбинируйте с зарезервированным/подготовленным параллелизмом (reserved/provisioned concurrency) для гарантии производительности. Используйте частичный ответ на пакет (partial batch response), чтобы подтверждать только успешно обработанные записи и возвращать в очередь неудачные, избегая повторной обработки всего пакета. Установите тайм-аут видимости очереди так, чтобы он превышал общее время выполнения всех повторных попыток в худшем случае. Очереди недоставленных сообщений (DLQ) и политики повторной отправки изолируют «отравленные» сообщения.

• Kinesis Data Streams: По умолчанию один параллельный вызов Lambda на шард обеспечивает порядок обработки в пределах шарда. Увеличьте ParallelizationFactor до 10, чтобы обрабатывать несколько пакетов на шард параллельно, если порядок между подпоследовательностями не важен. Размер пакета до 10 000 записей (6 МБ) и максимальное окно пакетирования до 5 минут позволяют амортизировать затраты и увеличить пропускную способность. Используйте бинарный поиск по ошибке функции (bisect on function error) для нахождения проблемных записей в пакете, а также назначения при сбое (on-failure destinations) или максимальное количество повторов/возраст записи для отбрасывания или маршрутизации необрабатываемых записей. Отслеживайте метрику IteratorAge, чтобы выявлять отставание потребителя и, соответственно, выполнять решардинг или увеличивать параллелизацию.

• DynamoDB Streams: По семантике похожи на Kinesis; размер пакета до 1000 записей (6 МБ) и модель «шард на ключ раздела». Потребители получают упорядоченные изменения на уровне элементов (INSERT, MODIFY, REMOVE). Применяйте те же методы обработки сбоев (бинарный поиск по ошибке, максимальное количество попыток, возраст записи) и фильтрацию. Используйте тип представления потока (stream view type), который включает необходимые вашему потребителю атрибуты (NewImage, OldImage, NewAndOldImages или KeysOnly), чтобы оптимизировать размер полезной нагрузки.

Фильтрация событий в ESM сокращает количество вызовов, отбрасывая нерелевантные события на уровне опрашивающего компонента (poller). Используйте агрегацию по «падающим» окнам (tumbling window) в потоках с помощью Lambda для агрегирования записей за определенный период времени в рамках шаблонов обработки мини-пакетов.

Автоматизация операций и устранение неполадок: Systems Manager Automation и OpsCenter

AWS Systems Manager Automation предоставляет сборники сценариев (runbooks) — документы типа Automation, написанные на JSON/YAML, — с такими шагами, как aws:runCommand, aws:executeScript, aws:invokeLambda, aws:approve, aws:createStack и aws:executeAutomation. Автоматизации принимают параметры, генерируют выходные данные, поддерживают версионирование с историей изменений и выполняются с выделенной ролью AutomationAssumeRole для реализации принципа наименьших привилегий и выполнения операций в разных аккаунтах и регионах (Region). Контролируйте параллелизм и пороговые значения ошибок для всего парка ресурсов, требуйте подтверждений и соблюдения окон Change Calendar, а также интегрируйтесь с уведомлениями через SNS. Запускайте автоматизации по расписанию, с помощью правил EventBridge (для устранения неполадок в режиме, близком к реальному времени, на основе событий AWS Health, CloudWatch или API), из исправлений AWS Config для принудительного применения политик (например, для применения тегов по умолчанию к томам EBS или для подключения профиля инстанса по умолчанию к инстансам EC2), а также из OpsCenter.

OpsCenter агрегирует операционные проблемы в элементы OpsItems из оповещений CloudWatch, AWS Config, событий Health или пользовательских источников. Каждый OpsItem отслеживает статус, приоритет, дедупликацию, связанные ресурсы и ссылки на сборники сценариев (runbooks). Связывайте сборники сценариев (runbooks) для стандартных исправлений, запускаемые в один клик, и включайте автоматическое устранение неполадок, настраивая правила EventBridge или Config на запуск определенной автоматизации при создании или обновлении OpsItem до соответствующего условия (например, группа безопасности, разрешающая доступ по SSH с 0.0.0.0/0, несоответствие требованиям по установке исправлений или сбои резервного копирования). Используйте Systems Manager Explorer для визуализации состояния парка ресурсов и открытых OpsItems в разных аккаунтах и регионах. Эта пара — OpsItems в качестве постоянных записей и сборники сценариев Automation (runbooks) в качестве кодифицированных исправлений — обеспечивает аудируемые и согласованные операции в любом масштабе.

Рекомендации по проектированию и эксплуатации

Проектируйте с учётом идемпотентности для всех потребителей, поскольку доставка «по меньшей мере один раз» (at-least-once) является обычным явлением. Для параллельных реакций с низкой задержкой отдавайте предпочтение веерной рассылке на основе событий через SNS или правила EventBridge; для буферизации рабочих нагрузок и защиты производителей от медлительности потребителей используйте SQS; для аналитики, требующей строгого порядка в пределах шарда и повторно воспроизводимых потоков, выбирайте Kinesis. Используйте EventBridge Pipes для легковесной управляемой интеграции между источниками и целями, когда кастомный потребитель избыточен, и EventBridge Scheduler для триггеров на основе времени без необходимости поддерживать инфраструктуру cron.

Правильно подбирайте таймауты и количество повторных попыток. Для SQS таймаут видимости должен превышать максимальное время обработки с учётом повторов; для потоков ограничьте количество повторов и установите

undefined

, чтобы избежать бесконечного воспроизведения некорректных записей. Систематически используйте DLQ или назначения для сбоев (on-failure destinations) и добавляйте дашборды и оповещения для метрик SQS

undefined

, Lambda

undefined

/

undefined

/

undefined

,

undefined

, Step Functions

undefined

/

undefined

и EventBridge

undefined

. Когда пиковый трафик неизбежен, а SLA по задержке строгие, используйте Lambda provisioned concurrency для предварительного «прогрева» мощностей. Для управления (governance) предпочтительнее использовать EventBridge с ресурсными политиками для межаккаунтной маршрутизации и функцией архивации/воспроизведения для поддержки эволюции потребителей и восстановления после инцидентов.

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

Shopify необходимо модернизировать обработку заказов для событий флеш-распродаж, добавив аналитику в реальном времени и автоматизированное устранение неполадок при замедлении или сбое зависимых сервисов.

1. Приём и веерная рассылка событий заказов

• Используйте топик SNS FIFO для публикации событий

undefined

из процесса оформления заказа, что гарантирует упорядоченные уведомления без дубликатов для каждого

undefined

. Подписки включают:

• Очередь SQS FIFO (

undefined

) для выполнения заказа с сохранением последовательности.

• Пользовательская шина событий EventBridge (

undefined

) для управления и дополнительной маршрутизации.

• Поток доставки Kinesis Data Firehose для доставки заказов в S3 в режиме, близком к реальному времени, со сжатием GZIP для аналитики. Почему SNS FIFO: Обеспечивает упорядоченную семантику «ровно один раз» (exactly-once) с масштабируемой веерной рассылкой нескольким подписчикам без жёсткой связи издателей с потребителями.

2. Буферизация и обработка выполнения заказов

• Lambda считывает сообщения из очереди SQS FIFO через event source mapping с размером пакета 10, включённой функцией частичного ответа для пакета (partial batch response) и ограниченной максимальной параллельностью для защиты API склада. Таймаут видимости очереди установлен в шесть раз больше таймаута Lambda для учёта повторных попыток. DLQ собирает «отравленные» сообщения при

undefined

; рабочий процесс повторной отправки (redrive) позже обрабатывает исправленные сообщения. Почему SQS FIFO + Lambda ESM: Обеспечивает последовательность обработки для каждого заказа, изолирует замедление зависимых сервисов с помощью буферизации и предоставляет детальную обработку ошибок.

3. Оркестрация многошаговой саги

• Рабочий процесс Step Functions Standard оркестрирует захват платежа, резервирование на складе, проверку на мошенничество и оформление доставки, используя повторные попытки, таймауты и компенсирующие задачи (возврат средств, пополнение запасов) в случае сбоев. Первая задача (Task) запускается функцией Lambda, вызванной потребителем SQS. Почему Standard: Обеспечивает длительное, аудируемое продвижение состояния с семантикой «ровно один раз» между внешними системами и предоставляет широкие возможности для обработки ошибок.

4. Маршрутизация доменных событий к функциональным возможностям

• Шина

undefined

получает события

undefined

через

undefined

от сервисов-производителей и из подписки SNS. Правила EventBridge:

• Сопоставляют

undefined

для уведомления отдела маркетинга (Lambda) и создания обращения в поддержку (интеграция с AWS Support API) при заказе от ценных клиентов.

• Перенаправляют

undefined

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

5. Перенаправление потока данных от партнёра для обогащения

• EventBridge Pipes соединяет очередь SQS Standard партнёра (с SKU, ожидающими поступления) с рабочим процессом Step Functions Express, который обогащает данные с помощью функции Lambda и отправляет результаты во внутреннюю очередь SQS для пополнения запасов. Почему Pipes + Express: Управляемая интеграция с низкими накладными расходами, обеспечивающая легковесное обогащение данных с высокой пропускной способностью и низкой стоимостью.

6. Аналитика и поиск в реальном времени

• Kinesis Data Stream собирает данные о кликах (clickstream) и операционные события. Lambda (в качестве потребителя с Enhanced Fan-Out) выполняет сессионизацию, а Kinesis Data Analytics агрегирует KPI. Firehose доставляет преобразованные заказы и аналитику в data lake на S3 и в Amazon OpenSearch Service с динамическим партиционированием по дате/рынку для эффективных запросов. Почему Streams + Firehose: Упорядоченная обработка для аналитики с низкой задержкой, а также управляемая доставка и преобразование данных для хранения и поиска.

7. Автоматизация на основе времени

• EventBridge Scheduler каждую минуту по расписанию (cron) публикует событие

undefined

в

undefined

, запуская рабочий процесс Step Functions Express, который собирает срезы данных по складам для обеспечения точности информации о запасах в режиме, близком к реальному времени. Почему Scheduler: Нативный, отказоустойчивый cron без необходимости поддерживать собственную инфраструктуру.

8. Автоматизированное устранение неполадок и операции

• Правила AWS Config обнаруживают открытые порты SSH или публичные ACL для S3 в VPC, используемых для выполнения заказов. Управляемые исправления (Managed remediations) вызывают runbook’и Systems Manager Automation для устранения расхождений в конфигурации. Оповещения CloudWatch по метрикам SQS

undefined

и Lambda

undefined

создают OpsItems в OpsCenter; связанные с ними runbook’и масштабируют provisioned concurrency для определённых функций Lambda, увеличивают зарезервированную ёмкость Step Functions или временно расширяют окна обработки пакетов. Правило EventBridge для событий AWS Health о техническом обслуживании EC2 запускает документ SSM Automation для корректного перезапуска затронутых инстансов во время окон обслуживания. Почему OpsCenter + Automation: Централизованное, аудируемое отслеживание проблем с возможностью исправления в один клик или автоматически, с минимальными привилегиями, которое безопасно выполняется в разных аккаунтах и регионах.

Такая архитектура выдерживает пиковые нагрузки флеш-распродаж за счёт буферизации и веерной рассылки, сохраняет бизнес-инварианты с помощью оркестрации, предоставляет аналитику за секунды и замыкает цикл с помощью автоматизированного устранения неполадок на основе политик.

← Высокая доступность · Все домены · Хранилища →

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

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