OpenAI Habitatにおける共有コンテナーへの回帰：ホットキー抑制とQoSが支えるマルチテナント設計

なぜ今ストレージ刷新が必要になったのか：急成長とクライアント運用の限界

OpenAIのストレージ基盤「Habitat」は、当初、Pythonクライアントライブラリから単一のデータベースへ直接接続する構成を採用し、GPTsを支える用途から運用を開始しました[1]。

その後、サービス規模は急速に拡大しました。2026年9月11日公開の公式報告（Part I）によると、Habitat全体で毎秒7,000万件超の要求を処理し、OpenAI製品を週ごとに利用する人は10億人を超え、取り扱うデータ量は500PB超、サービス地域は「40弱」に達しています。この週次利用者数はChatGPT単体ではなく、OpenAI製品群全体の規模として報告されています[2]。同報告では、直近3年間に前年比10倍超で成長したとも述べられています。ただし、成長の対象指標が利用者数、要求数、データ量のいずれかは特定されておらず、Habitat基盤固有の成長率と直接結びつけることはできません[3]。さらに、2026年10月23日公開の続編報告（Part II）では、Habitatが40の地理的地域で10億人超の利用者を支えていると説明されています。ただし、Part IIには週次や月次といった集計期間の指定がありません。そのため、Part Iの週次指標とは分母や測定期間を区別して扱う必要があります[4]。

規模の拡大に伴い、重要データを複数リージョンに分散したAzure Cosmos DBアカウントへ移行する過程で、クライアントライブラリにルーティングの判断を持たせる方式が限界を迎えました。当時は、フィーチャーフラグやシャドー検証を使い、クライアント側のルーティング変更を多数のマイクロサービスへ段階的に展開していました。しかし、あるチームが過去の不具合を含む旧バージョンのクライアントへロールバックしたことをきっかけに、本番障害が発生しました[5, 6]。

こうした運用の複雑さと障害の経験を受け、OpenAIはクライアントライブラリ方式を改め、Habitatを独立したストレージサービスとして再構築しました。独立サービス化によって、配備、可観測性、機能改善の制御点を一元化し、各製品の開発チームがルーティング、認可、暗号化、保存先といった基盤側の詳細を意識せずに開発へ専念できるアーキテクチャへ移行しました[7]。

補足：シャドー検証（Shadowing）とは

本番環境のトラフィックを複製し、新しいシステムや経路にも並行して送信することで、既存処理に影響を与えずに挙動や性能を検証する手法です。

何が起きたのか：コンテナー分離の課題と制御付き共有への回帰

Azure Cosmos DBの基本仕様では、同一のパーティションキー値を持つ項目群が論理パーティションを形成し、1つ以上の論理パーティションが単一の物理パーティションに配置されます[8]。コンテナーにプロビジョニングされた全体のスループット（Request Units: RU）は各物理パーティションへ均等に配分されます。保存データ量やスループット要件が増えると、物理パーティションは自動的に分割されます[9]。

初期のHabitatでは、論理パーティションキーの選定を各クライアントに委ねていました。その結果、異なる製品ユースケース間でuser_idやworkspace_idなどの同一キー値が衝突し、同じ論理キーに対するCosmos DBの制限を共有する事態が発生しました[10, 11]。さらに、同一物理パーティションに配置された論理パーティション同士が容量上限を共有していました。また、データ量の増加に伴って物理パーティションが分割された際、コンテナー全体の総RUが据え置かれると、物理パーティション1つあたりの実効スループットが低下しました[12]。

パーティションキーの衝突やノイジーネイバー（近隣ワークロードによる干渉）に対処するため、OpenAIは一時的にアーキテクチャを変更し、強い分離が必要な重要な新規用途に専用コンテナーを割り当てました[13, 14]。専用コンテナーを設けると、物理パーティションもコンテナーごとに占有されます。これにより、他用途のワークロードから物理的に隔離し、障害の影響を特定機能の劣化に抑えやすくなります[13, 15]。弱いパーティションへの対策として、コンテナーごとの物理パーティション数に応じてRUを同期するスクリプトも運用されました[14]。

しかし、専用コンテナーが増えるにつれ、運用現場の負担も増しました。コンテナーごとに容量計画や監視を行い、新機能のローンチ前に事前プロビジョニングする必要があり、サービス立ち上げ時の緊急増強や過剰プロビジョニングを招きました[16, 15, 16]。

こうした運用負荷を解消するため、Habitatは共有コンテナーを既定とするマルチテナント構成へ回帰しました[17]。共有化にあたっては、共有環境でもワークロード間の安定した分離を維持できるよう、ホットキーの抑制、QoS（Quality of Service）、Cosmos DBのサーバーレスモードの改良を組み合わせた多層防御を導入しました[18]。

