OpenAIはCosmos DBの共有運用、地域キャッシュ、Rust化を解説しました。読み取り遅延の中央値を約120ミリ秒から約10ミリ秒へ改善したと報告しています。 モデル以外の基盤も体験と開発速度を左右します。障害範囲、容量、データ配置を共同で運用する設計が参考になります。 急増する利用を支える共有データ基盤 OpenAIは10月23日、オンラインストレージ基盤Habitatの技術解説第2部を公開しました。10億人超の利用者に対し、40の地域で高速なデータ参照を支える基盤です。シリーズでは500ペタバイト超のデータを扱うまでの発展を説明しています。今回はAzure Cosmos DBの運用と読み取り性能が中心です。最初は共有コンテナを使い、他の処理からの影響を避けるため個別のコンテナへ分けました。その後、容量計画の負担が増え、共有を基本とする設計へ戻しています。単にデータベースを大きくする話ではなく、製品チームへどこまで運用を求めるかという組織上の課題も扱っています。信頼性、速度、効率の順に改善してきたと説明しています。 隔離と容量計画の負担を両立させる 共有環境では、一部の高負荷なキーや裏側の処理が利用者向けの要求を圧迫します。Habitatでは、高負荷キーの制限、要求の優先順位、利用量に応じた分割を組み合わせました。Azure側との共同開発により、製品ごとの容量計画を減らしたとしています。地域をまたぐ参照には、必要な小規模データの複製や、近くに置いたValkeyのキャッシュを使います。変更の通知によってキャッシュを無効化し、鮮度と再利用率を両立する方針です。Rustへの書き換えも含め、読み取り遅延の中央値は約120ミリ秒から約10ミリ秒へ改善したと報告しています。この値は同社基盤全体での改善であり、Rust単独の効果ではありません。大規模なAIサービスや複数製品を共通基盤で支えるチームに関係する実例です。 キャッシュの鮮度と障害試験が運用の焦点 自社へ応用する際は、共有と専有を固定的に選ぶより、負荷の特徴と障害範囲を測ることが論点になります。認証のような重要処理と大量の背景処理を分け、移行できる仕組みを用意する進め方が考えられます。近くにデータを置けば遅延は減りますが、地域の電力や冷却、容量には制約があります。複製やキャッシュには、費用だけでなく古い値を返す時間も評価対象になります。OpenAIは、本番相当の規模を持つ試験環境や共通の監視、直接の連絡経路をAzureと整備したと説明しています。委託先に任せる範囲が広くても、自社の規模で切り替えを試す体制は必要と見られます。今後は独自の大規模ストレージも開発中ですが、既存の構成を一般向けに提供する発表ではありません。公開事例として自社の制約と照合することが焦点です。遅い要求の改善は、今後も課題として残っています。