Брокер в программировании что это
Брокеры сообщений
Что такое брокер сообщений?
Брокер сообщений — это программное обеспечение для связи между приложениями, системами и службами, помогающее им обмениваться информацией друг с другом. Это делается посредством перевода сообщений из одного формального протокола обмена сообщениями в другой. Таким образом независимые службы могут «общаться» между собой напрямую, даже если они написаны на разных языках или реализованы на разных платформах.
Брокеры сообщений — это программные модули или решения промежуточного ПО, ориентированного на обмен сообщениями (MOM). Промежуточное ПО такого типа предоставляет стандартизованные средства обработки потока данных между компонентами приложения, позволяя разработчикам не отвлекаться на это и заниматься основной логикой программ. Также брокер может выступать в качестве распределенного уровня связи, позволяющего приложениям, охватывающим несколько платформ, взаимодействовать друг с другом.
Брокеры сообщений проверяют, хранят, маршрутизируют сообщения и доставляют их в место назначения. Они выступают в качестве брокеров между разными приложениями: для отправления сообщений отправителям необязательно знать, где находятся получатели, активны ли они и сколько их всего. Это упрощает разделение процессов и услуг внутри систем.
Чтобы обеспечить надежное хранение сообщений и гарантированную доставку, в брокерах часто используется очередь сообщений — вспомогательная структура или компонент, который хранит и упорядочивает сообщения, пока они не будут обработаны приложениями-получателями. Сообщения в очереди хранятся в том же порядке, в котором они были переданы, до тех пор, пока не будет подтверждено их получение.
Брокеры сообщений работают по принципу асинхронного обмена сообщениями (15:11) между приложениями. Эта модель предотвращает потерю ценных данных и поддерживает функционирование систем даже при нестабильной связи или высоких задержках, присущих общедоступным сетям. При асинхронном обмене сообщениями сообщения будут доставлены один (и только один) раз в том же порядке, в котором были отправлены.
В брокеры сообщений могут входить администраторы очередей для взаимодействия между несколькими очередями, а также инструменты маршрутизации данных, перевода сообщений, хранения и управления состоянием клиента.
Модели брокеров сообщений
Брокеры сообщений работают по двум основным шаблонам (стилям) обмена сообщениями:
Брокеры сообщений в облачных архитектурах
Облачные приложения позволяют реализовать преимущества, присущие облачным вычислениям: это гибкость, масштабируемость и быстрое развертывание. Эти приложения состоят из отдельных маленьких, многократно используемых компонентов, которые называются микросервисами. Каждый микросервис развертывается и работает независимо от остальных. То есть, любой из них можно обновлять, масштабировать или перезапускать, не затрагивая другие сервисы в системе. Микросервисы часто упаковываются в контейнеры и работают как единое целое в составе приложения, однако у каждого из них может быть свой, отличный от других, стек технологий, включающий базу данных и модель управления данными.
Чтобы работать в связке с другими компонентами, микросервисам нужны средства обмена информацией друг с другом. Один из механизмов для создания общей магистрали обмена сообщениями — брокеры сообщений.
Брокеры сообщений часто используются для управления обменом сообщениями между локальными системами и облачными компонентами в гибридных облачных средах. Использование брокера сообщений дает больше контроля над связью между службами и гарантирует, что данные будут пересылаться между компонентами приложения безопасно, надежно и эффективно. Аналогичную роль брокеры могут играть в интеграции мультиоблачных сред, обеспечивая связь между задачами и средами выполнения, работающими на разных платформах. Также эта технология отлично подходит для бессерверных вычислений, подразумевающих запуск отдельных облачных служб по предварительному запросу.
Брокеры сообщений и API
Для связи между микросервисами обычно используются REST API. Термин «репрезентативная передача состояния» (Representational State Transfer или REST) определяет набор принципов и ограничений, учитываемых разработчиками при разработке веб-служб. Любые службы, созданные с учетом этих ограничений, впоследствии смогут взаимодействовать друг с другом с помощью набора унифицированных общих операторов и запросов без сохранения состояния. Программный интерфейс приложений (API) указывает базовый код, который при условии соответствия правилам REST обеспечивает взаимодействие служб друг с другом.
REST API взаимодействуют по протоколу HTTP. Поскольку HTTP является стандартным транспортным интернет-протоколом, REST API широко известны, часто используются и отлично сочетаются друг с другом. Но так как HTTP — это протокол запроса/ответа, то он лучше всего подходит для ситуаций, когда нужен асинхронный запрос/ответ. Это означает, что службы, отправляющие запросы через REST API, должны разрабатываться с расчетом на немедленный ответ. Если клиент не сможет принять ответ, то сервис, отправивший запрос, окажется заблокирован в ожидании ответа. В обе службы должна быть встроена логика аварийного переключения ресурсов и обработки ошибок.
Брокеры сообщений обеспечивают асинхронный обмен сообщениями между службами, при котором отправителю не нужно ждать ответа получателя. Это повышает отказоустойчивость и надежность систем, в которых реализованы такие службы. Также использование брокеров сообщений упрощает масштабирование систем, так как шаблон издатель/подписчик с легкостью допускает изменение числа служб. Кроме этого, брокеры сообщений отслеживают состояние приемника.
Брокеры сообщений и платформы потоковой обработки событий
В отличие от брокеров сообщений, поддерживающих два или несколько шаблонов обмена сообщениями (включая очереди и издатель/подписчик), платформы потоковой обработки событий работают только с шаблоном издатель/подписчик. Платформы потоковой обработки событий предназначены для больших объемов сообщений, поэтому изначально рассчитаны на масштабирование. Они способны упорядочивать потоки записей в категории (темы) и хранить их в течение установленного срока. В отличие от брокеров, платформы не гарантируют ни доставку сообщений, ни отслеживание их получателей.
Хотя возможности масштабирования платформ потоковой обработки событий шире, чем у брокеров сообщений, эти платформы менее устойчивы к сбоям (например, нет функции повторной отправки сообщений), а также у них ограничены возможности маршрутизации сообщений и функции работы с очередями.
Брокер сообщений и ESB (сервисная шина предприятия)
Сервисная шина предприятия (ESB) — это архитектурный шаблон, иногда используемый в организациях в архитектурах на основе служб. ESB представляет собой централизованную программную платформу, объединяющую протоколы обмена и форматы данных в общий «язык», который могут использовать все службы и приложения в архитектуре. Например, она может переводить запросы, поступившие по одному протоколу (допустим, XML) в другой (допустим, JSON). Преобразование полезной нагрузки сообщений в ESB осуществляется автоматически. Также централизованная платформа обрабатывает и другую логику координации, например обеспечение связи, маршрутизация и обработка запросов.
Однако инфраструктуры ESB достаточно сложны, затратны в обслуживании и могут вызывать затруднения с интеграцией. При использовании таких архитектур сложно устранять неполадки в производственных средах, они не очень хорошо масштабируются, а процесс их обновления довольно утомителен.
Брокеры сообщений — это «облегченная» альтернатива ESB практически с тем же функционалом (обмен информацией между службами), но гораздо проще и дешевле. Они хорошо подходят для архитектур на основе микросервисов, которые сейчас распространяются все больше, тогда как ESB теряют популярность.
Варианты использования брокеров сообщений
Брокеры сообщений можно реализовать для широкого ряда задач в самых разных отраслях и корпоративных вычислительных средах. Они полезны в тех случаях, когда требуется надежная связь между приложениями и гарантированная доставка сообщений.
Чаще всего брокеры сообщений используются для следующих задач:
Брокеры сообщений и IBM Cloud
По мере того как организации модернизируют приложения в ходе освоения облака, брокеры сообщений приобретают все более важное значение и открываются с новой стороны. Многие из самых успешных компаний мира, в том числе 85% компаний из списка Fortune 100, используют брокер сообщений IBM, предназначенный для поддержки современных сред гибкой разработки, архитектур на основе микросервисов и гибридного облака, а также широкого ряда разнообразных систем и требований к связи.
Сделайте следующий шаг: узнайте об IBM Cloud Pak for Integration, в основе которого лежат функции ведущего решения для корпоративного обмена сообщениями IBM MQ.
Начните работать с учетной записью IBM Cloud уже сегодня.
RabbitMQ tutorial 1 — Hello World
RabbitMQ позволяет взаимодействовать различным программам при помощи протокола AMQP. RabbitMQ является отличным решением для построения SOA (сервис-ориентированной архитектуры) и распределением отложенных ресурсоемких задач.
Под катом перевод первого из шести уроков официального сайта. Примеры на python, но его знание вовсе не обязательно. Аналогичные примеру программы можно воспроизвести практически на любом популярном ЯП. [так выглядят комментарии переводчика, т.е. меня]
Вступление
RabbitMQ ‒ это брокер сообщений. Его основная цель ‒ принимать и отдавать сообщения. Его можно представлять себе, как почтовое отделение: когда Вы бросаете письмо в ящик, Вы можете быть уверены, что рано или поздно почтальон доставит его адресату [видимо, автор ни разу не имел дела с Почтой России]. В этой аналогии RabbitMQ является одновременно и почтовым ящиком, и почтовым отделением, и почтальоном.
Наибольшее отличие RabbitMQ от почтового отделения в том, что он не имеет дела с бумажными конвертами ‒ RabbitMQ принимает, хранит и отдает бинарные данные ‒ сообщения.
В RabbitMQ, а также обмене сообщениями в целом, используется следующая терминология:
Поставщик, подписчик и брокер не обязаны находиться на одной физической машине, обычно они находятся на разных.
Hello World!
Первый пример не будет особо сложным ‒ давайте просто отправим сообщение, примем его и выведем на экран. Для этого нам потребуется две программы: одна будет отправлять сообщения, другая ‒ принимать и выводить их на экран.
Общая схема такова:
Поставщик отправляет сообщения в очередь с именем «hello», а подписчик получает сообщения из этой очереди.
Библиотека RabbitMQ
RabbitMQ использует протокол AMQP. Для использования RabbitMQ необходима библиотека, поддерживающая этот протокол. Такие библиотеки можно найти практически для каждого языка программирования. Python ‒ не исключение, для него есть несколько библиотек:
Отправка сообщений
Наша первая программа send.py будет просто отправлять одно сообщение в очередь.
Мы подключились к брокеру сообщений, находящемуся на локальном хосте. Для подключения к брокеру, находящемуся на другой машине, достаточно заменить «localhost» на IP адрес этой машины.
Перед отправкой сообщения мы должны убедиться, что очередь, получающая сообщение, существует. Если отправить сообщение в несуществующую очередь, RabbitMQ его проигнорирует. Давайте создадим очередь, в которую будет отправлено сообщение, назовем ее «hello»:
Теперь все готово для отправки сообщения. Наше первое сообщение будет содержать строку и будет отправлено в очередь с именем «hello».
Вообще, в RabbitMQ сообщения не отправляются непосредственно в очередь, они должны пройти через exchange (точка обмена). Но сейчас мы не будем заострять на этом внимание, точки обмена будут рассмотрены в третьем уроке. Сейчас достаточно знать, что точку обмена по-умолчанию можно определить, указав пустую строку. Это специальная точка обмена ‒ она позволяет определять, в какую именно очередь отправлено сообщение. Имя очереди должно быть определено в параметре routing_key:
Перед выходом из программы необходимо убедиться, что буфер был очищен и сообщение дошло до RabbitMQ. В этом можно быть уверенным, если использовать безопасное закрытие соединения с брокером.
Получение сообщений
Наша вторая программа receive.py будет получать сообщения из очереди и выводить их на экран.
Также как и в первой программе сначала необходимо подключиться к RabbitMQ. Для этого следует использовать тот же код, как и ранее. Следующий шаг, как и прежде ‒ убедиться, что очередь существует. Команда queue_declare не будет создавать новую очередь, если она уже существует, поэтому сколько бы раз не была вызвана эта команда, все-равно будет создана только одна очередь.
Вы можете задаться вопросом, почему мы объявляем очередь снова, ведь она уже была объявлена в первой программе. Это нужно, чтобы быть уверенным в существовании очереди, так будет, если сначала будет запущена программа send.py. Но мы не знаем, какая программа будет запущена раньше. В таких случаях лучше объявить очередь в обеих программах.
Мониторинг очередей
Если Вы хотите посмотреть, какие очереди существуют в RabbitMQ на данный момент, Вы можете сделать это с помощью команды rabbitmqctl (потребуются права суперпользователя):
(для Windows ‒ без sudo)
[в нашей компании используют более удобный скрипт мониторинга:]
[скрипт выводит и обновляет каждые 2 секунды таблицу со списком очередей: имя очереди; количество сообщений в обработке; количество сообщений готовых к обработке; общее количество сообщений; устойчивость очереди к перезагрузке сервиса; является ли временной очередью; количество подписчиков]
Получение сообщений из очереди более сложный процесс, чем отправка. Получение осуществляется при помощи подписки с использованием callback функции. При получении каждого сообщения библиотека Pika вызывает эту callback функцию. В нашем примере она будет выводить на экран текст сообщения.
Далее, нам нужно обозначить, что callback функция будет получать сообщения из очереди с именем «hello»:
Здесь необходимо быть уверенным в том, что очередь, на которую мы хотим подписаться, была объявлена. Мы сделали это ранее с помощью команды queue_declare.
Параметр no_ack будет рассмотрен позже [во втором уроке].
И, наконец, запуск бесконечного процесса, который ожидает сообщения из очереди и вызывает callback функцию, когда это необходимо.
Ну а теперь все вместе
Полный код receive.py:
Теперь мы можем попробовать запустить наши программы в терминале. Сначала отправим сообщение при помощи программы send.py:
Выполнение этой программы будет завершаться после отправки каждого сообщения. Теперь сообщение нужно получить:
Отлично! Мы отправили наше первое сообщение через RabbitMQ. Как Вы могли заметить, выполнение программы receive.py не завершилось. Она будет ожидать следующих сообщений, а остановить ее можно, нажав Ctrl+C.
Попробуйте запустить send.py снова в новом окне терминала.
Мы изучили, как отправлять и получать сообщения через именованные очереди. В следующем уроке мы создадим простую очередь задач [ресурсоемких].
UPD: библиотеку, работающую с RabbitMQ, для своего любимого ЯП Вы можете найти на официальном сайте тут.
Kafka, RabbitMQ или AWS SNS/SQS: какой брокер выбрать?
Четкая работа микросервисных приложений в значительной степени зависит от передачи сообщений и асинхронных операций.
Правильный выбор брокера сообщений — это одно из первых важных решений, которое потребуется принять при разработке взаимодействующих сервисов. Поиск «правильного» решения может превратиться в мучительное сравнение функций и пограничных вариантов, которые мало отличаются друг от друга.
В этой статье я бы хотел немного прояснить ситуацию и рассказать о нескольких наиболее известных брокерах сообщений. Я рассмотрю задачи, под которые они разрабатывались, используемую в них общую модель обмена сообщениями и постараюсь помочь с выбором оптимального варианта.
Apache Kafka
Kafka — это брокер сообщений с открытым исходным кодом, который был разработан и сейчас поддерживается в первую очередь фондом Apache Software Foundation при содействии сообщества разработчиков приложений с открытым кодом.
Основные характеристики
Акцент на потоковом контенте, работа с большими потоками данных.
Основные возможности: обеспечение сохранности сообщений и их многократная повторная обработка.
Хостинг на месте и поддержка сторонних модулей.
Kafka обеспечивает оптимизированную потоковую обработку событий, при этом связь между потребителями реализуется по модели «Публикации — подписки». События могут быть разбиты на топики — эта возможность позволяет лучше организовать схемы взаимодействия распределенного приложения. Кроме того, события делятся между несколькими серверами в пределах одного кластера — благодаря этому достигается высокая устойчивость и производительность системы.
Технические особенности развертывания
Apache предлагает SDK на нескольких языках.
Kafka предназначен для развертывания на месте в рамках вашей собственной архитектуры. Это может быть группа отдельных серверов, виртуальная машина или Docker-контейнер.
Многие компании предлагают хостинг Kafka в качестве услуги (например, AWS, CloudKarafka и Aiven) или на их виртуальных машинах.
Ниже приведен пример кода на JavaScript для начала работы с событиями Apache Kafka.
Преимущества и недостатки
Kafka ориентирован на высокую пропускную способность потока данных, это видно по его статистике производительности.
Kafka заточен на обработку потоков данных, поэтому получается высокопроизводительная система, которая выполняет сложную обработку больших объемов данных. Функционал маршрутизации этих потоков относительно ограничен по сравнению с другими брокерами сообщений. Однако этот разрыв постоянно уменьшается по мере совершенствования продуктов.
Таким образом, Kafka представляет собой надежный высокопроизводительный отказоустойчивый продукт для потоковой обработки сообщений, который дает вам полный контроль над поведением приложения. В зависимости от доступной пропускной способности канала и ресурсов можно выбрать комфортную для вас степень абстракции хостинга, и Kafka будет надежным вариантом, который способен масштабироваться вместе с вашим трафиком.
RabbitMQ
RabbitMQ — это еще один брокер сообщений с открытым кодом. Первоначальным разработчиком была компания Rabbit Technologies, но в результате ряда приобретений продукт перешел в собственность VMware.
Основные характеристики
Акцент на обмене сообщениями с возможностью поддержки больших потоков данных.
Основная особенность — расширенный функционал маршрутизации.
Хостинг на месте и поддержка сторонних модулей.
RabbitMQ также использует модель «Публикации — подписки», отправляя объекты сообщений в двоичной форме в различные именованные очереди, которые могут динамически создаваться и уничтожаться.
Он может работать как автономно, так и в составе кластера, позволяет наращивать достаточную мощность для достижения любой степени избыточности или безопасности данных.
Технические особенности развертывания
Для RabbitMQ существует несколько клиентских библиотек на множестве языков.
Он может быть развернут на месте: на полноценном сервере, в контейнере или на одном из нескольких облачных хостингов.
Следующий код на Node.js с пакетом AMQPLIB иллюстрирует простейший пример работы с RabbitMQ.
Преимущества и недостатки
RabbitMQ способен справляться практически с любыми нагрузками и может эффективно масштабироваться вместе с вашим приложением по мере роста базы пользователей.
Благодаря акценту на доставке сообщений и сложных сценариях маршрутизации RabbitMQ легко адаптируется к любой архитектуре приложений. Хотя изначально обработка потоков данных не поддерживалась и сообщения, как правило, обрабатывались однократно без возможности повторной обработки, эти слабые стороны были устранены по мере развития RabbitMQ.
RabbitMQ может выполнять любую подходящую роль в инфраструктуре вашего приложения благодаря тому, что позволяет контролировать все необходимое и передавать остальное на сторону.
Amazon Web Services (AWS) SQS/SNS
SNS и SQS представляют собой примеры двух разных подходов к распределенному обмену сообщениями.
SNS в значительной степени ориентирован на доставку сообщений. С помощью модели «Публикации — подписки» он позволяет быстро передавать сообщения множеству клиентов, например мобильным устройствам, конечным точкам HTTPS или другим сервисам AWS.
SQS, напротив, приоритетом ставит успешную доставку и обработку сообщений отдельными клиентами.
Основные характеристики
Возможность передавать широковещательные сообщения и работать по модели «Публикации — подписки».
Быстрая настройка с помощью AWS.
Отсутствие хостинга за пределами AWS.
SNS транслирует одно и то же сообщение множеству получателей, а SQS распределяет организованные в очередь сообщения среди отдельных подписчиков.
В SNS применяется режим push-уведомлений, который позволяет автоматизировать ответы. SQS больше ориентирован на механизм опроса с поддержкой некоторых дополнительных функций, управляемых событиями.
Технические особенности
AWS предлагает общий SDK с доступом к большинству сервисов AWS (включая SQS и SNS) на нескольких популярных языках.
Ниже приведен код, который демонстрирует работу с сервисами SNS и SQS при помощи SDK AWS.
Преимущества и недостатки
При совместном использовании AWS SQS и SNS могут стать основой масштабируемого надежного распределенного приложения. Благодаря интеграции со множеством других сервисов AWS (например, Lambda) эти два инструмента могут помочь с легкостью расширить коммуникационные возможности вашего приложения и предоставить обширный инструментарий для разрешения проблем взаимодействия между сервисами.
Если ваше веб-приложение уже работает в инфраструктуре AWS, на настройку фактически не придется тратить время и сложностей будет существенно меньше, чем у множества других систем. Потенциально это удобство обернется счетом за услуги AWS, который будет расти по мере увеличения количества сообщений.
В отличие от Kafka и RabbitMQ, которые не ограничивают размер сообщений по умолчанию, AWS устанавливает некоторые ограничения для сообщений SQS и SNS и после достижения определенного размера преобразует сообщения в объекты S3.
Мы публиковали подробную статью о том, как можно преодолеть это ограничение по размеру. Рекомендую ознакомиться с ней, чтобы понять, как SQS работает с большими сообщениями.
https://www.aspecto.io/blog/how-to-send-large-sqs-sns-messages-with-node-js/
Так как SQS и SNS построены в соответствии с принципом Cloud First, дополнительная сложность их использования вызвана привязкой к конкретному провайдеру. Другие брокеры сообщений избавлены от этого благодаря возможности локальной установки и сопровождения.
Выбор подходящего брокера сообщений
При выборе брокера вам следует принять во внимание два фактора:
Фактор 1: тип отправляемых сообщений
Первым делом при выборе брокера нужно определить, какие сообщения вы будете отправлять и в каком формате. Именно особенности ваших сообщений определят, на что следует обращать внимание при оценке возможностей каждой платформы. Платформы будут приблизительно похожи по своему функционалу — в том смысле, что каждый из продуктов имеет все необходимое для поддержки масштабируемого распределенного приложения. С точки зрения чисто функциональных возможностей все решения хороши.
Фактор 2: характер вашей ежедневной деятельности и инфраструктура приложений
Тут свою роль могут сыграть второстепенные обстоятельства. Подумайте о своей ежедневной работе и своих системах и задайте себе следующие вопросы:
Вы создаете приложение только в AWS? Возможно, для взаимодействия между службами будет целесообразнее использовать SQS и SNS.
Вам больше нравится работать над своим приложением, чем заниматься вопросами передачи данных между его компонентами? Тогда сторонний брокер может быть оптимальным вариантом, который позволит сосредоточиться на ваших сильных сторонах и нарастить вашу базу кода.
Вам требуются скорость доставки и минимальная задержка? Тогда Kinesis — то, что вам нужно (рассмотрим его в другой статье, так что следите за обновлениями). При этом для приложения, которое ориентировано на гарантированную доставку и избыточность, может потребоваться другая технология.
На этом уровне ваш выбор зависит от требований инфраструктуры приложения и характера работы.
С учетом вышесказанного и с оговоркой, что свести эти сложные технологические системы к рекомендациям в несколько строк — трудно и несколько несправедливо, дам некоторые советы по правильному выбору брокера сообщений.
Если для вас важны сохранность сообщений и возможность многократной повторной обработки — ваш выбор должен пасть на Kafka.
Если вас больше волнует возможность поддерживать и внедрять сложный набор правил маршрутизации — вам лучше всего подойдет RabbitMQ.
Если у вас небольшой стартап и вы хотите быстрее приступить к работе с минимальными накладными расходами — для вас отличным вариантом станут AWS SQS и SNS, учитывая их быструю настройку и структуру расходов.
Сквозная видимость в процессе обмена сообщениями
Один из аспектов, который следует оценить, — это оптимальный способ сопровождения конечного продукта. Как определить место возникновения ошибки после того, как приложение начнет отправлять сообщения и произойдет сбой?
OpenTelemetry представляет собой набор SDK и инструментов для обеспечения наблюдаемости распределенного приложения и позволяет устранять неполадки в распределенном обмене сообщениями. Краткое пошаговое руководство содержит инструкции по внедрению OpenTelemetry в распределенные приложения для сквозной видимости передаваемых сообщений. В примере в качестве брокера сообщений используется Kafka.
По ссылке далее руководства можно загрузить инструмент OpenTelemetry Kafkajs Instrumentation для Node.js
https://www.aspecto.io/blog/how-to-achieve-end-to-end-microservices-visibility-in-asyn-messaging-with-opentelemetry/
Выводы
Если вы создаете приложение, которое имеет тот или иной «распределенный» аспект, то велики шансы, что вам в какой-то момент потребуется обрабатывать асинхронное взаимодействие между его компонентами.
Сообщения и брокеры, которые их доставляют, будут критически важны в инфраструктуре, которая управляет вашим приложением.
Этот обзор не является исчерпывающим — мне потребовалась бы еще тысяча слов, чтобы начать полноценный рассказ о брокерах сообщений, но надеюсь, обзор содержит полезную информацию, которая пригодится вам при принятии решения. Главное — до конца понимать потребности вашего приложения и то, как эти потребности соответствуют возможностям брокеров сообщений, которые вы рассматриваете. В конечном счете вопрос выбора брокера сообщений не имеет «неправильного» ответа, но хочется верить, что эта статья поможет вам сделать шаг в правильном направлении.
Связанные репозитории GitHub
Библиотека производителей и потребителей SQS/SNS. Дает возможность передавать полезные нагрузки через S3.