ウェアハウスの枠を超えて: METRO MarketsがClickHouse Cloud上に万能データプラットフォームを構築した方法

ヨーロッパ各地で、青と黄色の巨大な METRO の卸売店舗はおなじみの光景です。60年間にわたり、このキャッシュ＆キャリー型卸売倉庫は大陸中のレストラン、ホテル、ケータリング業者へ物資を供給してきました。20か国以上に広がる600以上の拠点を擁し、世界最大級の小売企業としての地位を不動のものにしています。

しかし2018年、社内のあるチームがB2Bコマースの展望を見渡し、ひとつのギャップに気づきました。METROほどの規模を持つ企業であっても、顧客が事業を運営するのに必要なもののほんの一部しか提供できていなかったのです。ホスピタリティ業界に特化して構築されたオンラインマーケットプレイスなら、実店舗の在庫をはるかに超える幅広い品揃えを提供できるはずでした。

METRO Markets は2019年9月にドイツで立ち上げられ、現在ではヨーロッパ6か国で展開しており、顧客基盤であるホテル、レストラン、ケータリング事業者に向けて100万点以上の商品を提供しています。その舞台裏では、少人数のデータチームがプラットフォームを支えるインテリジェンスを動かしています。セラー分析や信用リスクスコアリングから、行動データ、運用ログに至るまで、そのすべてが ClickHouse Cloud を通じて流れています。

今回私たちは METRO Markets チームにお話を伺い、より優れたデータウェアハウスを追求した結果、いかにしてはるかに価値が高く野心的な成果—社内のあらゆるチームにリアルタイムで現実の共通ビューを提供する単一プラットフォーム—に行き着いたのかを聞きました。

データレイヤーにおける成長の痛み #

2020年に Luis Jurado 氏がデータエンジニアリングチームリードとして加わった際、会社はインフラを上回るスピードで成長していました。自社運用のデータスタックは Impala と Kudu という、一定の規模までは理にかなっていたものの限界が見え始めていた Hadoop エコシステムのツール群で構築されていました。「会社の成長とともに手に負えなくなっていきました」と彼は振り返ります。「社内でのメンテナンス課題が山積みで、スケールさせるのも容易ではありませんでした」

ビジネスが拡大するにつれ、データの信頼性は深刻な懸念事項となりました。エンジニアリングチームは需要に追いつくために並行してデータストアを構築しましたが、ビジネスレポートは依然として Impala に依存しており、成長する METRO Markets が求める信頼性と一貫性の水準を満たすことが難しくなっていました。「チームごとに異なる数値を見ている状態でした」と、エンジニアリングオペレーション＆セキュリティ責任者の Hakan Dilaver 氏は語ります。価格設定、物流、与信に関する意思決定をリアルタイムで行う企業にとって、そうした認識の不一致は実害を伴うものでした。

人的なコストもかかっていました。会社の成長にもかかわらず、データチームは事業の他の部門ほど急速には拡大していませんでした。データエンジニアリング＆サイエンスリードの Markus Nutz 氏は、優秀な人材がビジネスを真に前進させる仕事ではなく、夜の間に何かが壊れていないかを確認することに時間を取られすぎていたと説明します。誰もが求めていたのは、日々の業務を楽にしてくれるもの、Markus 氏の言葉を借りれば「ただ普通に動くもの」でした。

選ばれざる道 #

代替案の検討を始めた際、真っ先に挙がったのは Google BigQuery でした。METRO グループ全体で広く使われていたためです。Luis 氏は「グループの他の部門と異なるツールを選ぶには、常に特別な説明と合意形成が必要になります」と述べています。

それでもチームは適切な分析を行い、本番環境で実行されている実際のクエリを使って、Snowflake や ClickHouse と並んで BigQuery をテストしました。大小さまざまなクエリにおいて、「ClickHouse のほうが高速に動作しました」と Luis 氏は言います。特に負荷の高いクエリの1つでは、プラットフォーム間で完了時間に顕著な差が確認されました。別のクエリでは、応答時間が4秒から200ミリ秒未満にまで短縮されました。

