OpenAIのストレージ基盤「Habitat」とは — ChatGPT 10億人を支える設計とPython→Rust移行
OpenAIのストレージ基盤HabitatはChatGPTの週10億人超・70M req/s超・500PB超のデータを支える。クライアントライブラリからサービス化し、2026年にPythonからRustへ全面書き換え。Python版を2,000万req/sまで伸ばした4つの工夫をPart 1記事から解説する。
Habitat（ハビタット）は、OpenAIがChatGPTなど自社サービス向けに構築した社内オンラインストレージ基盤である。結論から言うと、Habitatはもともとクライアントライブラリとして始まったが、規模の限界に直面して独立サービス化し、さらに2026年にPythonからRustへ全面書き換えられた——この記事はその過程を追った、OpenAIエンジニアリングブログのPart 1を解説するものだ。
元記事は2026年9月11日に公開された「Rapidly scaling online storage to serve over 1 billion ChatGPT users」（著者: Jon Lee、Chaomin Yu、Ben Ries）で、週10億人超が使うChatGPTを支えるストレージ層がどう限界に達し、どう作り直されたかを扱う全2部構成のPart 1にあたる。OpenAIはOpenAI Agents APIとはのような開発者向け機能の発表が目立つが、今回はその裏側を支えるインフラの舞台裏を解説する。以下、原文にある事実だけをもとに要点を整理する。
Habitatとは — ChatGPTを支えるオンラインストレージ基盤
Habitatは、ChatGPTや社内の各サービスがデータを読み書きする際に必ず経由する中間層だ。構造としては「各クライアントサービス → Habitat → 実際のストレージ資源（Azure Cosmos DBなど）」という3層になっており、クライアント側はHabitatが提供するシンプルなAPIだけを見ればよく、背後でどのストレージにどう分散配置されているかを意識しなくていい。一次情報はOpenAI公式記事（英語）。
| 指標 | 値 |
|---|---|
| ピーク時リクエスト数 | 70M+ req/s |
| 週次アクティブ利用者 | 10億人超 |
| 保存データ量 | 500PB超 |
| 展開リージョン数 | 約40リージョン |
| 起点 | DevDay 2023 |
なぜクライアントライブラリから独立サービスにしたのか
Habitatはもともと各サービスに組み込むクライアントライブラリとして始まったが、2025年中頃にはこの形が限界を迎えていた。象徴的なのが、リージョン分散したCosmos DBアカウントへ移行した際のロールアウト事故だ。新しいクライアントを数十のサービスに配布するだけで数日、安全のためのシャドーイング機能を追加するのにさらに数日、見つかったバグの修正にまた数日を要した。そうして慎重に進めていた最中、ある1チームが全く無関係な理由で古い（バグ入りの）クライアントバージョンへロールバックし、まさに避けたかった障害を引き起こしてしまった。
この経験から、OpenAIはHabitatをライブラリではなく独立したサービスとして切り出す判断をした。サービス化によって、デプロイ・可観測性・改善を単一の制御点に集約できるようになり、複数サービスへ配布して足並みを揃える必要がなくなる。さらにACL（アクセス制御リスト）や監査ログ、ストレージへのアクセス制限をHabitat側で一括して実施できるセキュリティ上のチョークポイントにもなり、外部・内部・そしてエージェント主体からの不正アクセスを防ぐ砦としても機能する。
Pythonサービスを1秒2,000万リクエストまで伸ばした4つの工夫
Habitatのサービス本体はPythonで書かれている。OpenAIはこれを「意図的な技術負債」と位置づけていた——100倍規模のトラフィックでは通用しないと分かっていながら、Codex/GPTモデルの進化によって将来の書き換えがより容易になるという賭けをして、あえてPythonのまま突き進んだ。実際にピーク時2,000万req/s超まで処理できるようになったのは、次の4つの工夫があったからだ。
(a) asyncioのイベントループ遅延を実測する — asyncioが提供するのは並行性であって、CPU並列性ではない（GILの制約による）。ところがHabitatにはルーティング、圧縮、暗号化、チェックサム計算、ヘルスチェック、シャドーイング、ヘッジングなどCPUを食う処理が多く含まれる。p99以上の遅いリクエストのトレースを見ると、下流のデータベース自体は速く応答しているのに、コルーチンの再スケジュールを待つ間に処理が止まっているケースが目立った。そこでバックグラウンドタスクを一定間隔でスケジュールし、期待した実行時刻と実際の実行時刻の差分を記録することでイベントループ遅延を実測した。高負荷時には数百ミリ秒から数秒のジッターが確認されている。対策として、1プロセスあたりの同時処理リクエスト数を小さく抑え、その代わりにプロセス数を大量に横展開する構成に変更した。
```python
# イベントループ遅延を計測する概念を示す簡略例
import asyncio
import time
async def measure_loop_delay(interval: float = 0.5):
while True:
expected = time.monotonic() + interval
await asyncio.sleep(interval)
actual = time.monotonic()
delay = actual - expected
# 実運用ではメトリクス基盤へ送信する
print(f"event loop delay: {delay * 1000:.1f}ms")
asyncio.create_task(measure_loop_delay())
```(b) フィーチャーフラグ設定のパース負荷を下げる — フィーチャーフラグ管理に使うStatsigは、既定では毎分・ジッターなしで全サービス分の本番ルールを含む巨大な設定をポーリングする。Habitatは1つのPodあたり最大8つのPythonプロセスを動かす設計だったため、毎分、Pod内の全ワーカーがほぼ同時に停止してJSONパースを行うという事態が起きていた。対策として、パース対象を必要なものだけに絞った小さな設定に変更し、更新間隔を延ばし、バックグラウンドタスクの実行タイミングにジッターを加えて同時実行を散らした。
(c) コネクションプールをLIFOからFIFOへ — クライアント側でのコネクションプーリングは、少数のサーバプロセスに負荷が集中しやすい。尾部（テール）のプロセスは平均の5〜10倍もの同時リクエストを抱えることがあった。過負荷なクライアントを止めても一部のサーバプロセスは劣化したままで、再起動するまで悪化し続ける「メタステーブル障害」も観測された。原因は、利用していたaiohttpのTCPConnectorが既定でLIFO（後入れ先出し）でコネクションを再利用する設計にあったことだ。遅い（過負荷の）サーバへの接続ほどプールに遅く返却され、次のリクエストで優先的に選ばれてしまい、さらに負荷が集中するという正のフィードバックループが生まれていた。これをFIFO（先入れ先出し）にパッチすることでループを断ち切り、定常時の負荷分散も改善した。現在は主にIstio/Envoyのサーバ負荷を考慮したロードバランシングに依存している。
(d) Envoyでコネクションをfan-inする — Habitatはプロセス数が桁違いに多いため、下流サービスへのコネクション数がふくれ上がり「thundering herd（雷鳴の群れ）」問題を起こしやすい。通常のデプロイでも接続の再生成によるCPU churnが発生し、接続がリークすればNATゲートウェイの飽和にもつながる。そこでEnvoyを使い、PythonからのHTTP/1接続をHTTP/2へ昇格させて多重化・プール化し、接続の寿命を延ばすことでこの問題を緩和した。レート制限やサーキットブレーカーもEnvoy側に集約している。
| 課題 | 原因 | 対策 |
|---|---|---|
| イベントループ遅延 | asyncioは並行性のみでCPU並列性がない（GIL） | 同時リクエスト数を抑えプロセスを横展開 |
| フィーチャーフラグのパース負荷 | 毎分・ジッターなしで巨大設定を全ワーカーが同時パース | 設定を縮小・間隔延長・ジッター付与 |
| コネクション集中 | aiohttpのLIFO再利用による正のフィードバック | FIFOへパッチしIstio/Envoyの負荷考慮バランシングへ |
| thundering herd | プロセス数過多で下流コネクションが急増 | EnvoyでHTTP/2へ昇格し多重化・プール化 |
Habitatは「できることを減らす」設計 — 制約付きNoSQL API
Habitatは任意のSQLクエリを許す設計にしていない。あえて単純なNoSQL APIに制約することで、「一定コストで予測可能なリクエスト」を実現するというトレードオフを選んでいる。Postgresを使っていた時代は、すべてのクエリやスキーマ変更をチームがレビューできていたが、サービスが成長するにつれてそれが不可能になり、ホットパス上の高コストなクエリがデータベース全体を落とす障害が繰り返し発生するようになった。SQLは「書くのは安いが実行するのは高い」というコスト不均衡を抱えており、Habitatはこれを、高コストになりうる操作をクライアント側のコード上で明白にすることで回避している。
データモデルはMetaのTAOに着想を得たobject/edge型で、型自体はクライアントが定義する。直接のedge照会以外のグラフ走査はサポートしない。objectと自分自身が持つedgeは同じストレージパーティションに同居させる一方、edgeの先にあるobjectまで同居させることは狙わない——水平分割は容易になるが、走査は非効率になり、別リージョンの別Cosmos DBアカウントを跨ぐこともある。複雑なクエリが必要な場合は、CDC（Change Data Capture）でRocksetへデータを流すオフラインの二次ビューを用意する構成で、各チームが自前でRocksetをスケールさせる必要があり摩擦はあるものの、「単純なクエリを既定にし、複雑なクエリには逃げ道を用意する」というトレードオフ自体は正しいと位置づけられており、分析・検索の負荷からオンラインストレージを切り離す効果もある。
PythonからRustへ — 2人のエンジニアとCodex・GPT-5.5で全面書き換え
書き換えを1年先送りしたことで、OpenAIは成長期の急務に集中できたという。Habitatは現在、OpenAI社内でコア数において第2位の規模のサービスであり、Envoyのフットプリントで見ると第4位にあたる。Python実装はピーク時に2,000万req/sを超えるリクエストを処理していた。
2026年第2四半期、エンジニア2名がCodexとGPT-5.5を使ってHabitatをRustへ全面的に書き換えた。OpenAIによれば、現在は本番リクエストの95%をRust版が処理しており、数週間以内にPython版を完全に廃止する予定だという。同社のデータでは、Rust版はCPU効率が6倍、メモリ効率が15倍向上し、平均遅延・テール遅延ともに大幅に改善したとしている。ただしRust版の内部設計については本記事では公開されておらず、今後の別記事で扱うとされているため、ここでは推測を書かない。なお、逆方向の判断をした例として、RustからTypeScriptへ舵を切ったPrisma ORMの現在地もある。言語選択は扱う規模とチーム体制次第であり、どちらが正解ということではない。
| 指標 | Rust移行の効果 |
|---|---|
| CPU効率 | 6倍（OpenAIのデータ） |
| メモリ効率 | 15倍（OpenAIのデータ） |
| 本番トラフィックのRust比率 | 95% |
| 開発体制 | エンジニア2名＋Codex＋GPT-5.5 |
| 実施時期 | 2026年第2四半期 |
中小規模のシステムに持ち帰れる教訓
- API面積を絞る — 任意のクエリを許さず、できることを減らすことでコストを予測可能にする
- 「既定値」を疑う — フィーチャーフラグの更新間隔やコネクションプールのLIFO/FIFOなど、ライブラリの既定挙動がボトルネックを生むことがある
- 本当のボトルネックを計測してから直す — イベントループ遅延のような見えにくい遅延要因は、まず実測してから対策する
- 書き換えは技術負債として意図的に先送りしてよい — ただし期限と撤退条件（どうなったら書き換えるか）を決めておく
よくある質問
Habitatは他社でも使える？
Habitatは公開されたOSSやAPIではなく、OpenAI社内向けのストレージ基盤であり非公開だ。
なぜAzure Cosmos DBを選んだのか？
Part 1の元記事では選定理由そのものには触れられていない。Part 2ではAzure Cosmos DBとの協業をどうスケールさせたかを扱う予定とされている。Azureの基礎については中小企業のためのAzure導入ガイドも参考になる。
Pythonで2,000万req/sは本当に可能なのか？
OpenAIの実例では可能だったが、1プロセスあたりの同時処理数を抑えてプロセス数を大量に横展開し、asyncioのイベントループ遅延を継続的に計測・管理する運用が前提になっている。
Rust版とPython版の性能差はどれくらい？
OpenAIのデータでは、CPU効率が6倍、メモリ効率が15倍向上し、平均・テール遅延も大幅に改善したとされている。
Part 2では何が語られる予定？
マルチテナント環境での信頼性、読み取り性能の階層化戦略、Azure Cosmos DBチームとの協業について扱う予定とされている。
まとめ
HabitatはOpenAIが10億人規模のトラフィックを支えるために、まずクライアントライブラリからサービス化し、次にAPIをあえて単純化し、最後にPythonという「意図的な技術負債」をRustへ計画的に解消するという順序で進化してきた基盤だ。Part 2ではマルチテナント信頼性や読み取り性能の階層化、Cosmos DBチームとの協業が語られる予定であり、続報を待ちたい。
この記事に関連する無料ツール（登録不要・その場で結果）
お気軽にご相談ください
お問い合わせ