エンジニア2人とCodexが、ChatGPTの全データ読み取りを支えるサービスをRustで書き直した

OpenAIは、ChatGPTのあらゆるデータ読み取りの前段にあったPythonサービスを2026年第2四半期にRustで書き直した。エンジニア2人がCodexとGPT-5.5を使って完了させたプロジェクトである。新サービスは現在、本番トラフィックの95%を処理し、置き換え前よりCPU効率で6倍、メモリ効率で15倍優れる。Python実装は全面的に廃止へ向かっている。

要点

• OpenAIのオンラインストレージ基盤Habitatは、500ペタバイトを超えるデータに対して毎秒7000万件以上のリクエストを処理する。週に10億人が使う製品群がその上で動く。
• PythonからRustへの書き換えは、CodexとGPT-5.5に頼ったエンジニア2人が実施し、CPU効率6倍・メモリ効率15倍の改善をもたらした。
• 難しい教訓は言語ではなく運用面から出た。asyncioのスケジューリング遅延、すでに苦しいポッドに負荷を集めてしまうLIFO方式のコネクションプーリング、EnvoyとIstioを経由して起きたサンダリングハード現象である。

Habitatの役割と存在理由

Habitatは、OpenAIの製品とその下にあるストレージ群の間に位置する。Azure Cosmos DB、ブロブストレージ、キャッシュ層、社内データベースが対象だ。製品がデータを必要とすると、Habitatがスキーマを解決し、リクエストをルーティングし、認可を確認し、暗号化とシリアライズを処理したうえで、リクエストを整形しコネクションプールを管理する。製品側のエンジニアは各バックエンドを覚える代わりに、ひとつのインターフェースだけを相手にすればよい。

出発点はずっと小さかった。Habitatは2024年半ば、Pythonのクライアントライブラリとして始まった。サービスがデータベースと通信するためにインポートする共有パッケージに近い。この設計は作るのが速く、しばらくは改善も速かった。キャッシュや圧縮を追加するには新バージョンを公開し、各チームが取り込めばよかった。

ライブラリの難点は、アップグレードが分散することだ。OpenAIは、リージョン障害に耐えるため重要データを複数のリージョン別データベースアカウントへ分散しようとした経験を挙げている。この作業では、利用する全サービスの内部に新しいルーティングロジックを入れ、ひとつずつデプロイし、実トラフィックに対してシャドー実行し、フィーチャーフラグの背後で有効化する必要があった。数十のサービスを調整するのに数日を要し、あるチームは古いバグを抱えたバージョンへロールバックしてしまい、本来防ぐはずだった障害をそのまま起こした。Habitatは2025年半ばに独立したサービスへ切り出され、製品側には薄いクライアントSDKだけが残り、ルーティング・デプロイ・監視・アクセス制御は一箇所に集約された。

規模が明らかにした失敗

OpenAIのリクエスト量でそのサービスをPythonで動かすと、ベンチマークでは現れない問題が浮上した。CPU負荷の高いバックグラウンド処理によるasyncioのスケジューリング遅延は、下流の呼び出しが速く戻る場合でもテールレイテンシを支配した。ある事例では、すべてのポッドがStatsigのフィーチャーフラグ設定を1分ごとにJSONとして解析していたが、ジッターがなく、1ポッドあたり8プロセスで同時に走った。全ワーカーが同じ瞬間に停止したのである。対処は平凡だが示唆的だった。設定を絞って小さくし、更新間隔を延ばし、タイミングをランダム化した。

2つ目の失敗はより微妙だった。Pythonのaiohttpのコネクションプールは、既定でLIFO順にコネクションを再利用する。つまり、遅く過負荷のサーバーはコネクションを返すのが遅いため、かえって選ばれやすくなる。負荷をもっとも捌けないポッドにトラフィックが集中する構図だ。FIFO再利用へ切り替えるとこのフィードバックループが断たれ、副次的に定常状態のリクエストのばらつきも減った。EnvoyとIstioを経由したサンダリングハード現象がリストの最後を埋めた。

OpenAIは、制約のように見えて実際には安全弁として働く設計判断も下している。Habitatは意図的に機能を絞ったNoSQL APIしか公開しない。高コストだったり予測しにくいクエリは、そもそも表現できない。利用する製品が増えてもリクエスト単価が発散しないのはこのためだ。

エンジニア2人、書き換え1件

今回の移行で最も広く語られるのは人員構成だろう。週10億人が使う製品のクリティカルパス上にあるサービスを、インタプリタ言語からRustへ移す作業を、OpenAI自身のコーディングツールを用いたエンジニア2人がやり切った。これまで逸話でしか語られてこなかった論点に、具体的なデータ点がついた。言語移行は、移行先の言語が誤っていたからではなく、移植の労力を正当化できないために却下されてきた。エージェント型のコーディングツールはその計算式を変える。

効率の数字は注意して読むべきだ。CPU6倍・メモリ15倍という改善は、シリアライズとI/O調整が支配的なリクエストルーティング処理において、Pythonインタプリタが負うオーバーヘッドを反映している。Rust書き換えにとってほぼ最良の条件にあたる。ボトルネックがデータベースや外部APIにあるチームは、同等の見返りを期待すべきではない。

OpenAIの路線をたどる側には、Rustエコシステム自体のサプライチェーン露出という別の課題が残る。汚染されたクレートが86分間公開され続けた事件がそれを明確に示した。OpenAIのエンジニアリング解説記事は全2回の第1回で、ストレージ層そのものは続編で扱われる。

FAQ

OpenAIはなぜHabitatをPythonからRustへ書き直したのか

このサービスのリクエスト量ではインタプリタのオーバーヘッドが許容できなくなった。チームが直面した運用上の失敗、つまりasyncioのスケジューリング遅延やコネクションプールの準安定状態は、Pythonサービスを快適な範囲の外へ押し出したことの症状だった。Rust版はCPU効率6倍・メモリ効率15倍で、現在は本番リクエストの95%を処理している。

Pythonは本番サービスに向かないということか

そうではない。Habitatは年10倍超の成長を3年間経験する間、Pythonで動いていた。むしろそこが要点だ。製品の形がまだ動いている段階ではその言語が正しい選択であり、規模が正当化した時点で負債を意図的に返済した。これは順序に関する判断であり、Pythonへの評決ではない。

Habitatの背後にはどのストレージがあるのか

主なデータベース層はAzure Cosmos DBで、その周囲にキャッシュ、ブロブストレージ、その他の社内データサービスがある。製品はこれらを直接呼ばない。Habitatを呼び出すと、データがどこにあり、どう到達するかをHabitatが解決する。