RabbitMQ, Apache Kafka, SQS от Amazon, – технологическим компаниям, которые перешагнули определенный порог нагруженности своих веб-сервисов есть из чего выбрать, когда нужно встроить в свою архитектуру такой новый элемент, как «брокер сообщений». Ведущий разработчик Aeroclub Артем Рудяков, которому поручили ускорение поиска и интеграцию сервиса с еще 5 новыми API тоже оказался перед этим выбором. Почему решение было принято в пользу RabbitMQ? Как происходило внедрение? Какие результаты удалось получить? Артем согласился ответить на эти и другие вопросы редакции.

Aeroclub – бесспорно высоконагруженный сервис в области интеграции и обработки информации из API трэвэл поставщиков данных. Такие сервисы позволяют «одной кнопкой» найти и купить лучшие билеты, самые подходящие номера в отелях, выбрать нужные параметры услуг.

Все это они делают за счет сведения «в одну точку» поставляемых на аутсорс цифровых данных большого числа поставщиков услуг для путешественников: авиакомпаний, логистических компаний, сервисов бронирования отелей. У Aeroclub более 2 тысяч корпоративных клиентов с 1 тысячей и более сотрудников. Базы данных на десятки миллионов записей. Цена ошибки в обработке кодом информации пользователей платформы становится слишком высокой! 

• Артем, для тех, кто знает приблизительно или не знает вовсе, что такое брокеры сообщений: какие проблемы решают фреймворки в этой сфере?
• C помощью RabbitMQ и его альтернатив можно оптимизировать многие процессы «на бэке» веб-сервисов, но чтобы не загружать вас деталями, сосредоточусь на таком аспекте, как нотификация пользователей: push-уведомления, SMS-ки, информирующие сообщения в WhatsApp и Telegram. Как вы понимаете, при миллионных ежедневных транзакциях на платформе, даже если информация застряла, она должна гарантированно дойти до пользователя. Я говорю «застряла», но вы не обрадуетесь, если не увидите мгновенного изменения информации о балансе после нажатия вами, условно, кнопки «Купить». А что будет, если заказчик комплексной услуги организации командировки Aeroclub не найдет свое имя в списке постояльцев отеля в каком-нибудь малознакомом городе? Я что хочу сказать: информация не должна приходить медленно, веб такого позволить себе не может! Помимо недовольства пользователей как такового, есть такие вещи, как SLA – соглашение об уровне услуг, которое вы заключаете с корпоративными клиентами (в случае с Aeroclub B2B клиенты – большинство), а в SLA прописано: сколько времени могут занимать технические сбои. И вдруг вы понимаете, что от минут этот коэффициент взлетает до целых часов. Плохая архитектура в том, что касается приема и обработки пользовательской информации оборачивается повторными запросами, блокировками запросов, обратными запросами и кешированием. Со всем этим и помогают брокеры сообщений, или «системы очередей», как их еще называют. Когда данных пользователей становится очень много, архитектура, которая существовала раньше, не выдерживает и информация может идти минутами или потеряться вовсе. Если повезет, то пользователь не заметит потерь, ведь благодаря микросервисам они никогда не будут тотальными, но если они затронут критически важную информацию, то последствия будут очень плачевными для компании.

Брокеры сообщений – прокладка между компонентами пользовательской части приложения и сервером. Они получают информацию в виде JSON и более тонко маршрутизируют в системе. Благодаря своим особенностям, они помогают обрабатывать данные быстрее и обеспечить полную гарантию их доставки пользователю, то есть гарантировать отказоустойчивость. Что касается быстроты, то тот же RabbitMQ может обрабатывать пользовательскую информацию асинхронно. При традиционных подходах выполнение программы продолжится, только если какой-либо запрос отправлен и получен, то при асинхронности ждать уже ничего не надо. Сообщения идут дальше и обрабатываются – не обязательно ждать отработки одного метода, чтобы переходить к следующему. Остается еще возможность, что ответ сервера, который мы «перешагнули» так и не придет. На этот случай RabbitMQ легко и надежно сохраняет информацию и корректно реагирует на задержку или полное неполучение данных на каком-то этапе.

