OpenAIがストレージ基盤Habitatを公開、毎秒7000万リクエストを処理

OpenAIがChatGPTを支える内部ストレージ基盤Habitatの設計を公開、毎秒7000万リクエスト超と500ペタバイト超のデータを扱う規模に達している
2024年半ばのPythonライブラリから単独サービスへ分離し、2026年第2四半期にRustで全面的に書き直した経緯を説明
Rust版はPython版と比べてCPU効率6倍、メモリ効率15倍で、すでに本番リクエストの95%を処理している

Habitatとは何か

OpenAIが、ChatGPTなどの自社プロダクトのデータを保持する内部ストレージ基盤「Habitat」について、設計と運用の経緯を公式ブログで公開しました。2回に分けた連載の第1回にあたり、今回はストレージ層そのものではなくサービス層の進化に焦点が置かれています。

同社の説明では、Habitatは毎秒7000万件を超えるリクエストを処理し、500ペタバイトを超えるデータを提供しています。支えているのは週あたり10億人以上が使うプロダクトで、展開先は約40の地理的リージョンに及びます。

モデルの能力に関する発表が続くなかで、その裏側でデータをどう保存し取り出しているかが一次情報として語られる機会は限られます。バックエンドやインフラの設計を担う開発者にとっては、規模が変わる局面でどの判断がどう効いたかを追える資料になっています。

Pythonライブラリから出発

Habitatが始まったのは2024年半ばで、当初はChatGPTのメインサーバーと直接やり取りする小さなPythonライブラリでした。スキーマの参照、ルーティング、認可、暗号化、シリアライズ、リクエストの整形、コネクションプールの管理といった処理をまとめて抽象化し、アプリケーション側からデータベース操作の細部を隠す役割を担っていました。

ライブラリという形態は、初期の開発速度という点では合理的な選択です。一方で利用側のサービスが増えるにつれて、後方互換性を保ったままプロトコルを変更する作業が重くなります。数十のサービスに散らばったライブラリを同時に足並みをそろえて更新する必要が生じ、調整コストが開発速度を圧迫しました。

単独サービスへの分離

そこで2025年半ば、OpenAIはHabitatをライブラリから独立したサービスへ移行させました。デプロイ、可観測性、プラットフォームとしての機能追加を一箇所で制御できる点が、この移行の主な狙いです。各サービスに埋め込まれていたロジックが一元化されたことで、改善の反映が全利用者に一度で行き渡るようになりました。

現在のリクエスト経路では、コネクションプールやHTTP/2の多重化をEnvoyとIstioが担い、永続化層にはリージョン分散されたAzure Cosmos DBが使われています。複雑な集計クエリはオンライン系から切り離され、変更データの取り込みを通じて分離されたRocksetのインスタンスに流す構成です。

図1のように、オンラインの読み書きと分析用の重いクエリを別系統に分ける構成が、レイテンシの予測しやすさを支えています。

Rustへの書き直しで効率化

2026年第2四半期、OpenAIはサービス全体をRustで書き直しました。担当したのはエンジニア2名で、CodexとGPT-5.5を併用したと説明されています。開発支援ツールの活用例としても踏み込んだ記述です。

同社の計測値では、Rust版はPython版に対して次の差が出ています。

項目	Rust版	Python版
CPU効率	6倍	基準値
メモリ効率	15倍	基準値
本番リクエストの処理比率	95%	移行中のため公表なし

移行はすでに大部分が完了しており、Rust版が本番トラフィックの95%を受け持つ段階に入っています。なお、Python時代のピークでも毎秒2000万リクエスト超をさばいていたとされ、言語の選択だけが規模を決めたわけではないことも同時に示されています。

Python時代に起きた障害

興味深いのは、Python版の運用で踏んだ不具合が具体的に開示されている点です。ルーティングや圧縮、暗号化、ヘルスチェックといったCPU負荷の高い処理が重なると、asyncioのイベントループのスケジューリング遅延が伸び、テールレイテンシが悪化しました。対策として遅延を実時間で監視し、プロセスあたりの同時リクエスト数を制限してワーカープロセスを大幅に増やす方向へ切り替えています。

機能フラグの設定取得も落とし穴になりました。既定の挙動では全プロセスが1分ごとに本番設定の全体を解析するため、CPU使用の山が同期してしまいます。対象を絞った小さな設定を配布し、更新間隔を延ばしてジッターを加えることで解消しました。

さらに、Pythonのaiohttpがコネクションを後入れ先出しで再利用する挙動が、すでに負荷の高いサーバーへトラフィックを集中させるフィードバックループを生み、準安定的な障害につながっていました。先入れ先出しへの変更でこのループを断ち切っています。プロセス数の増加で下流のコネクションが飽和した問題には、EnvoyのHTTP/2多重化とコネクションの集約で対処しました。

あえてSQLを避けた理由

設計面で一貫しているのは、APIを意図的に狭く保つという判断です。HabitatはSQLではなく、Metaが公開したTAOに着想を得たシンプルなNoSQL APIを提供しています。SQLは安価に書ける一方で、実行コストが高く運用しにくいクエリも簡単に書けてしまう、という理由が挙げられています。

データはオブジェクトとエッジで表現され、両者はストレージ層のパーティション内に同居します。ただし他オブジェクトへの参照は、リージョンをまたぐ場合に必ず同居するとは限りません。グラフ探索の効率よりも水平方向のスケーラビリティを優先した割り切りです。こうした「使える操作を絞ることで運用の予測可能性を確保する」考え方は、OpenAIがAgents APIを公開、Codexハーネスをマネージド提供で示された、実行環境を同社側で抱え込む方針とも通じるものがあります。