本文へ移動
H/ACCH/ACC
計算基盤 ／ テクノロジー

OpenAIが共有ストレージの高速化と負荷の分離を両立

H/ACC · AI支援による編集資料公開日 編集日 2026-10-23

今回の進展

OpenAIの公表によると、Habitatの内部ストレージの読み取りリクエストは、世界全体でみた応答時間の中央値が約120ミリ秒から約10ミリ秒に短縮された。今回の技術報告は、リクエストの優先順位づけ、データ配置、キャッシュを一体で見直すとともに、共有リソースによって各製品チームの容量計画の負担をどう減らすかを示している。

要点AI支援による分析

共有基盤に容量配分とキャッシュ管理を集約することで、各製品チームは共通の技術基盤を再利用できる。読み取り性能はデータ配置、キャッシュ、サービスの処理負荷を併せて最適化することで改善し、負荷の優先順位づけは複数のサービスが安定してリソースを共有する助けとなる。

事実を読み解く

読み取りの応答時間の中央値が約10ミリ秒に

OpenAIが10月23日に公開したHabitatの技術報告第2部によると、今年に入って性能改善に集中的に取り組み、世界全体の読み取りリクエストのp50が約120ミリ秒から約10ミリ秒に短縮された。p50は中央値で、半数のリクエストがこの時間以内に処理されたことを意味する。

報告は、利用場所に近いデータ配置、少量の重要データの複数リージョンへの複製、キャッシュの統合、Rustによるサービスの書き直しを改善策に挙げている。これらの数値は内部ストレージの読み取りリクエストを測ったもので、複数の改修が組み合わさった結果だ。記事には、それぞれの改修の寄与を切り分けた完全な比較結果は示されていない。

リソースの共有と専有で変わる負担

Habitatでは当初、異なるサービスが標準構成のAzure Cosmos DBコンテナーを共有していた。公式報告によると、同じ物理パーティション上のサービスが処理能力を奪い合い、アクセスの集中がほかのサービスに影響することがあった。その後、重要なサービスには専用コンテナーを割り当て、障害の影響範囲を狭めた。ただし、各製品チームが必要な容量を事前に見積もり、設定する負担も生じた。

その後、チームはAzureと協力し、アクセスが集中するキーのレート制限、大量データの取り込みや抽出などのバックグラウンドリクエストの優先度引き下げ、負荷に応じた拡張機能の改善を進めた。こうした条件が整ったことで、共有コンテナーを再び標準構成とし、容量計画のより多くの部分を、共通で運用する基盤側で担うようにした。

処理する場所の近くにキャッシュを置き変更時に無効化

Habitatは、最近アクセスされたデータのコピーを、リクエストを処理する場所に近いValkeyキャッシュに置く。基盤となるデータベースが更新されると、変更データキャプチャの仕組みによって、キャッシュの無効化処理が世界各地に伝わる。原文では、この伝播は秒単位とされている。その後の読み取りでキャッシュに有効なデータがなければ、ストレージ層から更新版を取得し、キャッシュに補充する。

広範囲への複製は、認証メタデータなど、データ量が少なく遅延の影響を特に受けやすいものに限って使われる。原文は同時に、利用場所に近いデータ配置が、各リージョンのストレージ容量、電力、冷却能力に制約されることも説明している。最も遅いリクエストの一部では、キャッシュにないデータを別のリージョンから読み取る必要が依然としてある。

H/ACC の視点

待つ順番を共有リソースのルールにする

H/ACC編集部の解釈：今回の改修の意義は、共有する処理容量の配分ルールを、より明確にした点にある。ユーザーの操作に応じるリクエストと、大量の処理を行うバックグラウンドタスクでは、求められる処理のペースが異なる。アクセスの集中を抑え、どの処理を待たせられるかを定めることで、空いている容量を共同利用しながら、一つのタスクの急拡大がほかのサービスを巻き込む可能性を減らせる。

したがって、負荷を分離する能力は、サービスごとに専用リソースを用意する方法だけでなく、リクエストの処理順序にも表れる。そのためには、システムが負荷を見分け、優先順位を適用し、異常を監視する必要がある。容量の利用効率と重要なリクエストの安定性は、同じ高負荷の条件で併せて評価する必要がある。

製品チームが共通基盤の能力を使えるようにする

データ配置、キャッシュの更新、容量管理を共有プラットフォームに組み込めば、各製品チームは成熟した技術基盤を再利用できる可能性がある。新機能を接続するたびに解き直す課題を減らし、データベースとクラウド基盤のチームは、拡張、アクセスの集中、障害からの復旧にまとめて取り組める。これは、インフラが製品開発の効率を高める具体的な道筋の一つだ。

次に注目したいのは、速く処理されるリクエスト以外の体験だ。キャッシュにデータがないとき、リージョンをまたいでアクセスするとき、バックグラウンドタスクと競合するときにも、待ち時間は予測可能な範囲に収まるのか。中央値は一般的なリクエストの改善を示す一方、特に遅いリクエストの所要時間であるテールレイテンシーとデータの鮮度が、その改善の及ぶ利用場面を左右する。

判断の限界

  • 性能と運用経験はOpenAIによる公表内容に基づく。本記事では実験を独自に再現していない。10月23日は報告の公開日であり、すべての改修が同日に完了したことを意味しない。
  • 約120ミリ秒から約10ミリ秒への短縮は、Habitatのストレージ読み取りリクエストの世界全体でのp50を示す。モデルの生成速度やChatGPT全体の応答時間が同じ割合で改善したとは換算できない。
  • キャッシュの無効化が秒単位で伝わることは、常に最新の値を読み取れる強い整合性の保証にはならない。別のリージョンのデータを読み取る際のキャッシュミスや、各リージョンの物理的な容量制約は、別途評価する必要がある。

次に注目することAI支援による分析

  1. 今後、キャッシュのヒットとミス、同一リージョンと別リージョンに分けた読み取りリクエストのp95とp99が公開され、中央値の改善が遅いリクエストにも及ぶかを検証できるか。
  2. アクセスが集中するキーと大量の書き込みが同時に発生する負荷試験で、ユーザーの操作に応じるリクエストのエラー率とテールレイテンシーは安定するか。バックグラウンドタスクはどれほど待つ必要があるか。

参照資料

この記事で参照した報道や研究資料。

  1. Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part II)OpenAI · Jon Lee, Hrachya Hakobyan, Chaomin Yu · 資料公開日 2026-10-23

動向を追う

次に読む

OpenAIがオフライン訓練と継続的なレッドチーム検証を隔離の仕組みに組み込むOpenAI 高頻度の小さな判断に専用API
フィードに戻る