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

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

• выстраивают глубинную сквозную аналитику;
• рассматривают интеграцию аналитических решений;
• выстраивают аналитическую инфраструктуру in-house.

В статье поделимся: новой архитектурой и переездом на Apache Kafka, сравнением прошлой и новой версий сервисов, системой мониторинга и алертинга инцидентов и работой с кейсами потери данных.

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

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

Предпосылки

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

Как было: старая архитектура

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

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

Такая архитектура была реализована из-за нехватки физического ресурса и сжатых сроков. Сложности её поддержки:

• Масштабирование. Каждая новая ВМ увеличивала нагрузку на ClickHouse.
• Релиз. Обновление требовало разворачивать новую версию на всех машинах.
• Надёжность. Любая ошибка могла привести к потере запроса.

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

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

• приём входящих запросов и их сохранение в очередь;
• разбор хитов и извлечение значений;
• обогащение данных;
• трансформация в конечную структуру;
• загрузка в БД.

Изолированные процессы дают повышение стабильности системы, возможность вносить правки в отдельные компоненты и упрощение локализации ошибок.

Переход обеспечил решение нескольких кейсов:

1. Все данные сохраняются в «сыром» виде. Наличие сырых данных помогает определять причины и источник ошибок при их возникновении.
2. Исключена обработка данных до их сохранения. Это практически исключает вероятность того, что данные от клиента не дойдут.
3. Подключено резервное хранилище S3. Получение и обработка входящих запросов — наиболее критичный слой сервиса, и резервное хранилище страхует этот этап.

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

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

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

1. Обнаружение проблем — быстро выявить проблему и уведомить команду.
2. Оптимизация производительности — анализ производительности и поиск узких мест.
3. Прогнозирование — сбор данных для прогнозирования будущих нагрузок.
4. SLA — контроль выполнения соглашений об уровне обслуживания.

Как мы замечаем аномалии в данных:

1. Мониторинг объёма хитов и трафика по каждому клиенту.
2. Автоматический алертинг на список метрик: CPU, memory usage, free disk size, network, RPS, коды ответов, скорость обработки.
3. Ответственные дежурные следят за работой всего процесса.

Вместо заключения

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