大規模なフロントエンドオブザーバビリティ: OpenReplayがClickHouseで日々数十億件のイベントをリアルタイムに収集する方法

OpenReplay は、開発者向けに構築されたセッションリプレイおよびプロダクトアナリティクスプラットフォームです。プロダクトチームは、ユーザーがアプリケーションをどのように操作しているかを確認することで、問題のボトルネックを特定し、ユーザーの行動を理解し、トラブルシューティングや不具合の修正を迅速に行うことができます。

OpenReplay の創業者兼 CEO である Mehdi Osman 氏は、これをフロントエンドエンジニア向けのオブザーバビリティだと説明しています。「まるでユーザーの隣に座っているような感覚です」と彼は言います。「電話をかける必要も、インタビューをする必要もありません。静かに隣に座り、ユーザーが何をしているのかを正確に見守るだけでよいのです」

OpenReplay の最大の差別化要因の 1 つは、完全にセルフホスト可能である点です。「これにより、エンドユーザーである顧客はデータを完全に制御し、ガバナンスを効かせることができます」と Mehdi 氏は言います。またオープンソースでもあるため、コミュニティからのフィードバックをもとに迅速な改善を繰り返すことができ、ClickHouse、Postgres、Kafka、Redis などの他のオープンソースプロジェクトの上にプラットフォームを構築するという方針とも一致しています。

Mehdi 氏によると、データに関する課題には 3 つの側面があります。バックエンドは、顧客ごとに 1 日あたり数テラバイトを取り込む必要があります。「ほんの少しの砂粒のような問題でも、取り込みパイプライン全体に影響を及ぼしかねません」と彼は言います。その後、OpenReplay はそのデータを有用な形に変換しなければならず、「そこで ClickHouse が登場します」。そして、そのすべてが各顧客の自社環境内で稼働し、顧客にとっても OpenReplay の小規模なチームにとっても運用負荷を最小限に抑えられなければなりません。

私たちは Mehdi 氏とシニアソフトウェアエンジニアの Taha Yassine Kraiem 氏に、これまでの歩みについて話を聞きました。OpenReplay の大規模な顧客が、垂直スケールした単一の ClickHouse インスタンス上で 1 秒未満のクエリ応答を維持しながら、1 日あたり数十億件のイベントを取り込んでいる方法についても伺いました。

Postgres から ClickHouse への移行 #

2019年当時、OpenReplay はすべてのシステムを AWS 上でホストされた Postgres で運用していました。トランザクションデータベースはメタデータの処理には問題ありませんでしたが、セッションを構成するクリックやページビューなどの行動イベントの処理となると話は別でした。「Postgres はアナリティクスデータベースではありません」と Mehdi 氏は言います。「Postgres では実行に莫大な時間がかかり、実現できない処理がありました」。チームはテーブルをシャーディングして補おうとしましたが、Mehdi 氏が語るように「運用上の大混乱を招き、対処しきれなくなりました。それは採用できる手段ではありませんでした」。

パフォーマンス問題の好例が、OpenReplay のセッション検索です。この機能では、複数のイベントタイプを順序立てて組み合わせ、それぞれに条件を設定できます。チームの目標は 1 秒未満の応答時間でした。インデックスの追加、パーティショニング、シャーディングを施した後でも、一般的な Postgres のクエリには約 3 秒かかり、中には最大 10 秒かかるものもありました。

ClickHouse に移行した後、平均応答時間は約 1 秒にまで短縮されました。「Postgres では到底達成できませんでした」と Mehdi 氏は語ります。「不可能ではなかったかもしれませんが、膨大な作業や多数のシャーディングが必要になり、私たちには抱えきれない運用負荷が生じていたはずです」。

ストレージについても同様でした。Postgres で約 1 TB にまで肥大化していたイベントテーブルは、ClickHouse では 1〜2 GB にまで圧縮されました。「実質的に無いに等しいサイズになりました」と Taha 氏は言います。「しかも、圧縮されたデータに対するクエリの実行であっても非常に高速です」。

Postgres のもう 1 つの課題はデータ保持(リテンション)でした。OpenReplay はセッションデータを一定期間保持した後に削除します。Postgres では、テーブルのロックや再起動を余儀なくさせるスクリプト、DELETE 処理、VACUUM 処理を意味していました。「完全に混乱状態でした」と Taha 氏は言います。「多大な時間と労力がかかり、時には処理がうまくいかずに修正作業が発生することもありました」。

