Mercado LibreがClickHouse Cloudでオブザーバビリティ基盤を再構築し、トレースクエリを50倍高速化した方法

Mercado Libre はラテンアメリカを代表するコマース・フィンテックプラットフォームで、18か国で事業を展開し、地域の市場シェアは約35%(Amazonの4%と比較して)に達します。複数の言語、スタック、規制、物流をまたぐ極めて複雑な環境です。システムを稼働させ続けているのと同じテレメトリを使って、チームは変更をリリースし、監視し、プラットフォーム内で顧客が得る体験を改善しています。

Open House SF 2026 で、テクニカルリーダーの Daniel Da Rosa 氏とソフトウェアエキスパートの Francislei Reis 氏は、Mercado Libre が AWS 上の ClickHouse Cloud 上でオブザーバビリティプラットフォームを再構築し、トラブルシューティングを数日から数分に短縮し、クエリを50倍高速化し、データを最大89%圧縮した経緯を共有しました。

新しいトレーシングプラットフォームの必要性 #

2026年第1四半期において、Mercado Libre は1億2,600万人のユニークバイヤーにサービスを提供し、27億個の商品を配送し、870億ドルの決済を処理しました。同社の5つの主要事業(コマース、広告、物流、アクワイアリング、フィンテックサービス)は同一のプラットフォーム上で運営されており、その決済・銀行事業である Mercado Pago も同じプラットフォーム上で稼働しています。

これらすべては、同社の内製開発者プラットフォーム Fury 上で動作しています。Fury は、Go、Java、Python、JavaScript、ネイティブコード、さらに増加するAIワークロードで書かれた35,000以上のマイクロサービスを支えています。

すべてのクリック、すべてのドル、すべての荷物がテレメトリデータを生み出します。Mercado Libre の規模では、1日あたり10,000のデプロイと7,000のプルリクエストを支え、1秒あたり150億以上のリクエストを処理しています。

— Daniel Da Rosa 氏、Mercado Libre オブザーバビリティ テクニカルリーダー

Mercado Libre の規模では、一見単純に聞こえる質問への回答が難しくなります。なぜ特定の支払いIDが失敗したのか?なぜ特定のユーザーがチェックアウトでエラーに遭遇したのか?「30サービス程度の小さなビジネスフローなら、ログ、メトリクス、トレースを調べるのに数分から数時間かけられるかもしれません」と Daniel 氏は言います。「しかしアーキテクチャが大きくなるにつれ、この種の問題を解決するのに時間がかかるようになります…リクエストの完全な全体像が必要です」。

チームは、トレーシングこそがオブザーバビリティのパズルに欠けている最後のピースだと判断しました。トレースを使えば、1つずつのサービスの健全性ではなく、ビジネスフロー全体のエンドツーエンドの可視性と、フロー健全性やボトルネックを定量的に把握でき、ビジネスコンテキストをデータに直接組み込めます。そのコンテキストがあれば、トレーシングによりインシデント対応を「サービスXのP99が高くなっている」から「この特定のサービスがタイムアウトしたため、この特定の支払いが失敗した」に変換でき、将来的にはプロセスマイニングと最適化の基盤にもなります。

チームは新プラットフォームに4つの要件を設定しました。1つ目はトラブルシューティングを数日から数分に短縮すること。2つ目は完全なビジネスフローの可視化により、本番環境のサービス全体を横断してフロー全体を確認できること。3つ目はハイカーディナリティなフィルタ(決済ID、ユーザーID、およびチームが検索したいその他多数の識別子でのフィルタリング機能)。4つ目は持続可能なスケール、つまりオブザーバビリティのコストがビジネスの成長に連動しないようにすることです。

遅いオブザーバビリティのコストはインフラだけではありません。顧客体験そのものです。

— Daniel Da Rosa 氏、Mercado Libre オブザーバビリティ テクニカルリーダー

こうして生まれたのが、オブザーバビリティチームが O11y events と呼ぶプラットフォームです。重要なアプリケーションのトラフィックを100%サンプリングするため、重要なものは何も見逃されず、そのボリュームでも保持コストを効率的に抑えられます。OpenTelemetry 上に構築されており、ビジネスフロー属性が計装に組み込まれています。Daniel 氏の説明によれば、これは Mercado Libre の規模のオブザーバビリティプラットフォームに期待されるトレンド分析、異常検出、パフォーマンス監視に加えて、分析、データガバナンス、AI を最初から念頭に置いて設計されました。

従来のオブザーバビリティプラットフォームからの脱皮 #

