OpenAI、Habitatストレージを10億人規模に再設計

ChatGPT規模のストレージ「Habitat」

OpenAIの10月23日の技術記事は、オンラインストレージ基盤Habitatについての連載第２部だ。同社によれば、40の地理的地域にまたがる10億人超の利用者を支え、基盤全体で500ペタバイト超のデータを扱う。これらは自社システムに関する発表値で、本稿が独立に測定した数字ではない。第１部はPythonのクライアントライブラリーからサービスへの発展を扱い、第２部はAzure Cosmos DBを下支えにする設計と運用を説明する。

重要なのは、共有と分離の選択が一方向ではなかったことだ。Habitatは初め共有コンテナーを使い、負荷の干渉を抑えるために専用コンテナーへ移り、Azureとの共同改良後に再び共有を既定にした。専用方式は利用者同士の影響を減らせるが、製品チームごとに容量を計画する負担が生じた。新機能の負荷が試験段階から毎秒100万クエリーまで急増しても、事前の容量設定を忘れるチームがあったと記事は述べる。

共有方式を支える変更

OpenAIによると、新設計は特に負荷の高いパーティションキーを先に制限し、１つの利用が物理パーティション全体の処理能力を奪う状態を抑える。改良したCosmos DBのサーバーレス方式では、１物理パーティション当たり毎秒１万リクエストユニットまで拡張でき、保存量だけでなく処理量に応じても分割する。リクエストユニットはデータベース操作の資源量であり、利用者からのリクエスト件数と同じ単位ではない。したがって「１万」はアプリの応答時間の保証でもない。

記事は、最大のCosmos DBアカウントが数十ペタバイトを保存し、毎秒2000万クエリー超を処理すると説明する。2024年末の地域停電では、最大規模のアカウントを別地域へ切り替えるのに数時間かかることが分かったという。管理サービスでも、顧客固有の規模になれば提供側と共同で実データや負荷を使った演習が必要になる。一般的な障害復旧の説明だけでは、この規模での所要時間を保証できない。

OpenAIは世界全体の読み取り遅延の中央値が約120ミリ秒から約10ミリ秒に下がり、12倍改善したと報告する。期間、キャッシュ、負荷の条件を含む同社の測定であり、別の企業が同じデータベースを選べば12倍速くなるという意味ではない。中央値だけでなく、遅い側の応答、書き込み、ホットキー、障害時の読み取りも確認する必要がある。

他社に移せるのは検証方法

自社で共有か分離かを決める際には、テナントごとの処理量、キーの偏り、成長速度、許容できる停止時間を並べたい。新機能公開時の急増と地域切り替えを演習し、誰が容量変更を担当するかも定める。OpenAIの経験は、理論上きれいな分離より、運用責任の置き方が結果を左右する場合を示した。

本稿は10月26日付で10月23日の原記事を紹介する。OpenAIの内部監視データやAzureの非公開契約を確認したものではなく、性能値を独立再現したとも主張しない。

共有方式の評価では、最も混雑する利用者を抑えたとき、その利用者自身の応答がどう変わるかも見たい。別の利用者を守れても、重要な作業が長時間待たされるなら調整が要る。基盤全体の500ペタバイトと最大アカウントの数十ペタバイトも異なる階層の数字で、同一コンテナーに全量が置かれていると解釈しない。