Переход на новую архитектуру проекта: как это влияет на надежность стриминга web-данных
Предположим, что перед вашей командой стоит задача по поиску надежного стриминга web и app данных, который бы соответствовал требованиям службы безопасности, ожиданиям отделов маркетинга и аналитики, а также был бы полезен для управляющей команды. Не менее важно удобство и прозрачность работы стриминга, а внесение изменений в ожидаемый результат, желательно, без привлечения дополнительного ресурса аналитиков и разработчиков.
Этот материал будет полезен проектам, которые:
Выстраивают глубинную сквозную аналитику;
Рассматривают возможность интеграции аналитических решений;
Выстраивают аналитическую инфраструктуру инхаус.
Чем поделимся?
Новая архитектура и переезд на apache Kafka. Почему мы пошли в разработку новой архитектуры сервиса, и как это влияет на развитие наших решений;
Сравним прошлую и новую версии сервисов;
Система мониторинга и алертинга инцидентов. Как мы выстроили систему уведомлений и быстрого реагирования на них, и почему на это важно обращать внимание при выборе стриминга;
Как мы работаем с кейсами потери данных.
Про DataGo!
Команда DataGo! (ex. OWOX в РФ) предоставляет прозрачные и удобные инструменты для построения маркетингового DWH.
Наша платформа помогает аналитикам получать качественные данные, а маркетологам — строить прикладную отчетность.
Как мы обеспечиваем надежность маркетинговых и продуктовых данных?
Данные являются бесценным активом для большинства компаний. На их основе компании принимают стратегические и управленческие решения, исследуют поведение и предпочтения целевой аудитории, разрабатывают маркетинговую и продуктовую стратегию. Надежность данных, которые попадут в маркетинговые и продуктовые отчеты, — важнейший аспект для бизнеса.
Что такое надежные данные?
Надежные данные — это объективные и своевременные данные, соответствующие целям и задачам бизнеса, переданные без ошибок и ограничений. Если ваш бизнес принимает решения, основанные на данных, то вы должны быть уверены в их надежности, полноте и актуальности.
С чего все началось? Предпосылки
В портфеле DataGo! более 80 крупных клиентов из e-com, retail, finance и других сегментов. Это создает высокую нагрузку на нашу внутреннюю инфраструктуру: почти на каждом клиентском проекте используется мобильное приложение и сайт, на которые поступает трафик из нескольких источников (таргетированная и контекстная реклама, СРА-площадки, баннерная и медийная реклама и др.)
В начале 2024 года мы пришли к выводу, что при повышении нагрузки на наш сервис, возникнет риск невозможности принимать весь объем входящих данных. Это значит, что новые клиенты, подключенные к стримингу, и текущие будут рисковать частью своих данных и могут потерять их безвозвратно. Мы просто не смогли бы принимать входящие запросы и обрабатывать необходимый объем информации.
С целью защиты данных текущих клиентов и обеспечения качественного сервиса при подключении новых проектов, мы приняли решение о переезде на новую архитектуру аналитического проекта apache Kafka.
Как было? Старая архитектура
Компания DataGo! была основана в 2022 году. Создание DataGo! стало ответной реакцией на уход зарубежных аналитических инструментов из РФ: многие проекты вынужденно мигрировали на альтернативный аналитический стек, спасая свои данные от высокого риска безвозвратной потери.
Старая архитектура проекта
Устройство старого стриминга:
Все сервисы необходимые для работы стриминга разворачивались на каждой виртуальной машине, входящей в состав инфраструктуры приложения, создавая монолитную структуру;
На каждую ВМ поступали сырые данные;
Запросы проходили через все модули стриминга в рамках одной ВМ без сохранения их в сыром виде и промежуточных результатов обработки, что создавало риск потери данных на любом этапе обработки.
Почему была реализована такая архитектура?
Нехватка физического ресурса на реализацию более сложной логики;
Сжатые сроки для реализации: аналитическим проектам необходимо было решение, позволяющее быстро мигрировать на альтернативный стек.
Сложности поддержки старой архитектуры:
Масштабирование. Каждая новая ВМ стриминга увеличивала нагрузку на ClickHouse — формировались мелкие батчи, приводящие к высокому rps;
Релиз. Обновление требовало разворачивать новую версию сервиса на всех машинах, вне зависимости от масштаба изменений;
Надежность. Любая ошибка в процессе обработки запроса могла привести к его потере, что создавало риск потери данных.
Эти ограничения потребовали радикального пересмотра подходов к обработке входящего потока
Переход на новую архитектуру
Новая архитектура проекта
Устройство нового стриминга
Архитектура проекта была разбита на несколько микросервисов, выстроенных в единую цепочку, где каждое звено выполняет небольшую часть работы:
Прием входящих запросов и их сохранение в очередь на обработку;
Разбор хитов и извлечение значений из параметров;
Обогащение данных;
Трансформация в конечную структуру;
Загрузка в БД.
Изолированные процессы:
Повышение стабильности системы;
Возможность внесения правок в отдельные компоненты системы;
Упрощение локализации ошибок при обработке потока данных.
Переход на новую архитектуру обеспечил DataGo! решение сразу нескольких кейсов:
Все данные сохраняются в «сыром» виде. Стриминг это не изолированный процесс, на результат напрямую влияет полнота и корректность входящих запросов. Наличие «сырых» данных помогает определять причины и источник ошибок при их возникновении, а также значительно ускоряет процесс их исправления;
Исключена обработка данных до их сохранения. Это практически исключает вероятность того, что данные от клиента не дойдут или не сохранятся из-за программных ошибок;
Подключено резервное хранилище S3 при сохранении входящего потока. Получение и обработка входящих запросов наиболее критичный слой сервиса, для повышения стабильности этого процесса, помимо достаточно стабильной Kafka, используется в качестве резерва S3 от YC. Хранилище данных S3 имеет динамически расширяемый условно безграничный ресурс, репликацию и высокую пропускную способность сети, что решает потенциальные сложности с «перегрузкой» Кафки или ее недоступностью по различным причинами
Важно отметить!
Мы часто сталкиваемся с кейсами, когда у клиентов возникают сложности с текущим хранилищем, и по какой-то причине данные до него не могут быть доставлены. В таких случаях наша система сохраняет всю хитовую информацию до тех пор, пока хранилище клиента снова не станет доступным. Это гарантирует, что данные клиента не потеряются и дойдут в полном объеме.
Система мониторинга и алертинга инцидентов
В случае возникновения сложностей с [некорректной] доставкой данных до клиента, мы оперативно реагируем для выяснения причины возникшей ситуации и стараемся ее исправить. Например, сложности могут возникнуть из-за увеличения нагрузки на сервис, из-за проблем у хостинг провайдера и пр.
Для чего мы используем мониторинг инцидентов?
Обнаружение проблем. Мониторинг позволяет быстро выявить проблему и уведомить команду о необходимости вмешаться в процесс, минимизируя риски потери данных;
Оптимизация производительности. С помощью мониторинга инцидентов можно анализировать производительность систем и находить bottle necks: нагрузка процессоров, использование памяти и других параметров;
Прогнозирование. Мониторинг текущего состояния позволяет собирать данные для прогнозирования будущих нагрузок и планирования ресурсов;
SLA. Мониторинг позволяет контролировать выполнение соглашений об уровне обслуживания и обеспечивать соответствие требованиям.
Мониторинг помогает в принятии обоснованных решений на основе данных. Например, если система работает стабильно, но производительность начинает снижаться, можно использовать данные мониторинга для определения причин и принятия мер по их устранению. Это позволяет не только поддерживать стабильную работу системы, но и улучшать ее производительность.
Как мы замечаем, что с данными происходят аномалии?
Мониторинг. Сформированные внутренние процессы позволяют отслеживать объем хитов и трафика по каждому клиенту. В текущей версии валидация расхождений происходит в полуавтоматическом режиме.
Настроили автоматический алертинг, позволяющий отслеживать стабильность работы всех ВМ, находящихся в архитектуре проекта. Алертинг настроен на список метрик, отражающих стабильность системы (базовые показатели ВМ: CPU, Memory usage, Free disk size, Network), а также метрики, учитывающие специфику продукта (RPS и его динамику, коды ответов, скорость обработки запросов и др.)
Данные не остаются без присмотра: ответственные дежурные следят за работой всего процесса и, в случае необходимости, исправляют возникающие инциденты.
Своевременный переход на новую архитектуру позволил нам не только снизить риски потери данных и повысить контроль над возникновением ошибок, но и способствовал повышению надежности хранения и обработки данных для клиентских проектов.
В компаниях, где управленческие и стратегические решения принимаются на основе данных, особое внимание уделяют как полноте этих данных, так и их качеству, своевременности, согласованности и другим аспектам. Осознавая важность в получении данных, соответствующих задачам бизнеса, мы постоянно совершенствуем и развиваем наши продукты