ホットスポット対策では、最も負荷の高いキーを検出し、優先的にスロットル（流量制限）をかけます[19, 20, 21]。また、QoS機構では、一括挿入（バルクインサート）やデータ抽出といったバックグラウンドのオフライン処理に低い優先度を割り当てます。ユーザー向けの対話リクエストに影響が及ぶ前に、こうしたオフライン処理を先に制限することで、対話型トラフィックの可用性と応答性を保護しています[19, 20, 22]。

さらに、Azureチームと共同開発した改良型サーバーレスモードが、この共有構成を支えています。一般公開されているCosmos DB serverlessでは、物理パーティションあたりの最大スループットは5,000 RU/sに制限されています[23]。Habitat向けに構築された改良モードでは、上限が10,000 RU/sに引き上げられました[24, 25]。また、従来のデータ保存量に基づく分割に加え、RU使用量に基づく自動分割も導入され、手動監視や事前拡張作業を大幅に削減しています[23]。

項目	一般公開 Cosmos DB serverless	Habitat向け改良サーバーレスモード
物理パーティション上限	最大 5,000 RU/s [23]	最大 10,000 RU/s [24, 25]
パーティション自動分割の基準	保存データ量に応じた分割 [9]	保存データ量に加え、RU使用量に応じた分割 [23]
運用形態と特徴	断続的負荷に適する一方、消費量により費用予測に監視が必要 [26]	手動監視や事前プロビジョニングの負担を削減 [23]

一般公開のCosmos DB serverlessは、消費RUと保存容量に応じた従量課金です。断続的なアクセス負荷では経済的な利点がある一方、消費量に応じて費用が変わるため、使用量の監視が推奨されています。これは一般的な製品仕様であり、Habitat固有の費用額を示すものではありません[26]。また、Habitatが設けた分離境界は、製品ユースケースやワークロード単位の保護と解釈するのが妥当です。正式なテナントIDやエンドユーザー個人の分離仕様は公表されていません[27, 28, 29]。

補足：RU（Request Unit）とは

Azure Cosmos DBにおいて、読み取り・書き込み・クエリ実行などの操作で消費されるCPU、メモリ、IOPSを正規化した測定単位です。

何が変わるのか（キャッシュと整合性）：9割超の読み取りを支えるValkeyと変更フィード無効化

Habitatが処理するリクエストのうち、90%超を読み取り要求が占めています[30, 31, 32, 33]。その多くは、設定情報や直近の状態など、比較的小さなワーキングセットを繰り返し取得するものです[33]。OpenAIのインフラでは、計算資源とデータ保存先が異なる地域に配置される場合があり、リージョン間通信を避けられません。従来のクライアント側キャッシュやバッチ処理は、製品コードの構造を複雑にしていました[30]。

この課題に対し、Habitatはユーザー要求の処理拠点の近くに配置したValkeyサーバーを使い、分散ルックアサイドキャッシュを構築しました[34, 35]。直近にアクセスされたオブジェクトやグラフ構造のエッジをキャッシュに保持し、Cosmos DBの変更フィード（Change Feed）を使って更新を検知・配信する設計です[34, 36]。データが更新されると、変更フィードを通じて数秒以内に各ローカルキャッシュへ無効化イベントが伝わります[32]。明記されている読み取り動作では、無効化後の次の読み取りがキャッシュミスとなり、バックエンドのCosmos DBから最新値を取得してキャッシュを再充填します[37]。一方、通常のキャッシュヒット時における詳細な探索順序や、ミス時に保存先へアクセスする具体的な手順は、公表資料に記載されていません[37]。

キャッシュの鮮度は、変更フィードによるイベント駆動型の無効化とTTL（Time to Live）を併用して制御しています。TTLを短くするとデータの鮮度を保ちやすくなりますが、保存先からの再取得頻度は増えます。反対にTTLを長くするとキャッシュヒット率は向上しますが、無効化が遅れた場合に古い値が返される時間も延びます。Habitatは両者を組み合わせ、通知が遅れた場合も古い値が残る時間を一定範囲に抑えています[38, 33]。

無効化通知が各ローカルキャッシュへ届くまでの時間差や部分障害、リージョン間ネットワークの揺らぎ、キャッシュへの反映とストレージ複製との競合が起きた場合、一時的に古いデータが参照される可能性があります[39, 33]。

