ユニバーサルインターフェース: QuintoAndar が Managed Postgres で ClickHouse をプラグアンドプレイにした方法

QuintoAndar は 2013 年の創業で、保証人の仕組みを自社の審査に置き換えました。現在はラテンアメリカ最大の住宅プラットフォームとして、物件を借りたい、買いたい、売りたい人に、直接的でシンプルかつ透明性のある体験を提供しています。毎月 15,000 件を超える新規賃貸契約と 3,000 件の売買契約を成立させ、650,000 件以上の内見予約を受け付けています。

Bruno Brito 氏は、カスタマーデータプラットフォーム (CDP) チームのテックリードマネージャーです。このチームは、入居者、オーナー、エージェントに関するデータの収集、統合、一元化を担っています。「私たちは 1,400 万人を超えるユーザーから月に 10 億件以上のイベントを収集しており、そのうち月間 9 億件近くの生イベントが ClickHouse に入っています」と同氏は語ります。そのデータは、月におよそ 3 億件の API リクエストを通じて、チャットボットや社内サービスへ返されます。

Bruno 氏は私たちの先日のウェビナーに参加し、チームが ClickHouse Cloud 上で CDP を再構築している過程を、統合の取り組みから、それを止めかけた障壁、そして ClickHouse Managed Postgres が足りなかったピースになった経緯まで語りました。

従来の Lambda アーキテクチャの問題 #

CDP の起点は、モバイルユーザーのトラッキングイベントと、トランザクションデータベースからの CDC (Change Data Capture) で、いずれも Kafka 経由でストリーミングされます。両者は自社開発のイベントゲートウェイに流れ込み、チームはそこでガバナンスを適用し、変換を実行し、通過するイベントを補強します。これらはすべて、Bruno 氏が「顧客を中心にした 360 度の視点」と呼ぶものを実現するためのものです。

従来のアーキテクチャは、そこから古典的な Lambda 型の構成に分岐していました。ホット層 (Datazord と呼ばれる、こちらも自社開発の Postgres サービス) はゲートウェイの出力トピックを消費し、低レイテンシの読み取りを理由に選んだ自前の Postgres データベースから、チャットボットなどの社内コンシューマーへユーザー情報を提供していました。コールド層は Kafka Connect ですべてをデータレイクのランディングゾーンへ投入していました。そこでは 24 時間 365 日稼働する Databricks のワークフローがデータをシルバー層へ加工し、分析用 ETL と、ユーザーアクティベーションツールである Hightouch がそこから読み取っていました。

従来の CDP アーキテクチャ: イベントゲートウェイの出力トピックは、Datazord が Postgres からチャットボットにデータを提供するホット層と、24 時間 365 日の Databricks ワークフローを回すコールド層に分岐していた。

Bruno 氏の説明では、問題はいくつかありました。第一に、チームは 2 つの別々のコードベースを保守しなければなりませんでした。Lambda アーキテクチャを運用した人なら誰もが知る、おなじみの負担です。第二に、コールドパスでは膨大な量の重複イベントのために、Delta テーブルに対する MERGE INTO 操作が絶えず必要でした。「数百万件ものイベントを毎回重複して処理するのは、コストの面でも時間の面でも負担が大きくなっていました」と Bruno 氏は言います。そして第三に、ホット層を担う Postgres インスタンスは、そこを流れるイベント量には向いていないことが明らかになりつつありました。

「アーキテクチャとしては、いささか複雑でした」と Bruno 氏は言います。「そこで私たちは考えました。どうすれば簡素化し、高速化し、こうした情報をすべて提供できる高鮮度・低レイテンシのアーキテクチャを手にできるのか、と。……そのときに見つけたのが ClickHouse でした」

ClickHouse Cloud への統合 #

チームの答えは、Kafka トピックをパイプラインの出力として扱うのをやめ、代わりにイベントゲートウェイから ClickHouse へ直接書き込むことでした。旧アーキテクチャの図を順に指しながら、Bruno 氏は変わった点を挙げていきます。「これを消せる、これも消せる、あれも消せる……そして、分析クエリはすべて ClickHouse で支えられます」

新しいアーキテクチャでは、Hightouch はユーザーアクティベーションのために ClickHouse にクエリを実行し、Datazord は自前の Postgres ではなく ClickHouse から API リクエストに応答しつつ、引き続き 1 秒未満で結果を返せます。これにより、ランディングゾーン、絶え間ない MERGE INTO 操作、そして 2 つ目のコードベースが不要になります。

Bruno 氏は、QuintoAndar の全社的なデータ組織が Trino 上で Superset を運用していることに触れます。同氏のチームは、自分たちだけが他の全員から孤立してしまうのではないかと懸念しました。実際には、そうはなりませんでした。ClickHouse のコネクターを使えば Trino と Apache Spark のどちらからも CDP のテーブルにアクセスでき、逆に ClickHouse 側からは社内データレイクの Delta テーブルを読み取れました。「このスタックとの統合は、私たちにとって大きな問題ではありませんでした」と同氏は言います。

CDP チームが実装を進めている新しいスタック: イベントゲートウェイが ClickHouse へ直接書き込み、Superset、Trino、Spark のいずれも CDP のテーブルにアクセスできる。

