Фильтрация сообщений SQS и интеграция SNS + SQS

В архитектуре широковещательной рассылки без фильтрации каждый подписчик SQS получает каждое сообщение SNS. Если в Вашей теме публикуются события заказов для 10 разных категорий товаров, а подписчик обрабатывает только заказы электроники, он всё равно получает сообщения о продуктах питания и одежде и вынужден их отбрасывать. Это приводит к неэффективному использованию вычислительных ресурсов, увеличивает затраты и создаёт ненужную нагрузку на потребителей. Политики фильтрации подписок SNS решают эту проблему, позволяя самому SNS направлять сообщения только подходящим подписчикам.

Политика фильтрации — это объект JSON, применяемый к подписке SQS или Lambda. SNS проверяет каждое сообщение на соответствие политике по его атрибутам сообщения перед доставкой. Если атрибуты сообщения соответствуют политике фильтрации, сообщение доставляется; в противном случае SNS молча пропускает этого подписчика. Политики фильтрации поддерживают сопоставление строк, числовые диапазоны, сопоставление по префиксу и оператор exists для проверки наличия или отсутствия атрибута.

По умолчанию политики фильтрации сопоставляются с атрибутами сообщения (метаданными). Начиная с 2023 года SNS также поддерживает фильтрацию по полезной нагрузке (телу) с помощью указания области действия политики фильтрации MessageBody. Это позволяет выполнять фильтрацию непосредственно по телу сообщения на основе пути JSON, не требуя от издателей добавлять атрибуты. Фильтрация по телу более гибкая, но требует, чтобы тело сообщения было корректным JSON. Всегда проверяйте, какая область действия соответствует формату данных, выдаваемых издателем.

Политики фильтрации поддерживают несколько операторов сопоставления, помимо простого равенства строк:

• Числовое значение: {"numeric": ["=", 100]}, {"numeric": [">", 50, "<=", 200]}
• Префикс: {"prefix": "order-"} соответствует любой строке, начинающейся с этого префикса
• Исключение значений: {"anything-but": ["CANCELLED"]} соответствует любому значению, кроме перечисленных
• Наличие: {"exists": true} соответствует сообщению, если атрибут присутствует; значение false — если он отсутствует

Чтобы фильтрация работала, издатель должен включать атрибуты сообщения при публикации в SNS. Атрибуты представляют собой пары «ключ—значение» с типом данных (String, Number, Binary). Издателю не нужно знать, какие политики фильтрации настроены у подписчиков: он лишь дополняет сообщение атрибутами, описывающими событие. SNS автоматически выполняет маршрутизацию. Благодаря этому издатели полностью отделены от логики, специфичной для подписчиков.

Сложная топология широковещательной рассылки может предусматривать маршрутизацию SNS в очереди SQS с несколькими уровнями специфичности: одна очередь получает все заказы (без фильтра) для аудита, другая — только заказы HIGH_VALUE (сумма >= 1000) для проверки мошенничества, а третья — только заказы ELECTRONICS для склада электроники. У каждой очереди SQS есть собственный потребитель Lambda. Этот шаблон позволяет независимо масштабировать каждый уровень обработки и добавлять новых потребителей, не затрагивая существующих потребителей или издателя.

SNS может доставлять сообщения в очереди SQS, находящиеся в другом аккаунте AWS. Политика ресурсов очереди SQS должна разрешать субъекту-службе SNS вызывать sqs:SendMessage из SNS-темы публикующего аккаунта, указанной в ARN. Это позволяет централизованно публиковать события (один аккаунт публикует, а несколько команд аккаунтов подписываются), не передавая учётные данные. Широковещательная рассылка между аккаунтами — распространённый шаблон в конфигурациях AWS Organizations с несколькими аккаунтами.

При резком увеличении объёма событий прямые вызовы SNS→Lambda немедленно масштабируют Lambda, что может перегрузить расположенные ниже по потоку базы данных или API. Добавление SQS между SNS и Lambda создаёт буфер: SNS доставляет сообщения в SQS, а Lambda опрашивает SQS с заданным размером пакета. Это позволяет Lambda обрабатывать сообщения с устойчивой скоростью, пока SQS поглощает всплески трафика. Глубина очереди служит механизмом обратного давления: Вы можете отслеживать её и настроить оповещение, когда она превысит порог, указывающий на отставание потребителя.

SNS → Lambda (напрямую): минимальная задержка, отсутствие буферизации, Lambda масштабируется немедленно. Оптимальный вариант для оповещений в реальном времени или срочных уведомлений, когда важна задержка менее секунды. SNS → SQS → Lambda: добавляет поддержку DLQ, управляемую пропускную способность, повторные попытки с тайм-аутом видимости и мониторинг глубины очереди. Оптимальный вариант для обработки транзакций, обновления запасов и любых сценариев, где необходимо соблюдать ограничения расположенных ниже по потоку систем. В экзаменационных вопросах выбирайте буферизацию SQS, если упоминаются надёжность хранения и управление скоростью обработки.

Используйте редактор политик фильтрации в консоли SNS, чтобы проверить, будет ли пример сообщения соответствовать Вашей политике фильтрации, прежде чем развёртывать её. Вы также можете использовать песочницу SNS для имитации доставки сообщений и проверки маршрутизации. В коде проверяйте политики фильтрации, публикуя тестовые сообщения с известными атрибутами и просматривая метрики CloudWatch для каждой подписки: метрика NumberOfMessagesFiltered показывает, сколько сообщений было заблокировано фильтром, помогая настраивать политики без ожидания событий в рабочей среде.

Полная интеграция SNS + SQS выглядит следующим образом: (1) приложение публикует событие в стандартную тему SNS с атрибутами сообщения; (2) SNS оценивает политику фильтрации каждой подписки и доставляет только подходящие сообщения в соответствующую очередь SQS; (3) Lambda опрашивает каждую очередь SQS с настроенным размером пакета и обрабатывает сообщения; (4) после достижения значения maxReceiveCount сообщения с ошибками попадают в DLQ; (5) тревога CloudWatch, отслеживающая глубину DLQ, уведомляет команду. Этот полностью развязанный и отказоустойчивый шаблон представляет собой эталонную архитектуру SAA-C03.

Проверьте своё понимание концепций AWS Solutions Architect (SAA-C03), рассмотренных в этом уроке.

В этом уроке Вы узнали, что политики фильтрации SNS маршрутизируют сообщения на уровне SNS на основе атрибутов сообщения или содержимого его тела, устраняя ненужную обработку у последующих потребителей; шаблон SNS→SQS→Lambda добавляет надёжную буферизацию и управление скоростью между широковещательной рассылкой и обработкой; а доставка SQS между аккаунтами обеспечивает централизованную архитектуру pub/sub в средах с несколькими аккаунтами с помощью политик ресурсов очередей. Далее мы рассмотрим REST-, HTTP- и WebSocket API Amazon API Gateway.