Shopify が ClickHouse でグローバル規模のコマースを支えるオブザーバビリティを実現

Shopify は世界最大級のコマースプラットフォームであり、5 大陸で事業を展開し、常時約 500 の Kubernetes クラスターと 150 万のポッドを稼働させています。Ruby、Go、TypeScript のサービス、モバイルアプリ、エッジのログ、データベースなど、さまざまなソースから絶え間なくトラフィックが流れ込みます。エンジニアリングディレクターの Elijah McPherson 氏はこう表現します。「コマースは眠りません。Shopify も眠りません」

この需要は毎年、Black Friday と Cyber Monday (BFCM) の時期にピークを迎えます。「これは私たちにとってのスーパーボウルです」と Elijah 氏は言います。昨年の BFCM 期間中、Shopify はフリート全体で 90 PB のデータを保存し、エッジで 2.2 兆リクエストを処理し、データベースに対して 14.8 兆クエリを実行しました。ピーク負荷時には、プラットフォームは 1 分あたり最大 510 万ドルの取引を処理します。

「この前の Black Friday と Cyber Monday の期間中は、1 分のダウンタイムでマーチャントに 510 万ドルの損失が生じかねませんでした。だからこそオブザーバビリティは極めて重要です。問題を検知し、あらゆるダウンタイムを防ぐ必要があります」 — Elijah McPherson 氏、Shopify エンジニアリングディレクター

Open House SF 2026 で Elijah 氏は、Shopify がグローバル規模のコマース向けに自社のオブザーバビリティプラットフォームを構築した経緯を語りました。セルフホストの ClickHouse を選んだ理由、ログ、トレース、例外を 1 つのエンジンに統合することでコストと複雑さを削減できた仕組み、そして、もし一からやり直すならおそらく ClickHouse Cloud を選ぶだろうと考える理由です。

分断され、予測のつかない構成 #

Elijah 氏は 2021 年、オブザーバビリティ基盤を再構築するために Shopify に入社しました。当時の構成はベンダーごとにサイロ化しており、メトリクス、ログ、トレースにそれぞれ別のベンダーを使っていました。請求額はフリートそのものより速いペースで増え、チームはそれを予測できませんでした。

「私が入社したのは、まさにオブザーバビリティプラットフォームが複数のベンダーにまたがってばらばらになっていたからです」と Elijah 氏は言います。「コストは天文学的に膨らんでいて、しかも予測できませんでした」

この分断はチームのロードマップにも影響しました。本番環境の中核インフラとなっていたツール群が、Shopify の管理下にない外部のロードマップに縛られていたのです。その結果、本来一緒に扱うべきシグナルが、互いに連携しないシステムに分かれて存在していました。メトリクス、ログ、トレースをまたぐ 1 つの質問に答えるには、ベンダーごとの回答を手作業でつなぎ合わせる必要がありました。

状況を整理すると、チームに必要なものは明確でした。一貫性のあるものを構築し、コストを抑え、Shopify に特化させ、スケールさせることです。

Shopify が Shopify のために構築したオブザーバビリティ #

その答えが、チームが「Observe」と呼ぶ社内プラットフォームでした。あらゆるシグナルを 1 か所で横断的に見て、開発者の疑問に答えるという発想です。本番環境で今まさに何が起きているのか。チェックアウトは正常か。デプロイで挙動は変わったか。インシデント中に何が起きたのか。BFCM 中のパフォーマンスはどうか。自信を持ってデプロイできるか。

すべてが一度に実現したわけではありません。Shopify のチームは、最も困っており、最大の効果を見込めるメトリクスから着手しました。高コストのオブザーバビリティベンダーから ClickHouse へメトリクスを移した後、ログ、トレース、プロファイル、例外を同じエンジンに集約しました。これらのシグナルはすべて同じプリミティブ (構造化され、時系列順に並んだ、高次元のイベント) であると捉え、そのすべてを横断して検索と分析を行う 1 つのプラットフォームを構築したのです。現在 Shopify は、メトリクス、ログ、トレース、例外、プロファイルを ClickHouse 上で運用しています。

