RidgelineがIcebergとClickHouseを統合し投資管理向け分析レイヤーを単一化した方法

多くの資産運用会社では、トレーディング、会計、レポーティング、CRM、アナリティクスを個別のシステムとして運用し、それらを事後的に繋ぎ合わせて照合しています。Ridgeline は、統合されたデータモデルと組み込み AI を備えた単一のプラットフォーム上にこれらすべてを集約しています。パフォーマンス測定およびアナリティクス担当マネージャーの Hayden Hudgins 氏は、「私たちは、すべてを網羅したオールインワンの製品を提供することを目指しています」と語ります。

社内において、Hayden 氏のチームはトレーディングと会計の下流に位置し、未加工の取引数値を投資パフォーマンスとアナリティクスへと変換しています。ポートフォリオが利益を上げたのか、それとも損失を出したのか？ なぜそれが起きたのか？ ポートフォリオやその構成比率にはどのような影響があるのか？

これらすべてが機能するためには、2 つの条件を満たす必要があります。テクニカルプロダクトマネージャーの Erin Corrado 氏は、「Ridgeline 全体において、極めて重要なのはスピードと正確性です。私たちは非常に高速でなければなりません。それは市場での差別化要因です。そして正確であることも欠かせません。誤ったレポート数値や古いデータを提供してしまえば、顧客から苦情が寄せられるからです。ClickHouse は、この種の分析クエリを非常に迅速かつ正確に実行するための力を私たちに与えてくれます」と述べています。

私たちは Hayden 氏と Erin 氏に話を伺い、Postgres で直面した壁から、AWS 上の ClickHouse Cloud を採用するという決断、そして顧客基盤を 2 倍以上に拡大する原動力となった 10 倍のアーキテクチャ刷新に至るまで、Ridgeline のパフォーマンスアナリティクスをどのように再構築したのかを聞きました。

アップマーケットへの進出と Postgres の限界 #

Ridgeline は「主に Postgres を中心とした環境です」と Erin 氏は言います。「Postgres はトランザクションに非常に長けています。会計や取引を扱うのであれば、極めて優れています。しかし、大量のデータを集約して分析しなければならない大規模で複雑な集計となると、ClickHouse が明確な勝者です」

2 年前、Ridgeline は従来の約 10 倍の規模を持つ顧客層のオンボーディングを開始しました。このワークロードは、そもそも過酷なものでした。Ridgeline はシステム内のすべてのポートフォリオについて日次の損益データを算出しますが、その結果として生成されるテーブルは幅広く、ポートフォリオごとに毎日およそ 40〜80 カラムが書き込まれます。そのデータ上で実行されるアナリティクスは、クエリというよりも数学の計算に近いものです。「これらのレポートの多くでは、このデータを取り込んだ上で、実質的に SQL で積分を行うような処理が求められます」と Hayden 氏は言います。

以前の顧客負荷では、Postgres でも対応できていました。しかし、Ridgeline がアップマーケットへ進出するにつれて、要求は大きくなっていきました。Hayden 氏は当時を振り返ります。「何十年も遡るポートフォリオの設定来レポートを日次粒度で、しかも数千ものポートフォリオに対して計算しなければならない状況にまで達しました」

その規模になると、2 つの事態のいずれかが起こり得ました。Ridgeline は共有インフラストラクチャ層を運用しており、Postgres インスタンスは複数のチームで共通して使用されていたため、パフォーマンスチームが単一のレポートを計算するためにクラスター全体を事実上使い果たしてしまうか、あるいはジョブがハードリミットに達してしまうかのどちらかでした。「メモリ容量を使い果たし、Postgres インスタンスを常に垂直スケールさせていました」と Hayden 氏は言います。元のシステムでこれらのアップマーケット向けレポートを実行した場合、おそらく数時間かかるか、最悪の場合は完了すらしない可能性がありました。

その年に Ridgeline がプラットフォームへ導入しようとしていた顧客は、データ量が 10〜40 倍に増加することを意味していました。既存のアーキテクチャのいかなる構成でも、それを受け止めることはできませんでした。「これらの顧客を稼働させるためには必須の要件でした」と Hayden 氏は語ります。「ビジネスをより上位の市場へと押し上げるために、契約を結び本番稼働させたい顧客が存在しており、私たちの認識としては、何としてもこれらの機能を提供しなければならなかったのです」

セキュリティとガバナンスを理由に ClickHouse Cloud を選択 #

ソリューション候補を評価する際、Ridgeline の基準は合否判定となる問いから始まりました。そもそもこれらのレポートを処理できるのか？ という点です。それをクリアしたものは、「パフォーマンスとコストのバランス」で評価されたと Hayden 氏は言います。「コスト効率に優れ、得られる最も高速なソリューションはどれか？」という点です。

