Bullet が ClickHouse Cloud を活用し、DeFi 最速の取引所にリアルタイム分析を提供する方法

Tristan Frizza氏と共同創業者たちがBulletを立ち上げたとき、彼らの頭には明確な課題がありました。過去5年間で、パーペチュアル・フューチャーズ(perps)は暗号資産取引の主流商品として台頭してきましたが、その多くは中央集権型取引所に集中していたのです。FTXのようなプラットフォームはそのモデルのリスクを露呈しました。中央集権型取引所で取引するということは、資産をその取引所に預けることを意味します。FTXが破綻したとき、トレーダーたちはすべてを失いました。

代替案としてDeFi(分散型金融)は原理的には存在していましたが、実際には遅くコストも高すぎて、本格的なトレーダーを引きつけることはできませんでした。初期のEthereumベースの取引所では、1回の取引に20ドルかかり、決済に1分を要することもありました。「RobinhoodやCoinbaseを使い慣れた一般消費者にとって、それは大きな後退です」とTristan氏は言います。

Bulletは、DeFiがどうあるべきかについての彼のチームの賭けです。このプラットフォームは、パーペチュアル、スポット取引、レンディングをすべて単一の取引所で提供します。取引はブロックチェーン上で決済され、ユーザーが自分の資産をセルフカストディし、しかも全体がプロトレーダーにとって十分に高速に動作します。Tristan氏の言葉を借りれば、「必要なものがすべて揃った『何でも取引所』を構築しようとしています。すべてがブロックチェーン上で動作し、しかもすべてが速い……かなり野心的な目標です」。

Tristan氏は2026年1月にシンガポールで開催されたClickHouse meetupで講演し、Bulletのサブミリ秒トレーディングアーキテクチャについて解説しました。また、イベントインデックス、リアルタイム分析、モニタリングにClickHouse Cloudをどのように活用しているか、そしてDatabricksから切り替えることでクエリレイテンシが10〜15秒からミリ秒単位に短縮され、サービングレイヤー全体が不要になり、しかも同程度のコストで1,000倍のデータを扱えるようになった経緯を共有しました。

DeFiの中心にあるレイテンシ問題 #

トレーディングにおいて、市場情報は光の速度で伝わります。だからこそウォール街の企業は、取引所間で価格情報が移動する時間からマイクロ秒でも削ろうと、光ファイバー接続やマイクロ波タワーに何百万ドルも投じるのです。もしあなたが遅いプラットフォーム上で価格を提示するマーケットメーカーであれば、常にリスクにさらされています。裁定取引者は、あなたがキャンセルするより速く古い気配値から買っていくことができるからです。マーケットメーカーがまさにこの理由から低レイテンシを求めており、それが深く流動性の高い市場が最速の会場に集中する理由なのです。

これは歴史的にDeFiのアキレス腱でした。Ethereum L1は約15秒で決済します。Solanaはそれを400ミリ秒まで短縮し、ローンチ時には画期的でしたが、それでもデリバティブ取引には遅すぎます。最近最も成功したDeFiトレーディングプラットフォームの一つであるHyperliquidは、インフラを地理的に集中させることで約70ミリ秒を実現しています。中央集権型取引所のBinanceは10〜20ミリ秒に達しますが、その代償としてDeFiの価値を成すセルフカストディと透明性を失っています。

「ブロックチェーンは歴史的にかなり遅いものでした」とTristan氏は言います。「もっと良くできないか?もっと速くできないか?市場情報をもっとずっと速く伝播させられないか?しかも、それをブロックチェーン的なやり方、つまり人々が自分の資産を所有し、どこかの中央サーバーに置かれるだけではない形で実現できないか?」高速化することで、と彼は付け加えます。「もっと多くの流動性を得られますし、良い市場を作れます。結局のところ、消費者は非常に良い板の厚みを得られ、大きなサイズで取引でき、スリッページも小さく、取引ごとに損失を出すこともなくなるのです」。

BulletはSolana上でピュアRustによるアプリ専用ロールアップとして稼働し、HyperliquidやBinanceよりも高速なサブミリ秒のスピード、具体的にはp50で約500マイクロ秒、p99で約650マイクロ秒を達成しています。Tristan氏はこのp99の値の重要性を強調します。「もし中央値が1ミリ秒でも、最悪ケースが1秒なら、その最悪ケースで必ず負けます」。低ジッター(単に速いだけでなく、予測可能な約定)こそが、マーケットメーカーに流動性を提供する動機を与え、それが取引所を取引する価値のあるものにするのです。

