Nava が Elasticsearch から ClickHouse への移行を支援し、ELO のインフラコストを 87% 削減した方法

Navaは、大規模組織のデータセンターインフラの構築・管理を支援するため、1995年にブラジルで設立されました。しかし、可視性のないインフラは全体像の半分に過ぎません。やがて同社は、自ら構築する環境を補完するため、独自の監視・オブザーバビリティ製品を開発するようになりました。

金融サービス分野への転換点が訪れたのは2012年のこと。ブラジル最大級の銀行グループの一つであるItaúが、Navaに対し、ネットワークを流れる決済の監視を依頼したのです。データエンジニア兼アーキテクトのLucas Souza氏は次のように振り返ります。「オブザーバビリティと監視に関する当社の専門知識と、彼らのドメイン知識を組み合わせ、私たちはこの課題を引き受けました。そして決済業界向けのリアルタイムビジネスモニタリングという、まったく新しいものを生み出すことに決めたのです」。

これは大きな転換点でした。噂はブラジルの金融業界に瞬く間に広がり、決済・与信分野の他のプレイヤーたちも同様の機能を求めて訪れるようになりました。今日、Navaは決済分野で10社以上の取引を監視しており、ブラジルにおけるカード取引全体の約90%を占めています。

2025年11月にサンパウロで開催されたClickHouseミートアップで、Lucas氏はそのうちの1社、ブラジルの大手カードネットワークであるELOが、Navaの支援を受けて分析基盤をElasticsearchからClickHouseへ移行し、コストを87%削減し、1日2,200万件の取引監視のあり方を一変させた経緯について語りました。

Lucas氏とClickHouseとの出会い #

Lucas氏個人のClickHouseとの旅路は、ELOへの導入に至るほぼ10年前にさかのぼります。Microsoft SQL Serverのスペシャリストとして、ブラジル国内外のカンファレンスで長年講演してきた彼は、すべての基準としてSQL Serverを用いていました。

しかし2014年から2016年ごろ、Navaが扱うインジェスト量はリレーショナルデータベースの限界を押し上げるレベルに達していました。「リレーショナルデータベースを扱う人なら誰でも分かることですが、毎秒8,000件や10,000件のレコードをインジェストすると、データページ競合が発生します」とLucas氏は述べます。

インメモリソリューションは助けにはなりましたが、ライセンスコストの問題で、小規模顧客に競争力のある価格で提供することが難しかったのです。「自分のニッチのニーズを満たし、パフォーマンスを損なわず、SQL Serverと同等の効率性を持ち、リスクが低いかゼロのソリューションを見つける必要がありました」とLucas氏は語ります。

彼はRocksDB、MariaDBなど複数のデータベースを評価しましたが、Perconaの知人がClickHouseを紹介してくれました。それは強い印象を残しました。「ClickHouseは別次元です」と彼は言います。「初めて触れた瞬間、そのパフォーマンスは常識を超えています」。

SQL Server出身のLucas氏には、目にしたものを徹底的にストレステストするだけの技術的な深さがありました。ClickHouseは、圧縮率、クエリ速度、SQLサポートのいずれの観点でも期待に応えました。彼は自分自身にこう言い聞かせたといいます。「自分の問題の解決策を見つけた、と」。

Elasticsearchの限界 #

それから数年間、Lucas氏とNavaのチームは社内でClickHouseの専門知識を蓄積し、本番環境への展開にふさわしい機会を待っていました。

その機会はブラジルの主要決済ネットワークの一つであるELOという形で訪れました。同社は毎日約2,200万件、毎秒260件以上の金融取引を処理しており、年間80億件以上の取引レコードが蓄積されています。

当時、Navaはこれらの取引の可視化を、Google Cloud Platform上にホストされたElasticsearchベースのプラットフォームを通じてELOに提供していました。しかし取引量が増加し、ELOがダッシュボードへの要求を高めるにつれて、その限界は無視できないものになっていきました。

「最大の問題はコストでした」とLucas氏は言います。「ストレージ要件、インフラ費用の両面でです」。Elasticsearch構成では12TBのストレージを必要とし、年間のインフラコストはR$900,000(90万レアル)に膨らんでいました。

パフォーマンスも信頼できないものでした。広い期間範囲にわたる複雑な集計は決まって極端に遅くなり、チームは需要に追いつくためだけに、週に何度もクラスタを再インデックスする状況に陥っていました。

最後に、EQL構文の複雑さの問題がありました。「Elasticsearchのクエリ言語はユーザーフレンドリーではありません」とLucas氏は語ります。「冗長で、退屈な言語です」。新しいダッシュボードを作るたびに専門知識が必要となり、これがボトルネックとなって、ELOの運用チームは新しいデータビューが必要になるたびに開発者を待たなければならなかったのです。

ClickHouseへの移行 #

社内での長年のテストでClickHouseへの信頼は培われていたものの、Navaは本番環境にデプロイした経験はありませんでした。Lucas氏は、これをELOの監視基盤の土台として提案するのは大きな一歩だと理解していました。それでも彼は決断しました。

「私たちは常にリスクを取らなければなりません」と彼は言います。「リスクを取らず、自分のしていることを信じなければ、コンフォートゾーンから出ることはできず、どこにも辿り着けません」。

移行はELOの既存データパイプラインの中核を維持しました。取引データは引き続きKafkaに流入し、Navaのカスタム ETLツールであるDataflowがデータ辞書とビジネスルールに基づいてエンリッチした後、クエリと可視化のためにClickHouseへロードされます。変わったのは、そのインジェスト層から下流のすべてです。