チームは Redshift、Iceberg 上の Trino、SingleStore、そして Postgres を列指向ストアのように動作させるプラグインなどを検討しました。問題が Postgres 自体にあるのか、それともその使い方にあるのかを再検討しました。独自のデータ型を備えたインメモリの計算エンジンをゼロから開発することさえ検討しました。

最終的に、ClickHouse がパフォーマンスで勝利し、Ridgeline が見積もりを取った他の分析用データストアよりも低コストで導入できることがわかりました。

次の決定事項は、それをどのように運用するかでした。チームはまず ClickHouse をセルフホストすることから始め、ステージング環境で動作するバージョンを稼働させました。その上で、これを本番運用するにはどれだけのコストがかかるかを検討しました。「プリンシパルエンジニアや経営幹部と多くの議論を重ねた結果、これをどのように稼働させ、運用していくかを自前で解明することに投資したくはないという結論に至りました」と Hayden 氏は言います。

残る選択肢は ClickHouse Cloud と Bring Your Own Cloud (BYOC) でした。決定打となったのはセキュリティです。Ridgeline は SOC 2 の下で運営されている金融サービス企業であり、当時の BYOC はサードパーティに対して Ridgeline 自身の VPC 内への足がかりを認めることを意味していました (BYOC は現在 AWS および Google Cloud で一般提供されており、データプレーンは顧客自身のアカウント内で稼働し、SOC 2 Type II の対象範囲は BYOC デプロイにも適用されます)。ClickHouse のマネージドサービスの方がより明確で適切な選択肢でした。Ridgeline はデータ共有契約に ClickHouse を盛り込み、分かりやすい Ingress/Egress ルールによってその関係を統制しました。

分離に関する要件が極めて特殊であったため、Ridgeline のエンジニアと ClickHouse のエンジニアは共同でその構造を設計しました。Ridgeline は互いに接触することが許されない環境間で保存データを分離する必要があったため、ステージング用と本番用で別々の ClickHouse 組織を運用し、組織間でクレジットを共有しながら、その配下で顧客ごとに個別の ClickHouse サービスを実行しています。その過程で、Ridgeline はそのインフラストラクチャをプログラムからプロビジョニングするための API エンドポイントを要望しました (これらの機能は現在、すべての ClickHouse Cloud ユーザーが利用できる Terraform プロバイダーの基盤となっています)。「双方にとって有益なパートナーシップであったと思いたいです」と Hayden 氏は述べています。

ClickHouse Cloud は、本来であればチームが自前で担うはずだった作業も肩代わりしました。Ridgeline は事業継続性のためにプライマリとセカンダリのリージョンを運用し、それらの間でフェイルオーバーを行っており、必要な復旧機能を構築するために ClickHouse のサポートチームと協力しました。「オープンソースの ClickHouse を採用してすべてを自分たちで管理しようとしていたなら、はるかに重い負担になっていたはずです」と Erin 氏は語ります。

ClickHouse を介した Iceberg データのクエリ #

現在、Ridgeline 内部で生成される会計データは ClickHouse に直接書き込まれます。ベンダーデータ (カストディアンのフィード、価格データなど) は、本来の役割どおり Postgres にトランザクションとして格納され、ClickPipes CDC を介して ClickHouse にレプリケーションされます。そして、顧客のレガシープロバイダーから膨大な量で届く履歴データは、第 3 の経路をたどります。

その第 3 の経路自体が、独自の 10 倍規模の課題でした。Ridgeline は数億行の履歴データであれば大きな問題なく処理できましたが、ビジネスがアップマーケットへ移行するにつれて、顧客は 10 億行、さらには 20 億行ものデータを持ち込むようになりました。そこでチームは、それらの大容量アップロードを取り込んで Iceberg に格納する Spark パイプラインを構築しました。Iceberg であれば、数十年分の履歴をより経済的に保存できます。そして Erin 氏のチームが構築したアダプターが、オンデマンドでその Iceberg データを ClickHouse に取得します。

「私たちは、ポートフォリオの設定時から Ridgeline システムにおける現在に至るまでに何が起きたのかを完全に把握する必要があります。それを提供してくれるのが、Iceberg テーブルと ClickHouse の組み合わせです」

— Hayden Hudgins 氏、Ridgeline パフォーマンス測定およびアナリティクス担当マネージャー

