Привет, Хабр! Сегодня поговорим о принципах асинхронной работы с сообщениями и их очередями в распределенной и бессерверной архитектуре. У Amazon для этого есть веб-сервисы Simple Notification Service (SNS) и Simple Queue Service (SQS): они позволяют обмениваться сообщениями между микросервисами. В этой статье разберём, чем они отличаются, что могут и какие есть ещё предложения на этом рынке.

Сообщения в Amazon

В общей сложности у Amazon есть шесть разных вариантов асинхронного обмена данными. Но сегодня мы поговорим лишь о двух из них, предназначенных для обмена независимыми сообщениями: Simple Notification Service (SNS) и Simple Queue Service (SQS). Эти сервисы закрывают два наиболее популярных сценария передачи. В слабо связанной архитектуре можно выбрать один из этих подходов или использовать их сочетание — в зависимости от поставленной задачи.

Что такое SNS

Amazon Simple Notification Service (SNS) — асинхронный обмен сообщений между приложениями или приложениями и пользователями. Обмен реализован по модели pub-sub («издатель-подписчик»), в рамках которой получатели «подписываются» на тему (топик), а издатель публикует в эту тему сообщения. Так темы разделяют сообщения по каналам отправки. Считывать их может множество получателей.

SNS предназначен для обмена сообщениями в масштабных распределённых системах:

• для параллельной обработки данных на большом количестве агентов,

• для отправки конечным пользователям писем по электронной почте, SMS-сообщений и Push-уведомлений в мобильные приложения;

• для рассылки уведомлений о событиях, когда одни и те же сообщения должны попасть в несколько приложений (для систем мониторинга);

• для обновления записей в бизнес-системах.

Пропускная способность Amazon SNS практически не ограничена, поэтому оптимально использовать его там, где важен масштаб обмена. Однако SNS со стандартными топиками не гарантирует сохранение последовательности сообщений и отсутствие дупликации (сообщение доставляется как минимум один раз примерно в нужном порядке).

Кроме того, SNS не регулирует частоту доставки получателю. Если конечный сервис недоступен, SNS повторяет отправку в соответствии с прописанной политикой. Это значит, что если получатель какое-то время был недоступен, впоследствии он может быть завален повторными сообщениями (если не принимать дополнительных архитектурных решений). Избежать этого помогает правильная настройка dead-letter queue (DLQ). Туда сообщение отправляется, если после всех повторений оно так ни разу и не доставлено.

Что такое SQS

Amazon Simple Queue Service (SQS) — это распределенная очередь сообщений для обмена между приложениями. SQS работает по модели put-take, в рамках которой есть только один получатель. Если SNS доставляет максимально быстро, то SQS дожидается получения одного сообщения, прежде чем отправить следующее. При этом не требуется, чтобы отправитель и получатель одновременно были в сети.

У Amazon реализовано два типа очередей: стандартная (best-effort) и FIFO (first in — first out), используемые в зависимости от бизнес-логики.

В первом случае доставка осуществляется в любом порядке хотя бы один раз. Обеспечивается наилучшее из возможного упорядочивание, но копии сообщения могут прийти вне очереди.

Во втором сообщения доставляются строго один раз и в порядке отправки. 

Этот тип очереди работает с меньшей пропускной способностью — не более 300 транзакций в секунду на одно API. Стандартные очереди при этом, как и SNS, практически не имеют ограничений на количество отправляемых сообщений.

Осенью 2020 года Amazon ввёл и топики FIFO для SNS. Их логика работы аналогична, за исключением того, что сообщения доставляется в предопределенном порядке всем подписчикам. Ограничения действуют те же: 300 сообщений в секунду.

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

Как и в SNS, в SQS предусмотрен механизм DQL. Условия, при которых недоставленное сообщение отправляется в эту очередь, настраиваются. В случае FIFO-очереди правильные настройки переноса в DQL помогают не заблокировать обмен данными одним недоставленным сообщением.

