10月24日、OpenAIが「Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part II)」と題した記事を公開した。この記事では、ChatGPTの10億ユーザーを支えるストレージ基盤「Habitat」において、Azure Cosmos DBのマルチテナント設計をいかにスケールさせたかについて詳しく紹介されている。
Habitatとは何か
OpenAIは社内のストレージ基盤としてHabitatを構築している。40の地理的リージョンにまたがり、10億人以上のユーザーからのリクエストにミリ秒単位で応答する要求がある。バックエンドにはAzure Cosmos DBを採用しており、現時点でOpenAIの最大アカウントは数十ペタバイトのデータを保持し、2000万QPS超を処理している。
Part IではHabitatのサービス化（PythonクライアントからgRPCサービスへの移行）を扱ったが、今回のPart IIの核心は「Azure Cosmos DBのマルチテナント設計をめぐる失敗と再設計の軌跡」だ。
3フェーズの変遷：マルチ→シングル→マルチ
Phase I：Cosmos DBのプリミティブに頼る（失敗）
当初は単一のデフォルトコンテナにすべてのテナントを同居させ、Azure Cosmos DBが持つ「論理パーティションキーあたり10K RU/s」の制限をバックプレッシャーとして活用する設計だった。
なお、RU（Request Unit）はAzure Cosmos DB固有のスループット単位であり、読み取り・書き込み・クエリの複雑さなどに応じて消費量が変わる。1RUは1KBのドキュメントの読み取りに相当し、スループットのプロビジョニングや制限はこの単位で管理される。
しかしこの設計には3つの致命的な問題が潜んでいた。
- 論理パーティションキーの衝突：
user_idやworkspace_idという汎用的なキーを複数のプロダクトが共有するため、あるユーザーへの上限が複数プロダクトをまたいで消費される - ノイジーネイバー問題：制限は論理パーティションではなく物理パーティションで実施されるため、無関係な別テナントのバースト負荷がログイン・サインアップフローを阻害した
- ウィークパーティション問題：データ量が増えると物理パーティションが分割（スプリット）されるが、総スループットは変わらないためパーティションあたりの実効スループットが低下し続ける
Phase II：シングルテナントコンテナへ（別の問題が発生）
ノイジーネイバーと物理パーティション問題を回避するため、重要なユースケースごとに専用コンテナを切り出す方針に転換した。これはブラストラジアスをサービス単位に限定する効果があり、サイト全体の障害は減った。
ただし、運用面で新たな問題が発生した。
- スタートアップ時の急激な負荷変動：共有コンテナでは「あるユースケースが0→100万QPS」になっても全体への影響は小さい。しかし専用コンテナでは同じ変化が1000倍の負荷増を意味し、プロダクトチームがローンチ前のプレスケールを忘れるたびにインシデントが発生した
- キャパシティプランニングの分散：すべてのプロダクトチームが自分のコンテナを管理することになり、チームごとに運用品質の差が出た
Phase III：マルチテナントに回帰、ただしAzureと共同設計で
根本的な解決のため、OpenAIはAzureチームと密に協力し、マルチテナント設計の欠陥を修正する3つの機能を実装・投入した。
- ホットキースロットリング：物理パーティション内で最も負荷の高いキーから優先的にスロットリングし、ノイジーネイバーの影響を局所化する
- QoS（Quality of Service）リクエスト優先度制御：バルクインサートやデータエクスポートなどオフラインワークロードには低優先度を付与し、エンドユーザー向けのインタラクティブリクエストへの影響を防ぐ
- 改良版サーバーレスモード：既存のサーバーレスモードは物理パーティションあたり5K RU/sに制限されていたが、Azureチームが新たに10K RU/sまでスケール可能かつRU消費量ベースのスプリットも導入した改良版を開発。これによりウィークパーティション問題を解消しつつ、RU集約型ユースケースにも対応できるようになった
この3つの変更により、単一の共有コンテナに回帰することが可能になった。以降、プロビジョニング起因のインシデントやノイジーネイバー起因のインシデントは数ヶ月間ゼロを維持しているという。
「マネージドサービス」は規模が大きくなるほど「アンマネージド」になる
このPart IIで最も注目すべき論点の一つが、大規模利用時のマネージドサービスの限界だ。
2024年末、プライマリリージョンの電源障害に伴うフェイルオーバーで、最大規模のCosmos DBアカウントが別リージョンへの切り替えに数時間かかることが判明した。その規模でのフェイルオーバーはOpenAI・Azure双方ともテストしていなかった。
さらに約1ヶ月後のフェイルバック（元リージョンへの復帰）時に、コネクションスタンピード（接続の爆発的な集中）が発生。Cosmos DBのゲートウェイモードクライアントの実装上の癖で、全クライアントが一斉に元リージョンへ接続要求を送った結果、ゲートウェイが輻輳した。
これを受けて現在のHabitatチームとAzureチームの連携体制は以下のようになっている。
- 本番同等規模の非本番環境を共同で保有し、変更を事前テスト
- SDKの共同開発・ベストプラクティスの策定
- Teamsの直接チャンネルおよび相互にページング可能な体制（サポートティアを経由しない）
- ゲートウェイのスケーラビリティ強化、Cosmos DBメタデータのキャッシュ追加、Pythonプロセス側のコネクションプーリング改善なども共同実施
OpenAIは「自分たちの知る限り、これほどの規模でAzure Cosmos DBを本番運用しているのは世界で唯一の企業だ」と述べている。
まとめ
HabitatのCosmos DB設計は「シングル共有コンテナ→ユースケース別専用コンテナ→改善済み共有コンテナ」という一周を経た。各フェーズで得た知見は、スケールにおけるマルチテナント設計の難しさと、クラウドプロバイダーとの深い技術連携の必要性を端的に示している。数十ペタバイト規模のデータを運用するインフラエンジニアにとって、設計判断の根拠と失敗の経緯が明示されている点で読む価値がある内容だ。
詳細はRapidly scaling online storage to serve over 1 billion ChatGPT users (Part II)を参照していただきたい。
