Amazon SAA-C03: Интеграция приложений, обмен сообщениями и стриминг — Руководство по подготовке

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

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

Amazon SQS: Разделение компонентов, порядок и семантика доставки

Amazon SQS — это полностью управляемая очередь сообщений, работающая по модели извлечения (pull-based), чья основная архитектурная роль — разделение (decoupling) производителей и потребителей. Цепочка синхронных вызовов связывает задержку и доступность производителя с каждой последующей зависимостью; добавление очереди SQS преобразует это в асинхронную передачу. Производители помещают сообщения в очередь с той скоростью, с которой поступает трафик, а потребители извлекают их с той скоростью, с которой могут безопасно их обработать. Это каноническое решение для всплесков записи, которые в противном случае перегрузили бы экземпляр RDS — очередь поглощает всплеск, а ограниченный парк потребителей обрабатывает его с контролируемой параллельностью, удерживая количество подключений к базе данных в рамках нормы.

Существует два типа очередей, и выбор определяет как пропускную способность, так и гарантии доставки.

Стандартные очереди доставляют сообщения как минимум один раз с негарантированным порядком (best-effort). Дубликаты могут появляться, когда потребитель не успевает удалить сообщение до истечения тайм-аута видимости, или когда распределенный бэкенд повторно отправляет сообщение между своими шардами. Даже если вы никогда не видели дубликатов при тестировании, сервис архитектурно допускает повторную доставку, особенно во время отказа брокера. Предположение, что стандартные очереди «обычно» доставляют сообщение один раз — это дефект проектирования, а не операционный риск: при масштабировании дубликаты гарантированно появятся. Поэтому логика потребителя должна быть идемпотентной: отслеживать MessageId или бизнес-ключ в DynamoDB с условной записью, использовать ключ идемпотентности в последующих вызовах API или полагаться на семантику upsert.

Очереди FIFO обеспечивают строгий порядок в рамках MessageGroupId и обработку строго один раз с помощью MessageDeduplicationId (либо явного, либо SHA-256 от тела сообщения), который подавляет дубликаты в течение 5-минутного окна. MessageGroupId — это ключевая концепция: все сообщения с одинаковым ID группы доставляются строго по порядку одному потребителю за раз, в то время как сообщения с разными ID групп могут обрабатываться параллельно. Для системы обработки заказов, где события каждого клиента должны быть последовательными, но разные клиенты независимы, используйте MessageGroupId = customerId. Использование одного ID группы для всего сериализует всю рабочую нагрузку и уничтожает пропускную способность. ID дедупликации — это правильный примитив для предотвращения создания дублирующихся заказов, когда пользователь повторно отправляет зависшую форму оплаты: клиент генерирует детерминированный токен идемпотентности (UUID, привязанный к сессии оплаты), и SQS отбрасывает любые дублирующие отправки, поступившие в пределах окна.

PaymentsQueue:
  Type: AWS::SQS::Queue
  Properties:
    QueueName: payments.fifo
    FifoQueue: true
    ContentBasedDeduplication: true
    DeduplicationScope: messageGroup
    FifoThroughputLimit: perMessageGroupId
    VisibilityTimeout: 60
    RedrivePolicy:
      deadLetterTargetArn: !GetAtt PaymentsDLQ.Arn
      maxReceiveCount: 5

Выбор стандартной очереди, когда в требованиях указан «порядок» или «отсутствие дубликатов» — это классическая ошибка. Никакая логика на уровне приложения не сможет восстановить порядок, который очередь никогда не сохраняла, потому что сообщения от разных хостов бэкенда приходят вперемешку. Выбирайте FIFO всегда, когда рабочая нагрузка требует упорядочивания (журналы транзакций, переходы конечного автомата) или семантики «строго один раз» (списание платежей, уменьшение складских запасов).

Тайм-аут видимости, «отравленные» сообщения и лимиты полезной нагрузки

Когда потребитель получает сообщение, SQS делает его невидимым для других потребителей на время тайм-аута видимости (по умолчанию 30 секунд, максимум 12 часов). Если потребитель удаляет сообщение до истечения тайм-аута, оно исчезает; если нет — из-за сбоя потребителя или слишком долгой обработки — сообщение снова становится видимым и доставляется повторно. Установка тайм-аута видимости меньше, чем фактическое время обработки — одна из главных причин дублирующей обработки: Lambda, работающая 45 секунд с очередью, у которой тайм-аут по умолчанию 30 секунд, будет обрабатывать каждое сообщение как минимум дважды. Устанавливайте тайм-аут как минимум на уровне p99 времени обработки (рекомендация AWS для очередей, управляемых Lambda, — устанавливать его как минимум в 6 раз больше тайм-аута функции), а для задач непредсказуемой длительности продлевайте тайм-аут динамически:

