OpenAIは2026年9月11日、ChatGPT、Codex、APIなどのデータアクセスを支えるオンラインストレージ基盤Habitatの設計を公開しました。
公表値は毎秒7,000万超のリクエスト、500PB超のデータ、約40地域、週10億人超。注目すべきは規模だけではなく、Pythonサービスを延命しながら、複雑な問い合わせを意図的に排除し、オンライン処理と分析処理を分離した判断です。
この記事では、OpenAIの公式発表とAzure Cosmos DBの公式資料を基に、一般の開発・運用チームが持ち帰れる設計原則を整理します。
出典：OpenAI公式発表。値は同社による2026年9月11日時点の公表値。
利用者のログイン、Codex設定の取得、新しい会話の開始には、画面が返るまでに複数のデータ参照が走ります。Habitatは、製品とAzure Cosmos DB、独自ストレージ、Valkeyキャッシュ、Blob Storageなどの間に入り、次を共通化します。
2年前は単一データベースへ接続するPythonのクライアントライブラリでした。製品ごとの複雑さを吸収するため、現在は独立した分散サービスへ進化しています。
Pythonのasyncioは、1つのイベントループが多数のI/O処理を切り替えます。OpenAIはバックグラウンドタスクを定期実行し、予定時刻と実行時刻の差からイベントループのスケジューリング遅延を実測しました。
高負荷時には数百ミリ秒、極端な場合は数秒の揺らぎが発生したため、1プロセス当たりの同時要求数を低く保ち、Pythonワーカープロセスを大量に水平展開しています。編集上の推論として、これは「非同期なら同時実行数を上げるほど効率的」という単純な運用が、CPU処理やコールバック集中で崩れることを示します。
初期運用では、一部のプロセスが平均の5〜10倍の同時要求を抱えました。負荷元を止めても過負荷プロセスへ要求が偏り続ける「準安定障害」が起き、再起動まで回復しない状態になったといいます。
調査で焦点になったのが、aiohttpのTCP接続プールにおけるLIFO（最後に戻った接続を最初に再利用）です。接続の最大再利用時間を制限すると劣化が抑えられ、原因の切り分けが進みました。
教訓は、ロードバランサが均等でも、長寿命接続の再利用規則が実効負荷を偏らせることです。インスタンス別の接続数、同時処理数、レイテンシを同じグラフで確認する必要があります。
Habitatは任意SQLを許さず、オブジェクトと直接エッジを扱う単純なNoSQL APIに制限しています。巨大スキャン、複雑なJOIN、無制限のファンアウトをオンライン経路から排除し、1要求の処理量を予測しやすくします。
Microsoftの公式資料でも、Azure Cosmos DBでは1KB項目のポイント読み取りが1 RUである一方、問い合わせは結果数、述語、データ量などで消費量が変わります。また、物理パーティションは最大10,000 RU/s、50GBで、偏ったパーティションキーはホットスポットと429応答の原因になります。Habitatの単純なAPIとパーティション設計は、この特性に合うものです。
大量のPythonプロセスによる水平展開は、OpenAIが基盤移行までの時間を買うために選んだ戦術でもあります。同社はRustへの移行も進めています。通常規模のサービスなら、言語変更より先に、遅い問い合わせ、ホットパーティション、キャッシュミス、接続偏りを直す方が費用対効果は高いでしょう。
今回の記事は2部構成の前編です。OpenAIは次回、マルチテナント信頼性、階層的な読み取り最適化、Azure Cosmos DBとの大規模運用を詳しく説明すると予告しています。
今後の焦点は、Rust移行でテールレイテンシと計算効率がどこまで改善するか、500PB超でデータ配置をどう再均衡するか、障害ドメインとテナント分離をどう両立するかです。具体的なSLO、キャッシュヒット率、コストは今回の公表範囲に含まれていないため、数値比較は続報を待つ必要があります。
Habitatの本質は、巨大なデータベース製品ではなく、製品チームが危険な問い合わせを作りにくい境界です。毎秒7,000万要求を支える設計原則は、機能追加よりも予測可能性、オンラインと分析の分離、実測によるボトルネック特定を優先することでした。
規模が何桁小さくても、「自由度を制限して事故を減らす」「平均ではなく偏りを見る」という考え方は、そのまま業務システムに応用できます。
最終確認日：2026年9月13日