「世代を超えた飛躍」: Trio が ClickHouse Cloud で決済分析を統合し、ストレージを 88% 削減した方法

Trio は、大量の電子決済を処理するブラジルのフィンテック企業です。事業が拡大し、2025年にゲーミング・宝くじ分野の有力決済処理事業者である PayBrokers を買収してポートフォリオを広げる中で、刻々と動き続ける決済アクティビティのストリームを、業務部門や財務部門が信頼して扱えるデータへと変換する必要に迫られました。

2025年上半期だけで、Trio は2億4,300万件超の決済を処理しており、各決済はログやシステムイベントを含む数百もの下流シグナルを生成します。この規模になると、アナリティクスは決済機構そのものの一部となります。つまり、チームがパフォーマンスを監視し、トランザクションを照合し、自信を持って提示できる財務ビューを生成するための仕組みです。

2025年11月にサンパウロで開催された ClickHouse のミートアップ において、Trio のメンバーである Fabricio Epaminondas 氏(Head of Engineering)、Eurico Nicacio 氏(Head of CloudOps and IT)、Filipe Coelho 氏(Data Specialist) が、ClickHouse Cloud 上でアナリティクスをどのようにスケールさせているか、なぜ特定のインジェスト方式を選んだのか、そしてその過程で得た学びについて語ってくれました。

単一の信頼できる情報源(Single Source of Truth)の必要性 #

決済の世界では、「アナリティクス」の意味が他のビジネスとは異なります。SaaS なら、トラフィックやエラー率が数イベントずれていても許容されます。グラフから依然として価値を引き出せるからです。しかし、財務はそうはいきません。「クライアントが R$101.94 を保有しているのに、R$101.95 だと伝えるわけにはいかない」と Fabricio 氏は語ります。

なぜなら、アウトプットは社内ダッシュボードに留まらないからです。「データをどのように利用し、照合し、財務・会計サマリーを準備するか――そのすべてに法的な含意があります」と Fabricio 氏は説明します。「コンプライアンスが関わり、連邦法、マネーロンダリング対策規程、しっかり整備されるべき一連の規制メカニズムがあります。」

つまり、数字は高速であると同時に、説明可能であり、ソースまで遡れ、チーム間・システム間で一貫している必要があります。

Trio が成長するにつれて、その基準を満たすことは難しくなっていきました。Filipe 氏は、同社が単一のデータベースや単一の信頼できる情報源で運用していたわけではなかったと説明します。「停止済みのレガシーシステムと現役のレガシーシステムの両方を含む、ばらばらのシステムを単一の視点に集約する必要がありました」と彼は言います。「同時に、膨大な量の金融トランザクションから分析データと過去系列を生成する必要がありましたが、それらのトランザクションを保持していたシステムは、そのようなワークロード向けに設計されていませんでした。」

Trio に必要だったのは、これらのソースを統合し、イベントの大流量に追従しつつ、ビジネスが報告の根拠に据えられるアウトプットを生み出せる分析基盤でした。「この問題を解決するソリューションとして ClickHouse にたどり着きました」と Filipe 氏は語ります。

Trio の ClickHouse ベースのアーキテクチャ #

Trio は ClickHouse を、社内業務やレポーティングから財務照合、コンプライアンス、顧客向けアナリティクスまで、さまざまな機能で利用しています。

運用面では、テレメトリーを ClickHouse にパイプし、Grafana を用いてプラットフォームのアクティビティをリアルタイムに監視しています。Eurico 氏は、Trio が始まった頃には ClickStack のような新しい ClickHouse のオブザーバビリティ機能はまだ存在しなかったため、すでに信頼していたツールを軸に独自のパターンを構築したと述べています。「Grafana は私たちの良き友です」と彼は言います。

クラウドアプリケーション――主に Elixir で、追加のサービスは TypeScript――は AWS 上で動作し、Tiger Data、Postgres、MongoDB、Amazon S3 を含む複数のトランザクショナル/オペレーショナルなデータソースとやり取りします。そこからデータは2つの主経路で流れます。メッセージング駆動のイベントは Redpanda を介したストリーミング、スケジュールされたロードは Airflow を介したバッチです。ClickHouse は分析レイヤーとして中央に位置し、Grafana、Hex、Trio 独自のアプリケーションにデータを供給し、ビューは FinOps チーム、DevOps チーム、そして顧客によって利用されます。

インジェストに関して、チームは ClickHouse のネイティブなインジェストサービスである ClickPipes と、カスタム ETL アプローチのどちらかを選ぶ必要がありました。Fabricio 氏は、「ClickPipes は物事を非常に簡単にしてくれます」、特にインジェストを素早く立ち上げて、データ整形の多くを下流の ClickHouse に任せたい場合には有用だと述べる一方で、Trio が選んだのはカスタムソリューションでした。Redpanda のトピックが専用の ETL サービスにデータを供給し、そこでイベントを前処理してペイロードを構造化したうえで、整形済みで型付けされたレコードを ClickHouse にインサートする方式です。

その理由は、変化下での運用性に帰着します。スキーマドリフト、進化するイベントフォーマット、イベント間の依存関係がある中で、Trio はデータが着地する前にどのように整形されるかをより細かく制御したいと考えました。途中でパイプラインを停止して復旧させる必要が生じないようにするためです。「ここに優劣はありません」と Fabricio 氏は語ります。「ClickHouse はどちらの場合でも非常に優れています。」

