OpenAI Habitat ストレージプラットフォームのスケーリング: マルチテナンシー、Azure Cosmos DB の拡張、およびグローバルパフォーマンス

TL;DR

OpenAI は Habitat のスケーリングストーリーの第2部を公開し、チームが Azure Cosmos DB の使用方法を再設計し、マルチテナントのデフォルトコンテナを導入し、ホットキー調整、QoS、カスタムサーバーレスモード、Rust ベースのサービス、CDC 駆動のキャッシュを追加して、500 PB 以上のデータを 2000 万 QPS 以上で提供し、読み取りレイテンシを約 120 ミリ秒から約 10 ミリ秒に短縮したことを説明しました。

Habitat の概要

Habitat は OpenAI のオンラインストレージプラットフォームであり、40 の地理的リージョンにわたるすべての OpenAI 製品にミリ秒単位のデータアクセスを提供します。これは 10 億人以上の ChatGPT ユーザーを支え、500 ペタバイト以上のデータを保存しています。

マルチテナンシーデザインの旅

結論: 共有コンテナ、マルチテナントモデルにより、現在は信頼性が高く、メンテナンスが容易なストレージを大規模に提供しています。

OpenAI は 3 つのフェーズを経ました:

フェーズ I – プリミティブなマルチテナンシー – 単一の Cosmos DB コンテナがすべてのトラフィックを処理しました。論理パーティションキーの制限とノイジーネイバー効果により、スループットの競合が発生しました。
フェーズ II – 機能ごとのシングルテナンシー – 個別のコンテナがワークロードを分離しましたが、大規模なキャパシティプランニングのオーバーヘッドと頻繁なローンチ日のスケーリングインシデントが発生しました。
フェーズ III – 緩和策を備えたデフォルトのマルチテナンシー – Azure と協力して、OpenAI はホットキー調整、QoS ティアリング、カスタムサーバーレスモードを追加し、単一の共有コンテナが再び多くのテナントを安全にホストできるようにしました。

「製品開発を加速しているにもかかわらず、それ以来、プロビジョニングやノイジーネイバーのインシデントは発生していません。」 – OpenAI エンジニアリングチーム

Azure Cosmos DB の拡張

結論: Azure が構築したプリミティブにより、ホットキー、弱いパーティション、手動介入なしのスケーリングが処理されるようになりました。

ホットキー調整 – 最もアクティブな論理キーの調整を優先し、単一のテナントが物理パーティションを独占するのを防ぎます。
サービス品質 (QoS) ティアリング – バルクまたはオフラインのワークロードに低い優先度を割り当て、インタラクティブなレイテンシに敏感なリクエストを保護します。
カスタムサーバーレスモード – Azure のサーバーレスオファリングを物理パーティションあたり 10,000 RU/s に拡張し、RU ベースのパーティション分割を追加して、手動のスループットプロビジョニングの必要性を排除します。

これらの変更により、OpenAI は単一の共有コンテナを実行し、数十ペタバイトを保存しながら 2000 万クエリ/秒 (QPS) 以上を提供できます。

共同管理サービスによる信頼性

結論: Azure との共同エンジニアリングにより、本番規模のテストと迅速なインシデント対応が提供されます。

OpenAI と Azure は現在、ダッシュボード、テストスイート、直接のエンジニアリングチャネルを共有しています。
2024 年のリージョン障害により、大規模な Cosmos アカウントのフェイルオーバーに数時間かかる可能性があることが明らかになりました。その後の共同テストにより、フェイルオーバー時間が短縮され、ゲートウェイのスタンピードが排除されました。
コントロールプレーンのスケーラビリティ、接続プーリング、メタデータキャッシュの継続的な共同エンジニアリングが標準的な慣行になっています。

グローバルパフォーマンスの最適化

結論: データをユーザーに近づけ、重要なデータセットを複製し、CDC 駆動のキャッシュを追加することで、読み取りレイテンシが 12 倍 (約 120 ミリ秒 → 約 10 ミリ秒) 削減されました。