sqs.change_message_visibility(
    QueueUrl=queue_url,
    ReceiptHandle=handle,
    VisibilityTimeout=300  # extend by 5 minutes
)

Очереди недоставленных сообщений (DLQ) собирают «отравленные» сообщения (poison-pill messages). RedrivePolicy в исходной очереди определяет maxReceiveCount (обычно 3–5); после превышения этого значения SQS перемещает сообщение в DLQ для офлайн-анализа. Тип DLQ должен соответствовать типу исходной очереди (FIFO ↔ FIFO). Без DLQ некорректно сформированные сообщения зацикливаются бесконечно, и в очередях FIFO это особенно вредно — порядок доставки не позволяет доставлять последующие сообщения в той же группе, пока не будет обработано проблемное, поэтому одно плохое сообщение останавливает всю группу.

Сообщения SQS ограничены размером 256 КБ. Для более крупных полезных нагрузок — например, для задачи, передающей отрендеренный документ — используйте SQS Extended Client Library, которая записывает полезную нагрузку в S3, а в очередь помещает только ссылку на бакет и ключ. Клиентская библиотека прозрачно извлекает данные при получении сообщения. Не разделяйте полезную нагрузку на несколько сообщений (вы потеряете атомарность и порядок) и не пытайтесь закодировать 2 МБ данных в base64 в надежде, что они поместятся.

Масштабирование на основе очереди

Для группы потребителей на EC2 или ECS, работающих с очередью SQS, правильным сигналом для масштабирования является не CPU, а бэклог очереди. CPU отстает от скорости поступления сообщений и неверно интерпретирует полностью загруженного потребителя как «занятого, но справляющегося». Канонической метрикой для масштабирования является ApproximateNumberOfMessagesVisible, но масштабирование напрямую по необработанной глубине очереди является грубым. Рекомендуемый подход — это пользовательская метрика бэклога на экземпляр (backlog-per-instance):

backlogPerInstance = ApproximateNumberOfMessagesVisible / RunningInstances

Опубликуйте ее в CloudWatch и используйте для политики отслеживания цели (target-tracking policy) в Auto Scaling group или сервисе ECS, чтобы каждый воркер поддерживал ограниченный бэклог (например, 10 сообщений). Это обеспечивает плавное горизонтальное масштабирование во время всплесков и предотвращает колебания, когда глубина очереди мала, но потребители уже насыщены. Для обратного масштабирования (scale-in) используйте ее в паре с ApproximateAgeOfOldestMessage, чтобы не удалять мощности, пока в очереди остаются старые сообщения.

Amazon SNS: Веерная рассылка (Fan-Out), фильтрация и межаккаунтная доставка

SNS — это сервис публикации/подписки (publish/subscribe), работающий по принципу push. Издатели (publishers) отправляют сообщения в топик; SNS доставляет их каждой подписке: очередям SQS, функциям Lambda, эндпоинтам HTTP(S), по email, SMS, в Kinesis Data Firehose или в виде мобильных push-уведомлений. Основной паттерн для обеспечения надежности — веерная рассылка из SNS в SQS (fan-out): один топик с несколькими подписанными на него очередями SQS. Таким образом, каждый нижестоящий сервис получает собственный надежный буфер, политику повторных попыток и очередь DLQ, в то время как издатель знает только о топике. Если сервис-потребитель отключается на несколько часов, его очередь накапливает сообщения и обрабатывает их после восстановления — сам по себе SNS не имеет такой буферизации и исчерпает свою политику повторов.

Producer ──▶ SNS topic ──┬──▶ SQS Queue A ──▶ Service A
                         ├──▶ SQS Queue B ──▶ Service B
                         └──▶ SQS Queue C ──▶ Service C

Фильтрация сообщений позволяет каждой подписке объявить политику фильтрации в формате JSON, чтобы SNS доставлял только соответствующие сообщения. Это позволяет избежать антипаттерна, когда каждый потребитель получает все сообщения и фильтрует их на своей стороне:

{
  "eventType": ["order_placed", "order_cancelled"],
  "region": ["us-east-1", "us-west-2"]
}

Важны два аспекта поведения. Во-первых, стандартные топики SNS не гарантируют порядок сообщений — таймеры повторных попыток для каждого подписчика и независимые сетевые пути делают изменение порядка обычным явлением. Если порядок важен, используйте FIFO-топик SNS, на который подписаны FIFO-очереди SQS; идентификатор группы сообщений (message group ID) передается сквозным образом. В противном случае подписчики должны быть идемпотентными и устойчивыми к изменению порядка. Во-вторых, подписки HTTP(S) повторяют доставку в соответствии с политикой доставки (по умолчанию: три немедленных повтора, затем экспоненциальная задержка (exponential backoff) до одного часа, после чего сообщение отбрасывается). Подписчики должны отвечать кодом 2xx в течение 15 секунд, проверять подпись x-amz-sns-message-type и — для ненадежных эндпоинтов — всегда иметь DLQ для SNS (с перенаправлением в SQS), чтобы недоставленные сообщения захватывались, а не молча отбрасывались.

Межаккаунтный вызов — частая ловушка. Когда аккаунт A публикует сообщение в топик, который рассылает его в Lambda-функцию в аккаунте B, требуются две политики: политика топика SNS (или направление подписки) должна разрешать подписку, а ресурсная политика Lambda должна разрешать lambda:InvokeFunction от sns.amazonaws.com с условием SourceArn, соответствующим топику. Отсутствие ресурсной политики Lambda — самая распространенная причина сбоя: подписка выглядит исправной, но вызовы отклоняются с ошибкой 403. Если топик зашифрован с помощью ключа KMS, управляемого клиентом, политика ключа также должна предоставлять права kms:Decrypt и kms:GenerateDataKey принципалу-издателю и сервису sns.amazonaws.com.

{
  "Effect": "Allow",
  "Principal": {"Service": "sns.amazonaws.com"},
  "Action": "lambda:InvokeFunction",
  "Resource": "arn:aws:lambda:us-east-1:222222222222:function:ProcessOrder",
  "Condition": {"ArnLike": {"AWS:SourceArn": "arn:aws:sns:us-east-1:111111111111:orders"}}
}

Amazon EventBridge: Маршрутизируемые шины событий

EventBridge (ранее CloudWatch Events) расширяет модель pub/sub, добавляя маршрутизацию на основе содержимого, обнаружение схем, источники событий от SaaS-партнеров и архивацию/повтор. События проходят через шины событий (по умолчанию, пользовательские или партнерские) и сопоставляются с правилами, шаблоны событий которых фильтруют по структуре JSON. Правила могут преобразовывать полезную нагрузку с помощью путей ввода и шаблонов ввода, прикреплять цели для недоставленных сообщений (dead-letter targets) и доставлять их более чем 20 нативным целям, включая Lambda, Step Functions, задачи ECS, SQS, SNS, Kinesis и API destinations.

{
  "source": ["com.acme.orders"],
  "detail-type": ["OrderPlaced"],
  "detail": {"amount": [{"numeric": [">", 500]}]}
}

Отличие от SNS носит архитектурный характер. SNS оптимизирован для высокопроизводительной широковещательной рассылки гомогенным подписчикам с простой фильтрацией по атрибутам и меньшей задержкой. EventBridge оптимизирован для гетерогенных событийно-ориентированных архитектур: множество производителей генерируют события с разными схемами, а потребители подписываются по шаблону, а не на топик. Для монолита, который разлагается на микросервисы — особенно когда среди производителей есть SaaS-партнеры или сервисы AWS (Config, GuardDuty, CodePipeline, CloudTrail), которые нативно генерируют события — EventBridge обычно является правильным выбором. Для веерной рассылки с чрезвычайно большим объемом и низкой задержкой идентичным подписчикам SNS по-прежнему выигрывает, поскольку у EventBridge немного выше задержка на одно событие и ниже предел пропускной способности по умолчанию.

Amazon MQ: Брокер сообщений для существующих протоколов