直近のデータは ClickHouse 内に保持され、テナントあたり数百 GB、通常は 2〜4 年分をカバーします。それ以前の古いデータは Iceberg に残り、ClickHouse の Iceberg コネクタを介して読み取られます。「そのコネクタによる 40 ミリ秒のオーバーヘッドは問題ありません」と Hayden 氏は言います。「40 年分のデータをクエリするのであれば、わずかに遅くなることは誰もが想定内です」

Hayden 氏は、マテリアライズドビューが自身のチームが提供する機能の「バックボーン」になっていると指摘します。チームは現在、書き込み側のデータを最適化された読み取り側のビューへと変換する一連のマテリアライズドビューを運用しており、ReplacingMergeTree テーブルエンジンがバックグラウンドですべてを整合させています。「私たちは SQL を定義し、ClickHouse 内部の MergeTree ロジックがデータをあるべき場所へと適切に届けてくれると信頼しています」と彼は語ります。さらに、パフォーマンスの向上も素晴らしいものの、開発の容易さも同様に重要であると付け加えました。「1 日以内に作成でき、意図したとおりにマテリアライズされることが分かっています」

ClickHouse が Ridgeline にもたらしたもの #

このプロジェクトの成功を示す最も明確な指標は、Ridgeline がプラットフォームに迎え入れることができるようになった顧客の規模です。従来のアーキテクチャには厳格な規模の上限があり、ビジネスの成長を制約していました。ClickHouse により、同社はアップマーケットへと大きく舵を切りながら、プラットフォーム上で稼働する顧客数を 2 倍以上に増やしました。

「最大のブレイクスルーは、以前なら不可能だった顧客を本番稼働させられたことです。あの 10 倍規模のアーキテクチャ刷新をリリースしていなければ、最終的に結ぶことができた契約を獲得することはできなかったでしょう」

— Hayden Hudgins 氏、Ridgeline パフォーマンス測定およびアナリティクス担当マネージャー

日々の業務において、その違いは Ridgeline の顧客が信頼を寄せるパフォーマンスレポートに現れています。これらは管理下のポートフォリオごとに作成される、巨大なバッチで生成される複数ページの PDF です。ClickHouse により、かつては何時間もかかっていたバッチ処理が数分で完了するようになりました。そして重要なことに、それらのレポートは送信前に確認され、再実行されます。

旧システムでは、その確認サイクルはコーヒーブレイクや一晩の待ち時間単位で測られていました。Hayden 氏は振り返ります。「当時は、ジョブを実行してから昼食を取りに行ったりコーヒーを飲みに行ったりして、後で戻ってきて確認するという具合でした」。現在では、システムの一部で行われた変更がパイプラインとマテリアライズドビューを介して約 1 分で反映され、ClickHouse に対してレポートが再実行されるため、顧客は数値が期待どおりに変更されたことを検証できます。

Erin 氏が指摘するように、エンドユーザーがこうした裏側を目にすることはありません。「エンドユーザーは、それが ClickHouse であろうと何であろうと気にしていません」と彼女は言います。「彼らが見るのは、単にパフォーマンスレポートだけです」

次なる 10 倍の飛躍に向けて #

ClickHouse Cloud を基盤として、Ridgeline はすでに次の境界線を見据えています。社内では、Ridgeline の現在の顧客よりもさらに一桁大きいポートフォリオを運用する「ホエールスケール」の顧客について議論されています。「私たちは 1、2 年前に 10 倍の規模を達成しました」と Hayden 氏は言います。「そして今、再びそれを実現しようとしています」

これには、プラットフォームがようやく保持できるようになったデータに対する、より高度な機能も含まれます。Hayden 氏は次のように説明します。「Iceberg と ClickHouse により、顧客は大量の過去のパフォーマンスデータを Ridgeline に持ち込み、その履歴を Ridgeline で計算された結果と並べて利用できるようになり、Ridgeline への移行期間を通じても設定来のパフォーマンスレポーティングを維持できるようになります」

また、社内の新たな領域への展開も含まれています。Ridgeline の照合チームは、見込み客から要望のあったほぼリアルタイムのアナリティクスダッシュボード向けに ClickHouse を評価しています。「ほぼリアルタイムでそれを真に実現する唯一の方法は ClickHouse であるように見受けられます」と Erin 氏は語ります。「手元にある他の既存ツールでは到底不可能です」

パフォーマンスアナリティクスから始まったパターンは広がりを見せています。「Postgres では到底対応できないユースケースがさらに見つかっています」と彼女は付け加えます。ClickHouse Cloud のおかげで、チームにはそうしたワークロードを受け入れる受け皿があります。「Ridgeline 社内の ClickHouse 向けロードマップには、間違いなくさらに多くの項目が控えています」と Hayden 氏は述べています。