• Серьезные изменения в архитектуре, если мы говорим про IT, всегда очень непростое дело. В какой момент вы поняли, что брокер сообщений нужен и вам следует начать внедрять такое решение в legacy Aeroclub?
• Мне поручили возглавить работу по устранению «узких мест», заставляющих систему работать со скоростью самого медленного ее компонента. Ситуация была такова, что при запросах со сложными фильтрами результат поиска мог «грузиться» две минуты. Мне попадались исследования, согласно которым, даже 40 секунд заставляет многих современных пользователей испытывать дискомфорт и формировать негативное отношение к веб-сервису. Также, передо мной как тим-лидом стояла задача начать забирать и использовать в сервисах Aeroclub данные от пяти новых трэвэл поставщиков данных. Причем, ситуация была такова, что принимать информацию надо было по самым разным протоколам от WCF до RPC. Как вы понимаете, это усугубляло ситуацию.

Получается, количество информации от поставщиков и нагрузка на поиск и другие компоненты должны были возрасти, при том, что имеющаяся архитектура плохо справлялась даже с имеющимися данными. Требовалось повысить отказоустойчивость и скорость обработки пользовательской информации. Я понял, что брокер сообщений нам нужен, когда тщательно обдумывал проблемы архитектуры сервиса. Так как скорости поиска в 2 минуты давали системные проблемы, то отделаться какими-то полумерами было невозможно. И сейчас, после окончания всех работ по внедрению RabbitMQ, я считаю, что наличие такой подсистемы – признак зрелости архитектуры высоконагруженного сервиса, потому что неизбежно связанные с масштабированием проблемы решаются сейчас именно так.

• Почему вы остановили свой выбор именно на RabbitMQ? Есть и другие брокеры сообщений.
• Кроме меня на нем остановили свой выбор разработчики Bloomberg, Reddit, WeWork, NASA. По разным причинам. Для нас было важно, чтобы маршрутизацию сообщений можно было тонко настроить для разных случаев (за роутинг в библиотеке отвечает модуль, который называется Exchange). Это давало возможность экономить ресурсы и получить более эффективную производительность системы. Ни в одном из конкурентов RabbitMQ нет такого количество вариантов маршрутизации. Суть библиотеки проста: есть очереди сообщений из пользовательского интерфейса, в которые, в соответствии с настройками binding, попадают данные от разных сервисов. Если нужно отправить пользователю SMS, вы обращаетесь к одной очереди, если сообщение в Telegram, то в другую. Они выступают шинами, где вы можете держать JSON без обработки здесь и сейчас. Очереди не удаляют сообщения, а хранят их пока принимающие сервисы (паблишеры на языке Rabbit) их не получат. Основных в библиотеке три: direct, topic, fanout. Например, fanout записывает сообщение во все очереди сразу. Способ быстрый, тесты показывают 30000mps. Direct «пишет» только в те очереди, которые соответствуют ключам. С Topic можно писать или не писать те или иные сообщения в те или иные очереди с еще более тонкой фильтрацией. Впрочем, скорость метода существенно ниже Direct и Fanout: 5000-10000mps. В очередях поддерживается приоритезация, которая позволяет чему-то уделить больше внимания, что-то игнорировать. Идеальное решение для онлайн-сервиса, интегрирующего «пестрые» данные трэвэл поставщиков. Как вы помните, нам надо было получать информацию с помощью самых разных протоколов передачи данных. Единственной проблемой RabbitMQ я бы назвал трудности с масштабированием. Приходится писать дополнительные обработчики, которыми сложно и неудобно управлять. В остальном RabbitMQ – превосходная библиотека. Отдельно хочу сказать про сохранность сообщений.