こうした障害への耐性を高めるため、HabitatのCDC（Change Data Capture）基盤には堅牢な保護機構が組み込まれています。内部制御プレーンが、監視対象コンテナーや読み取り元リージョンの選定、複数地域のワーカーへの負荷分散を統括します。また、対話トラフィックへの影響を抑えるため、レプリカから低優先度で読み取ります[40]。さらに、ストリーム間の障害分離、配信に失敗したメッセージを退避するデッドレターキュー（DLQ）、チェックポイントのまとめ書き、リージョン障害時に別のCosmos DBリージョンへ読み取り元を切り替えるフェイルオーバー機構を備えています[41, 40]。なお、Azure Cosmos DB SDKには、優先リージョンが利用できないときに後続要求を次点のリージョンへ切り替える一般的な仕組みがあります。これは同一アカウント内でのSDKの基本動作であり、Habitat固有の基盤間ルーティング仕様ではありません[42]。

一次資料では、キャッシュのヒット率と鮮度は定性的に高く保たれていると説明されています。一方、実測ヒット率、無効化遅延の分布や上限、古い値の発生頻度、具体的なTTL設定値は公開されていません。そのため、外部から鮮度や費用対効果を定量的に評価することはできません[43, 44]。

補足：CDC（Change Data Capture）とは

データベース内のデータに対する変更（挿入・更新・削除）を検知し、その変更イベントを他のシステムやキャッシュ層へリアルタイムに伝達・同期する仕組みです。

何が変わるのか（データ配置と性能）：物理制約下の広域複製と読み取り12倍改善の測定条件

OpenAIは、重要データの近接地域への複製、リージョン内キャッシュの展開、Habitatサービス自体のRustによる再実装という一連の改善施策を実施しました[45]。その結果、Habitat全体のグローバル読み取りp50（中央値）は、改善前の約120msから改善後の約10msへ短縮され、約12倍の性能改善を達成したと報告されています[46, 47, 48, 49]。

ただし、この約12倍という改善値を解釈するには、前提条件と限界を整理する必要があります。報告された数値はHabitatストレージ基盤の読み取り処理に関する指標であり、推論処理やフロントエンド通信を含むChatGPT全体のエンドユーザー応答時間を示すものではありません[47, 48, 49]。また、この改善倍率は3つの施策を合わせた結果として報告されており、各施策の個別の寄与度は示されていません[45, 49]。

さらに、公開資料の性能セクションには、計測対象のネットワーク区間やテレメトリの計測境界、同時接続負荷、サンプル件数、キャッシュヒット率、集計対象期間、地域や利用者の構成比率、p50を上回る分位値（p95やp99など）が明記されていません[50, 31]。Habitat全体のデータ量として別途示されている500PB超も、プラットフォーム全体の規模を示す値であり、性能比較の測定対象データ量とは区別されます[51]。中央値が約10msに改善した後も、キャッシュされていないデータを遠隔リージョンの保存先から取得する遅い読み取り要求は残っています。中央値の改善値だけでは、テールレイテンシーの挙動までは説明できません[52, 53]。したがって、この結果はHabitatストレージ基盤における特定の改善報告として捉え、他環境での再現性やChatGPT全体の応答速度の保証にまで拡大解釈しないことが妥当です[54]。

項目	公開資料における報告内容	留意すべき測定条件と解釈の限界
読み取りレイテンシー	グローバル読み取りp50が約120msから約10msへ短縮（約12倍改善） [46, 47]	Habitatストレージ層の指標であり、ChatGPT全体のエンドユーザー応答時間やp95/p99値は非開示 [47, 50]
適用施策の内訳	重要データの近接複製、リージョン内キャッシュ、Rust化の複合適用 [45]	施策ごとの個別寄与度は公表されておらず、単一技術の効果とは特定不可 [45, 49]
測定環境の前提	90%超が読み取り要求のワークロード [31]	計測区間、同時接続数、サンプル数、キャッシュヒット率、集計窓などの詳細条件は未公開 [50]
データ配置の対象	認証メタデータなど選別データを全40リージョン等へ複製 [56, 57]	プラットフォーム全体の500PB超すべてが広域複製されているわけではなく、電力や物理容量の制約を受ける [51, 56]

データ配置では、地理的な近接配置の推進と物理的な制約を踏まえ、対象が選別されています。データレジデンシー要件のある利用者には特定リージョンのCosmos DBアカウントが割り当てられ、要件がない場合も、低レイテンシー化に向けてユーザーの近くへの配置が試みられます[55]。しかし、大規模な近接配置は、クラウド事業者の物理的な収容能力や電力、冷却設備の制約を受けます。限られた容量をデータ保存と推論用の計算資源のどちらに割り当てるかによって、保存先がユーザーから離れた地域にとどまる場合があります[56, 55]。

こうした物理的制約から、広域複製の対象は、認証メタデータのように毎回のリクエストで参照される、遅延に敏感な少数のデータセットに絞られています[56, 57]。一部の特定アカウントでは全40のAzureリージョンへ複製する構成が採用され、別のアカウントでは各大陸に少なくとも1つのリージョンを配置する構成が例示されています[57, 58, 59]。未キャッシュデータへの遠隔アクセスを解消し、データそのものを利用場所にさらに近づける取り組みは、将来的な容量拡大と保存効率の改善を伴う継続課題とされています[52]。

