Amazon SOA-C02: Бессерверные вычисления и интеграция приложений — Руководство по подготовке
Часть AWS SysOps Administrator Associate SOA-C02 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Amazon, или пройдите тесты на время на ExamRoll.io.
Бессерверные вычисления и интеграция приложений охватывают запуск событийно-ориентированных приложений без управления серверами и надежное соединение сервисов. Операционная важность заключается в управлении масштабированием, задержками, режимами отказа и доступом по принципу наименьших привилегий при сохранении предсказуемости затрат. Эта область сфокусирована на поведении Lambda (холодные старты, одновременное выполнение), надежной доставке событий (EventBridge, SNS, SQS), контроле безопасности (роли выполнения и разрешения) и наблюдаемости для асинхронных потоков.
Операционные аспекты и одновременное выполнение AWS Lambda
Производительность и доступность Lambda зависят от холодных стартов, лимитов одновременного выполнения и контроля троттлинга. Холодные старты происходят, когда Lambda необходимо инициализировать новую среду выполнения; уменьшайте их влияние, используя подготовленное одновременное выполнение (provisioned concurrency) (
undefined
) для критичных к задержкам путей, и отдавайте предпочтение более легким средам выполнения или меньшему объему инициализационной работы. Резервируйте и ограничивайте одновременное выполнение с помощью зарезервированного одновременного выполнения (reserved concurrency) (
undefined
), чтобы защитить последующие сервисы и применять квоты для каждой функции; отслеживайте метрики CloudWatch ConcurrentExecutions и Throttles.
Модели повторных попыток и вызовов различаются в зависимости от режима: синхронные вызовы (API Gateway, прямой вызов Invoke) немедленно возвращают ошибки; асинхронные вызовы (EventBridge, SNS, асинхронные уведомления S3) используют политику асинхронных повторов Lambda (две повторные попытки с экспоненциальной задержкой) и могут использовать DLQ или назначения (destinations). Для сопоставлений с источниками событий (SQS, Kinesis, потоки DynamoDB) опрашивающий компонент Lambda (poller) повторяет попытки до тех пор, пока сообщение не истечет или политика повторной отправки источника событий не инициирует перемещение в очередь недоставленных сообщений. Настраивайте тайм-аут и память консервативно (
undefined
) и устанавливайте тайм-аут видимости SQS больше тайм-аута функции (рекомендуется visibility >= function timeout * 2), чтобы уменьшить количество дублирующихся обработок.
Событийно-ориентированные архитектуры с EventBridge
EventBridge предоставляет управляемую шину событий с гибкой маршрутизацией, реестром схем, доставкой между аккаунтами и настройками повторных попыток/DLQ. Используйте пользовательские шины событий для разделения доменов и партнерские шины событий для интеграции с SaaS; создавайте правила с шаблонами (patterns) (
undefined
) и присоединяйте цели с конфигурацией очереди недоставленных сообщений и повторных попыток (JSON для targets поддерживает DeadLetterConfig и RetryPolicy). Используйте реестр схем для обнаружения и принудительного применения форматов событий; регистрируйте схемы, когда производители событий четко определены, и используйте Code Bindings для генерации типизированных моделей, где это полезно.
Выбирайте EventBridge, когда вам необходимо:
- Сложная маршрутизация и фильтрация с помощью многофункциональных шаблонов событий или изоляция между аккаунтами/шинами событий
- Нативная поддержка множества целей (Lambda, Step Functions, Kinesis, SQS, SNS)
- Обнаружение схем и управление ими между командами
Выбирайте прямое использование SNS/SQS, когда вам нужна более простая веерная рассылка или гарантированная семантика очереди:
- SNS для веерной рассылки многим подписчикам и семантики push-доставки
- SQS для надежной обработки на основе извлечения (pull) с тайм-аутом видимости и политиками повторной отправки
Обмен сообщениями с помощью SNS и SQS (DLQ, тайм-аут видимости)
SNS — это push-сервис типа «издатель-подписчик» (pub/sub); SQS — это надежная очередь с семантикой извлечения (pull). Для высоконадежной обработки предпочитайте паттерн SNS -> SQS -> Lambda, чтобы отделить прием данных от их обработки и получить контроль над повторными попытками и видимостью. Настройте политику повторной отправки (redrive policy) SQS (
undefined
), чтобы перемещать сообщения в DLQ после достижения maxReceiveCount, и убедитесь, что тайм-аут видимости достаточно велик, чтобы избежать преждевременной повторной доставки (рекомендуется visibility >= function timeout * 2). Для задач, требующих соблюдения порядка (FIFO), используйте SQS FIFO или SNS FIFO с идентификаторами групп сообщений (message group ID) для сохранения порядка и идентификаторами дедупликации (deduplication ID) для избежания дубликатов.
Варианты обработки недоставленных сообщений и где их использовать:
- Асинхронные вызовы Lambda: настройте
DeadLetterConfigили Destinations (AsyncEventInvokeConfig), чтобы отправлять сбои в SQS/SNS или вызывать другую Lambda-функцию. - SQS: настройте политику повторной отправки (redrive policy) в SQS DLQ для «отравленных» сообщений и установите соответствующее значение
maxReceiveCount. - EventBridge: установите
DeadLetterConfigиRetryPolicyдля целей правила, чтобы перехватывать недоставляемые события.
Идемпотентность крайне важна: реализуйте идемпотентные обработчики, используя условные записи в DynamoDB (PutItem с ConditionExpression attribute_not_exists(pk)), токены идемпотентности, хранящиеся с TTL, или дедупликацию SQS FIFO для семантики «ровно один раз» (exactly-once).
Разрешения функций, роли и принцип наименьших привилегий
Применяйте принцип наименьших привилегий к ролям выполнения Lambda и политикам ресурсов функций. Начните с AWSLambdaBasicExecutionRole для логов CloudWatch, затем предоставьте явные ARN ресурсов для сервисов (например, dynamodb:PutItem для arn:aws:dynamodb:region:acct:table/MyTable). Избегайте подстановочных знаков, таких как Resource: "*", когда возможно указать конкретные ARN. Используйте управляемые или пользовательские политики, ограниченные по действию и ресурсу, и включайте условия (aws:SourceAccount, aws:SourceArn) при добавлении разрешений на вызов для сервисов:
- Добавление разрешения на вызов для EventBridge:
undefined
- Для SNS: используйте условие
source-arn, чтобы ограничить, какой топик может вызывать функцию
Критерии принятия решений:
- Используйте политики на основе ресурсов функции, чтобы разрешить вызовы от сервисов (EventBridge, SNS, CloudWatch Events)
- Используйте роль выполнения IAM для разрешений во время выполнения (DynamoDB, S3, Secrets Manager)
- Отдавайте предпочтение разрешениям на уровне ресурсов и условным ограничениям, чтобы уменьшить радиус поражения (blast radius)
Наблюдаемость и диагностика проблем в бессерверных приложениях
Наблюдаемость должна охватывать метрики, логи, трассировки и статус асинхронной доставки. Ключевые метрики CloudWatch: Invocations, Duration, Errors, Throttles, ConcurrentExecutions, IteratorAge (для триггеров от потоков и SQS). Для отслеживания сбоев асинхронных вызовов отслеживайте метрики “AsyncEventInvoke” и настраивайте оповещения CloudWatch Alarms для DeadLetterErrors и Throttles. Включите трассировку X-Ray (
undefined
), чтобы получать сквозные трассировки по всем сервисам и визуализировать холодные старты, задержки в нижестоящих сервисах и исключения.
Используйте структурированные JSON-логи и запросы CloudWatch Logs Insights для быстрого поиска шаблонов ошибок; реализуйте проверки на идемпотентность и записывайте в логи идентификаторы корреляции. Для распределенной трассировки явно передавайте идентификаторы трассировки в полезной нагрузке событий для потоков EventBridge/SNS, если автоматический контекст теряется. Для сопоставлений источников событий SQS отслеживайте метрику ApproximateAgeOfOldestMessage и настраивайте оповещения на ее рост, что указывает на обратное давление или троттлинг. Собирайте метрику Lambda Throttles и оповещайте о ней, а также отслеживайте компромисс между использованием подготовленной конкурентности и затратами.
Распространенные ошибки и критерии принятия решений
- Отсутствие настройки DLQ или использование только стандартных повторных попыток: настраивайте DLQ или Destinations для асинхронных Lambda и политику перенаправления (redrive) для очередей SQS, чтобы собирать «отравленные» сообщения для ручного анализа.
- Неверный тайм-аут видимости в SQS, приводящий к повторной обработке: установите тайм-аут видимости >= таймаута функции * 2 и учитывайте повторные попытки и вызовы нижестоящих сервисов, чтобы избежать дубликатов.
- Избыточно разрешающие роли выполнения Lambda: избегайте
Resource: "*"и добавляйте условия по сервису/источнику (aws:SourceArn,aws:SourceAccount) в политики вызова и политики ресурсов. - Игнорирование лимитов конкурентности, вызывающее троттлинг: используйте зарезервированную конкурентность для ограничения функций, подготовленную конкурентность для чувствительных к задержкам функций и отслеживайте ConcurrentExecutions/Throttles.
- Отсутствие трассировки через асинхронные границы: добавляйте идентификаторы корреляции в события и включайте X-Ray или передавайте заголовки трассировки для восстановления потоков выполнения.
- Неправильное использование прямой интеграции SNS с Lambda для задач, требующих надежности: предпочитайте схему SNS->SQS->Lambda, когда вам нужна надежная буферизация, контроль видимости и более простое управление DLQ.
Практическая задача: Сценарий использования
Компания AcmePayments получает большой объем событий платежей через EventBridge и сталкивается с периодическим троттлингом Lambda и дублирующейся обработкой во время пиковых нагрузок. Им необходима надежная обработка, отсутствие потерь данных и ограниченная нагрузка на нижестоящий сервис DynamoDB.
- Создайте пользовательскую шину событий EventBridge и правило для отбора событий платежей; добавьте очередь SQS FIFO в качестве надежной цели с
DeadLetterConfigиRetryPolicyв конфигурации цели. - Настройте Lambda на опрос очереди SQS (через сопоставление источника событий) с размером пакета, настроенным в соответствии с пропускной способностью нижестоящего сервиса, и тайм-аутом видимости, установленным в >= таймаута функции * 2.
- Зарезервируйте конкурентность для Lambda (
undefined
), чтобы ограничить всплески записи в DynamoDB; реализуйте подготовленную конкурентность для небольшого пула, если требуется низкая задержка. 4. Реализуйте идемпотентность с помощью условных операций записи в DynamoDB по ключу payment-id и сохраняйте записи об идемпотентности с TTL для их последующей очистки. 5. Включите трассировку X-Ray и структурированные логи с идентификатором корреляции в событии для отслеживания обработки; настройте оповещения CloudWatch для метрик ApproximateAgeOfOldestMessage, Throttles и метрик DLQ.
Обоснование: Разделение EventBridge и SQS обеспечивает надежную буферизацию и семантику повторных попыток; зарезервированная конкурентность защищает нижестоящий сервис DynamoDB от всплесков нагрузки, идемпотентность предотвращает дублирование, а трассировка и оповещения обеспечивают операционную видимость режимов сбоя.
← Базы данных и кэширование · Все домены · Управление затратами и тегирование ресурсов →
Отработать эти вопросы → · Тесты на время на ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Сдайте экзамен →