OpenAI、10億人のChatGPTを支えるストレージ基盤「Habitat」の裏側を公開

10億人を超えるユーザーが利用するChatGPTの裏側で、データベースは一体どのように耐えているのか。

OpenAIのエンジニアリングチームは10月23日、40の地域で500ペタバイト以上のデータを処理するストレージ基盤「Habitat」の運用ノウハウを公開しました。マイクロソフトのAzure Cosmos DBをベースに、試行錯誤の末に読み取り性能を12倍に引き上げた舞台裏です。

障害の連鎖から「リリース当日の緊急対応」へ

当初、OpenAIは1つの巨大なマルチテナントコンテナに全データを集約していました。しかし、ニッチな機能で特定のキーにアクセスが集中すると、同じ物理パーティションを共有するログインやサインアップといった中核機能まで道連れに停止する問題が発生しました。

さらにデータ容量が増えて物理パーティションが自動分割されると、パーティションあたりの実効スループットが低下するというCosmos DB特有の落とし穴にも直面します。

影響範囲を抑えるため、チームはサービスごとにコンテナを分けるシングルテナント運用へと舵を切りました。しかし今度は、開発チームが事前のキャパシティ計画を怠り、機能リリースのたびに対策部屋（SEVルーム）で緊急スケールアップに追われるという組織的な破綻を招きました。

Azureチームとの共同改修とRustによる書き換え

結局OpenAIは、Azureチームと密に連携してマルチテナント構造に戻る選択をしました。これを「共同管理コンテナ」と呼んでいます。

最もアクセスの集中したホットキーだけを優先的に絞り込むスロットリングや、バックグラウンド処理よりも対話リクエストを優先するQoS制御を導入し、ノイズの影響を抑え込みました。

あわせて、ユーザーに近い拠点へのデータ配置、遅延に敏感なデータのみを選択的にレプリケーションする工夫、キャッシュ統合、さらにプロキシロジックをRustで全面的に書き直すことで、500PBもの規模で読み取り速度12倍を達成しました。

なぜ重要か

最先端のAIモデルを動かすだけでなく、世界規模の超高トラフィックを支えるストレージ運用の実態が詳細に明かされた点で、きわめて価値の高い知見です。

一般的なエンジニアが今すぐこの巨大構成を真似する必要はありません。しかし「完全なリソース分離を進めすぎると組織全体の運用負荷が爆発する」という教訓は、クラウドを活用するあらゆる開発組織にとって耳が痛い話でしょう。

自前で分散データベースをゼロから開発せず、Azureの既存コンポーネントを徹底的に使い倒し、クラウドベンダーを巻き込んで改善させたアプローチは非常に賢明に見えます。一方で、ここまでAzure Cosmos DBの内部仕様に深く最適化したシステムを作り上げたことで、OpenAIが将来的にマルチクラウドへ移行するハードルは以前にも増して高くなったと言えます。