はじめに
OpenAIが2026年9月11日、ChatGPTなど自社サービスの裏側を支えるオンラインストレージ基盤「Habitat」の進化について、エンジニアリングブログで詳しく解説しました。本稿では、小さなPythonライブラリとして始まったHabitatが大規模サービスへと成長し、最近Rustへ移行した経緯について紹介します。
参考記事
- タイトル: Rapidly scaling online storage to serve over 1 billion ChatGPT users
- 著者: Jon Lee、Chaomin Yu、Ben Ries（OpenAI Members of Technical Staff）
- 発行元: OpenAI
- 発行日: 2026年9月11日
- URL: https://openai.com/index/scaling-storage-one-billion-users-part-one/
関連記事
要点
- OpenAIのオンラインストレージ基盤「Habitat」は、毎秒7000万件以上のリクエストを処理し、週10億人超のユーザーを支えている。
- Habitatは2023年のDevDayでGPTs向けの小規模なPythonライブラリとして始まり、2025年半ばに独立したサービスへ切り出された。
- サービス化後は、Pythonの非同期処理(asyncio)によるレイテンシ管理や接続プールの最適化を重ねてきた。
- HabitatはSQLのような柔軟なクエリを許可せず、シンプルなNoSQL APIに機能を絞る設計を採用している。
- 2026年第2四半期、エンジニア2人とCodex・GPT-5.5を用いてPythonからRustへの全面書き換えを実施した。
詳細解説
Habitatとは何か——小さなライブラリからOpenAI全体を支える基盤へ
OpenAIによれば、Habitatは2023年のDevDayでGPTsを支えるための小規模なPythonライブラリとして始まりました。当初はAzure Cosmos DB(マイクロソフトが提供するNoSQL型のデータベースサービス)と連携する簡易なクライアントサイドの仕組みにすぎず、製品エンジニアがデータベース管理の詳細を意識せずに済むようにすることが目的だったといいます。スキーマの参照やルーティング、認可、暗号化といった処理をHabitatが肩代わりすることで、エンジニアはストレージの内部構造を気にせず開発に集中できたとしています。現在では毎秒7000万件以上のリクエストを処理し、週10億人超のユーザーが利用する製品群を、約40の地域にまたがって支え、500ペタバイトを超えるデータを扱う分散システムに発展したとのことです。
こうした急成長を支える基盤整備は、独自推論チップJalapeñoの実測データを紹介した過去記事でも取り上げたように、OpenAIが近年注力してきた領域の一つといえます。本稿としては、「インフラの複雑さを意識させない」という設計思想自体は目新しいものではないものの、それを10億人規模のトラフィックまで維持し続けた点にこの事例の特徴があると考えています。
サービスとして独立させた理由——クライアントライブラリの限界
OpenAIの説明では、2025年半ばまでにHabitatは複雑化し、後方互換性を保ったままプロトコルを変更することが難しくなっていました。ある事例では、重要なデータセットを地域分散されたAzure Cosmos DBアカウントへ移行する際、数十のサービスに新しいルーティングロジックを展開する必要があり、調整だけで数日かかったといいます。フィーチャーフラグ(コードを変更せずに機能の有効・無効を切り替える仕組み)を有効化する直前、あるチームが別の理由で古いクライアントにロールバックしたことで、避けたかったはずの障害がかえって発生してしまった経験も明かされています。こうした経緯から、OpenAIはHabitatをクライアントライブラリから独立したサービスへと切り出し、デプロイやアクセス制御、監査ログを一元管理できる体制へ移行したとしています。
本稿としては、機能追加よりも先に「デプロイの一元化」を優先した判断は、複数の製品で共通基盤を運用する組織にとって一つの教訓として参考になると考えています。
Pythonサービスの高速化——非同期処理とレイテンシ管理
OpenAIは、高スループットのサービスをPythonで動かすことがネットワーク遅延やCPU・メモリコストの面で不利になると認識しつつも、まずはPythonのまま製品開発をブロックしないことと基盤の安定化を優先したと説明しています。Pythonのasyncio(入出力を伴う処理を並行実行する仕組み)は、GIL(Global Interpreter Lock、複数スレッドが同時にPythonコードを実行するのを防ぐ仕組み)によるCPU並列化の制約を回避できません。ルーティングや圧縮、暗号化などCPU負荷の高い処理が多いHabitatでは、下流のデータベース応答そのものより、処理を担当するコルーチンの再スケジュール待ちがテールレイテンシ(全体の中でも特に遅い一部のリクエストの応答時間)を左右していたといいます。
原因の一つとして、フィーチャーフラグ管理ツールStatsigの設定ファイルを1分間隔でパースする処理が挙げられています。1ポッドあたり最大8プロセスというアーキテクチャと重なり、毎分すべてのワーカーが巨大な設定ファイルの解析に時間を取られる状態になっていたとのことです。対象を絞った設定ファイルへの縮小、更新間隔の延長、ジッター(処理タイミングを意図的にずらす調整)の追加という対応で解消したと述べています。
本稿としては、大規模分散システムでは個々の処理が軽くても、同期したタイミングで積み重なると無視できない遅延を生むという点は、Python以外の環境でも起こりうる典型的な落とし穴だと受け止めています。
接続プールと下流リソースの保護
OpenAIは、クライアント側の接続プーリングが偏った負荷分散を招いた事例も紹介しています。一部のプロセスが平均の5〜10倍の同時リクエストを受け続ける現象が発生し、原因はPythonのHTTPライブラリaiohttpが標準で採用するLIFO(Last In First Out、最後に返却された接続を次に優先して使う方式)の接続再利用にあったといいます。負荷の高いサーバーほど接続をプールに遅く返却するため、次のリクエストで選ばれやすくなり、特定のプロセスに負荷が集中し続ける「メタ安定障害」につながっていたとしています。FIFO(First In First Out、先に返却された接続から使う方式)に切り替えることで、このフィードバックループを断ち切ったとのことです。現在はIstioとEnvoy(いずれもサービス間通信を仲介するプロキシ技術)を使い、接続プーリングとHTTP/2への多重化によって、下流のAzure Cosmos DBへ向かう接続数そのものを抑える運用に移行しています。
本稿としては、LIFOという一見合理的な既定値が特定の負荷パターン下でかえって障害を助長したという事例は、デフォルト設定をそのまま使う際の注意点として実務上参考になると考えています。
あえて機能を絞る設計——HabitatのNoSQL API
OpenAIによれば、Habitatはクライアントが自由にクエリを組み立てられる設計をあえて採用していません。任意のテーブル結合や大規模なスキャンを招きかねない柔軟なAPIではなく、オブジェクトとエッジ(オブジェクト同士のつながり)をクライアント側で事前定義するシンプルなNoSQL APIに機能を絞っているといいます。複雑な問い合わせが必要なクライアント向けには、CDC(変更データキャプチャ、データベースの変更をリアルタイムで別システムへ配信する仕組み)を通じてRocksetへ複製する「エスケープハッチ」を用意し、分析用途をオンラインストレージから切り離しているとしています。
本稿としては、便利さよりも予測可能性を優先し、コストのかかるクエリを書けなくすることでシステム全体の安定運用を図るという判断は、大規模インフラを内製する組織にとって示唆的な考え方だと考えています。
PythonからRustへ——2人のエンジニアとAIによる移行
OpenAIは、2026年第2四半期に、エンジニア2人とCodex、GPT‑5.5を使ってHabitatサービス全体をRustで書き直したと明らかにしました。Pythonでの運用はピーク時に毎秒2000万件以上のリクエストを処理していましたが、新しいRustサービスは現在本番トラフィックの95%を処理しており、近くPythonを完全に廃止する計画だといいます。OpenAIのデータでは、RustサービスはPython版と比べてCPU効率が6倍、メモリ効率が15倍向上し、平均・テールレイテンシも大幅に改善したとのことです。
本稿としては、コーディング支援AIの進歩を見込んで「将来の書き換えのしやすさ」に賭け、あえて短期的な非効率を受け入れるという判断は、AIツールの実力を前提とした技術選定の一例として注目に値すると考えています。
まとめ
本稿では、OpenAIのストレージ基盤Habitatが小さなPythonライブラリから10億人規模のサービスへと発展し、Rustへ移行した経緯を紹介しました。OpenAIは今後、Azure Cosmos DBとの連携を掘り下げた続報も予定しています。同社のインフラ効率化の取り組みは推論最適化の舞台裏も過去記事で紹介していますので、あわせてご覧ください。