ClickHouseクラスタはAltinityオペレータを使用してKubernetes上にデプロイされ、Navaは構成のきめ細かな制御とゼロダウンタイムでのアップデートを実現しました。クラスタは4つのノード(2シャード、2レプリカ)で構成され、サンパウロとリオデジャネイロにあるELOの2つの主要データセンターに分散配置されています。ClickHouseの分散テーブルエンジンを使用し、取引はサイトIDに基づいて適切なシャードにルーティングされ、両拠点間でインジェスト負荷を分散させると同時に、ダッシュボードクエリで利用可能な読み取りキャパシティを2倍にしています。

その上にいくつかの最適化が重ねられました。ZSTDおよびLZ4圧縮コーデックによりストレージ要件は劇的に削減されました。LowCardinalityデータ型は、ユニーク値が10,000未満の文字列カラムに適用され、圧縮率とクエリ速度の両方が向上しました。マテリアライズドビューは一般的なクエリパターンを事前集計し、Elasticsearchでパフォーマンス問題を引き起こしていた日付範囲比較クエリ向けには、本質的に事前計算された実行計画であるプロジェクションが追加されました。

ELOのチームにとって、おそらく最も即座に体感できた変化は、標準SQLへの移行でした。EQLは専門知識を要求し、ダッシュボード開発を遅らせていましたが、ClickHouseのANSI SQLサポートにより、あらゆるレベルのアナリストが急な学習曲線なしにデータをクエリし、可視化を構築できるようになりました。

より安く、より速く、より使いやすく #

移行前と移行後の違いはまさに昼と夜のような違いです。ストレージは12TBから2TBに減少し、ELOの年間インフラコストはR$900,000からR$120,000に下がり、87%の削減を実現しました。Lucas氏はこう表現します。「データが小さくなればなるほど、転送が速くなり、アクセスが速くなり、メモリに取り込めるデータ量が増え、使用されるインフラが少なくなります」。

ClickHouseのクエリパフォーマンスも同様の物語を語っています。Elasticsearchでは数秒かかっていた集計が、今やミリ秒で完了します。全データセットの集計は5倍、フィルタリングされたクエリは6倍、事前集計されたデータでは9倍高速です。「パフォーマンスは、私たちが評価した他のどのデータベースよりも紛れもなく優れています」とLucas氏は語ります。

ELOは現在、約300の運用ダッシュボードを24時間体制で稼働させており、それぞれが5秒ごとにリフレッシュされています。「Kafkaにデータが到着してから、そのデータが可視化に表示されるまでにかかる時間は2秒です」とLucas氏は語ります。

その速度のビジネス価値は、可視性の遅れが実際にどれほどのコストになるかを考えれば明らかです。特定の地域で決済リンクがダウンし、ELOの優先ネットワークが処理を停止した場合、加盟店は自動的に手数料率の高いセカンダリネットワークにフェイルオーバーします。リアルタイム監視がなければ、その状況は何日も検出されないかもしれません。決済コストや加盟店との関係に影響を与えるには十分な時間です。ClickHouseを基盤としたダッシュボードがあれば、ELOの運用チームは特定の拠点での取引量低下を数秒以内に特定し、加盟店やカード保有者が問題に気づく前にエスカレーションすることができます。

その結果、ELOはNavaの最も声高な擁護者の一つになりました。「今日、ELOはElasticsearchからの脱却で節約したコストのおかげで、私たちにレッドカーペットを敷くようなものです」とLucas氏は言います。「彼らが参加するイベントでは、ClickHouseを高く評価しています。なぜか?コストが下がり、アプリケーションのパフォーマンスが向上し、クエリ言語のおかげでダッシュボード作成の容易さが圧倒的に生産的になったからです」。

ブラジル全土の金融サービスを監視 #

ELOの移行以来、Navaは増加し続ける金融サービス顧客にClickHouseを適用しており、その都度、プラットフォームに対するチームの知見が深まっています。

最近で特に要求の厳しかったプロジェクトのひとつは、約200億件のレコードをMongoDBからClickHouseに移行する案件でした。「Mongoは抱えていた膨大なドキュメントデータのせいでオンラインを維持できませんでした」とLucas氏は説明します。「完全な置き換えを行わなくても、単にこのデータを統合し、集計し、最新の日付を使用するだけで、パフォーマンスはすでに10〜15倍向上していました」。

Navaはまた、プラットフォームのパフォーマンスメリットを享受しながら、自身のクラスタ管理という運用負担を負いたくない顧客向けに、ClickHouse Cloudの活用も模索し始めています。現在大規模なSnowflake環境を運用しているある顧客は、分析ワークロードのClickHouse Cloudへの移行を評価中です。Lucas氏はこう述べます。「Snowflakeは優れた製品ですが、このデータを維持するコストはClickHouseと比較して非常に高いです」。

Lucas氏にとって、ClickHouseの5年間の本番運用経験は、プラットフォームに対する信頼をさらに深めることになりました。「私たちがテストしたすべての機能は、いつでもどこかのシナリオで役立ってきました」と彼は言います。馴染みのないデータベースへの計算されたリスクとして始まったものは、今やNavaが大規模分析ワークロードに対して選ぶ第一のソリューションとなり、ブラジルのほぼすべてのカード取引に触れる監視能力の基盤となっています。