Amazon MQ — это управляемый брокер, работающий на базе ActiveMQ или RabbitMQ. Он предназначен для миграции локальных (on-premises) рабочих нагрузок, которые зависят от AMQP 0-9-1, AMQP 1.0, MQTT, STOMP, OpenWire или JMS, без переписывания приложения. Если платежная система использует сторонний JMS-брокер с транзакционной семантикой “ровно один раз” (exactly-once), перенос ее в Amazon MQ сохраняет протокол передачи и гарантии доставки, устраняя при этом необходимость в управлении инфраструктурой. Выбирайте SQS/SNS/EventBridge для новых проектов, изначально создаваемых на AWS (greenfield); выбирайте Amazon MQ только тогда, когда ограничением является совместимость протоколов.

Kinesis Data Streams

Kinesis Data Streams (KDS) — это надежный, упорядоченный, партиционированный лог для высокопроизводительного потокового приема данных, таких как потоки кликов (clickstreams), телеметрия IoT, агрегация логов. Записи помещаются в шарды (shards) по PartitionKey; порядок гарантируется внутри шарда, но не во всем потоке. Каждый шард поддерживает запись со скоростью 1 МБ/с или 1000 записей/с и чтение со скоростью 2 МБ/с (или выше с Enhanced Fan-Out). Записи хранятся 24 часа по умолчанию, с возможностью продления до 365 дней, поэтому несколько независимых потребителей могут повторно прочитать одну и ту же историю — то, чего не может сделать SQS, поскольку SQS удаляет сообщения после подтверждения (ack).

Режим On-demand избавляет от необходимости расчетов шардов, автоматически масштабируясь до 200 МиБ/с на запись на поток, что идеально для непредсказуемого трафика. Режим Provisioned дешевле при стабильной нагрузке, когда требуемая емкость известна.

Выбирайте KDS вместо SQS FIFO, когда рабочая нагрузка требует упорядоченного, воспроизводимого приема данных с пропускной способностью, которую FIFO не может обеспечить (предел FIFO значительно ниже миллионов записей в секунду, которые обрабатывает KDS), когда несколько независимых потребителей должны читать один и тот же поток, или когда в требованиях встречается формулировка «сохранять исходный порядок на протяжении всей обработки» в сочетании с большим объемом данных.

Kinesis Data Firehose

Kinesis Data Firehose — это полностью управляемый сервис доставки. Он считывает данные из потока Kinesis или напрямую через PUT, буферизует их по размеру (1–128 МБ) или по времени (60–900 секунд, в зависимости от того, какой лимит будет достигнут первым), опционально вызывает Lambda для преобразования каждой записи (удаление персональных данных (PII), нормализация формата), может на лету конвертировать JSON в Parquet или ORC, используя схему Glue, шифрует данные с помощью KMS и доставляет их в S3, Redshift, OpenSearch или Splunk. В нём нет шардов, не нужно запускать потребителей, а оплата производится за гигабайт.

Канонический паттерн для масштабируемого приёма данных в озеро данных объединяет Data Streams (в режиме on-demand) в качестве надёжного буфера и Firehose для доставки в S3:

Producers → Kinesis Data Streams (on-demand) → Firehose (60s buffer, Parquet) → S3 → Athena/Glue

Для приёма миллионов событий от мобильных устройств, их шифрования и сохранения в S3 в формате Parquet правильным решением будет Firehose с конвертацией в Parquet и ключом KMS, а не KDS с кастомным потребителем и самописным модулем для записи в Parquet, что требует значительно больше кода и инфраструктуры. Firehose работает в режиме, близком к реальному времени, и не поддерживает повторное чтение данных потребителем (replay); когда повторное чтение необходимо, следует оставить KDS в архитектуре.

Kinesis Data Analytics (теперь Managed Service for Apache Flink) выполняет задания SQL или Flink для потока данных для оконных агрегаций.

Интеграция с Lambda и семантика повторных попыток

Lambda интегрируется с этими сервисами, демонстрируя существенно различное поведение при повторных попытках:

Для SQS устанавливайте тайм-аут Lambda-функции меньше или равным тайм-ауту видимости очереди, а тайм-аут видимости — как минимум в 6 раз больше тайм-аута функции. Для Kinesis включите BisectBatchOnFunctionError и настройте место назначения OnFailure (SQS или SNS), чтобы одна «отравленная» запись не блокировала весь шард на неопределённое время.

Таблица для принятия решений по выбору сервиса

← Аналитика · Все домены · Безопасность →

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

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