しかし、パフォーマンスだけで議論に勝てるわけではありませんでした。「ビジネスの観点からは、コストの予測可能性も求められていました」と Luis 氏は語ります。「代替製品ではコストの予測が困難でした。支出を抑えるための制御機能は用意されていたものの、私たちのユースケースには適さないパフォーマンス上のトレードオフが生じることがわかりました」。対照的に、ClickHouse の料金モデルは、クエリ速度を犠牲にすることなく支出を予測できるようにしてくれました。

「私たちはデータジャーニーにおける次のステップを必要としていました」と Luis 氏は言います。「いくつかのツールを分析し、テストした結果、ClickHouse に行き着いたのです」

基盤の構築 #

現在のアーキテクチャでは、データ移動の大半を Airbyte が担っており、CDC コネクタを介して MySQL や Postgres のソースからデータを取得し、ClickHouse へ書き込んでいます。ただしチームでは、GCP のサポートが利用可能になり次第、ClickHouse ネイティブの取り込みエンジンである ClickPipes をテストする予定です。バックグラウンドでのマージ中の重複排除には、実験的なクリーンアップ機能を備えた ClickHouse の ReplacingMergeTree エンジンを使用しています。「このインフラをさらに簡素化するために、GCP 上で ClickPipes が利用可能になるのを楽しみにしています」と Markus 氏は語ります。

特に難題だったのは Google アナリティクスのデータでした。これは BigQuery 内に存在し、標準のコネクタでは移動できませんでした。チームはクラウドストレージのバケットにデータをダンプし、外部テーブル経由で ClickHouse に読み込むことでこれを解決しました。Markus 氏はこれを「大きな前進」と呼び、「これでようやく、社内のすべてのデータが1つのデータウェアハウスに揃いました」と付け加えます。

データの活用側について、Luis 氏は取り込み機能と同じくらい ClickHouse の幅広い互換性が重要だったと語ります。「Impala を使っていた頃は、ODBC や JDBC のドライバーしか利用できませんでした」と彼は説明します。「私たちのサービスは主に PHP で書かれています。Grafana も Looker Studio も使えませんでした」。ClickHouse の MySQL プロトコルエンドポイントがそれを変え、開発者もビジネスアナリストも、各自が好むツールから同じデータをクエリできるようになりました。

1つのデータプラットフォーム、広がる用途 #

METRO Markets が ClickHouse を導入した際、当初の役割を越えてこれほど急速に広がるとは誰も予想していませんでした。データウェアハウスのプロジェクトとして始まったものは、ストレージ、分析、機械学習、オブザーバビリティを網羅する、スケーラブルな単一プラットフォームへと発展しました。

現在、ClickHouse は同社の中核となるデータウェアハウスとして機能し、トランザクションデータ、行動データ、MongoDB のコレクションを1か所に集約しています。「これは METRO Markets が始まって以来、成し遂げられていなかったことです」と Markus 氏は言います。

その基盤の上に構築されているのが、拡充を続けるリアルタイム分析レイヤーです。プラットフォーム上で販売を行うセラーは、期日通りに配送できているか、自社の価格設定にどれだけ競争力があるか、商品がどのように売れているかをほぼリアルタイムで把握できます。これはセラーの事業運営に直結するため、データには高速性と可用性の双方が求められます。ClickHouse はその両方を満たしています。

ClickHouse の Query API エンドポイント機能(Markus 氏が「嬉しい驚きでした… ドキュメントの記載以上に素晴らしい機能です」と評するもの)は、こうしたユースケースのいくつかで中核的な役割を果たしています。チームはこの機能を利用して、VIP ステータスやアカウントフラグといったユーザー特性を下流のシステムへ即座に提示しています。また、同社の信用リスクモデル向けの軽量なフィーチャーストアの動力源にもなっています。トランザクションごとに ClickHouse からユーザーの特徴量が取得され、中間システムを介さずにエンドツーエンドで予測が生成されます。「フィーチャーストアを通常どのように構築するか—インフラや取り込みパイプライン—を考えると、少し冒険ではありました」と Markus 氏は振り返ります。「しかし賭けに出てみたところ、非常にうまく機能しています」