データローカリティ – データ常駐要件のあるリージョンに複数の Cosmos DB アカウントがデプロイされています。容量が許す場合、データはコンピュートと同じ場所に配置されます。
選択的レプリケーション – レイテンシに重要なデータセット (例: 認証メタデータ) は、40 の Azure リージョンすべてに複製されます。他のデータは少数のリージョンに残ります。
統合分散キャッシュ – Valkey ベースのルックアサイドキャッシュが、最近のオブジェクトをリクエストハンドラの近くに保存します。キャッシュの無効化には Cosmos DB のチェンジフィード CDC を使用し、秒単位の鮮度を実現します。
Rust サービス層 – Habitat サービスを Rust で書き直すことで Python のオーバーヘッドがなくなり、レイテンシの削減に貢献しました。

図 5 (元の投稿内) は、これらの変更後の p50 読み取りレイテンシの改善を 120 ミリ秒から 10 ミリ秒に示しています。

変更データキャプチャ (CDC) のスケーリング

結論: 専用の CDC プラットフォームが複雑さを抽象化し、数千のコンテナにわたって毎秒数百万の変更を維持します。

CDC ストリームは 100 を超える Kafka トピックにフィードし、セカンダリインデックス、分析、リアルタイム機能をサポートします。
内部コントロールプレーンが関連する Cosmos アカウント/コンテナを自動的に検出し、ワーカーフリートのバランスを取り、読み取りをレプリカリージョンにルーティングします。
堅牢性対策には、リースストアの分離、デッドレターキュー、カスタム Azure CDC SDK チェックポイントバッチ処理が含まれます。

将来の方向性: エクサバイト規模の社内ストレージ

結論: OpenAI は、次の 10 億人のユーザーを処理するためのカスタムストレージシステムをプロトタイプしています。

このシステムは、RocksDB Cloud (Rockset 製) と Raft ベースのレプリケーションを組み合わせています。
Cosmos スタイルのドキュメントモデルを維持しながら、分離されたストレージを使用してフラッシュ容量のニーズを削減します。
予想されるトレードオフ: ピーク QPS の削減と引き換えに、大規模なストレージ効率を実現します。

業界への影響

マルチテナンシーの実現可能性 – OpenAI は、プロバイダーレベルの拡張により、単一の共有コンテナが数十億のリクエストを安全に処理でき、運用の複雑さを軽減できることを実証しています。
プロバイダーとの協力 – フロンティア規模では、コンシューマーとクラウドプロバイダー間の深い共同エンジニアリングが不可欠になります。他の大規模な AI 企業も同様のパートナーシップが必要になる可能性があります。
パフォーマンスファーストのアーキテクチャ – ローカリティ、選択的レプリケーション、CDC 駆動のキャッシュ、低レベル言語の書き直しを組み合わせることで、桁違いのレイテンシ改善が得られ、これはグローバルに分散されたサービスすべての青写真です。
自社製ストレージへのロードマップ – Azure の機能があっても、OpenAI は社内ソリューションに投資しており、将来のフロンティア AI ワークロードがパブリッククラウドのストレージ制限を超える可能性があることを示しています。

重要なポイント

Habitat は、単純な Python クライアントから、500 PB 以上と2000 万 QPS 以上を提供するグローバルに分散されたマルチテナントストレージプラットフォームに進化しました。
Azure Cosmos DB は、ホットキー調整、QoS、カスタムサーバーレスモードで拡張され、単一の共有コンテナがコストのかかる機能ごとのコンテナを置き換えることができるようになりました。
グローバルなレイテンシ改善は、データローカリティ、選択的レプリケーション、CDC 駆動の Valkey キャッシュ、Rust サービスの書き直しによるもので、読み取り p50 レイテンシを約 120 ミリ秒から約 10 ミリ秒に削減しました。
Azure との継続的な共同エンジニアリングと、今後のエクサバイト規模の社内ストレージシステムにより、OpenAI は次の 10 億人のユーザーをサポートする態勢を整えています。

フロンティア規模のデータインフラストラクチャに興味のあるエンジニア向けに、OpenAI は Habitat 関連の役割を募集しています。