要件は厳しいものでした。取り込みは平常時で毎秒約 5,000 万イベント、BFCM のピーク時には 1 億イベントに達し、ピーク時の非圧縮テレメトリは約 110 GB/s に相当します。しかもデータは数百のチームから届き、スキーマは絶えず変化します。「エンジニアはこのデータが利用できることを本当に頼りにしていますし、このデータを 1 分以内にクエリできることも求めています」と Elijah 氏は言います。クエリの形はさまざまで、広範な分析から、30 日分のデータの中から針を探すようなルックアップまであります。

エンジンとして ClickHouse を選ぶ #

チームは複数のソリューションを試しましたが、最も優れていたのは ClickHouse でした。「私たちにとって ClickHouse が勝った主な理由は、速いこと、私たちの負荷を処理できること、そしてオープンソースであることです。オープンソースなら、コントリビュートもできますし、ソースコードも理解できます」と Elijah 氏は言います。

Elijah 氏は ClickHouse を「スケールするオープンソースプロジェクトという点で非常にユニーク」だと評します。ClickHouse によって Shopify はコストとロードマップの主導権を手にしました。成長に伴って限界を迎えるバイト単位の課金モデルもありません。さらに、ClickHouse チームと幅広いコミュニティが投資を続けることで、データベースは改善を続けています。「上げ潮はすべての船を持ち上げます」と Elijah 氏は言います。

Shopify の規模で完全なターンキーの製品は存在しないものの、Elijah 氏によれば ClickHouse は「その道のかなり先まで」連れて行ってくれ、「そのままの状態で高性能」でした。ClickHouse はバッチジョブではなく、大量の列指向インサートとペタバイト規模のインタラクティブ分析のために作られており、柔軟なスキーマモデルはチームがその上に構築していく余地を与えました。

「ClickHouse をデプロイした時点で、そのままの状態で約 16 倍の改善が見られ、ピーク性能では 30 倍を超えました。私たちにとって、コンピュートの削減はお金の節約です」

— Elijah McPherson 氏、Shopify エンジニアリングディレクター

ClickHouse を大規模に運用して得た教訓 #

ClickHouse を選ぶことは始まりにすぎませんでした。Shopify のオブザーバビリティプラットフォームの基盤として ClickHouse を数年間運用してきた Elijah 氏は、Open House で、パフォーマンス、コスト効率、信頼性の向上に関するいくつかの教訓を共有しました。

1 つ目は耐久性についてです。ClickHouse は多数の小さなインサートより大きなバッチを好みますが、Elijah 氏が言うように、「大きなバッチを待つ」ことはレイテンシの増大を意味し、Shopify はその間にデータを失うわけにはいきません。解決策は、テレメトリを Kafka にバッファリングしてから大きな同期書き込みをコミットし、ClickHouse がバッチを永続的に保存した後にのみ確認応答を返すパイプラインです。

次は柔軟なスキーマです。Shopify の数百のチームは、日々変化する数百種類のイベント形状を送出するため、スキーマを事前に固定することはできません。それでもクエリを高速に保つために、Elijah 氏とチームはマテリアライズドビューを使っています。メタデータビューで存在するフィールドとその値を追跡しているため、オートコンプリートのクエリは 50-100 ミリ秒で返ります。また、アクセス頻度の高いキーを Map(String, String) から型付きカラムへ昇格させ、クエリが読み取り時に型変換をしないようにしています。これにより、すべて文字列のベースラインと比べて約 30% 高速になり、圧縮率も向上しました。

さらに、マテリアライズドビューはもう 1 つの課題である相関付けも解決します。障害が起きたとき、エンジニアは 1 つのリクエストに紐づくすべてのイベントを必要としますが、それらはログ、トレース、クエリ、プロファイルに散在しています。Shopify は、価値の高い識別子ごとに、どのデータセットにいつ現れたかを記録するマテリアライズドビューを維持しています。まずこのルックアップを参照することで、フリート全体の検索が少数の的を絞ったスキャンに変わり、10 倍の高速化につながります。「『このジョブのすべてのログ、すべてのイベント、すべてのトレースを見せてほしい』と言われれば、それができます」と Elijah 氏は言います。

本番環境での日々の運用 #

現在、ClickHouse を用いた Shopify のオブザーバビリティプラットフォームは約 20 のテナントにまたがって稼働しており、各テナントが固有の取り込みソース、スキーマ、クエリ構成を持ちます。毎週、スキーマ変更、ClickHouse の更新、Kubernetes のアップグレード、互換性のないノードタイプなど、何かしらの移行が進行中ですが、それでも取り込みを止めることはできません。

