SocialprufがNeonをClickHouse管理のPostgresに置き換えて、より高速で信頼性の高いデータスタックを構築した方法

クリエイターエコノミーは膨大な量のパフォーマンスデータを生み出していますが、その大半は依然としてスクリーンショットや古くなったPDF、そして勘に頼った判断の中に閉じ込められたままです。Socialpruf は、この状況を変えるために作られました。

トロントを拠点とするこのプラットフォームは、自らをブランド、タレントエージェンシー、スポーツメディア企業向けの「ソーシャルオペレーティングシステム」と称し、Instagram、TikTok、YouTube、Xのパフォーマンスデータを集約して、リアルタイムのダッシュボード、キャンペーントラッカー、共有可能なレポートを提供しています。

このような製品をスケールで支えるには、大きなインフラ上の課題があります。現在、Socialprufは毎秒数百件の投稿を取り込んでいます。データを顧客へ高速かつ確実に届けることが、この製品の価値を支える中核となっています。

私たちは、創業者兼CTOのSemyon Khlavich氏と、プリンシパルエンジニアのEvgenii Baldin氏に話を聞き、Socialprufがどのようにしてスピードと信頼性を最大化するデータスタックを構築したのかを伺いました。同社は分析ワークロードを ClickHouse Cloud に移行してほぼ瞬時のクエリ性能を実現し、さらに ClickHouseによるマネージドPostgres を本番環境で利用する最初のチームの一つとなりました。

分析の課題を解決する #

Socialprufは、モダンなイベント駆動型アーキテクチャ上で動作しています。顧客向けの製品としてTanstack StartのWebアプリが稼働し、その背後ではNode.jsパイプラインがソーシャルメディアデータを継続的に収集・処理しています。投稿の取り込み、動画フックの分析、デモグラフィックデータの抽出、メンションの処理、プラットフォーム横断での共同投稿者データの集約などを担っています。Pythonワーカーは外部プロバイダーやブラウザベースのコレクターからのデータ収集を行い、すべてのデータは記録システムであるPostgresに流れ込みます。

「Postgresは多機能で素晴らしいデータベースで、立ち上げて稼働させるのが簡単だったので、それをベースに構築を始めました」とEvgenii氏は語ります。

しかしSocialprufが成長するにつれて、分析レイヤーが追いつかなくなってきました。顧客向けダッシュボードはPostgres上でその都度計算されており、ロード時間が1秒、2秒、時には3秒へと延びていました。「当時はそれほど大量のデータがあったわけでもありませんでした」とSemyon氏は付け加えます。「成長して顧客が増えれば、ますます遅くなることは予測できました」。

2025年の夏、彼らはデータ領域の大手プレイヤーが分析ワークロードをどのように扱っているかを調査し始めました。そこでClickHouseにたどり着き、その効果はすぐに表れました。CDCを使ってPostgresからClickHouseへデータをレプリケートし、フロントエンドの分析クエリをすべてClickHouseへルーティングすることで、Socialprufは数百万行をミリ秒単位で集計できるようになりました。これは、スケール時のPostgresでは到底実現できないほどの大幅な改善でした。

製品への影響は明確でした。「顧客にとって本当に『すごい』と感じる体験を提供できています」とSemyon氏は語ります。「私たちには優れたUXがありますが、それにClickHouseのスピードが加わることで、素晴らしいユーザー体験が生まれるのです」。

Neon Postgres における信頼性の問題とネットワークコストへの対応 #

Socialpruf は当初から、Databricks 傘下の Neon 上で Postgres を運用していました。立ち上げ当時は、セットアップが速く、開発者体験も良好で、当時のニーズには十分すぎるほどで、自然な選択でした。「しばらく使っていて、うまく機能していました」と Evgenii 氏は語ります。「しかし、規模が拡大し始めると、2 つの問題に直面しました」

1 つ目は安定性です。データ処理パイプラインを妨げる接続切断や再起動が時折発生するようになりました。バックグラウンドジョブが停止し、影響を受けたサービスを特定して再起動するために手動の介入が必要になりました。「極端に時間がかかるわけではありませんが、常に目を配り、定期的にチェックしなければならないボトルネックになっていました」と Semyon 氏は述べています。

2 つ目はコストです。CDC レプリケーションによって Neon から ClickHouse へ絶え間なくデータがストリーミングされるようになると、ネットワーク転送料金が積み重なっていきました。「同じ AWS リージョン内にあるにもかかわらず、Neon はネットワーク転送料金を請求していました」と Semyon 氏は説明します。「コンピュート費用の半分以上に達し、請求額がどんどん膨らんでいたのです」

チームは別のソリューションを試すことも検討しました。「PlanetScale を検討した時期もありましたが、Neon と同様の問題を抱える可能性があると考え、先送りにしていました」と Evgenii 氏は述べます。

ClickHouse がマネージドする Postgres が発表されたとき、既存の ClickHouse 顧客であった彼らにとって、その価値提案はすぐに明確になりました。ClickHouse と同じインフラ上に物理的に同居するよう設計されたエンタープライズグレードのサービスで、ネットワーク転送コストを排除し、信頼性とパフォーマンスのために NVMe ストレージで支えられています。

「分析エンジンとトランザクションエンジンを同じプラットフォーム上で共存させたいという我々のビジョンに合致していました」と Semyon 氏は語ります。「このアーキテクチャは、顧客に提供したいと考えていたシームレスな分析体験をもたらしてくれるはずでした」

接続切断や再起動ゼロで、Postgres パフォーマンスが最大 5 倍に #

