Привет, Хабр! Сегодня поговорим о принципах асинхронной работы с сообщениями и их очередями в распределенной и бессерверной архитектуре. У 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 в целом.