Bulletのメインネットにおける注文処理時間: p50(緑)は約500μs、p99(黄)は約650μsで推移し、6時間の実取引を通じて両者の差は約150μs以内に収まっている。

なぜClickHouseが最適だったのか #

Bulletのトレーディングインフラは実行の問題を解決しますが、別の問題を生み出します。ブロックチェーンはステートマシンであり、トランザクションを処理して次の状態に移りますが、履歴を保持しません。「誰かが取引をして」とTristan氏は言います。「後で税務目的で監査したり、先週の自分の取引を振り返ろうとしても、その情報は基本的に消えています。その意味でステートレスなのです」。

そこで登場するのがClickHouse Cloudです。Bulletは取引所が発行するあらゆるイベントをインデックス化し、ミリ秒単位でクエリ可能にするためにClickHouse Cloudを利用しています。このデータは主に3つのユースケースを支えています。取引履歴、P&Lチャート、監査ログといったユーザー向け機能、24時間ボリューム、リーダーボードランキング、リファラル報酬などのリアルタイム分析、そして毎分のステートスナップショットをGrafanaダッシュボードに供給し、問題が起きる前にSlackやPagerDuty経由でチームにアラートを出す内部モニタリングです(Tristan氏はシンガポールでのプレゼン中にもページを受け取り、「機能している証拠ですね」と冗談を飛ばしていました)。

ブロックチェーンデータは追記専用で、Bulletが古いレコードを更新することはなく、新しいものを追加するだけです。1時間あたり1億5,000万行を超える量になると、それは相当なボリュームになります。ClickHouseのカラム型ストレージモデルは、この種のワークロードに「完璧にフィットする」とTristan氏は言います。データベースは時系列データに対してサブ秒のクエリを実現し、その「驚異的な圧縮率」により、以前S3に非圧縮のJSONを保存していた方式と比べてストレージコストが劇的に削減されました。同様に、ClickHouseのネイティブKafka統合は「箱を開けたそのままで動作」し、カスタム配線なしにBulletのイベントストリームからデータベースへ直接データが流れます。

ClickHouse Cloudの信頼性と使いやすさは、Bulletの以前のセットアップとは雲泥の差です。「いつも何かが壊れていて、休暇中でもすべて自分で保守しなければならず……本当に悪夢のようなものでした」とTristan氏は言います。「ClickHouseは素晴らしいです。イベントを入れ、分析を入れ、モニタリングやその他たくさんのものを入れています。スタックのほとんどのことに使っています。多くの用途において、これ一つで済むオールインワンになりました」。

データの取り込み: インジェスチョンと重複排除 #

Bulletのインジェスチョンパイプラインはロールアップのシーケンサーから始まります。Rustインデクサーが、Tristan氏が「秒間数千のイベントというクレイジーな消火栓」と呼ぶものをWebSocket経由で受信し、AWS MSK上で動作するKafkaトピックにすべてバッチ処理して送ります。Redpanda Connectがイベント分類を担当し、各イベントを読み取り、そのタイプを識別して、適切なKafkaトピックにルーティングします(災害復旧用にS3 Glacierへの並行フィードも行います)。ClickHouse Cloudはそれらのトピックから直接データを消費し、一つの大きな非構造化データベースではなく、専用テーブルにイベントを書き込みます。これによりクエリが「非常に高速」に保たれるとTristan氏は言います。各テーブルは、そのイベントタイプにとって最も重要なフィールドでソート・順序付けできるからです。

Bulletのインジェスチョンパイプライン: イベントはRustインデクサーを経由してKafkaに流れ、そこでRedpanda Connectが分類してClickHouse Cloudの専用テーブルにルーティングする。復旧用にS3への並行バックアップも行われる。

このパイプラインは、メッセージロスなしで秒間300万トランザクションまで負荷テストされています。本番環境では、シーケンサーがイベントを発行してから1秒未満でClickHouseに到達します。「非常によくスケールし、ClickHouseとうまく連携します」とTristan氏は言います。

Bulletが利用している重要なパターンの一つが、ClickHouseのReplacingMergeTreeテーブルエンジンで、これが重複排除の問題を解決します。高スループットのパイプラインでは、同じイベントが複数回到着することがあります(ネットワークの不調、リトライ、再インデックス等)。ClickHouseを導入する前、BulletはSparkで重複排除ジョブを実行し、すべてをRAMで処理していました。それは高価でスケールしにくく、会社経営もしている創業者にとっては時間の浪費でした。ReplacingMergeTreeを使えば、各取引には一意の自動インクリメントイベント番号とトランザクションハッシュがあり、ClickHouseは一致するキーを持つレコードの最新バージョンを保持し、インデックス化されたタイムスタンプをタイブレーカーとして使用します。