O11y events の初期バージョンは、標準的な OpenTelemetry 本番パターンに従っていました。アプリケーションが内部SDKを通じてテレメトリを OTel コレクターに送り、ストリームを経てコンシューマーを通り、クラウドストレージ層に格納されます。ダッシュボードや外部連携はそのストレージ層から読み取ります。この設計により、チームは1分あたり7,000万スパンにまで到達しました。

Mercado Libre の以前のアーキテクチャ

「しかしアプリケーションをスケールさせると、多くの障害にぶつかりました」と Francislei 氏は言います。問題は、変換、フィルタリング、集約といった重い処理が、クエリ実行時にストレージ層に対してクライアント側で実行されていたことでした。

クライアントによって重い処理が行われる、Mercado Libre の以前のアーキテクチャのストレージ層

クエリは5分以上かかり、コストは急速に増大しました。新しい属性のインデックス化は困難で、データ集約はコストがかかり、スパンからメトリクスを生成することは高コストのため実現不可能でした。エンジニアはどのトランザクションIDでもスパンを取得したり、集約ビューを引き出したり、スパンからメトリクスを導出できたものの、Mercado Libre の4つの要件を満たすほど速く、あるいは安価にそれを行うことはできませんでした。そのためチームは新しいストレージ層を探し始めました。

重い処理を ClickHouse Cloud 内部に移す #

次の段階では、チームはストレージ層として AWS 上の ClickHouse Cloud を選び、取り込みパイプラインの残りの部分はそのまま維持しました。アプリケーション、SDK、OpenTelemetry コレクター、ストリーム、コンシューマーはすべて元の場所に残しました。読み取り経路では、ChatHouse の前段にプロキシを追加してレート制限とアクセス制御を扱うようにしました。データを AI ツールに公開するための O11y MCP サーバーも構築していたためです。「基本的に変わったのは、データがどこに落ちるかと、誰が処理を行うかです」と Francislei 氏は言います。

Mercado Libre の現在のアーキテクチャ。ClickHouse の前段に読み取りプロキシと O11y MCP サーバーが配置されている

新しい構成では、重い処理がクライアントからデータベースに移りました。変換、フィルタリング、集約は、マテリアライズドビューを介して ClickHouse 内部で実行されるようになりました。以前のアーキテクチャの複雑度が、ユーザー総数とスパン総数の掛け算でスケールしていたのに対し、現在のアーキテクチャはユーザー数だけでスケールします。

ストレージ自体は、異なる保持期間を持つ層で構成されています。生データが最初に着地し、1日だけ保持されます。マテリアライズドビューはその生データテーブルから読み取り、スパンテーブル(トレースサマリ、スパン、ルックアップ属性)に投入され、いずれも30日間保持されます。別のマテリアライズドビューのセットがメトリクステーブルに供給され、90日間保持されます。パーセンタイルは、より長い履歴ウィンドウで比較する方が有用になるためです。生イベントが到着したら、「あとは ClickHouse がスキーマとマテリアライズドビューで処理してくれます」と Francislei 氏は言います。

ClickHouse によって重い処理が行われる、Mercado Libre の現在のアーキテクチャのストレージ層

Mercado Libre の階層化されたテーブル構造:生データは1日のTTLで着地し、マテリアライズドビューがスパンテーブル(30日保持)とメトリクステーブル(90日保持)に投入される

ハイカーディナリティでのトレースクエリ #

チームの最も難しかった問題は、ハイカーディナリティのフィルタリングだったと Francislei 氏は言います。彼らはこれを、1つのスキーマにすべてをやらせるのではなく、専用のルックアップテーブルを使って解決しました。

ルックアップテーブル span_events_attributes は、ClickHouse の ReplacingMergeTree エンジンを使用しています。設計の核は ORDER BY 句にあり、属性キーを先頭に、次に時間および分単位のタイムスタンプバケット、次に属性値、最後にトレースID の順に並んでいます。属性値には Bloom フィルタがスキップインデックスとして設定されています。これらを組み合わせることで、範囲やフィルタ対象のパラメータにかかわらず、テーブルは約5秒で結果を返せます。

これによりトレースのクエリは2段階の操作になります。クエリはまずルックアップテーブルに対してハイカーディナリティ属性(たとえばセッションIDや商品ID)でフィルタし、続いて AggregatingMergeTree 上に構築されたトレースサマリテーブルに対して、トレースIDとタイムスタンプで一致するトレースを解決します。

