---
title: "なぜOpenAIはペタバイト規模のオブザーバビリティにClickHouseを選んだのか"
date: "2025-07-16T06:22:23.369Z"
author: "ClickHouse"
category: "User stories"
excerpt: "OpenAIは1日にペタバイト級のログを取り込み、その処理を支えているのがClickHouseです。 数十億規模のモデル実験から、ChatGPTのバイラル的スパイクに至るまで、あらゆる現象を可視化するために、彼らがどのようにオブザーバビリティを構築したのかをご覧ください。"
---
# なぜOpenAIはペタバイト規模のオブザーバビリティにClickHouseを選んだのか
自分のオブザーバビリティがすごいと思ってる？それなら、一度 [OpenAI](https://openai.com/) の立場になってみるといい。
OpenAIは毎日、ペタバイト級のログデータを取り込んでいます。これは、議会図書館500館分または20億枚のiPhone写真に相当します。もし1秒に1枚ずつ写真を撮ったとしても、OpenAIが1日でログに記録するデータ量に到達するには60年かかります。その保存には、パレット1台分のハードドライブが必要です。しかも、そのボリュームは毎月20％以上のペースで増加しています。
「このスケール感は、本当に信じられないレベルです」と、OpenAIのエンジニアリングマネージャー、Akshay Nanavati氏は語ります。
モデル研究、ChatGPT、企業向けAPIの提供など、OpenAIは複数の重要かつ急成長中のシステムを抱えており、それぞれが検索可能で高速かつ信頼性の高いログを生成しています。オブザーバビリティとはつまり、高カーディナリティのトレースや突発的な取り込みスパイク、バイラルなユーザー成長による急激な変動に対応できるインフラを構築することを意味しています。
Akshay氏とPoom氏が [ClickHouse初のOpen Houseユーザーカンファレンス](https://clickhouse.com/openhouse) で行った講演をご覧ください：
## AIのあらゆる層におけるオブザーバビリティ
OpenAIは研究機関であると同時に、プロダクトエンジニアリング組織でもあります。その使命は、AIの革新における複数の異なるが密接に連携した分野にまたがっています。
「これらすべての機能において、オブザーバビリティは欠かせないものです」とAkshay氏は言います。
まずは研究チーム。彼らは日々、モデルの可能性を限界まで押し広げようとしています。
「数十億のモデルを、何百万台ものGPUでトレーニングしているんです」とAkshay氏は説明します。彼らは膨大で高カーディナリティなデータセットに対して、しばしばリアルタイムで実験をトレースし、性能を理解し、素早く反復改善する必要があります。
次にChatGPTのチーム。ChatGPTは[史上最も急成長したコンシューマーアプリ](https://www.reuters.com/technology/chatgpt-sets-record-fastest-growing-user-base-analyst-note-2023-02-01/)です。
「ユーザーが増えれば、サーバーが増え、それに伴ってログも増えるんです」と彼は言います。彼らの課題はスケールです。膨大なテレメトリデータに対応し、トラフィックのスパイク中でも常に稼働を維持する必要があります。
そして最後に、企業向けAPIチーム。世界中の企業が、OpenAIのインフラ上でミッションクリティカルなAIアプリケーションを構築しています。ここで求められるのは、絶対的な信頼性です。もし何かが壊れた場合、SLAを満たし、運用を止めないためには、ログが即座に検索可能でなければなりません。
「深夜3時にエンジニアが呼び出されて、何か異常が起きていたとしましょう」とAkshay氏は言います。「そのとき、オブザーバビリティスタックを使って何が起きているのかを即座に把握する必要があります。」
## なぜOpenAIはClickHouseを選んだのか
OpenAIのオブザーバビリティチームがデータベースソリューションの検討を始めたとき、求めていたのは高速かつ柔軟で、将来的にも通用するシステムでした。ClickHouseは、その性能だけでなく、設計思想と構造の面でも群を抜いていました。
「ClickHouseはオープンソースなので、ベンダーロックインがありません」とAkshay氏は言います。
もし何か問題が発生しても、他の誰かの対応を待たずとも、自分たちでコードを読んでデバッグし、すぐに前に進むことができます。
「これは本当に便利なんです。」
ClickHouseはクラウドネイティブであり、水平方向へのスケーリングが容易にできるように設計されています。
「つまり、取り込み処理とクエリ処理の両面で、比較的少ない運用負荷でスケールできるということです」とAkshay氏は説明します。
ClickHouseの柔軟なインデックス機構は、多様なクエリやユースケースに対応しており、重要な点に応じてパフォーマンスを調整できます。
「クエリを速くするインデックスを有効にして、逆に遅くするインデックスは無効にできる。それがこのシステムをスケールさせるうえで非常に重要なんです」とAkshay氏は語ります。
さらに重要なのは、ClickHouseはSQLで操作できるという点です。SQLは人間にも、AIモデルにも、エージェントにも理解できる言語です。
そのため、AIをオブザーバビリティスタックに統合することが容易になり、非常に強力な機能の実現を可能にしているとAkshay氏は述べています。
最後に、ClickHouseがすでに多くの企業でオブザーバビリティ用途に使われていることも安心材料となりました。
「私たちの同業の多くが、まさにこの用途でClickHouseを使っているんです」とAkshay氏は言います。
「つまり、良いサポートが受けられるし、実戦で使われていることも証明されています。まさにこの用途にぴったりのツールなんです。」
## GPT-4o がクラスターを溶かした日
OpenAIのオブザーバビリティシステムでは、Fluent Bitエージェントから流れてくるログが、90個のシャードを持つClickHouseクラスター（各シャードに2つのレプリカ）に取り込まれます。ユーザーによるクエリの大半（Poom氏によると約80%）は直近2日間のデータにしかアクセスしないため、そのデータは高速アクセスのためにディスク上に保持されます。一方で、より古いログはBLOBストレージへ移動されます。
「ClickHouseはクラウドネイティブなシステムなので、このような階層化されたストレージ構成をうまく抽象化してくれます。SQLを書く人たちは、データがどこにあるかなんて気にしなくていいんです」と彼は言います。
以下の図は、Fluent Bitエージェントからログがロードバランサーを通り、90のClickHouseシャードへと流れていく仕組みを示しています：
この図は、新しいデータはディスク上に残り、古いログは自動的にBLOBストレージに移される構成を示しています：
「この構成によって、すべてが非常にスムーズに動いていました」とPoom氏は語ります。
……2025年3月25日までは。
この日、OpenAIは [GPT-4oで画像生成機能をリリース](https://openai.com/index/introducing-4o-image-generation/) しました。
「ユーザーたちはこれを大変気に入りました」とPoom氏は言います。アニメ風の自撮り、ミーム画像、さらにはステーキとして描かれたOpenAIのロゴまで登場しました。
「私がこれまで見た中で、最大級のユーザー増加スパイクのひとつでした。」
その一方で、「サーバーは全台、溶けかけていました」と彼は言います。ログの取り込み量は一晩で50%も急増しました。
「CPU使用率に50％の余裕があることを確認して安心して寝たんですが、翌朝にはその余裕が一夜にして消えていたんです。」
GPT-4oの画像生成のリリース後、CPU使用率は50%上昇：
もちろん、こんな状態は持続可能ではありませんでした。
「取り込み量を制御し、ClickHouseをどうにかしてスケールさせる必要があると分かっていました」とPoom氏は言います。そこで彼らは、クエリ専用の3つ目のレプリカを追加し、重たいクエリが取り込み処理を妨げないようにしました。また、積極的なサンプリングを開始し、ログをサービス・クラスター・コンテナ単位で分解してボトルネックを突き止めようとしました。
「でも、最終的にはそれでも足りなかったんです。」
ブレークスルーが訪れたのは、ClickHouseそのものをプロファイリングしたときでした。
スタックトレースの中で、あるパターンが浮かび上がりました。全CPU時間の半分以上が、Bloomフィルターの構築に使われていたのです。Bloomフィルターとは、クエリ時に無関係なデータブロックをスキップするためのインデックス構造です。問題の根源は？Bloomフィルター内部に埋もれていた、1つの除算命令でした。
Poom氏の説明によれば、除算は加算やビット演算に比べておよそ30倍遅い演算であり、ClickHouseでは挿入処理のたびにそれが実行されていました。
「毎回、同じ数値で割っていたことに気づきました。Bloomフィルターに要素を追加するたびに、そのハッシュを配列サイズで割っていたんです。」
そこで、ほぼ1行だけの変更――この除算を乗算とビットシフトに置き換えたところ、CPU使用率が即座に40%も削減されました。Poom氏は、その前後を示すグラフを共有し、
「これは“あの事件の間の私の心拍数の時系列”とも言えるかもしれませんね」と冗談を交えて話しました。
Bloomフィルターの最適化により、CPU使用率が40%減少：
事態が収束した後、その改善内容はチームメンバーによってClickHouse本体にアップストリームされ、より広いコミュニティにも貢献する形となりました。
「ClickHouseのクラウドネイティブな設計とオープンソース性が、いざという時に本当に私たちを救ってくれたんです」とAkshay氏は補足します。
## OpenAIとClickHouseのこれから
これまでで最も激しいトラフィックスパイクを乗り越えた後でも、Akshay氏は「OpenAIのオブザーバビリティの取り組みはまだまだ終わりじゃありません」と語ります。
チームは、ClickHouseの堅牢性をさらに強化し、よりスマートにスケールさせるべく取り組みを続けています。中でも、\*\*クエリプランニング（クエリの実行計画）\*\*に改めて注力しています。
「今の私たちは、クエリをすべてのシャードにナイーブにばらまいている状態です」とAkshay氏は言います。
「そのやり方が限界に達しつつあるんです。」
同時に、社内ツールの使いやすさ向上にも継続的に取り組んでいます。
「エンジニアがより効率よく仕事できるよう、パフォーマンスモニタリングなどの機能を整えていきたいんです」と彼は述べます。
さらにその先には、より自律的なオブザーバビリティスタックの構想があります。AIエージェントがオンコール対応のワークフローに直接組み込まれるのです。
「アラートの処理や、インシデントの診断を人間が関与する前にAIが対応できる――そんな世界を目指しています」とAkshay氏は言います。
OpenAIのオブザーバビリティの未来は、その製品群と同様に広大で、変化が速いものであり続けるでしょう。
しかしClickHouseという基盤の上で、彼らはスパイクのたびに進化するシステムを築いてきました。
ペタバイト級のデータスケーリングから、パフォーマンス改善のアップストリーム貢献に至るまで、OpenAIはClickHouseの限界に挑戦し、その未来の姿を共に形作っているのです。
ClickHouseがどのようにしてチームのデータ運用を変革できるか、[ClickHouse Cloudを30日間無料でお試しください](https://clickhouse.com/cloud)。