詳しい解説 · 読了目安 8 分
OpenAIが解説するHabitatの再設計：共有容量、地域キャッシュと条件付きの読み取り12倍改善
Cosmos DBの共有方式、CDCによる無効化、Rustを解説。読み取り中央値の改善は複数変更の合計。
- 当サイトの公開日
- 原典の公開日
- 出典確認日
OpenAIは10月23日の技術記事で、HabitatのAzure Cosmos DBストレージと読み取り経路の改良を説明した。運用上の選択と同社報告の測定値を扱う記事であり、新モデルや一般向けストレージ製品の発表ではない。
ニュースを聴く
この記事を読み上げるか、ニュースを続けて聴けます。
読み上げを準備中…
端末の音声
読み上げはブラウザーまたは端末が処理します。AISubHub は文章を音声 API に送りません。利用できる音声やロック画面での再生は端末によって異なります。
再開時に短い部分を繰り返す場合があります。
要点
- OpenAIは、世界全体の読み取りp50が約120ミリ秒から約10ミリ秒になった要因を、データ配置、地域キャッシュ、Rustへの書き直しの組み合わせとしている。遅いキャッシュミスは今も遠隔ストレージにアクセスする。
- Habitatは共有コンテナから分離へ進み、Azureとの共同開発後に標準を共有へ戻した。別のエクサバイト級システムは開発中である。
共有が無関係な機能を制限した理由
OpenAIはHabitatを、500ペタバイト超を管理し、40の地理的地域で10億人超にサービスを提供する製品を支える層と説明する。これは著者による規模の説明で、独立した利用者統計でも今回の新規利用者発表でもない。問題は、容量をまとめながら一つの機能が他を妨げないようにすることだ。当初はCosmos DBの各アカウントが標準コンテナ一つを使い、クライアントが論理パーティションキーを選んでいた。共通の識別子によって異なる用途が同じキーの上限を共有し得た。
RU/sは毎秒のリクエストユニットで、一定のクエリ件数ではない。初期設計は論理キーごとの公称10,000 RU/sを背圧に利用したが、実際の上限適用単位は共有される物理パーティションであり、無関係なキーも競合する。さらに、コンテナ全体のスループットを増やさずにデータ増加で分割が起きると、子パーティションの容量は減る。大きなオブジェクトを扱う用途は、要求件数が一定でも制限される。記事の模式図は仕組みを説明するもので、比率は本番測定値ではない。
分離の効果と増えた容量計画
専用コンテナは重要サービスに別の物理パーティションを与え、ノイジーネイバーの影響範囲を狭めた。チームは物理パーティション数に合わせて割り当てスループットも調整し、弱いパーティションに対処した。一方で各サービス境界が容量計画を担うことになった。社内試用から大規模公開へ移ると、小さな専用コンテナは飽和し得るが、同じ増分でも巨大な共有プールには小さな変化となる。分離は障害境界を変えても、公開前の需要予測を不要にはしなかった。
Habitatは、ホットキーの制限、大量処理の低優先度化、Azureと作ったserverlessの変種を伴って標準共有へ戻った。記事は、従来の物理パーティション当たり5,000 RU/s上限に対し、最大10,000 RU/sとし、保存量に加えRU使用量でも分割する専用方式を説明する。特定の協業であり、全Azure顧客が同じ設定を有効化できる証拠ではない。本站の分析では、対話処理を守る制御と需要に応じた容量調整があって初めて、共有余力が信頼できる利点になる。
マネージドでも共同の障害試験が必要だった
OpenAIによると、最大のCosmos DBアカウントは数十ペタバイトを保存し、毎秒2,000万件超のクエリを処理する。2024年末の停電と、その約1か月後の切り戻し事故が、この規模で未検証だった前提を露呈した。停電時には最大アカウントの予備地域への切り替えが数時間かかると判明し、その約1か月後の切り戻しでは接続が殺到して元地域のゲートウェイを圧迫した。対応する物理パーティションが全部戻る前にクライアントが再接続したためだ。異なる復旧段階の二件であり、一件の連続障害ではない。
対策は容量購入だけではない。HabitatとAzureは各層を共同監視し、本番規模の非本番アカウントで試験し、SDKを共同改善し、技術者間の直接連絡経路を持つ。ゲートウェイのメタデータキャッシュ、負荷保護、接続再利用、重要処理とオフライン処理の分離も挙げられる。本站は、他チームも代表的な規模で切り替えと切り戻しの両方を試すべきだと考える。データベースが委託管理されていても、顧客の接続動作、復旧時間、許容影響範囲が自動で検証済みになるわけではない。
読み取り12倍改善に含まれる変更
OpenAIによるとHabitat要求の90%超は読み取りだ。容量が許せばデータを利用者に近づけ、小さく遅延に敏感な少数のデータセットを広く複製し、それ以外の頻出オブジェクトやエッジは近隣のValkeyでキャッシュする。一部の重要アカウントはサービス対象のAzure全40地域へ複製するが、全データが全地域にある意味ではない。ストレージと計算は電力、冷却、設置空間を取り合う。配置は製品と容量の取捨選択であり、無制限の近接性保証ではない。
無効化はCosmos DBの変更フィードを使う。CDCの消費側が更新後に地域キャッシュを無効にし、次の読み取りで再取得する。OpenAIは数秒以内の世界規模の伝播を報告し、TTL期限だけに頼らない鮮度管理を説明するが、瞬時の整合性ではない。Rustへの書き直しもサービスの余分な処理を削減した。全変更の組み合わせで世界の読み取りp50が約120から約10ミリ秒となった。図は近隣複製、地域キャッシュ、Rustを別段階で示す。12倍をRust単独、書き込み、全利用者のChatGPT応答全体へ拡張してはいけない。
CDCの拡張と稼働中・開発中の区別
CDCは二次索引、データ移動、分析にも使われる。OpenAIは、数千コンテナと数百万コンテナパーティションから毎秒数百万の変更が百超のKafkaトピックを通ると報告する。制御プレーンが地域とワーカーを割り当て、レプリカ読み取りと低優先度で対話トラフィックを守る。ストリーム分離、リース管理、デッドレターキュー、地域障害時の読み取り先変更が別々の故障に対処する。恒久失敗の配送を分離して後続を止めない仕組みは、全下流が最新である証明ではない。
適用時には限界も残る。遅いキャッシュミスは遠隔へ届き、記事には各改善を分離した対照実験も、普遍的なテール遅延保証もない。OpenAIはRocksetのRocksDB Cloudコア、Raft複製、Cosmos互換の文書モデルでエクサバイト級を開発中だ。分離型ストレージと物理複製でフラッシュ容量を減らす代わりに、ピークQPSを下げる設計であり、Cosmosの置換が完了したわけではない。本站は第II部本文と読み取り図を読んだが、リンク先の第I部、SDKソース、サービス保証は独立検証していない。
注目する理由
基盤チームには、分離範囲、共有プールの余力、運用責任を比較する材料となる。キャッシュの鮮度、復旧、テールレイテンシーは別々に検証する必要がある。
制約と提供状況
数値はOpenAIの主張で、本站の再現結果やAzureの保証ではない。専用serverless設定の一般提供、新しい会員特典、アプリ全体の遅延改善は示していない。
出典と根拠
原典の公開日: · 出典確認日:
AI を活用した編集記事を、記載した一次情報で確認しています。企業の主張は出典を明示し、掲載は推奨を意味しません。