実質的な効果(Tristan氏がReplacingMergeTreeの「スーパーパワー」と呼ぶもの)は、パイプライン全体が冪等になるということです。何かが壊れれば、Bulletはロールアップから再インデックスでき、ClickHouseが自動的に重複を排除します。「認知的負荷が大幅に軽減されました」とTristan氏は言います。「トレードテーブルに重複がなく、すべてのデータがクリーンで、パイプラインを再実行したり、バックフィルしたり、そういったことが何でもできると分かっているのです」。

シンプル化されたサービングインフラ #

ClickHouseの前は、BulletはDatabricks上で分析を実行していました。アーキテクチャは機能していましたが、根本的なミスマッチがありました。Tristan氏が説明するように、SparkはJVMの起動とクエリプランの作成だけで5〜30秒かかります。それではミリ秒単位で結果を期待するフロントエンドにデータを配信するには遅すぎました。

彼の回避策は、結果を毎時バッチ計算してDynamoDBに投入し、そこから配信することでした。これも機能はしていましたが、バッチパイプラインと別のキーバリューサービングレイヤーの2つのシステムを保守する必要があり、しかもデータは常に少なくとも1時間古いままでした。「少し不安定で、あまり誇りに思えるものではありませんでした」と彼は付け加えます。

ClickHouseによりDynamoDBレイヤーは不要になりました。クエリはミリ秒で返るので、Bulletは今やAPIレイヤーからClickHouseを直接呼び出しており、キャッシュは必要ありません。「その速さには驚かされました」とTristan氏は言います。「ClickHouseに対してクエリを投げれば10ミリ秒くらいで返ってくるんです。もうサービングレイヤーすら要りません」。

より重い計算のために、BulletはClickHouseの更新可能なマテリアライズドビューを利用しています。これは挿入ごとにトリガーするのではなく、固定間隔で再計算するようにビューをスケジュールできる機能です。トレーディングリーダーボードが良い例です。P&Lランキングの計算には、アカウントスナップショットと入出金履歴を結合し、入金額がリターンにカウントされないようにする必要があります。このクエリは複数のジョインを横断するウィンドウ関数を持つ6つの共通テーブル式にまたがっています。

Databricksではこのクエリは60分ごとのcronジョブとして実行され、20〜30分かかっていたため、リーダーボードデータが更新されるまでに最大90分古くなっていました。「大きな頭痛の種でした」とTristan氏は言います。「リアルタイムのトレーディングアプリケーションにとって、これは多くの人にとって退屈でエンゲージメントの低いものにしてしまっていました」と彼は付け加えます。

ClickHouseでは、同等の更新可能なマテリアライズドビューが10分ごとに実行され、必要であれば毎分にすることも可能です。Tristan氏の言葉によれば、「保守も簡単で、箱を開けたそのまま非常によく動作します」。

結果: より速いデータ、より少ない可動部品 #

最終的に、DatabricksからClickHouse Cloudへの切り替えにより、クエリレイテンシは10〜15秒からミリ秒単位へと、およそ10,000倍の改善を実現しました。「リアルタイムアプリケーションの構築やリアルタイム分析を重視するなら、ClickHouseが真価を発揮するのはここです」とTristan氏は言います。「途方もない速さでクエリできます。時間のかかるSparkのようなものの代わりに、ミリ秒以内で結果が得られます」。

一方、データの鮮度は1〜2時間から5秒未満に短縮され、トレーダーはリーダーボードでの順位、リファラル報酬、P&Lチャートをほぼリアルタイムで確認できるようになりました。月額コストはDatabricksと同程度ですが、ClickHouseは現在、ステージング、テストネット、メインネット環境全体で1,000倍のデータを扱っています。「フェアな比較ではありません」とTristan氏は言います。

少人数のデータエンジニアリングチームにとって、ClickHouse Cloudはインフラ管理にまつわる多くの保守負担を取り除いてくれました。「急成長中のスタートアップとして、そうした作業をできるだけ手放せたのは良かったです」と彼は言います。「クラスターを運用してチューニングし、あれこれ調整しつつ、同時に人を採用して会社を経営するなんて、やっていられません」。

ClickHouse Cloudにより、Tristan氏とチームはデータスタック全体をシンプルにし、脆弱なマルチシステム型アーキテクチャを、インジェスチョン、分析、モニタリングをスケールしながら扱える単一のデータベースに置き換えました。データエンジニアリングチームが1名だけであることがボトルネックになることなく、DeFiにおいて最速で最も機能豊富なトレーディング取引所を構築することに集中できるのです。