クエリが98%高速化、クラウドコストが50%削減:VerihubsのPostgresからClickHouseへの移行の軌跡

Verihubs は、顔認識、ディープフェイク検出、ライブネス検出、eKYCフロー、WhatsApp OTPといったIDインフラを構築するAI企業で、インドネシアの大手銀行、フィンテック、デジタルアプリの多くにサービスを提供しています。

「私たちが扱うデータは重要かつ機密性の高いものです」と、ソフトウェアエンジニアリングリードのRay Antonius氏は語ります。同社は非常に大規模な運用も行っており、「毎日大量のトランザクションを処理しています。全サービス合計で月間およそ5,000万件のAPIコールに上ります」とのことです。

これらのAPIコールの背後にあるのが、Verihubsがトラフィックを把握し、利用量を照合し、クライアントのパフォーマンスを測定し、請求書を生成するために使用しているデータウェアハウスです。ウェアハウスには機密データは保存されていませんが、正確性、速度、信頼性は依然として不可欠であり、特に経理や運用が月次締めや不整合の解消を行う際には重要になります。

2025年12月のジャカルタミートアップ で、Ray氏はVerihubsがClickHouseを中心にウェアハウススタックを再構築した経緯を共有してくれました。約6か月の間に、同社チームはバッチ処理中心のPostgresベースの構成から、より高速で低コストなリアルタイムOLAPアーキテクチャへと移行しました。

Postgresの痛み #

2022年にVerihubsに入社したRay氏が引き継いだのは、Postgresを中心に構築されたデータウェアハウジングパイプラインでした。Docker上で稼働するサービスがデータベースに接続し、Airflowが毎朝データを日次バッチで取り込みます。そのデータはウェアハウスにロードされ、必要に応じて追加のAirflowジョブで加工され、最終的にMetabaseで可視化されていました。

Verihubsの旧アーキテクチャ。Postgresからデータウェアハウスへ日次バッチでデータを取り込む構成。

「主な問題は」とRay氏は言います。「ほぼ すべて に問題があったことです」。

最初のボトルネックは、Postgres上で分析を実行するという選択と、それをOLTPシステムから繰り返しバッチで抽出する方法で行っていたことでした。Ray氏はこう語ります。「Postgresは最初は速かったのですが、ある時点から本当に遅くなり始めました」。単一のサービスでデータ処理に2〜6時間かかることもありました。「処理がタイムアウトして失敗し、やり直す必要があり、経理チームからは催促され続けるのです」と付け加えます。

さらに悪いことに、データが常にパイプラインの想定するウィンドウ内に届くとは限りませんでした。Verihubsは、SMSやWhatsAppメッセージが配信されたか失敗したかを示すコールバックを送るベンダーと連携しています。「本来は24時間以内に届くべきデータが、20日後にようやく届くこともあります」とRay氏は説明します。「また、既にデータを取り込んで請求書を生成し、処理を完了させた後で、実は誤っていたことが判明し差し替えが必要になることもあります。それにはさらに時間がかかります」。

バックフィルによってレコードは修正できましたが、それでPostgresは限界に達してしまいました。「Postgresのバックフィル時の動作特性上、クエリが極端に遅くなるのです」とRay氏は言います。その結果、チームはステークホルダーから同じ質問を繰り返し受け続けることになりました。最新のデータはいつ入手できますか? なぜこの数値が違って見えるのですか? なぜこのクエリはこんなに時間がかかるのですか?

ClickHouseベースの新しいアーキテクチャ #

Ray氏とチームが新しいアーキテクチャで掲げた主な目標は、速度、コスト、ユーザーエクスペリエンスの3つでした。彼らはClickHouseを中心にウェアハウスを再構築し、設計を取り込みと後処理の2つのフェーズに分割しました。

Verihubsの新アーキテクチャ。リアルタイムなデータ取り込みとClickHouse内での後処理に分割されている。

データ取り込み #

取り込み側で最大の変更は、日次プルからストリーミングへの移行でした。「今ではデータ取り込みをリアルタイムで実行しています」とRay氏は言います。毎朝OLTPから抽出する代わりに、VerihubsはKafkaを介してデータをプッシュし、ストリーミングにはKafka Connectを、後から行を更新する必要がある場合の変更データキャプチャにはDebeziumを使用しています。

Ray氏は、ClickHouseが ClickPipes を通じてよりシンプルなKafka連携を提供していることに触れましたが、Verihubsではまだ採用していません。Kafkaはまた、旧システムにはなかったもの、すなわち組み込みのリトライメカニズムをもたらしました。ClickHouseに直接書き込んでタイムアウトや挿入失敗に対処する代わりに、Kafkaを介してバッファリングすることで、取り込みが正常に回復できるようになったのです。

そこからVerihubsは、更新パターンに基づいてClickHouseにデータをルーティングします。追記専用のトランザクションログは、高速な挿入と分析スキャンに最適化された MergeTree テーブルに格納されます。CDC経由でキャプチャされる更新可能なデータセットは、ReplacingMergeTree テーブルに流れ込み、パイプライン全体をバッチモードに戻すことなく、時間をかけて修正された行を統合できるようにしています。

データ後処理 #

