Разработали Highload-сервис обработки событий для крупной системы аналитики
Команда Evrone разработала сервис для обработки больших данных для рекламного агентства СберМаркетинг. Он рассчитан на прием и обработку не менее 100 тысяч запросов в секунду и служит в качестве Data Lake для обогащенных данных и реализован на Python.
СберМаркетинг — один из лидеров рекламного рынка, состоящий из 6 бизнес-юнитов. Предлагает полный комплекс услуг: от создания рекламного контента и его продвижения во всех каналах, маркетинговых, digital и AI-продуктов до организации мероприятий, создания цифровых аватаров и мерча.
В числе digital-продуктов СберМаркетинга есть «Платина» — платформа для веб-аналитики. Платформа собирает данные, безопасно сохраняет и позволяет на их основе делать отчеты о пользовательской активности, отслеживать источники трафика и оценивать эффективность кампаний.
Задача
Клиент пришел к нам с готовым техническим заданием, по которому нам предстояло выбрать технологии и создать решение для приема и сохранения поступающих событий — обезличенных действий пользователя, для обработки входящих запросов и их первичной аналитики. Система должна принимать, обогащать и кратковременно хранить данные, а затем передавать их в общую систему для дальнейшего хранения и использования. События приходят с разным набором информации, наша задача — привести их к одному, максимально полному виду (обогатить) и передать на последующее хранение в архив, где они будут доступны в долгосрочной перспективе.
Главным вызовом стали условия по нагрузке. Сервис должен обрабатывать 100 тысяч сообщений в секунду и не потерять ни одного события.
Подбор стека
У клиента не было жестких требований к стеку, лишь пожелание о Go и использовании инструментов, которые позволят в будущем продавать это решение клиентам в России.
Go казался клиенту привлекательным из-за скорости и удобного использования в микросервисах. Все это действительно так, но мы обратили внимание, что основной стек разработки у клиента это Python, поэтому решили рассмотреть варианты, которые позволили бы остаться при такой нагрузке в рамках Python. На момент реализации найти специалистов по Go существенно сложнее Python-разработчиков, и нам было важно, чтобы на долгой дистанции клиенту было комфортно работать с нашим решением.
Нам предстояло найти фреймворк, который бы помог нам адаптировать Python к Big Data, обработке и анализу больших данных. Мы протестировали AIOHTTP, Litestar, Robyn, но ни один из них нас не устроил. Мы выбрали Granian — библиотеку для обработки информации, реализованную на Rust. Ее можно использовать для любого стека, мы адаптировали ее к Python. У нас получился удачный тандем: Granian добавляет скорости, а управляющую логику быстро можно написать на Python.
Тестирование
Инженеры Evrone написали четыре тестовых сервиса: на Go, Python, Python+Granian и Rust. Нашей целью была отвечающая требованиям производительность при адекватном сетапе.
Для нагрузочного тестирования мы использовали Locust. Тестовый стенд развернули в Kubernetes и автоматизировали с помощью Terraform. Для каждого сервиса были готовы Docker-образы. Тестовые сценарии включали постепенное повышение нагрузки с фиксацией промежуточных результатов.
По итогам на одном ядре Go показал 5,7 тысяч RPS, а Python+Granian — 5,5 тысяч. Что подтвердило нашу теорию о том, что можно добиться нужной производительности без кардинальных изменений стека. Чистый Python показал несравнимо меньший результат.
Стоит отметить, что самые лучшие результаты показал Rust — 14 тысяч RPS. Однако, коммерческой разработки на этой технологии в России почти нет, да и в мире она в основном встречается в крипто-проектах и облачных сервисах технологических гигантов. Соответственно, специалистов найти крайне сложно, разработка дорогая, развивать проект в таких условиях будет невозможно.
Data Lake
Помимо высокой нагрузки на входе, разработанный нами сервис должен некоторое время хранить данные для дальнейшего обогащения. Мы создали Data Lake, который бы мог аккумулировать большие объемы стриминговых данных.
Одним из главных требований клиента была полная сохранность данных: ни одно событие или даже его часть не должны потеряться. Поэтому мы придерживались acknowledge-концепции, подтверждения доставки при передаче данных из одной части проекта в другую. Для основного хранилища мы выбирали из инструментов, которые дают возможность записывать лог сообщений до хранения, write-ahead log. Эта техника предполагает, что информация об изменениях в базе данных вносится и фиксируется перед записью в базу данных. Подход помогает понять, не была ли прервана операция при внезапном перезапуске системы, и либо запустить ее заново, либо отменить частичные изменения.
По совокупности требований мы решили использовать Tarantool — in-memory платформу с гибкой схемой данных. Изначально Tarantool был спроектирован не как внешняя система и база данных, а как полноценный фреймворк, внутри которого запускаются другие приложения, написанные на Lua. Фактически, рантайм для запуска других приложений с возможностью временного или персистентного хранения данных. Продукт претерпел несколько архитектурных изменений в части ядра и инструментов для развертывания и поддержки. Все нужные нам инструменты и подходы для Big Data остались только в enterprise-версии, и мы не могли их протестировать. Поэтому нам пришлось самостоятельно доработать community edition, который перестал обновляться.
Одной из главных сложностей стало отсутствие оператора для Kubernetes. В попытках сконфигурировать его для кластерного деплоймента наша команда даже связалась с создателем Tarantool. В итоге нам удалось собрать кластер, который содержит необходимые нам функции.
Итог
Мы предоставили клиенту выбор: онлайн протестировали все четыре пробных сервиса. Коллеги из СберМаркетинга согласились с нашими доводами и поддержали создание проекта на Python и Granian.
Evrone завершил разработку проекта и передал его клиенту. Мы полностью покрыли систему тестами, провели unit, нагрузочные, секьюрити и автоматизированные тесты компонентов, сопроводив документацией. Поддерживать работу сервиса смогут Python-специалисты middle-уровня, которые уже есть в штате компании, и заказчику не придется усложнять архитектуру системы вводом строго типизированных языков для динамических правил.
С этим проектом Evrone поучаствовал в разработке российской системы управления, клиентским опытом. С уходом зарубежных сервисов это актуальная задача для всех крупных технологических компаний.
Evrone может помочь и вашему проекту в области Customer Experience (CX). Напишите нам через форму внизу, чтобы обсудить возможности сотрудничества.