RabbitMQ — распределённый горизонтально масштабируемый брокер сообщений. Он разграничивает права доступа, поддерживает шифрование, сохранение сообщений на диск и работу в кластерах. Кроме того, он написан на Erlang, а значит, совместим с большинством популярных ОС. На примере кейсов Adidas и Laika разберём, как крупные компании используют RabbitMQ.
Креативный подход Laika: RabbitMQ в IT-структуре анимационной студии
Laika — американская анимационная студия, специализирующаяся на художественных фильмах, контенте для СМИ и музыкальных клипах. Наиболее известна картинами «Каролина в Стране Кошмаров», «Кубо. Легенда о самурае» и «Труп Невесты».
У студии есть небольшая IT-команда, которая описывает свою работу примерно так: «Мы поддерживаем продакшн. Каждый сэкономленный доллар — деньги, которые можно направить на производство фильмов». Чувствуя финансовую ответственность, инженеры студии ещё в 2009 году начали изучать RabbitMQ. Ниже краткое перечисление задач, которые они научились решать с помощью системы обмена сообщениями.
Особенности IT-структуры в анимационной студии
Управление IT-структурой в анимационной компании сопряжено с определёнными сложностями. При создании фильмов идёт постоянное обновление ресурсов: одни сотрудники подключаются к работе, другие выбывают. «Наша отрасль исторически была кочевой» — объясняет Махлон Смит, Senior Technologist. Для студии масштаба Laika объём работ по управлению идентификационными данными достаточно высок.
Помимо этого активно растёт число сред, которые необходимо интегрировать. Новое программное обеспечение внедряют регулярно, однако существующие системы практически не выводят из эксплуатации.
«RabbitMQ для админов и разработчиков»
Наконец, есть постоянная потребность в траблшутинге. Критически важно поддерживать получение оповещений между сетевыми событиями, настольными компьютерами и фермами рендеринга.
Как RabbitMQ помог решить описанные проблемы
Столкнувшись с проблемой динамичного числа пользователей, IT-команда разработала набор инструментов для предоставления учётных записей в отдельных системах. RabbitMQ выбрали в качестве решения для интеграции. Скажем, новому пользователю нужно дать добавочный номер телефона, но стандартное удостоверение LDAP не имеет прямого доступа к телефонной системе. С помощью RabbitMQ событие создания учётной записи попадает в очередь. Телефонная система обрабатывает эту очередь и назначает добавочный номер.
IT-команда использует web socket RabbitMQ для отправки обновлений в реальном времени в браузер. Это позволяет группе поддержки видеть, что происходит прямо сейчас, и оперативно устранять проблемы.
Поскольку Laika регулярно внедряет новое программное обеспечение, событийно-ориентированный подход к добавлению новых пользователей упрощает многие процессы:
«Со временем к новому пользовательскому событию мы добавляем всё больше слушателей, которые выполняют дополнительные задачи. Это делает его более устойчивым».
Способность RabbitMQ устанавливать политики выделяла его на фоне других инструментов обмена сообщениями, например NATS или NSQ. С помощью политик команда может убедиться, что частная информация остаётся на безопасном виртуальном хосте с ограниченным доступом.
90% внутреннего кодирования Laika выполняет на Ruby. В таком контексте особенно ценно, что RabbitMQ сам по себе не зависит от языка. «Плагин STOMP позволяет тривиально участвовать в сетевых событиях, используя только raw socket», — говорит Смит.
Как RabbitMQ снизил затраты
Использование RabbitMQ в качестве инструмента для обмена сообщениями позволило значительно сократить расходы на IT-команду. «С тех пор, как мы настроили RabbitMQ, поддержка IT-инфраструктуры требует минимальных усилий» — отмечает Смит.
Внедрение RabbitMQ помогло автоматизировать задачи, снизить вероятность возникновения ошибок, а также перестать хардкодить интеграции. Кроме того, гибкость RabbitMQ расширяет варианты его использования. Чем больше он интегрируется, тем полезнее становится при решении следующих задач.
Приложения для занятий спортом: как в Adidas используют RabbitMQ
Adidas вряд ли нуждается в дополнительном представлении. Это крупнейший производитель спортивной одежды и обуви с «тремя полосками. В 2015 году бренд укрепил свои позиции, приобретя Runtastic и превратив его в приложение для постоянных клиентов.
Во время пандемии популярность приложения для занятий спортом резко возросла. Александр Лакнер, инженер по инфраструктуре в Runtastic, отмечает: «Большинство мест, где люди привыкли заниматься спортом, были закрыты. Физическая активность на открытом воздухе стала популярной буквально за одну ночь. Мы увидели огромный всплеск числа пользователей, и нас захлестнула волна задач, которые пришлось решать параллельно».
Это могло бы привести к фатальным последствиям, если бы не RabbitMQ: «Практически во всех сервисах мы с самого начала запустили RabbitMQ. Он очень упростил масштабирование и обработку множества задач, поступающих одновременно».
Как работает приложение: вы выходите на пробежку и мониторите показатели с помощью Runtastic. Вернувшись домой, смотрите результаты активности на runtastic.com. А дополнительно ещё проверяете таблицу, где фиксируются недавно достигнутые рекорды.
Получается по одному сервису на каждую цель. Первый отвечает за текущую активность, второй — за ведение таблицы лидеров, третий — за записи. К объектам и сервисам IT-команда Runtastic применяет принцип единой ответственности. Это помогает с точки зрения владения данными и доступами к базе данных, но не решает проблему взаимодействия сервисов.
Взаимодействие микросервисов через RabbitMQ
Приложения Runtastic построено на инфраструктуре микросервисов. Они общаются через очередь сообщений, в данном случае RabbitMQ. Сообщения в приложении Runtastic генерируются каждый раз, когда пользователь начинает занятие. Затем различные службы обмениваются этими сообщениями и «слушают» друг друга. Например, когда физическая активность заканчивается, в таблице лидеров автоматически отображается актуальная информация.
В RabbitMQ у каждого сообщения должен быть топик. А каждый consumer определяет, к какому ключу маршрутизации прислушиваться, и даёт имя очереди. Например, сервис таблицы лидеров может прослушивать ключ маршрутизации run_session.# и назвать его очередь leaderboard.run_sessions. Благодаря этому он будет получать все сообщения с топиками, начинающимися с «run_session».
Топики и названия очередей не обязательно должны совпадать, но специалисты Runtastic решили идти таким путём. Они определили топики следующим образом:
<entity-type>.<crud operation>.<one other attribute>
entity-type — это, например, run_session, или friendship, или user;
crud operation — создание, удаление, обновление;
one other attribute — зависит от типа объекта.
Это помогает настроить фильтрацию с помощью RabbitMQ и получать меньше доставленных сообщений на одного consumer. Сервис, ответственный за объект, публикует сообщения в соответствии с тем, что произошло с этим объектом. Все заинтересованные сервисы прослушивают топик в определённой очереди:
Подводные камни
Во время разработки специалистам Runtastic пришлось столкнуться с некоторыми подводными камнями. Однако они выработали несколько правил, позволяющих нивелировать их:
«Избегайте циклов»: служба записей получает обновление и добавляет некоторую информацию в run_session, что вызывает другое сообщение об обновлении.
«Добавляйте измененные атрибуты»: сообщения об обновлении должны содержать измененные атрибуты объекта. Это повышает производительность consumer, поскольку получатель может игнорировать сообщение, если были изменены нерелевантные атрибуты.
«Используйте топики для фильтрации»: при использовании топиков для фильтрации не добавляйте слишком много информации, так как это может привести к усложнению структуры. Шаблон Runtastic с CRUD и одним дополнительным атрибутом в итоге сработал хорошо.
«Добавляйте имя службы к имени очереди»: это позволяет избежать того, чтобы два сервиса не получат сообщения, поскольку используют одно и то же имя очереди. Поскольку RabbitMQ намеренно отправит сообщение только в одну из очередей. Подробнее в документации.
Несмотря на небольшие сложности, для команды Runtastic RabbitMQ стал надёжным инструментом и с самого начала работал гладко, позволяя сосредоточиться на других задачах, а не на исправлении ошибок.
«RabbitMQ для админов и разработчиков»
Материал подготовлен на основе статей «LAIKA Gets Creative with RabbitMQ As the Animation Company's IT Nervous System» и «Adidas tracks sports activities with help from RabbitMQ»
Комментарии (10)
Johan_helm
25.11.2022 10:24Подскажите, имеет ли смысл отправлять сообщения через интернет? Насколько это безопасно если рабит будет торчать своими портами в мир? Или обязательно его прятать в впн?
mitya_k
25.11.2022 16:42В большинстве случаев лучше спрятать его от внешнего мира, по тем же причинам, что и БД прячут.
Если все-таки надо RabbitMQ сделать доступным снаружи, то необходимо коннектиться через ssl ради безопасности, но это добавит приседаний с сертификатами и их обновлением, а также снизит скорость передачи данных
geniyoctober
25.11.2022 16:45Я бы рекомендовал в комьюнити задать вопрос как правильно сделать https://t.me/rabbitmq_ru, но порты в мир это не вариант, у вас же порты баз данных не торчат наружу (надеюсь).
Kirill_Amber
Чё-т я не очень сильно понимаю, в чём прикол создания кучи очередей таким образом, если можно сделать единую структуру данных в какой-либо БД и оттуда все сервисы будут брать данные?
jetexe
И добавлять данные, и изменять данные, и устраивать взаимные блокировки и вычитывать всю базу за получением данных и не забывать блокировать данные для своей consumer-группы…
Очереди не для решения проблемы шаринга данных
Kirill_Amber
Да, об этом не подумал, спасибо
interhin
БД - единая точка отказа, если запросов будет слишком много то база будет bottle neck'ом - снижается производительность, постоянный опрос БД тоже снижает её. Ну и масштабировать БД намного сложнее, нужно будет решать проблемы балансирования задач если нужно несколько инстансов сервиса
gto
Раббит точно такая же единая точка отказа. Особенно если нужно решать проблемы с кворумами или зеркалами. Он точно так же может упереться в сетевой стек. Причём учтите, Раббит он не сам по себе, он работает в виртуалке эрланга. Хотя я сторонник использования раббит как шину для обмена сообщениями между сервисами хотя бы потому, что он на такой обмен заточен. Отправитель кинул сообщение, получатель или получатели тут же его поймали, без необходимости опрашивать базу о новых событиях. Плюс плюшки в виде контроля трафика и политик очередей и по мелочи.
interhin
Ну если развернут только один Rabbit сервер, то да, это тоже единая точка отказа, но можно делать несколько серверов (как, собственно, и с БД делают) / объединять их в кластеры. Делать это с Rabbit в теории проще, хотя на практике хз.