データがClickHouseに入ると、後処理はデータベース内での加工と、最も複雑なロジックのための外部オーケストレーションの組み合わせになります。チームは マテリアライズドビュー を使って大量データのテーブルを日次・月次のロールアップに事前集計し、プロジェクション を使ってステークホルダーが既に発行しているクエリを変更することなく高速化しています。

変換が複雑すぎる場合や、集計というよりも検知に近い処理になる場合には、チームはDagsterを使用し、疑わしい振る舞いパターン(異なる電話番号にまたがる連続的なSMSスパムなど)を検出してSlackに通知を送るパイプラインを実行しています。

KafkaがイベントをClickHouseにストリーミングし、MVが日次/月次のトランザクションおよびCOGSテーブルを構築する。

Ray氏はプレゼンテーションの中で、Verihubsの照合パスの例を紹介しました。ClickHouseはストリーミングされるトランザクションデータを取り込み、CDC経由で関連する参照データを取り込み、マテリアライズドビューを使って下流のテーブル(例: 日次COGS)を生成します。それらは経理が照合や請求業務に利用できます。

20〜30分から2〜3秒へ #

遅くタイムアウトしがちなダッシュボードを待たされることに慣れていたステークホルダーにとって、「結果は非常に大きなものでした」とRay氏は言います。

ClickHouseへの移行後、Verihubsはクエリ速度が最大98%改善したことを確認しました。かつて20〜30分かかっていたクエリが、1,800万行に及ぶような大規模データセットをスキャンする場合でも、わずか2〜3秒で完了するようになったのです。

パフォーマンスの向上は、チームがウェアハウスを日常的に利用する方法も変えました。「今ではリアルタイムOLAP分析データベースを持っています」とRay氏は言います。つまりステークホルダーは、日次のバッチ処理を待つことなく、最新のトラフィックデータや照合データにより速くアクセスできるようになったということです。

そして速度だけが成果ではありませんでした。新しいアーキテクチャによって、Verihubsはクラウド支出を削減し、インフラコストを最大50%削減できたとRay氏は語ります。

移行から得られた4つの教訓 #

Ray氏はPostgresからClickHouseへの移行の際にVerihubsが学んだ教訓をいくつか共有してくれました。

「まず」と彼は言います、「データベース設計が極めて重要です」。ClickHouseでは、スキーマとテーブルレイアウトが多くの処理を担います。Verihubsはスキーマをできる限り正規化して保ち、下流クエリでのJOINを最小限に抑え、並び順キー(ordering key) を慎重に選ぶことに注力しました。これらの決定を初期に誤ると、修正のためにテーブルを削除して再構築する羽目になることもあるとRay氏は指摘します。

テーブルエンジンの選択も重要です。適切な MergeTreeファミリーのエンジン を選ぶことは、バックフィル、クエリ、データ挿入の方法を長期にわたって左右する決定になります。

次にRay氏が強調したのは、ClickHouseのパフォーマンス特性がすべての書き込み操作で対称ではないという点です。挿入は高速ですが、更新と削除は挙動が異なります。ClickHouseはミューテーションを段階的に適用するため、Postgresから来たチームは驚くかもしれません。Verihubsでは、更新を適用して経理に通知した後で、ミューテーションがまだ完全に適用されていないためになぜ数値が変わっていないのかを説明せざるを得ない場面もありました。

ClickHouseのSQLはPostgresユーザーにとって馴染みやすいものですが、「Postgresのそれと完全に同じではありません」とRay氏は言います。特に JOIN や ORDER BY 周辺で、構文や挙動に違いがあります。ClickHouseには時間バケット化や変換のための組み込み関数も豊富に揃っています。「クエリを高速化するために使える関数がたくさんあります」と彼は付け加えます。

最後にRay氏は、バックフィルには計画が必要であること、特にマテリアライズドビューが他のテーブルに依存する場合には注意が必要だと警告しました。プロジェクションとは異なり、マテリアライズドビューはソーステーブルから自動的にバックフィルされません。「カスケードするマテリアライズドビューを作成する前に、慎重に検討してください」と彼は言います。「繰り返しバックフィルする羽目になりますから」。

より高速でコスト効率の高い分析 #

Verihubsの移行事例は、多くのチームが痛みを伴って学ぶ教訓を浮き彫りにしています。最初は「簡単で安価」に感じられるデータベースも、分析が中核的な運用ワークフローになると、隠れたコストになりうるということです。「時間とともに、決して安くはなくなります」とRay氏は言います。「最終的には、ホスティングコスト、労力、そして精神的な負担のすべてが高くつくようになります」。

「ClickHouseは、コスト効率を保ちながら速度重視で再設計することを可能にしてくれます」と彼は付け加えます。Kafkaによるストリーミングが脆弱な日次プルに取って代わりました。適切なMergeTreeエンジンを選んだことで、ウェアハウスは彼らのデータ変化の仕方に沿ったものになりました。マテリアライズドビューとプロジェクションによって、生の大容量テーブルは高速でステークホルダーに優しいデータセットに変わり、システムを停滞させることなく照合や請求を支えられるようになりました。

ClickHouseによって、Verihubsにとって最も重要な要素——速度、コスト、ユーザーエクスペリエンス——は、優先度を巡って争うのではなく、互いを強化し合う関係になりました。ステークホルダーは新鮮なデータとより速い回答を得られ、経理は自信を持って照合と請求を行うことができ、Ray氏のチームは新しい機能の構築とリリースに集中できるようになったのです。