チームは ClickHouse をオブザーバビリティにも活用し始めています。社内のエンジニアは、運用ログ、特にセラー向けプラットフォームの API ログの保存と調査に ClickHouse を使用しています。別のメトリクスレイヤーを構築することなくアドホックな集計やレート制限のクエリを実行できるため、大幅な時間節約につながっています。「ClickHouse なら、直接そのままクエリを実行できます」と Luis 氏は言います。「通常のログでは極めて困難だったはずです」。Hakan 氏は、チームが最大のログパーティションの1つを Datadog から ClickHouse へ移行することを検討していると付け加えます。

そして、誰も想定していなかったユースケースとして AI があります。複数の社内チームが、顧客対応スタッフが注文情報を照会して問題をより迅速に解決できるように、LLM を活用したツールを検討しています。関連データに最も手軽にアクセスできる経路は、ほぼ常に ClickHouse につながっています。これは、ClickHouse が業界全体で加速しているのを目の当たりにしている傾向の一例です。AI エージェントがデータへの主要なインターフェースになるにつれ、その背後にあるデータベースには高速性、高い同時実行性能、常時稼働が求められるようになっています。

より安く、より速く、より信頼性の高い環境へ #

ClickHouse のインパクトが真っ先に現れたのはストレージであり、Luis 氏が説明するように、それはコストに直結します。「Hakan と話すときはいつもこう言っています。『MySQL にあるこの 1 テラバイトのデータは保管に X ドルかかっていますが、ClickHouse に移せば 100 メガバイトになり、ギガバイトあたりの保管費用も安くなります』と」と彼は語ります。「つまり、明確なメリットがあるのです」

マネージドソリューションを採用するという決断も重要であったことが証明されました。Impala と Kudu を自社運用する運用負荷を経験していたチームは、インフラの管理を ClickHouse Cloud に任せるという賢明な選択をしました。Luis 氏が語るように、「以前のソリューションで自社運用の辛さを痛感していたため、そのリスクを再び冒したくはありませんでした」。

Markus 氏は「私にとって最大のメリットは、すべてのデータが利用可能であり、それを高速にクエリできることです」と述べています。本番クエリを用いたベンチマークテストにより、ClickHouse が同社の特定のユースケースやクエリパターンにより適していることが示されました。

Hakan 氏も同調します。「最も重要だったのは、高速で信頼性の高いソリューションにデータ運用を一元化できたことです」。その信頼性によって、かつて会社を悩ませていた不一致は解消されました。異なるチームが異なるデータソースを参照して別々の数値を得る代わりに、ビジネス部門もエンジニアリング部門も、各自が選んだツールを通じて同じウェアハウスからデータを引き出すようになり、プラットフォームは安定して稼働し続けています。

さらなる旅の続き #

METRO Markets では、データプラットフォームが当初想定していなかったチームまでもが、ClickHouse 上に構築を行う理由を見出しています。「機能セットのおかげで得られたメリットや、最終的に利用することになった用途の多さは、私たちの予想を上回るものでした」と Luis 氏は述べています。

この旅はまだまだ終わらない、と彼は付け加えます。「今後はさらに多くの要素を組み込んでいきたいと考えています」と語ります。ロードマップの次なるステップは、Kafka と Flink によるストリーミングインフラを ClickHouse に接続し、プラットフォームをさらに前進させるリアルタイムストリーム処理のユースケースへの扉を開くことです。

ClickHouse によって、当初はデータウェアハウスのプロジェクトとして計画されたものが、静かに、そして自然な形で、会社全体のあらゆる用途に応えるデータインフラへと成長を遂げました。