スライディングウィンドウによる解決策 #

金融システムには、きれいな図を複雑にしてしまう特性があります。決済イベントは遅れて到着します。一部は二重に到着します。下流システムが配信を再試行したり、上流の障害で生じた欠損が後から埋められたりするために、順不同で到着するものもあります。

Trio はメッセージングフローの上にリアルタイムメトリクスを構築する際にこの問題に直面しました。Pix 決済が最初のイベントの記録後に「完了」する場合や、以前のレコードがすでに集計された後で数秒、あるいは数分遅れて確認イベントが到着する場合があります。最初のイベントを最終とみなせば、後から合計値が遡って変動します。ソフトウェアでは「煩わしいが許容できる」程度のことが、金融では受け入れられません。

チームが最初に思いついたのは、新しいイベントが到着するたびに集計を再実行する refreshable materialized views を使うことでした。問題は、遅延データが現れるたびにビュー全体を再計算すると、小さな修正のために大量の高コストな処理を行うことになる点です。「素のリフレッシャブルビューはすべてを再マテリアライズします」と Fabricio 氏は言います。「これは非常に重いです。」

そこで Trio はアイデアを保ちつつ、対象範囲を狭めました。リフレッシュのたびに全データセットを完全に最新化するのではなく、直近の過去を修正することに注力したのです。このパターンはいわゆるスライディングウィンドウです。数分ごとに直近の時間範囲(例: 「直近4時間を5分ごと」)を再計算し、遅延イベントや重複が履歴の再構築なしに正しい合計に取り込まれるようにします。

これらの定期的な再計算はリフレッシャブル・マテリアライズドビューが駆動し、リプレイによって同じ論理レコードが複数回挿入された場合の重複排除は ReplacingMergeTree が担当します。また、コストの高いグローバルマージを避けるために パーティショニング にも細心の注意を払いました。

その結果、財務が求める通りに振る舞うシステムが得られました。ストリームが遅れたり繰り返したりしても、直近のデータは正確に保たれます。古いバケットは安定すると実質的に不変になります。レポーティングは欠損や不整合から解放され、データセットが拡大してもパフォーマンスは維持されます。「これにより、台帳由来の10億件超のデータポイントを1日のうちにスムーズに扱い、大きな問題なく更新し続けられます」と Fabricio 氏は語ります。

「世代を超える飛躍」 #

Trio にとって、ClickHouse のメリットは複数の形で同時に現れました。

ひとつは単純な統合です。個々のシステムに結びついた分離した分析の島を維持する代わりに、分析レイヤーを中央集約しました。「すべてのソースが1か所に集まります」と Filipe 氏は説明します。「クラウド内ですべてを管理します。会社のあらゆる分析課題に対する単一の信頼できる情報源となるのです。」

ストレージも劇的に減少しました。ClickHouse のカラムナーストレージと圧縮のおかげで、以前の構成と比較して約88%削減されました。

そして、スピード。これを Filipe 氏は最適化というより、真の段階的飛躍として描写しています。「スピードに関して言えば、ClickHouse は文字通り無敵です」と彼は語ります。「以前と比べて世代を超える飛躍で、最小限のチューニングでさえそれが実感できます。」

そのスピードはチームの日々の働き方を変えました。回答を待ったり、どのクエリを実行する「価値」があるかを取捨選択したりする代わりに、アナリティクスはより緊密なフィードバックループの中で使えるものになりました。「壁に頭を打ち付けるのをやめて、実際にデータを分析することにより多くの時間を使うようになりました」と Filipe 氏は語ります。

マイグレーションの負担も軽くなりました。「通常ならスキーマを整えるのに頭を悩ませて8時間かかるようなことを、ClickHouse の取り込みプロセスは数分で解決します」と Filipe 氏は言います。Trio がおよそ50億行――一部のテーブルは70列を超える――を移行した際にも、ClickHouse は怯みませんでした。「データを受け取って、基本的に文句ひとつ言いませんでした」と彼は語ります。「これは以前のデータベースを扱うときには毎回大問題でした。これは私たちの仕事を一変させる経験でしたし、今もそうです。」

Trio と ClickHouse の次なるステップ #

サンパウロでチームが説明したのはフェーズ1です。すなわち、ばらばらのソースを統合し、ストリーミング規模で取り込み、遅延や順序の乱れがあっても正しさを保てるアーキテクチャの上に、ステークスの高い財務アナリティクスを載せる、というものです。

今や焦点は「動くようにする」ことから「より洗練させる」ことへとシフトしています。欠けているレイヤーを埋め、オーケストレーションを引き締め、Trio が取り組み始めて以降に ClickHouse へ追加された機能や改善を活用していくのです。これには ClickPipes や新しいテレメトリ向け機能の再検討も含まれます。さらにチームは、本番環境に適用する前にローカルモードのワークフローで取り込みや運用手順をリハーサルする試みも進めています。

ボリュームが拡大しプラットフォームが広がる中での目標は、運用しやすく、変更しやすく、信頼しやすい分析基盤です。