まだ移行初期ではありますが、ClickHouse のマネージド Postgres サービスへの移行による最大のインパクトは安定性でした。「切り替えて以来、接続の問題や再起動は一度も発生していません」と Semyon 氏は述べます。スピード重視で開発を進めるチームにとって、こうした切断(およびそれに伴う手動対応)を排除できたことは大きな違いをもたらしました。

「我々は安定性とスピードの両方を重視しています」と Evgenii 氏は付け加えます。「そのバランスを保つことが我々にとって重要なのです」

パフォーマンス面では、数字が明確に物語っています。Postgres のクエリパフォーマンスは全体で約 30% 改善され、一部のクエリは最大 5 倍の向上を示しました。Datadog のメトリクスを見ると、特定のクエリは 42 ミリ秒から 22 ミリ秒へと、およそ 50% の改善を達成しました。これらの向上により、データ量が増加してもインスタンスをダウンスケールする余地が生まれる可能性もあります。NVMe ベースの Postgres によるこれらのパフォーマンス向上は、価格性能比の改善も期待でき、Socialpruf がはるかに効率的にリソースを管理できるようになると見込まれています。

下の画像は、移行前と移行後の Socialpruf の主要クエリの P50 および P99 レイテンシをリアルタイムで表示したダッシュボードです。ご覧の通り、すべてのクエリが以前より高速化され、一部のクエリでは最大 5 倍のパフォーマンス向上を達成しています。

一方、Semyon 氏が「ClickHouse の魔法のような部分」と呼ぶ ClickHouse の分析レイヤーは、引き続きコアプロダクト体験を支えています。数百万行をミリ秒単位で集計し、データ量に関わらずほぼ瞬時にロードされるダッシュボードを実現しています。

「結局のところ、我々は顧客にとって最高の製品を作りたいのです」と Semyon 氏は語ります。「マネージド Postgres は、技術面での運用のシンプルさと信頼性に関わる部分です。分析レイヤーとトランザクションレイヤーを統合することで、技術的なオーバーヘッドが減り、コストが下がり、単一のプラットフォームで作業できるようになります。ClickHouse は、顧客に提供する価値において重要な差別化要因です」

Neon から ClickHouse マネージド Postgres へのシームレスな移行 #

Socialpruf が ClickHouse マネージド Postgres への移行を決断する上での要因の 1 つが、移行そのもの、特に ClickHouse チームがそれを実現する上で果たした役割でした。

「最初は Postgres の論理レプリケーションを使って約 0.5 TB のデータを移行しようとしましたが、1 日後に失敗しました」と Semyon 氏は振り返ります。「その後、ClickHouse チームは PeerDB の使用を提案し、移行をシンプルかつ信頼性の高いものにするため、我々と緊密に連携してくれました」

移行は、ターゲットデータベースに必要なスキーマを作成し、必要なテーブルで Neon から ClickHouse マネージド Postgres へのミラーを開始することから始まりました。0.5 TB のデータセットは数時間以内にコピーされ、その後はターゲットデータベースがソースと継続的に同期され続けました。

Socialpruf はこのミラー構成を約 1 週間運用し、同期中のデータベースからフォークを立ち上げてアプリケーションをテストしました。十分な検証が完了した後、本番切り替え枠が予定されました。このフェーズでは、ClickHouse チームが Socialpruf と緊密に協力し、最終的な移行ステップを完了しました。

PgBouncer による大規模な接続管理 #

切り替え時に予期しなかった課題の 1 つが接続数でした。接続数が Postgres の max_connections 上限を超えてしまったのです。そこで彼らが頼ったのが、ClickHouse マネージド Postgres に含まれている PgBouncer でした。

Socialpruf では、アプリケーションと取り込みワーカーを合わせると、数千のデータベース接続が同時に発生することがあります。移行以来、PgBouncer はその負荷を問題なく安定して処理してきました。

ClickHouse のアプローチにおける重要な差別化要因は、複数のパラレル・ピアード PgBouncer インスタンスをサポートしていることです。これにより、運用の複雑さを顧客から隠したまま、接続処理を水平方向にスケールできます。これにより Socialpruf は、本番環境で大量の接続を効率的に処理することが可能になりました。(PgBouncer アーキテクチャの詳細については、今後の技術ブログ記事で取り上げる予定です。)

OLTP と OLAP を統合した、将来を見据えた基盤 #

Semyon 氏と Evgenii 氏にとって、ClickHouse のマネージド Postgres サービスへ移行する決断は、長々と検討するようなものではありませんでした。タイミングは適切で、ソリューションは理にかなっており、ClickHouse がすでに彼らの分析をどう変革したかを踏まえると、ClickHouse なら期待に応えてくれると信頼していたのです。

この実用主義は、より広いチーム哲学を反映しています。Socialpruf はまずプロダクトカンパニーであり、インフラはプロダクトに奉仕するために存在するのであって、その逆ではありません。今日、ClickHouse は顧客に「すごい」と言わせるリアルタイム分析体験を支えており、その下層ではマネージド Postgres サービスが安定した高性能なトランザクション基盤を提供しています。

Semyon 氏は、チームには Socialpruf に対する「大きな計画」があり、それに見合うデータインフラを手に入れた今、その実行に集中できると述べています。「Postgres と ClickHouse の組み合わせには非常に満足しています。シンプルに機能し、我々のニーズを満たしてくれます。我々が成長するにつれ、その役割はさらに大きくなっていくでしょう」

ClickHouse マネージド Postgres での体験を一言でまとめてほしいと尋ねられると、Semyon 氏と Evgenii 氏は一瞬顔を見合わせてからこう答えました。「信頼性が高く、速く、プレミアム品質」