OpenReplay — это платформа для сессионных реплеев и продуктовой аналитики, созданная для разработчиков. Наблюдая за тем, как пользователи взаимодействуют с их приложением, продуктовые команды могут использовать платформу для выявления трудностей, понимания пользовательского поведения, а также для более быстрого поиска и устранения проблем.
Мехди Осман (Mehdi Osman), основатель и генеральный директор OpenReplay, описывает это как наблюдаемость для фронтенд-инженеров. «Это все равно что сидеть рядом с пользователем», — говорит он. «Вам не нужно звонить им, вам не нужно проводить интервью. Вы просто сидите тихо и смотрите ровно на то, что они делают».
Одно из главных отличий OpenReplay заключается в том, что она полностью саморазворачиваемая (self-hosted). «Это дает нашим конечным клиентам абсолютный контроль над данными и их управлением», — говорит Мехди. Она также является открытой (open source), что позволяет команде быстро реагировать на отзывы сообщества и сочетается с тем, что платформа построена на базе других открытых проектов, таких как ClickHouse, Postgres, Kafka и Redis.
По словам Мехди, задача с данными состоит из трех частей. Бэкенд должен принимать терабайты в день от каждого клиента. «Любая песчинка может повлиять на весь конвейер приема данных», — говорит он. Затем OpenReplay должна превратить эти данные во что-то полезное, и именно здесь «на сцену выходит ClickHouse». И все это должно работать в собственном окружении каждого клиента с минимальными операционными затратами как для клиента, так и для небольшой команды OpenReplay.
Мы пообщались с Мехди и старшим инженером-программистом Тахой Яссином Краемом (Taha Yassine Kraiem) об их пути, в том числе о том, как крупнейшие клиенты OpenReplay обрабатывают миллиарды событий в день на одном вертикально масштабируемом инстансе ClickHouse с подсекундными запросами.
В 2019 году OpenReplay запускала всё на Postgres, хостящемся в AWS. Транзакционная база данных отлично справлялась с метаданными, но поведенческие события (клики и просмотры страниц, из которых состоит сессия) были совсем другой историей. «Это не аналитическая база данных», — говорит Мехди. «В Postgres были вещи, которые мы не могли сделать, или на их выполнение уходила вечность». Команда пыталась шардировать таблицы, чтобы компенсировать это, но, как говорит Мехди, «это создало операционный хаос, с которым мы не могли справиться. Это было исключено».
Хорошим примером проблемы с производительностью является поиск сессий в OpenReplay. Он может объединять несколько типов событий в последовательности с критериями для каждого. Целевым показателем команды было время отклика менее одной секунды. Даже после добавления индексов, партиционирования и шардирования типичные запросы в Postgres выполнялись около трех секунд, а некоторые занимали до 10 секунд.
После миграции на ClickHouse среднее время отклика сократилось примерно до секунды. «Мы никогда не смогли бы добиться этого с Postgres», — говорит Мехди. «То есть, могли бы, но это потребовало бы магии, кучи шардирования и операционных накладных расходов, которых у нас не было».
С хранилищем была похожая история. Таблицы событий, разросшиеся примерно до 1 ТБ в Postgres, сжались до 1 или 2 ГБ в ClickHouse. «Это было практически ничто», — говорит Таха. «И даже выполнение запросов по сжатым данным работает супербыстро».
Другой проблемой Postgres была политика хранения данных. OpenReplay хранит данные сессий в течение определенного периода, а затем удаляет их. В Postgres это означало написание скриптов, удаление и процедуру vacuum, которые блокировали таблицы и приводили к перезапускам. «Это был полный кошмар», — говорит Таха. «Это отнимало у нас много времени и сил, а иногда что-то шло не так, и нам приходилось это исправлять».
Поскольку клиенты используют собственное развертывание, очистка также означала координацию действий с каждым из них по выходным, когда трафик был низким. «На это уходят дни, потому что это просто вакуумирование, блокировка таблиц, и ты не понимаешь, что происходит», — говорит Мехди.
Благодаря функции TTL (time-to-live) в ClickHouse срок хранения задается один раз при установке. «Для одних клиентов это три месяца, для других — год, для третьих — месяц», — говорит Мехди. «Мы просто настраиваем это один раз, и всё — о данных больше не нужно беспокоиться». Правило жизненного цикла в объектном хранилище обрабатывает файлы записей точно так же, а Postgres хранит только метаданные. Звонки клиентам по поводу выходной очистки ушли в прошлое. «С ClickHouse», — говорит Таха, — «мы связываемся с ними раз или два в полгода, просто чтобы проверить, не нужно ли провести какое-то обслуживание».
«Этот TTL чертовски ценен», — добавляет Мехди. «Я знаю, что это мелкая функция. Вы будете говорить про JSON, кэширование и запросы. Но TTL сэкономил нам слишком много выходных».
Сегодня ClickHouse находится в центре конвейера данных OpenReplay. Каждое поведенческое событие попадает в единую таблицу; оттуда при каждой вставке запускается цепочка материализованных представлений, преобразующих строки и передающих их дальше. «Каждое из них извлекает и трансформирует данные, пока они не достигнут целевой таблицы», — объясняет Таха. «Это работает потрясающе быстро. Мы просто меняем базу данных, и всё. Нам не нужно менять какой-либо код под капотом»
Это разительно отличается от того, как конвейер работал раньше, когда перемещение данных между таблицами требовало либо триггеров Postgres, либо воркеров на Go (язык, на котором написан конвейер), а любое изменение структуры таблицы влекло за собой изменения в воркере. Воркеры Go до сих пор обрабатывают часть конвейера, но с материализованными представлениями изменение, которое раньше занимало два дня разработки и отладки, теперь занимает около половины дня. «Централизация всего в ClickHouse сделала жизнь намного проще», — говорит Таха.
Мехди добавляет, что материализованные представления — это также то место, с которого начинаются новые функции. «Когда это новая функция, и мы еще не уверены в структуре данных, мы полагаемся на эти материализованные представления, потому что можем обрабатывать данные очень быстро», — говорит он. «Мы можем удалить их, сделать заново. После нескольких итераций, когда мы в них уверены, мы берем эту часть и переносим в код на Go, потому что тогда вставка работает гораздо быстрее».
Он также подчеркивает нативную поддержку JSON в ClickHouse, которая открыла двери для кастомных событий. Хотя клики и просмотры страниц фиксируются автоматически, клиенты, занимающиеся серьезной продуктовой аналитикой, хотят инструментировать собственные события (например, «оплата завершена» или «заказ отправлен» с именем, телом и набором свойств). «Без поддержки JSON в ClickHouse мы бы не смогли этого сделать», — говорит Мехди, — «потому что вы не просто вставляете эти события, в дальнейшем должно быть очень легко делать по ним запросы и строить все эти воронки, тепловые карты и пути. За кулисами ClickHouse обрабатывает эти свойства как колонки, и вы этого даже не замечаете».
Все это укладывается в схему, настолько простую, что ее можно описать в одном-двух предложениях. «У нас по сути есть две главные таблицы», — говорит Мехди. «Таблица сессий, содержащая метаданные о записи, и таблица событий — большая плоская таблица, куда вставляются все события. Две таблицы, очень простые для понимания, и при этом мы можем выполнять поверх них очень мощные запросы».
OpenReplay обрабатывает самые разные объемы данных. Некоторые клиенты принимают миллион или два событий в день. Другие принимают миллиарды — до 6 ТБ данных в сутки. Даже при таком масштабе каждый экземпляр работает на одном инстансе ClickHouse, что является осознанным выбором для продукта, который развертывается на инфраструктуре клиента. Вместо шардинга или кластеризации команда масштабирует систему вертикально, добавляя оперативной памяти и процессорных мощностей по мере роста клиента. Как выразился Мехди: «Мы еще даже не исчерпали тот потенциал, с которым может справиться ClickHouse».
Он приводит в пример одного из клиентов — финтех-компанию стоимостью в миллиарды долларов, которая выбрала OpenReplay именно потому, что это саморазвертываемое решение (self-hosted). «Они могут запустить всю платформу на своих серверах, и у них есть полный контроль над конфиденциальностью и безопасностью данных», — говорит он. Два их основных сценария использования — это воспроизведение багов и поддержка. Пользователи пишут, что не смогли завершить платеж или подписать контракт. Сотрудник службы поддержки может совместно просматривать с ними экран в реальном времени и оставлять на нем пометки. Если это не помогает, разработчик воспроизводит сессию с открытыми инструментами разработчика.
Инфраструктура финтех-компании записывает сотни тысяч сессий в день, каждая из которых содержит сотни событий. В сумме это дает сотни миллионов событий ежедневно, и все они поступают в один инстанс ClickHouse на Kubernetes. «Каждый раз, когда они растут — каждые несколько месяцев, — мы масштабируем его вертикально, — говорит Мехди. — Нам не нужно делать шардинг, нам не нужно добавлять другие инстансы ClickHouse. Так что операционные расходы получаются довольно низкими, что чрезвычайно важно в условиях self-hosted развертывания».
Логика была бы иной, добавляет он, если бы OpenReplay был исключительно SaaS-решением. «Мы бы, наверное, подписались на облачный сервис ClickHouse — и всё, — говорит он. — Но мы развертываем весь продукт на их серверах, и именно поэтому мы должны быть очень эффективными и компактными».
Внутри компании OpenReplay отслеживает метрику, которую они называют «временем до воспроизведения» (time to replay), измеряя, сколько времени проходит с момента совершения сессии до того, как разработчик сможет нажать кнопку воспроизведения и посмотреть ее.
Прием данных должен происходить в реальном времени и в больших объемах. Если вы захватываете пару тысяч событий, вы этого не заметите. Но если вы собираете терабайты данных ежедневно, любой небольшой сбой может иметь последствия, и на восстановление от отставания уйдет день или два. Поэтому очень важно иметь оптимизированный конвейер, и ClickHouse играет в этом большую роль». — Мехди Осман, основатель и генеральный директор OpenReplay
Прием данных должен происходить в реальном времени и в больших объемах. Если вы захватываете пару тысяч событий, вы этого не заметите. Но если вы собираете терабайты данных ежедневно, любой небольшой сбой может иметь последствия, и на восстановление от отставания уйдет день или два. Поэтому очень важно иметь оптимизированный конвейер, и ClickHouse играет в этом большой вклад.
— Мехди Осман, основатель и генеральный директор OpenReplay
Что касается запросов, цель состоит в том, чтобы каждое представление в продукте — от поиска до воронок, тепловых карт и блок-схем — возвращало результат менее чем за две секунды. Недавно команда включила кэш запросов ClickHouse, поэтому запрос, который выполняет один инженер, выполняется мгновенно для его коллеги пару минут спустя. «Кэширование — это одна из тех вещей, которые ты включаешь, и оно просто работает», — говорит Мехди. На вопрос, не хочет ли он добавить что-нибудь еще о написании запросов к ClickHouse, ответ Тахи был таким же. «Ничего особенного, — говорит он. — Оно просто работает».
OpenReplay теперь использует ClickHouse для создания готовящейся к выходу функции агентов, которая автоматически просматривает записи сессий и заблаговременно выявляет проблемы, поскольку ни одна команда не в состоянии просматривать сотни тысяч записей в день. «Представьте себе команду аналитиков, задача которых — просматривать все сессии пользователей так, как это сделал бы человек», — говорит Мехди, добавляя, что каждый след, производимый агентами, попадает в ClickHouse: «Это то, что мы используем для оценки (eval), это то, что мы используем для поиска и устранения неисправностей, это то, что мы используем, чтобы узнать, насколько эффективно работают агенты».
Спустя семь лет ClickHouse стал одним из немногих стандартных компонентов, которым OpenReplay доверяет работу на инфраструктуре, которую компания не контролирует. Клиенты хранят данные на собственных серверах, а стек OpenReplay остается достаточно компактным, чтобы они могли запускать его самостоятельно. «Все эти компоненты выбраны неслучайно, — говорит Мехди, — они создают минимум хлопот, даже когда речь идет об их развертывании для клиента и последующем обслуживании».