Тот же фреймворк Kafka не отслеживает получения службой нужного сообщения, он только прописывает их в лог в той последовательности, в которой они поступали от того или иного компонента. В SQS Amazon с этим лучше, но раз у вас есть RabbitMQ SQS вам не нужен, ведь, при наличии ряда преимуществ перед open-source-ным «кроликом» это программное обеспечение настолько завязано на Amazon, что если вы меняете облачный сервер или еще каким-то образом отходите от Amazon, то вам придется менять и брокер сообщений, что крайне нежелательно. У продукта Amazon есть свои плюсы, например, там очень мощное шифрование при обработке пользовательской информации. Но эти проблемы мы решили самостоятельно, а в остальном: плюсы SQS для нас не перекрывают минусы. RabbitMQ устроен так, что точно передаст сообщение службе, которой он нужен, когда она станет доступна. Так как наша информация должна была быть представлена на разных платформах и клиентах, хорошей новостью стало то, что фреймворк работает с большим количеством разных протоколов. Основным для него, конечно, является AMQP, но можно настроить его для работы с HTTP, XMPP, MQTT, STOMP и многими другими. RabbitMQ поддерживает кластеризацию, что позволяет распределять очереди и обменники между узлами для повышения отказоустойчивости. Отмечу, что RabbitMQ хорошо работает с .NET. при помощи которого мы работали со многими API.

• Удалось ли вам добиться того, ради чего вы начинали работу с RabbitMQ?
• Да, наши реформы привели к тому, что скорости поиска возросли и достигли приемлемых показателей. Теперь даже на самых сложных фильтрах у нас время загрузки не превышало 5 секунд вместо 2 минут раньше! Службы-отправители (паблишеры) и службы-получатели (подписчики), между которыми с ростом размаха работы Aeroclub возник некоторый рассинхрон, мы успешно синхронизировали. Это заслуга не только RabbitMQ, ведь у нас был комплекс работ, который включал и оптимизацию запросов к базам данных. Но вклад RabbitMQ был немалым. 5 секунд скорость у нас была даже после того, как под моим руководством в сервис была добавлена информация из 5 новых трэвэл API. Здесь очень пригодилась работа «кролика» с большим количеством разных протоколов. В числе новых данных, которые мы начали «грузить» данные из API «Островок», IWay. Наличие этой и других видов данных в системе позволило создать для руководителей C-левела специальный сервис, в котором они могли наглядно видеть затраты на сложную комбинированную услугу по командировкам, которая формируется в личном кабинете веб-сервисов Глядя на данные из аккаунта, вы хорошо понимаете: сколько пошло и на что именно. В конечном счете, результатом нашей работы стало то, что уникальный сервис, который автоматизировал до 80% бюрократических задач при организации командировок, сохранил свои позиции, несмотря на наличие конкурентов.

Фреймворк критикуют за то, что он не очень хорошо переносит масштабирование архитектуры и критика заслужена. Однако то, каким будет опыт в этом вопросе, зависит от особенностей проекта. В нашей ситуации мы просто добавляли новые экземпляры обработчиков и этого хватило. В полной мере удалось добиться декомпозиции кода. Логика системы разложилась по маленьким удобным компонентам, с которыми легко работать и которые легко поддерживать и читать. С другой стороны, на этапе изучения вопроса мне попадались кейсы других компаний, у которых возникли большие проблемы. Я считаю, если задача нетривиальна, то можно испытать трудности, но у нас был обыкновенный рост количества данных. С этим «кролик» справился, даже при том, что они были очень разнотипными. Задачи в области отказоустойчивости мы тоже благополучно решили: кластеризация и гарантированное получение службой получателем нужной информации (через механизм подтверждения доставки – Acknowledgements) делают свое дело. Количество ошибок при передаче данных и направлении ответов уменьшилось кратно.
В разговоре с нами Артем Рудяков назвал RabbitMQ удобным инструментом, гибким, простым в разработке, хорошо совместимым с облачными и распределенными архитектурами и микросервисами. «Как эксперт, успевший поработать и хорошо изучить фреймворк, я волей-неволей замечаю в веб-сервисах, к которым не имею отношения как разработчик, проблемы, которые RabbitMQ мог бы решить», - подытожил Артем.   

Автор статьи: Левков Сергей