顧客がセルフホストしているため、クリーンアップ作業はトラフィックが少ない週末に各顧客と調整して行う必要がありました。「VACUUM を実行しているだけでテーブルがロックされ、何が起きているのかも把握できず、完了までに何日もかかりました」と Mehdi 氏は振り返ります。

ClickHouse の TTL (time-to-live) 機能 を使用すれば、データ保持期間は導入時に一度設定するだけで済みます。「顧客によって、3 か月の場合もあれば、1 年の場合も、1 か月の場合もあります」と Mehdi 氏は言います。「設定さえしてしまえば、あとはデータが自動的に処理されます」。録画ファイルについてもオブジェクトストレージのライフサイクルルールで同様に処理され、Postgres にはメタデータのみが保持されます。週末に顧客とクリーンアップのための連絡を取り合う必要は過去のものとなりました。「ClickHouse を導入してからは」と Taha 氏は言います。「必要なメンテナンスがないか確認するために、半年に 1、2 回顧客と連絡を取る程度です」。

「TTL 機能はとてつもなく貴重です」と Mehdi 氏は付け加えます。「ささやかな機能に思えるかもしれません。JSON やキャッシュ、クエリの性能ばかりが話題になりがちです。しかし、TTL のおかげで無駄にならずに済んだ週末は数え切れません」。

OpenReplay が ClickHouse 上に構築した仕組み #

現在、ClickHouse は OpenReplay のデータパイプラインの中心に位置しています。すべての行動イベントは単一のテーブルに集約されます。そこから一連のマテリアライズドビューが挿入ごとにトリガーされ、行を変換して後続へと渡します。「各ビューがデータを抽出・変換しながら、最終的な宛先テーブルへと送ります」と Taha 氏は説明します。「信じられないほど高速に動作します。データベース側を変更するだけで済み、背後にあるコードを編集する必要が一切ありません」。

これは以前のパイプラインの動作とは大きく異なる点です。かつてテーブル間でデータを移動するには Postgres のトリガーか Go のワーカー(パイプラインが記述されている言語)のいずれかが必要であり、テーブル構造を変更するたびにワーカー側にも対応する変更を加える必要がありました。現在でもパイプラインの一部は Go のワーカーが処理していますが、マテリアライズドビューのおかげで、かつて開発とデバッグに 2 日かかっていた変更作業が、今では半日ほどで完了します。「すべてを ClickHouse に集約したことで、開発がはるかにシンプルになりました」と Taha 氏は語ります。

Mehdi 氏は、マテリアライズドビューが新機能の開発の起点にもなっていると付け加えます。「新機能でデータ構造がまだ確定していない段階では、データを非常に迅速に処理できるこれらのマテリアライズドビューを活用します」と彼は言います。「削除して再作成するのも簡単です。数回のイテレーションを経て構造が確定したら、その部分を Go のコードへと移行します。そうすることで挿入がさらに高速になるためです」。

彼はまた、カスタムイベントの実現を可能にした ClickHouse のネイティブ JSON サポートにも言及しています。クリックやページビューは自動的に取得されますが、本格的なプロダクトアナリティクスを実施する顧客は、独自のイベント(名前、本文、プロパティのリストを持つ「決済完了」や「注文送信」など)を計測したいと考えます。「ClickHouse の JSON サポートがなければ、これを実現することは不可能でした」と Mehdi 氏は言います。「これらのイベントは単に取り込むだけでなく、後から非常に簡単にクエリを実行して、ファネル、ヒートマップ、フローなどを構築できなければならないからです。舞台裏では ClickHouse がこれらのプロパティをカラムのように扱ってくれるため、ユーザー側がそれを意識する必要すらありません」。

これらはすべて、1、2 文で説明できるほどシンプルなスキーマに収められています。「基本的には 2 つのメインテーブルしかありません」と Mehdi 氏は言います。「録画に関するメタデータを保持するセッションテーブルと、すべてのイベントが挿入される巨大なフラットテーブルであるイベントテーブルです。わずか 2 つの分かりやすいテーブルでありながら、その上で非常に強力なクエリを実行できています」。

単一インスタンスで 1 日数十億件のイベントを処理 #

OpenReplay が扱うデータ量は多岐にわたります。1 日に 100 万〜200 万件のイベントを取り込む顧客もいれば、数十億件、1 日あたり最大 6 TB のデータを取り込む顧客もいます。それほどの規模であっても、各デプロイは単一の ClickHouse インスタンス上で動作しています。これは顧客のインフラ上で稼働するプロダクトとして、意図的に選択されたアプローチです。チームはシャーディングやクラスタリングを行うのではなく、顧客の成長に合わせて RAM と CPU を追加する垂直スケーリング(スケールアップ)を採用しています。Mehdi 氏が言うように、「私たちは ClickHouse が処理できる限界の深みには、まだ足を踏み入れてすらいません」。