障壁: 「ClickHouse はどこ?」 #

ClickHouse は完璧な選択に見えました。しかしそこで、Bruno 氏いわく、すべてのエンジニアがいつか直面する瞬間が訪れました。「アーキテクチャに新しい部品を選び、テストを始めると、素晴らしく動く。そして、他のサードパーティツールすべてとの統合を始めると……」

QuintoAndar では、Hightouch はマーケティング組織の運営の中核にあり、キャンペーンを実行する各プラットフォームへオーディエンスデータを同期しています。マーケティングチームはその Customer Studio 機能を使いたいと考えていました。オーディエンスの構築、ユーザーのセグメント化、A/B テストの実施、複数ステップのジャーニーの組み立てができる機能です。ところが、Bruno 氏のチームがドキュメントで Customer Studio の対応ソースを確認すると、Snowflake、Databricks、BigQuery、Redshift、Athena、Synapse、MS SQL Server、PostgreSQL、Greenplum、Microsoft Fabric と並ぶリストに、ひとつだけ見当たらない名前がありました。

「ClickHouse はどこ?」と尋ねたことを Bruno 氏は覚えています。「私たちのユースケースすべてに完璧に合う素晴らしいソリューションに見えました。合わなくなるまでは」

QuintoAndar のスタックの中で条件を満たすエンジンは Databricks だけでした。しかし中央のデータチームはコストの高さを理由に Databricks SQL Warehouse をやめ、Trino のようなオープンソースの代替へ移ると決めており、CDP チーム自身も ClickHouse を使いたいと考えていました。しかし、Trino も対応していませんでした。

残る選択肢は 1 つ、Postgres でした。折よく、ClickHouse は分析ワークロードとトランザクションワークロードを 1 つの統合されたスタックで実行できる新しいサービスを提供し始めたところでした。Bruno 氏はこう振り返ります。「そのときに、ClickHouse のマネージド Postgres サービスのことを耳にしたのです」

足りなかったピース: ClickHouse Managed Postgres #

Hightouch を ClickHouse Managed Postgres に接続すると、Postgres が Hightouch に代わって ClickHouse にアクセスします。

「ClickHouse で目にした優れたパフォーマンスや低レイテンシ、その素晴らしい点のすべてを、ClickHouse Managed Postgres を通じて Hightouch でも活用できました。それが私たちのアーキテクチャに足りなかったピースでした」 — Bruno Brito 氏、QuintoAndar テックリードマネージャー

鍵となる仕組みは pg_clickhouse 拡張です。セットアップは簡単だったと同氏は説明します。拡張を作成し、ClickHouse を指す外部サーバーを作成し、スキーマを作成して、外部テーブルをインポートする。それだけで、ClickHouse のテーブルは通常の Postgres テーブルとしてクエリでき、JOIN や集約は Postgres 側に持ち帰って処理するのではなく ClickHouse にプッシュダウンされます。

Hightouch は ClickHouse Managed Postgres に接続し、Postgres が分析クエリを ClickHouse にプッシュダウンする。ClickHouse には、イベントゲートウェイがすでにイベントを直接書き込んでいる。

Postgres から ClickHouse への往復がパフォーマンスに与える影響を尋ねると、Bruno 氏は無視できる程度だと答えます。「Hightouch のユースケースでは、まったく影響しません」

そして Postgres はクエリを転送しているだけではありません。Hightouch の Lightning Sync 機能は自身の状態 (プランナーテーブルと監査テーブル) を保持し、スケジュールされた同期のたびにオーディエンス全体ではなく変更分だけを送ります。これらのテーブルは Postgres 上の NVMe ストレージに置かれています。結果として、1 つの接続が 2 つの役割を果たしています。

「OLTP データベースと同じように Postgres にデータを永続化しながら、分析クエリは実際には ClickHouse で実行しています。つまり、両方の良いところを活用しているのです」 — Bruno Brito 氏、QuintoAndar テックリードマネージャー

ユニバーサルインターフェースとしての Managed Postgres #

QuintoAndar にとって、ClickHouse Managed Postgres の最大の利点のひとつは、アーキテクチャがはるかにシンプルになることです。「ClickHouse が、Postgres に対応するどんなサードパーティツールにもつなげられる、プラグアンドプレイのデータベースになります」と Bruno 氏は言います。

そのシンプルさはガバナンスを犠牲にしていない、と同氏は付け加えます。「Postgres が ClickHouse 上のすべてにアクセスできるようになるわけではありません。ユーザーやロールを作成し、必要なときに必要なものへアクセス権を与える必要は変わりません」

また、ひとつの統合のためだけに 2 つ目のウェアハウスやクエリエンジンに費用を払う必要がなく、ClickHouse の価値を余さず活かせます。Bruno 氏の言葉を借りれば、「ClickHouse の力を本当に活かし、最大限に引き出せます」。

Hightouch の置き換えを検討したことはあったかと尋ねると、Bruno 氏は、その選択肢を考える必要はまったくなく、すでにある解決策をそのまま使い続けられたと答えます。今後は、Postgres に対応するどんなツールでも、同じやり方で ClickHouse にアクセスできます。「一部のパートナーがまだ対応していなくても、ClickHouse を活用し続けられます」と同氏は言います。