OpenAI сократила задержку чтения Habitat до 10 мс
OpenAI рассказала о масштабировании платформы онлайн-хранения Habitat, которая обеспечивает доступ к данным для ChatGPT, API, Codex и внутренних сервисов. Система обслуживает свыше 1 млрд пользователей в 40 географических регионах, хранит более 500 ПБ данных, а медианная задержка чтения сократилась примерно со 120 до 10 мс.
Во второй части инженерного обзора компания описала работу с Azure Cosmos DB. Крупнейший аккаунт OpenAI в этой базе хранит десятки петабайт и обрабатывает более 20 млн запросов в секунду. Habitat предоставляет приложениям хранение, кэширование, контроль доступа, размещение данных и обработку изменений.
От изоляции контейнеров к общей многопользовательской модели
Изначально OpenAI полагалась на один контейнер Azure Cosmos DB и ограничения для логических ключей разделов. На практике разные продукты могли использовать одинаковые ключи, а интенсивная нагрузка одного ключа влияла на соседние разделы. По мере роста объёма данных физические разделы дробились, а доступная им пропускная способность уменьшалась при неизменном общем резервировании контейнера.
Компания затем выделяла критичным сервисам отдельные контейнеры. Это ограничивало радиус инцидентов, но переносило планирование ёмкости на продуктовые команды: при запуске нагрузка могла вырасти с 1 тыс. до 1 млн запросов в секунду, а контейнер не успевали заранее масштабировать.
В итоге OpenAI снова сделала многопользовательские контейнеры вариантом по умолчанию. Совместно с Azure были внедрены ограничение самых горячих ключей, приоритизация запросов и обновлённый serverless-режим. Новый режим допускает до 10 тыс. RU/s на физический раздел и дробление не только по объёму данных, но и по потреблению RU. По словам OpenAI, в последующие месяцы не было инцидентов с резервированием мощности или «шумными соседями».
Кэш, репликация и Rust для глобального чтения
Более 90% запросов Habitat приходится на чтение. Для наиболее чувствительных к задержке данных, включая метаданные аутентификации, OpenAI использует аккаунты Cosmos DB с репликацией во множество регионов, в отдельных случаях — во все 40 регионов обслуживания. Массово копировать все данные компания не может из-за ограничений физической облачной ёмкости.
Для остальных данных Habitat применяет распределённый lookaside-кэш на Valkey рядом с обработкой пользовательских запросов. Изменения в Azure Cosmos DB передаются через change feed: сервис получает события и инвалидирует локальные кэши в течение секунд. Такой подход должен сочетать высокий процент попаданий с низкой устарелостью данных.
Дополнительный выигрыш дала перепись сервиса Habitat с Python на Rust. Вместе с кэшированием и выборочной репликацией это снизило глобальную p50-задержку чтения примерно в 12 раз. OpenAI также описала совместную эксплуатацию с Azure: команды используют общие тесты, дашборды и каналы прямой инженерной связи после инцидентов при региональном переключении.
Что это означает для компаний
Опыт OpenAI показывает, что на очень крупном масштабе управляемый облачный сервис требует не только настроек со стороны заказчика, но и совместной инженерной работы с провайдером. Бизнесу стоит заранее разделять интерактивные и фоновые нагрузки, автоматизировать реакцию на изменения данных и проверять сценарии отказа на средах, сопоставимых с производственными.
Следующим шагом OpenAI назвала собственную систему онлайн-хранения эксабайтного масштаба для крупных типов данных Habitat. Она будет использовать RocksDB Cloud от Rockset, репликацию на базе Raft и модель документов, совместимую с Azure Cosmos DB, в обмен на более низкий пиковый QPS.