10月23日、OpenAIが「Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part II)」と題した記事を公開した。ChatGPTの10億人超のユーザーを支えるストレージ基盤「Habitat」の設計変遷を率直に語った内容で、マルチテナント→シングルテナント→マルチテナントへと二度の方針転換を経た経緯が詳述されている。
設計変更の動機が純粋な技術的理由にとどまらず、組織運営の破綻にまで及んでいた点が本稿の読みどころだ。シングルテナント化によってノイジーネイバー問題は解消したが、今度は「全プロダクトチームがAzure Cosmos DBのプロビジョニングに関与する状態」に陥り、ローンチ当日に深刻なインシデントが頻発するという別の地獄を経験した。インフラ設計は技術だけでは完結しない——スケールした企業が必ず直面するリアルが詰まった記事だ。
Habitatとは何か
HabitatはOpenAIの全製品が高速かつ安定的にデータへアクセスするために構築されたオンラインストレージ基盤だ。40の地理的リージョンにまたがり、10億人超のユーザーへミリ秒単位で応答する必要がある。バックエンドにはAzure Cosmos DB（Microsoftが提供するグローバル分散型のNoSQLデータベースサービス）を採用している。本稿はその構築初期を振り返ったPart I（2026年8月公開）の続編にあたる。
ChatGPTは2025年に週間アクティブユーザー10億人を突破した。この規模に対応するストレージ基盤をどう設計・運用するかは、現時点で世界でもOpenAI以外にほぼ前例のない課題だ。その試行錯誤の記録として、本記事は一次資料的な価値を持つ。
Phase I：Azure Cosmos DBのプリミティブに頼った時代
最初の設計では、すべての用途を単一のデフォルトコンテナに収め、Azure Cosmos DBの論理パーティションキーあたり10K RU/s（リクエストユニット毎秒：Cosmos DBにおけるスループットの計測単位）という上限をバックプレッシャーとして自然に機能させていた。
しかしこれは三つの問題を引き起こした。
- パーティションキーの衝突：
user_idやworkspace_idなど、複数プロダクトが同じパーティションキーを使うことでスループットが食い合う。 - ノイジーネイバー問題：物理パーティションの上限は論理パーティション間で共有されるため、マイナー機能のワークロードがログインや新規登録フローに干渉する。
- ウィークパーティション問題：データ量の増加によって物理パーティションが分割されるとき、プロビジョニング済みスループットは据え置かれる。その結果、ストレージの増加だけで1パーティションあたりの有効スループットが下がるという逆説的な劣化が生じる。
Phase II：シングルテナントへの逃避とその代償
各ユースケースに専用コンテナを割り当てることで、ノイジーネイバーと衝突問題は解消した。しかしこれには別のコストが伴った。
新しいコンテナは事前のキャパシティプランニングを必要とする。共有コンテナであれば、新規ユースケースが0から大量QPSに急増しても全体へのインパクトは限定的だ。しかし専用コンテナでは、同じ急増がそのコンテナへの極端な負荷スパイクとして現れる。プロダクトチームはローンチ前のプリスケールを忘れ、ローンチ当日にSEV（Severity Event：深刻度の高いインシデント対応の区分）対応を強いられる事態が頻発したという。
「OpenAI全体の製品チームがAzure Cosmos DBのプロビジョニングに関与する状態になった」
組織的にスケールしない運用形態に陥ったことを、記事は率直に認めている。
Phase III：Azureとの共同開発でマルチテナントに戻る
最終的にOpenAIが選んだのはマルチテナント回帰だった。ただし以前の問題を解消するためにAzureチームと密接に連携し、三つの改善を実装している。
- ホットキースロットリング：最もホットなキーを優先的にスロットリングし、1つのキーがサイト全体に影響する事態を防ぐ。
- QoS（Quality of Service）によるリクエスト優先度付け：バルクインサートやデータエクスポートといったオフラインワークロードを低優先度に設定し、エンドユーザー向けのインタラクティブなリクエストへの影響を排除する。
- 改良版サーバーレスモード：既存のサーバーレスモードは物理パーティションあたり5K RU/sという上限があったが、Azureチームが新たに構築したモードでは10K RU/sまでスケール可能となり、RU使用量に基づくパーティション分割も追加された。これにより手動でのコンテナスケーリング監視が不要になった。
この変更以降、プロビジョニング起因やノイジーネイバー起因のインシデントは発生していないという。
「マネージドサービス」の限界——20M QPSで見えた現実
記事の後半で特に印象的なのが、マネージドサービスの本質的な限界についての記述だ。
「企業がOpenAIの規模に達すると、マネージドサービスは『マネージド』でなくなる」
現在、OpenAIの最大のAzure Cosmos DBアカウントは数十ペタバイトのデータを保持し、毎秒2000万クエリ（20M QPS）を処理している。一般的なWebサービスが数千〜数万QPSで運用されることを考えると、その規模の隔絶ぶりがわかる。同社によれば、このスケールでAzure Cosmos DBを運用している企業は世界で他にないという。
2024年末、プライマリリージョンでの電源障害が発生した際、最大規模のアカウントのフェイルオーバーに数時間かかることが判明した。このスケールでのテストを、OpenAI・Azureいずれのチームも実施していなかったためだ。さらに約1ヶ月後、元リージョンへのフェイルバック時にはコネクションスタンピード（多数のクライアントが一斉に接続を試みる現象）が発生し、Azure Cosmos DBゲートウェイを圧迫する深刻な障害が再発した。
これを受け、両チームは以下を共同で整備した。
- 本番同等規模の非本番環境での変更テスト
- HabitatサービスレイヤーからAzure Cosmos DBの物理ストレージレイヤーまでの全層共同モニタリング
- サポート階層を経由しない直接の相互エスカレーション経路の整備
10億ユーザー規模のストレージ基盤が直面した課題は、技術問題にとどまらず、組織運営とベンダーとの関係性にまで及んでいる。設計方針の揺れ戻しとその理由が率直に記されており、同様のスケール課題に直面するインフラチームにとって参考になる事例だ。
詳細はRapidly scaling online storage to serve over 1 billion ChatGPT users (Part II)を参照していただきたい。
