Amazon DVA-C02: Обмен сообщениями, потоковая передача данных и событийно-ориентированные архитектуры (SNS, SQS, Kinesis, EventBridge, Step Functions) — Руководство по подготовке

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

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

EventBridge и Step Functions для маршрутизации и оркестрации

EventBridge отлично подходит для маршрутизации событий на основе схем и интеграций между аккаунтами/с партнёрами по событиям, используя PutEvents для вставки событий и PutRule/PutTargets для их направления в SQS, Lambda, Kinesis, Step Functions или на HTTP-эндпоинты. EventBridge использует шаблоны событий (event patterns) для фильтрации и поддерживает архивацию и воспроизведение (replay) для восстановления состояния. Используйте очереди недоставленных сообщений (dead-letter queues) для правил (Target с SqsParameters или DeadLetterConfig) и помните, что EventBridge обеспечивает повторные попытки с экспоненциальной задержкой, а затем отправку в DLQ в случае сбоя. Для оркестрации выбирайте Step Functions: стандартные конечные автоматы (Standard state machines) для долговечных рабочих процессов с историей выполнения и встроенными повторными попытками/Catch, и Express для высокопроизводительных, недолговечных рабочих процессов с меньшей стоимостью и выполнением по принципу «best-effort». Используйте интеграции задач (Task integrations) с сервисами (arn:aws:states:::lambda:invoke или arn:aws:states:::aws-sdk:apigateway:invoke) и шаблоны обратного вызова (callback patterns) с использованием “waitForTaskToken” для реализации асинхронных внешних подтверждений. Реализуйте повторные попытки и Catch с экспоненциальной задержкой и используйте HeartbeatSeconds для длительных задач. Используйте состояние Map для распараллеливания обработки больших коллекций, но следите за параллелизмом (concurrency) и троттлингом нижестоящих сервисов. Типичная ошибка — неправильный выбор Express для рабочих процессов, требующих долговечной истории с гарантией однократного выполнения (exactly-once); для возможности аудита выбирайте Standard. Также обеспечивайте идемпотентность в задачах, вызываемых Step Functions, передавая токен идемпотентности и заставляя целевые сервисы обеспечивать уникальность во время записи.

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

Сценарий: StreamlyGames управляет глобальным игровым бэкендом в многоаккаунтной среде AWS. Игроки загружают 10-мегабайтные клипы геймплея в S3; конвейер обработки должен перекодировать видео, выполнять ML-анализ и записывать результаты в Aurora Serverless с упорядоченной, дедуплицированной обработкой и масштабируемыми потребителями.

Задача: Обеспечить, чтобы каждый загруженный файл запускал обработку ровно один раз и в правильном порядке для каждого игрока, обрабатывать всплески нагрузки без потери событий и масштабировать потребителей для ML-вывода, предотвращая дублирующиеся записи в БД.

Рекомендуемый подход:

1. Создайте уведомление о событии S3 для публикации событий создания объекта (object-created) в пользовательскую шину EventBridge (PutEvents), а также в очередь SQS FIFO (CreateQueue с FifoQueue=true), где ключом является PlayerID в качестве MessageGroupId, а MessageDeduplicationId основан на ETag объекта S3.
2. Настройте потребителя Lambda с сопоставлением источника событий SQS (CreateEventSourceMapping), используя BatchSize=1, FunctionResponseTypes=[“ReportBatchItemFailures”], и установите VisibilityTimeout больше максимального времени обработки; используйте ChangeMessageVisibility при вызове сторонних ML API.
3. Lambda выполняет идемпотентные записи в БД Aurora, используя детерминированный ключ идемпотентности (INSERT … ON CONFLICT DO NOTHING или ограничение уникальности), и фиксирует прогресс; для длительных ML-вызовов используйте асинхронные Step Functions с токенами задач (arn:aws:states:::lambda:invoke.waitForTaskToken) или Step Functions Express для высокой пропускной способности.
4. Для масштабирования вывода (inference) записывайте промежуточные события в Kinesis Data Streams (по одному на шард на регион) для высокопроизводительных потребителей и включите потребителей с расширенной параллельной обработкой (enhanced fan-out, SubscribeToShard) для выделенных парков ML-воркеров; для масштабирования отслеживайте IteratorAgeMilliseconds и используйте UpdateShardCount.

Обоснование: Использование SQS FIFO гарантирует порядок для каждого игрока и дедупликацию на входе, идемпотентные записи в БД обеспечивают семантику «ровно один раз» (exactly-once), а Kinesis с enhanced fan-out или Step Functions позволяют обрабатывать пиковую, высокопроизводительную ML-нагрузку, сохраняя потребителей слабосвязанными и масштабируемыми.

← Базы данных и кеширование (RDS · Все домены

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

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