Одним из источников сообщений для SQS может быть SNS. Такой кейс используется для асинхронной отправки многим компонентам системы. Сочетание SNS и SQS обеспечивает и масштаб, и контроль частоты доставки. Его оптимально применить в кейсе мобильного устройства с плохим интернетом, поскольку такая архитектура как раз решает проблему перегрузки устройства сообщениями после появления в сети.

Про практические применения SNS и SQS можно почитать тут:

• Kafka, RabbitMQ или AWS SNS/SQS: какой брокер выбрать?

• AWS: Итеграция SNS + SQS

• Опыт отправки Apple Push Notification через SNS сервис от Amazon и немного полезного кода

• Использование Slack для отслеживания очереди недоставленных сообщений SQS

• Amazon SQS vs RabbitMQ

• Очереди — что это, зачем и как использовать? Посмотрим на возможности AWS SQS

• Тестирование Amazon SQS

Альтернативные сервисы обмена сообщениями

Google и Azure реализуют свои брокеры очередей.

У Google есть сервис Pub/Sub. Он реализует модель «издатель-подписчик», как и Amazon SNS, с поправкой на то, что для сообщений можно включить упорядочивание. Pub/Sub не реализует очередь сообщений по аналогии с Amazon SQS, но у Google есть другие сервисы, в частности Tasks с иной идеологией, через которые можно построить нечто подобное.

В Azure реализованы как модель «издатель-подписчик» (Azure Service Bus), так и очереди: стандартные и FIFO (Azure Queue Storage). Логика их работы аналогична службам AWS.

В России есть свои облачные сервисы, а у них собственные реализации инструментов обмена сообщениями. 

• Mail.ru Cloud Solutions — очередь, совместимая с Amazon SQS API, которая работает на Tarantool. Реализованы стандартные очереди и FIFO. Подробнее почитать можно здесь;

• Yandex.Cloud с собственной реализацией очередей. Поскольку здесь на данный момент возможностей больше, на нём остановимся подробнее в следующем разделе.

Сообщения в Yandex

Yandex.Cloud пошел по стопам других облачных платформ, в том числе Amazon, и реализует разные подходы к обмену сообщениями. На данный момент их два.

Yandex Message Queue

Yandex Message Queue — это очередь сообщений. Наиболее близкая аналогия — Amazon SQS. Yandex Message Queue допускает присутствие у одной очереди сообщений нескольких получателей.

Как и у Amazon, реализованы два типа очередей: стандартная и FIFO с механизмом дедупликации. Правда, ограничения пропускной способности несколько жестче — заявлено 300 сообщений в секунду для обычной очереди и 30 сообщений в секунду для FIFO. Также есть настраиваемая очередь недоставленных сообщений (DLQ).

Очереди Yandex совместимы с API Amazon SQS. 

Как и инструменты Amazon, очереди Yandex используются для: 

• масштабирования приложений (запуска дополнительных экземпляров сервисов-обработчиков);

• обработки больших объёмов данных. На Хабре писали о создании конвертера видео в GIF на базе Yandex Message Queue.

Yandex Data Streams

Второй инструмент, Yandex Data Streams, ориентирован не на отдельные сообщения, а на потоки данных. Сервис используется для передачи информации между приложениями или микросервисами в рамках одной архитектуры. При этом из потока данные могут считать несколько получателей. Сервис совместим с Amazon Kinesis Data Streams API.

Внутри передаваемого потока данные делятся на сегменты, в которых сохраняется порядок передачи. При этом потоки могут читать одновременно несколько приложений и считанные сегменты удаляются только по истечении срока хранения.

Разработчики Yandex Data Streams рекомендуют его использовать для:

• логирования работы приложений и сервисов;

• потоковой обработки данных;

• сбора телеметрии.

Выбирая сервис, необходимо помнить об особенностях нашего законодательства в части обработки пользовательских данных. Но это тема для отдельной статьи.

Если вам интересна экосистема Serverless-сервисов и все, что с этим связано, заходите в наше сообщество в Telegram, где можно обсудить serverless в целом.