まとめ
- Walmartに最近買収されたVibe.coは、ClickHouse Cloudを活用して、数十億件の広告インプレッションにわたる数千のコネクテッドTV(CTV)広告主向けのリアルタイムキャンペーンレポートを提供しています。
- 事前集計アーキテクチャの限界に達したため、同チームはPostgresから移行しました。現在、プラットフォームはクライアントのキャンペーンレポートの90%以上を100ms未満で配信しており、アーキテクチャを再設計することなく約100GBから2TB以上へとスケールしています。
- セルフホストではなくClickHouse Cloudを選択した理由は、運用のシンプルさ、チームによるサポート、そしてストレージとコンピュートの分離による予測可能な価格設定にあります。
Connected TV(CTV)で番組をストリーミング視聴しているとき、広告に気づくことはあっても、それがどのようにしてそこに表示されたのかを深く考えることはあまりないでしょう。しかし、あらゆる広告の裏側では、誰にリーチするか、いつ、どのプラットフォームで、どの頻度で配信するかといった、一連の意思決定が行われています。専任のメディアチームを抱える大手ブランドにとって、この世界を渡り歩くことは常に複雑ではありましたが、少なくとも管理可能でした。それ以外の企業にとっては、多くの場合、まったく手の届かない領域だったのです。
先日Walmartに買収されたVibe.coは、あらゆる規模のブランドがCTV広告を5分以内に利用できるようにすることを使命とする、オールインワンプラットフォームです。顧客は誰もが知る大手ブランドから、初めてテレビ広告を打つ中小企業まで多岐にわたります。彼らを結びつけているのは、GoogleやMetaの広告を出稿したことがある人なら誰でも馴染みのあるセルフサービス型プラットフォームを通じて、プレミアムなストリーミング広告枠にアクセスできるという点です。
Rémi PaulinはVibeのデータプラットフォームチームでStaff Data Engineerを務めており、過去2年間、これらすべてを可能にするインフラを構築してきました。彼はシンプルさを保つことを強く信条としています。可動部分が少なければ壊れる箇所も少なくなり、壊れる箇所が少なければ、クライアントが本当に信頼できるプラットフォームになる、という考えです。この哲学は、ユーザー体験、システムアーキテクチャ、そして──もちろん──リアルタイム分析にも当てはまります。さらに近年では、AIエージェントが人間と同じように流暢に使えるインフラを選ぶこと、つまり実務的にはSQLを本格的にサポートするデータベースを選ぶことにも通じてきています。
「最良のアーキテクチャとは、問題を実際に解決できる最もシンプルなものです。ClickHouseは、パフォーマンスや柔軟性を犠牲にすることなく、アーキテクチャをシンプルに保たせてくれます。そしてその組み合わせは、聞こえるよりもずっと稀なものなんです。」
— Rémi Paulin、Staff Data Engineer、Vibe
適切なツール、ただしスケールが合わない
多くのスタートアップと同様に、Vibe.coもPostgresから始まりました。Rémiは「非常に汎用性が高く、多くのことができます」と語ります。しかしプラットフォームが成長し、広告インプレッション数が数十億に達すると、Postgresの限界が見えてきました。「PostgresはOLAP向けに作られていません。数十億行に対する集計中心のクエリを実行するようになると、事前集計層がボトルネックになりました」とRémiは言います。
問題はアーキテクチャ的なものでした。Postgresは、クライアント向けレポーティングを支える大量かつ集計中心の分析クエリ、つまりOLAPワークロード向けに設計されていなかったのです。「データベースのサイズが爆発しないように、そしてパフォーマンスを許容範囲に保つために、データを事前集計するジョブを持っていました」とRémiは説明します。
それは機能していましたが、ぎりぎりの状態でした。新しいレポート用途が出るたびに新しいジョブを書く必要があり、想定されるクエリパターンから外れるとすぐに遅くなったり高コストになったりしました。変換レイヤーが、スタックの中で最も脆弱な部分になっていたのです。
Rémiとチームが望んでいたのは、この中間層を完全になくすことでした。クライアントは、事前集計ジョブが出力するものだけを消費するのではなく、キャンペーンデータをインタラクティブに切り分けて分析できる必要がありました。そして社内でも、他のチームがそのデータの上に新しいプロダクトを構築する際、毎回データプラットフォームチームに新しいパイプラインを依頼せずに済むようにする必要がありました。
「アーキテクチャをシンプルにしたかったんです」とRémiは言います。「データを直接データベースに投入し、あらゆる合理的な集計に対して十分に高速にクエリを実行できるようにしたかった。」このビジョンにおいては、事前計算も、新しいユースケースやクエリパターンごとの専用パイプラインも必要ありません。適切なデータベースがあれば、想定済みのユースケースの中だけで柔軟なのではなく、真に柔軟なシステムを構築できるのです。
なぜClickHouse Cloudを選んだのか
パフォーマンスと柔軟性のために設計されたカラム型OLAPデータベースであるClickHouseは、Postgresを置き換える論理的な選択肢でした。問題は、それをどうデプロイするかでした。
チームは選択肢を評価しました。セルフホスト版のClickHouse、別のベンダーが提供するマネージド版、そしてClickHouse Cloudのベンチマークを行ったのです。Vibeのチームはセルフホストにも慣れており、ストレージのローカリティによってわずかなパフォーマンス上の優位性も確認できましたが、Rémiはトレードオフについて明確に見据えていました。「スタートアップとして、データベースを管理する時間はありません。セルフホストのために人的リソースを割きたくないし、スケールするにつれて状況は悪化する一方だとわかっていました。」
また、プロダクトを実際に作っている人々と組むことにも大きな価値があります。「マネージドを選ぶということは、サービスそのものと同じくらい、それを運用する人々に賭けるということです」とRémiは言います。「ClickHouseを実際に作っているエンジニア、つまりチームの背後にあるチームと仕事をすれば、私たちが成長する中で、彼らのロードマップと私たちのロードマップの整合性が保たれます。」
これは、Rémiのインフラ選定やパートナー選びに関するより広い哲学にも通じます。「知識豊富なパートナーに囲まれていることは間違いなく良いことです。特に、素早く動きたいけれど、あらゆるブログ記事やドキュメントを読み込む時間がないときには」と彼は語ります。「優れたパートナーと仕事をすることで、新鮮なアイデアや新鮮な視点が得られます。」
運用のシンプルさやチームのサポートに加えて、Rémiが惹かれたのはClickHouse Cloudのストレージとコンピュートの分離でした。彼は、他のウェアハウスソリューションが採用しているクエリ課金と対比します。そこでは、大規模なデータセットに対する追加クエリごとにコストが増え、成長するとすぐに請求額の急騰につながる可能性があります。「プラットフォーム上の顧客が増えても、既存の顧客がより多くのデータを持つようになっても、予測不能なコスト急増を心配する必要がありません」とRémiは言います。
GBからTBスケールへ、アーキテクチャを変えることなく
ClickHouse Cloudに移行して以来、Vibeの保存データは約100 GBから2 TB超にまで増加しましたが、アーキテクチャはほとんど変わっていません。「これは成功を測る重要な指標の一つです」とRémiは語ります。
「何かを構築して、その後データ量が20倍になっても、アーキテクチャもデータフローも、コンシューマーのデータアクセス方法も変えていません。インスタンスを少しスケールアップはしましたが、それは背後にあるエンジニアリングチームをスケールさせるより、はるかに安価です。」
— Rémi Paulin、Staff Data Engineer、Vibe
Rémiが最も注視している2つの指標は、コストとレイテンシです。コストについて彼はあまり心配していません。「ストレージは安いですから」と彼は言います。「1テラバイト保存しようが5テラバイト保存しようが、請求額が大きく変わることはありません。ボリュームが増えれば、インプレッションも広告も増える。つまり会社が好調ということです。その数字が上がることを心配することは決してありません。」
真の作業が行われるのはレイテンシの部分です。ClickHouseの組み込みオブザーバビリティにより、チームはすべてのクライアントにわたるクエリパフォーマンスをきめ細かく可視化できます。チームはリフレッシュ可能なマテリアライズドビューを基盤としたホット/コールドのティア分け構成を採用しています。過去30日間をカバーするホットテーブル(クライアントクエリの大部分をこれが処理します)が、完全な履歴データセットの前に配置され、各層は実際のクエリパターンに合わせてチューニングされています。その結果、数十億のインプレッションにまたがるクライアントキャンペーンレポートの90%以上で、100ms未満の応答時間を実現しています。
「パフォーマンスは素晴らしいです」とRémiは言います。「非常に満足しています。」
シンプル、柔軟、そしてスケール可能な設計
Vibeのストーリーから何を学んでほしいかとRémiに尋ねると、いくつかのテーマが繰り返し登場します。シンプルさ、品質、柔軟性、そして長期的な持続性です。彼の見方では、これらはすべてつながっています。
「可動部分が少なければ少ないほど、何かが壊れるリスクも減ります」と彼は言います。「アーキテクチャがシンプルであるほど、品質は高くなります。」つまり品質とは、単に稼働時間やパフォーマンスの話ではないのです。それは信頼の話です。「クライアントはもちろん、社内チームも、私たちが提供するものを安心して信頼してくれています。」
その信頼をスケールさせるのが柔軟性です。ClickHouseを基盤とすることで、Vibeの他のチームは、毎回データプラットフォームチームに個別ソリューションを依頼することなく、新しいプロダクトのアイデアを追求できます。「良いアイデアを思いついたら、そのまま実装できるようにしたいんです」とRémiは言います。「素早く動きたいなら、柔軟性は非常に重要です。」
その柔軟性はSQLにも及びます。多くの高速データベースは、名ばかりでSQLをサポートしており、ドキュメントの奥にサポートされていない機能の長いリストが埋もれているものです。ClickHouseはそれとは異なる、とRémiは主張します。「ClickHouseはその点で妥協せずに設計されています」と彼は言います。「SQLはファーストクラスの市民です。」これは、アナリストや社内チームにとって重要なだけでなく、データチームの働き方の中でますます大きな存在になりつつあるAIエージェントにとっても重要です。SQLはエージェントが最もよく知る言語であり、それを流暢に話すデータベースは戦略的資産となるのです。
Rémiが最後に繰り返し強調するのは、長期的な持続性です。データインフラの領域は速いペースで動いており、それに合わせて進化しない技術は置いていかれます。信頼できる進化の軌道を持つプラットフォームを選ぶことは、今日それが何をしてくれるかと同じくらい重要である、というのがRémiの見方です。Vibeにとってそれは、業界の進化に歩調を合わせるパートナーを選ぶこと、そして初日に下した決定に縛られることなくチームが成長できる余地を与えてくれるパートナーを選ぶことを意味しています。