補足：テールレイテンシー（Tail Latency）とは

リクエストのレイテンシー分布において、中央値（p50）から離れた上位のパーセンタイル（p95やp99など）に位置する、処理時間の長いリクエストの遅延を指します。

何が変わるのか（障害対策と将来拡張）：接続集中問題への対応と社内カスタムストレージの開発

大規模な広域分散環境では、リージョン障害時の復旧挙動が重要な設計課題となります。OpenAIの報告によると、2024年後半にプライマリーAzureリージョンで障害が発生した際、最大規模のアカウントでは副リージョンへのフェイルオーバーに長時間を要することが分かりました[60]。その後、元リージョンへ切り戻す過程で、クライアントからの接続要求が一斉に集中する接続集中（コネクションスタンピード）が発生し、ゲートウェイを圧迫しました。このとき、復旧対象となっていた物理パーティションはシステム全体の一部に限られていましたが、それでも要求が集中しました[61, 60]。

この事態を受け、OpenAIとAzureのエンジニアリングチームは、全レイヤーに及ぶ監視体制を構築しました。また、本番規模に匹敵する非本番アカウントを用いた事前検証や、Cosmos DB SDKの共同改良も実施しました。両チームは直接の連絡・エスカレーション経路を確立し、接続集中の原因を特定して修正を配備しています。ただし、改修後の具体的な目標復旧時間（RTO）やフェイルオーバーの自動発動条件は公表されていません[62, 60]。また、障害時にCDC基盤の制御プレーンが変更フィードの読み取り元を別リージョンへ切り替えるフェイルオーバーを備えていますが、これは変更検知基盤についての説明であり、一般ユーザーの通常リクエストに対するルーティング切り替え方式を示すものではありません[63]。

複製トポロジーが異なるCosmos DBアカウント間でデータセットを移行する、透過的なデータ移動・ルーティング層についても言及されています。ただし、データのコピー順序や整合性保証のレベル、切り替えのトリガー、ロールバック手順などの運用詳細は、公表資料から確認できません[64]。

将来のさらなる規模拡大に向けては、会話履歴などの大規模データを広域複製する際の物理的制約が顕在化しています。この課題に対応するため、OpenAIは容量要件の大きいHabitatデータ向けに、社内カスタムのオンラインストレージを開発しています[65]。このカスタムストレージでは、ストレージとコンピュートを分離し、物理的な複製手法を採用しています。また、ピークQPS（Query Per Second）を引き下げる設計上のトレードオフを受け入れ、高価なフラッシュストレージに必要な容量を削減することを目指しています。ただし、本番への移行時期や障害復旧特性、詳細な費用モデルは公表されていません[66]。

誰に影響するのか：製品開発者の負担軽減とマルチテナント設計の実務判断

Habitatのアーキテクチャ刷新は、OpenAI内部の製品開発者に直接影響しました。ルーティング、認可、暗号化、データ配置といった複雑なストレージ制御がHabitatサービス側に一元化されたことで、開発者は個別の容量計画や事前プロビジョニング、クライアント側でのルーティング管理から解放され、製品機能の実装に集中できるようになりました[7]。

一方、Habitatの変遷は、一般的なマルチテナントSaaSやクラウドアーキテクチャを設計する実務者にも重要な示唆を与えます。AWSが公開しているSaaSテナント分離ガイダンスでも、業務要件、規制要件、費用、性能、運用能力などに応じて、共有型（プール型）、専用型（サイロ型）、またはその混在型を選ぶべきであり、万能な単一の分離モデルはないと説明されています[67]。

Habitatは、専用コンテナーによる物理的分離から運用負荷の増大を経て、共有コンテナーへ回帰しました。この経緯を、共有化の一律な推奨と捉えるべきではありません。Habitatの共有化を支えているのは、ホットキー抑制、きめ細かなQoS、改良型サーバーレスモード、クラウド事業者との密接な共同運用といった高度な制御基盤です。

一般的なマルチテナントシステムで広域複製やデータ配置を設計する際も、クリティカルパス上の遅延短縮効果と、増大するデータ量、クラウド拠点の物理的な収容能力・電力・冷却の制約、データレジデンシー規制、データ移動とルーティングの運用複雑性を比較する必要があります。そのうえで、対象データを厳密に選別します。自システムの設計では、Habitatの構成例を一律の目標値として扱わず、クリティカルパスの要件や物理的制約に応じたトレードオフを踏まえて、対象データを取捨選択することが実務上の判断基準となります[68]。