SocialprufがNeonからClickHouse Managed Postgresへの移行により高速で信頼性の高いデータスタックを構築した方法

クリエイターエコノミーでは膨大なパフォーマンスデータが生成されますが、その大半はいまだにスクリーンショットや古い PDF、あるいは勘の中に閉じ込められたままです。Socialpruf は、その状況を変えるために設立されました。

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

このようなプロダクトを大規模に稼働させるには、インフラ面で大きな課題が伴います。現在、Socialpruf は毎秒数百件の投稿を取り込んでいます。データを迅速かつ確実にユーザーへ届けることは、このプロダクトの根幹をなす要素です。

創設者兼 CTO の Semyon Khlavich 氏と、プリンシパルエンジニアの Evgenii Baldin 氏にお話を伺い、Socialpruf が速度と信頼性を最大限に高めるデータスタックをどのように構築したのかを探りました。同社は分析ワークロードを ClickHouse Cloud へ移行してほぼ瞬時のクエリパフォーマンスを実現し、本番環境で ClickHouse Managed Postgres を採用した最初のチームの 1 つとなりました。

分析課題の解決 #

Socialpruf は、最新のイベント駆動型アーキテクチャ上で動作しています。ユーザー向けプロダクトとしては Tanstack Start 製の Web アプリケーションを提供し、そのバックエンドでは Node.js パイプラインがソーシャルメディアデータを継続的に収集・処理しています。投稿の取り込み、動画のフック分析、人口統計データの抽出、メンションの処理、プラットフォームをまたいだ共同作成者データの集約などを担っています。外部プロバイダーやブラウザベースのコレクターからのデータ収集は Python ワーカーが担当し、すべてのデータは信頼できる唯一の情報源(System of Record)として Postgres に集約されます。

「Postgres は豊富な機能を備えた素晴らしいデータベースであり、立ち上げてすぐに使い始められることから採用しました」と Evgenii 氏は述べています。

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

2025年の夏、同社はデータ業界の大手各社が分析ワークロードをどのように処理しているかの調査を開始しました。そこで行き着いたのが ClickHouse であり、その効果はすぐに現れました。Postgres から CDC を介して 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 Managed Postgres が発表された際、既存の ClickHouse ユーザーである同社にとって、その提供価値はすぐに明らかでした。ClickHouse とネイティブに共存するように構築されたエンタープライズグレードのサービスであり、両システムが同じインフラ内に物理的に配置されるため、ネットワーク転送コストが排除されます。さらに、信頼性とパフォーマンスを支える NVMe ストレージも備わっています。

「分析エンジンとトランザクションエンジンの両方が同じプラットフォーム上で共存するという構成は、私たちのビジョンと合致していました」と Semyon 氏は言います。「このアーキテクチャこそが、私たちが顧客に届けたかったシームレスな分析体験を実現してくれるものでした」

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

移行してまだ間もないものの、ClickHouse のマネージド Postgres サービスへの移行で最も大きな効果をもたらしたのは安定性でした。「移行後、接続の問題や再起動は一度も発生していません」と Semyon 氏は述べています。迅速なリリースを誇りとするチームにとって、それらの接続切断(およびそれに伴う手動対応)が解消されたことは極めて大きな違いを生み出しています。

「私たちは安定性とスピードを重視しています」と Evgenii 氏は付け加えます。「そのバランスを保つことが私たちにとって不可欠です」

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

以下の画像は、移行前後の Socialpruf における上位クエリの P50 および P99 レイテンシを示すライブダッシュボードです。ご覧のとおり、すべてのクエリが以前より高速化されており、一部のクエリでは最大 5 倍のパフォーマンス向上が見られます。

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

「結局のところ、私たちが目指しているのは顧客にとって最高のプロダクトを作ることです」と Semyon 氏は語ります。「マネージド Postgres は、技術面における運用のシンプルさと信頼性の確保という要素が大きいです。分析レイヤーとトランザクションレイヤーを統合することで技術的なオーバーヘッドが減り、コストを削減でき、単一のプラットフォームで運用できます。ClickHouse は、私たちが顧客に提供する価値における大きな差別化要因となっています」

Neon から ClickHouse Managed Postgres へのシームレスな移行 #

Socialpruf が ClickHouse Managed Postgres への移行を決めた決定打の 1 つは、移行プロセスそのもの、特にそれを成功に導いた ClickHouse チームのサポートにありました。

「当初は Postgres のロジカルレプリケーションを使って約 0.5 TB のデータを移行しようとしましたが、1 日経って処理が失敗してしまいました」と Semyon 氏は振り返ります。「そのとき ClickHouse チームが PeerDB の利用を提案してくれ、移行をシンプルかつ確実に行えるよう緊密に協力してくれました」

移行作業は、移行先データベースに必要なスキーマを作成し、対象テーブルを指定して Neon から ClickHouse Managed Postgres へのミラーリングを開始することから始まりました。0.5 TB のデータセットは数時間でコピーされ、その後も移行先データベースはソース側と継続的に同期され続けました。

Socialpruf はこのミラーリング構成を約 1 週間運用し、同期中のデータベースからフォークを作成してアプリケーションのテストを行いました。十分な検証を経た後、本番環境のカットオーバー枠を設定しました。このフェーズでは、ClickHouse チームが Socialpruf と密接に連携しながら最終的な移行ステップを完了させました。

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

カットオーバー時に発生した予期せぬ課題の 1 つが接続数でした。接続数が Postgres の max_connections の上限を超えてしまったのです。そこで導入されたのが、ClickHouse Managed Postgres に同梱されている PgBouncer でした。

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

ClickHouse のアプローチの大きな特長は、複数の並列ピアリングされた PgBouncer インスタンスをサポートしている点です。これにより、運用上の複雑さをユーザーに意識させることなく、接続処理を水平方向にスケールさせることができます。この仕組みによって、Socialpruf は本番環境での大量の接続を効率的に処理できるようになりました(PgBouncer のアーキテクチャについては、今後の技術ブログで詳しく解説する予定です)。

OLTP と OLAP の統合による将来を見据えた基盤づくり #

Semyon 氏と Evgenii 氏にとって、ClickHouse のマネージド Postgres サービスへの移行の決断は、長く悩むようなものではありませんでした。タイミングが良く、ソリューションとして理にかなっており、すでに同社の分析基盤を変革していた ClickHouse に対する信頼があったからです。

その合理的な判断には、チーム全体の理念が反映されています。Socialpruf は何よりもプロダクトを第一に考える企業であり、インフラはプロダクトに奉仕するために存在するものであって、その逆ではありません。現在、ClickHouse は顧客を驚かせるリアルタイム分析体験を提供し、その背後でマネージド Postgres サービスが安定した高性能のトランザクション基盤を支えています。

Semyon 氏は Socialpruf には「大きな計画」があると言います。そして今、それに見合うデータインフラが整ったことで、その実行に集中できるようになりました。「Postgres と ClickHouse の組み合わせには非常に満足しています。問題なく動作し、私たちのニーズを満たしてくれています。事業の成長に伴い、さらに重要な役割を果たすことになるでしょう」

ClickHouse Managed Postgres の利用体験を一言で表すとどうなるか尋ねると、Semyon 氏と Evgenii 氏は一瞬顔を見合わせ、こう答えました。「信頼性が高く、高速で、最高品質です」