これを機能させたスキーマ選択は、いくつかの重要ポイントに一般化できます。プライマリキーはクエリ指向で、低カーディナリティなカラムを優先すべきです。圧縮は ZSTD を使用し、チームはこれが効果的であることを確認しました。Bloom フィルタのスキップインデックスは、ハイカーディナリティ属性を安価に扱います。AggregatingMergeTree、マテリアライズドビュー、集約関数は分析エンジンとして機能します。そしてクラスタは、すべてを1つで実行するのではなく、読み取り、書き込み、マージ用の別々のサービスに分割されています。

ペタバイト規模で50倍高速なクエリ #

Mercado Libre の以前の構成と現在の ClickHouse Cloud 上の構成を比較すると、その差は明白です。以前は5分以上かかっていたクエリが、現在は約4秒で返ります。50倍の高速化です。ハイカーディナリティ属性は効率的にインデックス化され、マテリアライズドビューが事前集約済みで到着し、エンジニアはそれらの属性を直接フィルタできます。

Francislei 氏が共有したデータ量は、ClickHouse が吸収しているスケール感を伝えます。スパンテーブルは9.55兆行を保持し、4.34 PiB を約 621 TiB に圧縮しています。86% の削減です。ルックアップ属性テーブルは4.9兆行、トレースサマリは8,700億行を保持しています。生テーブルは181 TiB を約 20 TiB に圧縮しており、89% の削減です。

そしてこれらの数値は全体像の一部にすぎません。現時点でチームは重要なアプリケーションの約 30% を ClickHouse Cloud に移行済みで、その 30% だけで1分あたり4億スパンを生み出しています。ログとメトリクスの移行はこれからです。

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

Daniel 氏は、ClickHouse Cloud への移行から得た6つの教訓を共有しました。1つ目は、開発環境ではなく実際の条件下でプロファイリングとベンチマークを最初に行うことです。「実際の結果を出すには、同じワークロードを同じ条件下でベンチマークする必要があります」と Daniel 氏は言います。

2つ目はインデックス設計は反復的だということです。「プライマリキーはスキーマの中で最も重要な選択の1つです」と Daniel 氏は言い、チームはプライマリキーを見直すことを想定しており、すべてのスキップインデックスは信頼する前にテストしていると付け加えました。

3つ目の教訓は、ClickHouse のシステムテーブル内のメトリクスやログと、HTTP API 経由で公開されるメトリクスを使ってアラートを駆動し、クラスタを執拗に監視することです。4つ目は自分たちのボリュームに合わせてチューニングすること。「バッチサイズは単純な設定ではありませんが、極めて重要です」と Daniel 氏は言います。チームはパーツが多くなりすぎないように、バッチングと非同期挿入の挙動を一緒にチューニングしました。

5つ目の教訓は、ストレージとコンピュートを分離することです。チームは読み取り、書き込み、マージを1つのクラスタで開始しましたが、パーツが多すぎる問題に直面し、CPU をより有効に活用するために約50スレッドのマージクラスタを含む専用クラスタへ移行しました。これらのクラスタのサイジングには、本番トラフィックをテスト環境にミラーリングし、その後 ClickHouse の推奨に従い、水平スケールする前に垂直スケールを行いました。

6つ目の教訓は、スキーマとクエリはハードウェアと同じくらい重要だということです。「別の講演でマイクを渡されるまで、私はこう言い続けます」と Daniel 氏は笑いながら言いました。

Mercado Libre のオブザーバビリティの次のステップ #

今後、チームは AI テレメトリのためのオブザーバビリティバックエンドを検討しており、ClickHouse が2026年に買収したオープンソースの LLM オブザーバビリティおよび評価プラットフォームである Langfuse の利用を模索しています。「エージェントは増加しており、これらのコミュニケーションの内部で何が起きているのかを理解する必要があります」と Daniel 氏は言います。

また、デプロイなどのイベントとトレーシングデータを相関させてプロアクティブなインサイトを提供する新しいインテリジェンスレイヤーの追加、テキストインデックス(転置インデックスとも呼ばれます)の実装、スパン属性マップ内のあらゆる属性でフィルタリングと集約を行えるようにする取り組みも進めています。

最後に、ベクトル検索を使ったセマンティッククエリも検討しており、これによりエンジニアが特定のインシデントに類似したトレースを表示するよう依頼できるようになります。「オブザーバビリティの未来は、ダッシュボード上の会話ではありません」と Daniel 氏は言います。「データベースはそれに対応できる準備をしておかなければなりません」。