これを管理するために、チームは社内で Kubernetes オペレーターを作成しました。これは宣言的なスキーママネージャーとして機能し、全テナントにわたる移行やトポロジー変更を、その場限りの手作業ではなくレビュー可能な差分に変えます。

オープンソースの ClickHouse を運用するということは、パフォーマンスとコストのあらゆるトレードオフを自ら直接引き受けることでもあります。「私たちにとってはすべてが調整つまみです」と Elijah 氏は言います。大規模になると、ディスク帯域、IOPS、CPU、パートのマージスループット、オブジェクトストレージの請求といった要素が積み重なり、絶え間ないバランス調整が必要になります。

圧縮は繰り返し効果を上げている施策です。1 バイト節約するごとに、帯域も IOPS も請求額も減るからです。特に効果があった変更の 1 つが書き込み時にマップのキーをソートすることで、ディスク使用量を 20-40% 削減できました。

Shopify と ClickHouse の次のステップ #

Elijah 氏とチームにとって、この仕事に終わりはありません。現在は、ホットパスに NVMe、ウォームデータに SSD、コールドな過去データにオブジェクトストレージを使う階層型ストレージへの移行を進めており、ARM ベースのコンピュートと組み合わせています。スキーマ面では、Map(String, String) と昇格カラムから、バケット化したマップや ClickHouse ネイティブの JSON 型へ移行し、移行作業を減らしつつ圧縮とクエリプランを改善しようとしています。また、取り込みパイプラインを Rust で再構築しており、メッセージ単位の確認応答モデルとイベントループによるスケジューリングを採用しています。Elijah 氏が指摘するように、取り込み量は BFCM ごとに倍増する傾向があり、収集パイプラインは「ホットパスの中で最もホットな部分」になっています。この書き直しは、その増加に先回りし続けるためのものです。

社内オブザーバビリティを支えているのと同じエンジンが、いま隣接する領域にも広がっています。Shopify はフリート全体で継続的にプロファイリングを実行し、ログ、トレース、例外と並べて ClickHouse に書き込んでいるため、チームは数十億サンプルにわたる CPU のフレームグラフをクエリできます。すべてのデータが 1 か所にあるため、「Shopify の誰もが対話できる AI エージェント層にも供給でき、それはすべて ClickHouse を基盤とし、ClickHouse を通じてクエリされています」と Elijah 氏は言います。

次のステップは、チェックアウトのファネル、商品ビュー、コンバージョンのインサイトといったマーチャント向けの分析です。「ClickHouse は自然な選択に思えました」と Elijah 氏は言います。「すべてのテレメトリデータを取り込んで自分たちのためにクエリできるなら、実際にはマーチャントにとっても非常にうまく機能するはずです」

セルフホストの ClickHouse と ClickHouse Cloud #

Elijah 氏は、Shopify がセルフホストの ClickHouse 上にオブザーバビリティプラットフォームを構築したのは、当時 ClickHouse Cloud が存在しなかったからだと認めています。それは運用負荷を自ら引き受けることを意味します。「もし過去に戻って『本当に自分たちでやる必要があるのか』と問うなら、答えはおそらくノーです」と Elijah 氏は言います。「ClickHouse Cloud のようなものを選ぶと思います」

セルフホストにはロードマップ、SLA、コストカーブを完全に管理できるという利点がある一方、ClickHouse のマネージドサービスにはストレージとコンピュートの分離、アップグレード、スケーリングが最初から備わっており、成果を得るまでが早いと Elijah 氏は指摘します。「多くのことを代わりにやってくれます」と Elijah 氏は言います。「取り込みとクエリのコンピュートを分離できますし、実際にはデータのレプリカをそれほど多く持つ必要がないことがわかります。それがコスト削減になります」

さらに、Shopify は ClickStack チームが実装してきた最適化の多くに、独自にたどり着いていました。両チームが互いの取り組みから学び続ける中で、Shopify のようなユーザーが牽引した改善は ClickStack に還元され、より広いオープンソースコミュニティが、パフォーマンスとユーザビリティへの同じきめ細かな配慮の恩恵を受けられるようになります。