Переход на новую архитектуру проекта: как это влияет на надежность стриминга web-данных

Предположим, что перед вашей командой стоит задача по поиску надежного стриминга web и app данных, который бы соответствовал требованиям службы безопасности, ожиданиям отделов маркетинга и аналитики, а также был бы полезен для управляющей команды. Не менее важно удобство и прозрачность работы стриминга, а внесение изменений в ожидаемый результат, желательно, без привлечения дополнительного ресурса аналитиков и разработчиков. 

Этот материал будет полезен проектам, которые: 

• Выстраивают глубинную сквозную аналитику; 

• Рассматривают возможность интеграции аналитических решений;

• Выстраивают аналитическую инфраструктуру инхаус. 

Чем поделимся?

1. Новая архитектура и переезд на apache Kafka. Почему мы пошли в разработку новой архитектуры сервиса, и как это влияет на развитие наших решений; 

2. Сравним прошлую и новую версии сервисов;

3. Система мониторинга и алертинга инцидентов. Как мы выстроили систему уведомлений и быстрого реагирования на них, и почему на это важно обращать внимание при выборе стриминга;

4. Как мы работаем с кейсами потери данных. 

Про DataGo!

Команда DataGo! (ex. OWOX в РФ) предоставляет прозрачные и удобные инструменты для построения маркетингового DWH.

Наша платформа помогает аналитикам получать качественные данные, а маркетологам — строить прикладную отчетность.

Как мы обеспечиваем надежность маркетинговых и продуктовых данных? 

Данные являются бесценным активом для большинства компаний. На их основе компании принимают стратегические и управленческие решения, исследуют поведение и предпочтения целевой аудитории, разрабатывают маркетинговую и продуктовую стратегию. Надежность данных, которые попадут в маркетинговые и продуктовые отчеты, — важнейший аспект для бизнеса.

Что такое надежные данные? 

Надежные данные — это объективные и своевременные данные, соответствующие целям и задачам бизнеса, переданные без ошибок и ограничений. Если ваш бизнес принимает решения, основанные на данных, то вы должны быть уверены в их надежности, полноте и актуальности.

С чего все началось? Предпосылки

В портфеле DataGo! более 80 крупных клиентов из e-com, retail, finance и других сегментов. Это создает высокую нагрузку на нашу внутреннюю инфраструктуру: почти на каждом клиентском проекте используется мобильное приложение и сайт, на которые поступает трафик из нескольких источников (таргетированная и контекстная реклама, СРА-площадки, баннерная и медийная реклама и др.) 

В начале 2024 года мы пришли к выводу, что при повышении нагрузки на наш сервис, возникнет риск невозможности принимать весь объем входящих данных. Это значит, что новые клиенты, подключенные к стримингу, и текущие будут рисковать частью своих данных и могут потерять их безвозвратно. Мы просто не смогли бы принимать входящие запросы и обрабатывать необходимый объем информации. 

С целью защиты данных текущих клиентов и обеспечения качественного сервиса при подключении новых проектов, мы приняли решение о переезде на новую архитектуру аналитического проекта apache Kafka. 

Как было? Старая архитектура

Компания DataGo! была основана в 2022 году. Создание DataGo! стало ответной реакцией на уход зарубежных аналитических инструментов из РФ: многие проекты вынужденно мигрировали на альтернативный аналитический стек, спасая свои данные от высокого риска безвозвратной потери. 

Устройство старого стриминга:

• Все сервисы необходимые для работы стриминга разворачивались на каждой виртуальной машине, входящей в состав инфраструктуры приложения, создавая монолитную структуру;

• На каждую ВМ поступали сырые данные;

• Запросы проходили через все модули стриминга в рамках одной ВМ без сохранения их в сыром виде и промежуточных результатов обработки, что создавало риск потери данных на любом этапе обработки.

Почему была реализована такая архитектура? 

• Нехватка физического ресурса на реализацию более сложной логики; 

• Сжатые сроки для реализации: аналитическим проектам необходимо было решение, позволяющее быстро мигрировать на альтернативный стек.

Сложности поддержки старой архитектуры:

• Масштабирование. Каждая новая ВМ стриминга увеличивала нагрузку на ClickHouse — формировались мелкие батчи, приводящие к высокому rps; 

• Релиз. Обновление требовало разворачивать новую версию сервиса на всех машинах, вне зависимости от масштаба изменений;

• Надежность. Любая ошибка в процессе обработки запроса могла привести к его потере, что создавало риск потери данных.

Эти ограничения потребовали радикального пересмотра подходов к обработке входящего потока