彼は、セルフホスト可能であることを理由に OpenReplay を選んだ、数十億ドル規模のフィンテック企業の顧客を例に挙げます。「彼らはプラットフォーム全体を自社サーバー上で稼働させることができ、データのプライバシーとセキュリティを完全に管理下に置いています」と彼は言います。彼らの主なユースケースはバグの再現とサポートです。ユーザーから「決済を完了できなかった」「契約を締結できなかった」といった問い合わせが寄せられた際、サポート担当者はリアルタイムで画面を共同閲覧し、画面上に注釈を書き込むことができます。それでも解決しない場合は、開発者が開発者ツールを開いた状態でそのセッションをリプレイします。

このフィンテック企業の環境では 1 日あたり数十万件のセッションが記録され、各セッションには数百件のイベントが含まれます。それらを合計すると毎日数億件のイベントに達し、そのすべてが Kubernetes 上の単一の ClickHouse インスタンスへと投入されます。「データ規模が拡大するたびに、数か月おきに垂直スケールを行っています」と Mehdi 氏は言います。「シャーディングを行う必要も、他の ClickHouse インスタンスを追加する必要もありません。そのため運用コストを非常に低く抑えられており、これはセルフホスト環境において極めて重要です」。

OpenReplay が SaaS のみで提供されていたなら、判断は異なっていただろうと彼は付け加えます。「おそらく ClickHouse Cloud のサービスを契約して終わりだったでしょう」と彼は言います。「しかし、私たちはプロダクト全体をお客様のサーバーにデプロイしているため、可能な限り無駄を削ぎ落とした構成(リーン)を維持しなければならないのです」。

リプレイまでの時間と今後の展望 #

社内において、OpenReplay は「リプレイまでの時間(time to replay)」と呼ばれるメトリクスを追跡しています。これは、セッションが発生してから開発者が再生ボタンをクリックして視聴できるようになるまでの時間を測定するものです。

「大規模環境では、取り込みはリアルタイムでなければなりません。数千件のイベントを取得する程度であれば気づかないかもしれませんが、毎日数テラバイトものデータを取得する場合、わずかな障害でも影響が波及し、遅延から復旧するまでに 1、2 日かかってしまうことがあります。そのため、無駄のない洗練されたパイプラインを維持することが極めて重要であり、ClickHouse はその中心的な役割を果たしています」

— Mehdi Osman, OpenReplay 創業者兼 CEO

クエリ側では、検索からファネル、ヒートマップ、フローチャートに至るまで、プロダクト内のあらゆる画面表示が 2 秒未満で応答することを目標としています。チーム最近、ClickHouse のクエリキャッシュを有効にしました。これにより、あるエンジニアが実行したクエリの結果を、数分後に別の同僚が瞬時に取得できるようになりました。「キャッシュは、有効にするだけで期待どおりに機能する機能の 1 つです」と Mehdi 氏は言います。ClickHouse 向けのクエリ記述について他に付け加えることがあるか尋ねられた際、Taha 氏も同じ答えを返しました。「特別なことは何もありません」と彼は言います。「ただ動くだけです」。

1 日に数十万件もの録画を人間が見ることはできないため、OpenReplay は現在、ClickHouse を活用してセッション録画を自動的に確認し、プロアクティブに問題を浮き彫りにする新しいエージェント機能を開発しています。「人間と同じように全ユーザーセッションを確認することを任務とする、アナリストチームのようなものだと考えてください」と Mehdi 氏は語り、エージェントが生成するすべてのトレースが ClickHouse に保存されると付け加えました。「これは評価のために使用し、トラブルシューティングのために使用し、エージェントがどのように機能しているかを学習するために使用しています」。

創業から 7 年が経過し、ClickHouse は OpenReplay が自社の管理下にないインフラ上で稼働させる際に信頼を寄せる、数少ない標準コンポーネントの 1 つとなりました。顧客は自社サーバー上にデータを保持し続け、OpenReplay のスタックは顧客自身で運用できるほど無駄のない状態を保っています。「これらの技術のすべてに選定された理由があります」と Mehdi 氏は言います。「それは、顧客へのデプロイやその後のメンテナンスに関しても、運用負荷が極めて少ないということです」。