Переход на новую архитектуру 

Устройство нового стриминга

Архитектура проекта была разбита на несколько микросервисов, выстроенных в единую цепочку, где каждое звено выполняет небольшую часть работы: 

• Прием входящих запросов и их сохранение в очередь на обработку; 

• Разбор хитов и извлечение значений из параметров; 

• Обогащение данных; 

• Трансформация в конечную структуру; 

• Загрузка в БД.

Изолированные процессы:

• Повышение стабильности системы; 

• Возможность внесения правок в отдельные компоненты системы; 

• Упрощение локализации ошибок при обработке потока данных.

Переход на новую архитектуру обеспечил DataGo! решение сразу нескольких кейсов: 

1. Все данные сохраняются в “сыром” виде. Стриминг это не изолированный процесс, на результат напрямую влияет полнота и корректность входящих запросов. Наличие “сырых” данных помогает определять причины и источник ошибок при их возникновении, а также значительно ускоряет процесс их исправления; 

2. Исключена обработка данных до их сохранения. Это практически исключает вероятность того, что данные от клиента не дойдут или не сохранятся из-за программных ошибок; 

3. Подключено резервное хранилище S3 при сохранении входящего потока. Получение и обработка входящих запросов наиболее критичный слой сервиса, для повышения стабильности этого процесса, помимо достаточно стабильной Kafka, используется в качестве резерва S3 от YC. Хранилище данных S3 имеет динамически расширяемый условно безграничный ресурс, репликацию и высокую пропускную способность сети, что решает потенциальные сложности с “перегрузкой” Кафки или ее недоступностью по различным причинами 

Важно отметить! 

Мы часто сталкиваемся с кейсами, когда у клиентов возникают сложности с текущим хранилищем, и по какой-то причине данные до него не могут быть доставлены. В таких случаях наша система сохраняет всю хитовую информацию до тех пор, пока хранилище клиента снова не станет доступным. Это гарантирует, что данные клиента не потеряются и дойдут в полном объеме.

Система мониторинга и алертинга инцидентов

В случае возникновения сложностей с [некорректной] доставкой данных до клиента, мы оперативно реагируем для выяснения причины возникшей ситуации и стараемся ее исправить. Например, сложности могут возникнуть из-за увеличения нагрузки на сервис, из-за проблем у хостинг провайдера и пр.

Для чего мы используем мониторинг инцидентов?

1. Обнаружение проблем. Мониторинг позволяет быстро выявить проблему и уведомить команду о необходимости вмешаться в процесс, минимизируя риски потери данных;

2. Оптимизация производительности. С помощью мониторинга инцидентов можно анализировать производительность систем и находить bottle necks: нагрузка процессоров, использование памяти и других параметров; 

3. Прогнозирование. Мониторинг текущего состояния позволяет собирать данные для прогнозирования будущих нагрузок и планирования ресурсов; 

4. SLA. Мониторинг позволяет контролировать выполнение соглашений об уровне обслуживания и обеспечивать соответствие требованиям.

Мониторинг помогает в принятии обоснованных решений на основе данных. Например, если система работает стабильно, но производительность начинает снижаться, можно использовать данные мониторинга для определения причин и принятия мер по их устранению. Это позволяет не только поддерживать стабильную работу системы, но и улучшать ее производительность.

Как мы замечаем, что с данными происходят аномалии?

1. Мониторинг. Сформированные внутренние процессы позволяют отслеживать объем хитов и трафика по каждому клиенту. В текущей версии валидация расхождений происходит в полуавтоматическом режиме.

2. Настроили автоматический алертинг, позволяющий отслеживать стабильность работы всех ВМ, находящихся в архитектуре проекта. Алертинг настроен на список метрик, отражающих стабильность системы (базовые показатели ВМ: CPU, Memory usage, Free disk size, Network), а также метрики, учитывающие специфику продукта (RPS и его динамику, коды ответов, скорость обработки запросов и др.)

3. Данные не остаются без присмотра: ответственные дежурные следят за работой всего процесса и, в случае необходимости, исправляют возникающие инциденты. 

Своевременный переход на новую архитектуру позволил нам не только снизить риски потери данных и повысить контроль над возникновением ошибок, но и способствовал повышению надежности хранения и обработки данных для клиентских проектов.

В компаниях, где управленческие и стратегические решения принимаются на основе данных, особое внимание уделяют как полноте этих данных, так и их качеству, своевременности, согласованности и другим аспектам. Осознавая важность в получении данных, соответствующих задачам бизнеса, мы постоянно совершенствуем и развиваем наши продукты