OpenAI ускорила чтение в Habitat в 12 раз, но столкнулась с авариями Cosmos DB

23 октября OpenAI сообщила, что глобальная медианная задержка чтения в Habitat снизилась со 120 до 10 миллисекунд. Habitat — внутренний сервис хранения данных, который используется ChatGPT, Codex и другими продуктами компании.

В том же инженерном отчёте OpenAI описала два серьёзных инцидента с Azure Cosmos DB. Они произошли ещё до того, как компании удалось добиться нынешнего ускорения. Соседство этих историй показательно: низкая задержка чтения и устойчивость к авариям требуют разных инженерных решений.

Habitat работает с более чем 500 ПБ данных, обслуживает продукты с аудиторией свыше миллиарда пользователей и развёрнут в 40 регионах. Изначально для каждого аккаунта Cosmos DB использовался один общий контейнер. Разные сервисы делили ресурсы физических разделов, поэтому резкий рост нагрузки в одном из них мог повлиять даже на вход пользователей и регистрацию.

По мере увеличения объёма данных число физических разделов росло, но выделенная контейнеру пропускная способность оставалась прежней. В результате каждому разделу доставалось всё меньше ресурсов. Чтобы защититься от таких «шумных соседей», OpenAI начала выделять критически важным сервисам отдельные контейнеры. Это повысило изоляцию, но создало новую проблему: продуктовым командам пришлось заранее резервировать ёмкость для новых функций.

В конце 2024 года отключение электропитания затронуло основной регион Azure, где находился один из крупнейших аккаунтов Cosmos DB OpenAI. Инженеры выяснили, что аварийное переключение таких аккаунтов в резервный регион могло занимать несколько часов. Сценарий не был проверен ни OpenAI, ни Azure на сопоставимом масштабе.

Примерно через месяц произошёл второй сбой — уже при возвращении в исходный регион. Клиенты Cosmos DB, работавшие в режиме gateway, массово восстановили соединения и направили запросы обратно, хотя туда успели перенести только часть физических разделов. Шлюз оказался перегружен. При этом речь идёт о выявленном риске процедуры переключения, а не о доказанной продолжительности простоя ChatGPT.

Отдельные контейнеры оказались не универсальным решением

Изоляция сервисов помогала бороться с пиковыми нагрузками, но требовала постоянного контроля ёмкости. По признанию OpenAI, команды иногда выпускали обновления, не увеличив лимиты заранее. Инженерам приходилось срочно добавлять ресурсы непосредственно в день запуска и разбирать проблему на аварийных созвонах.

В итоге OpenAI вернулась к общим контейнерам по умолчанию. Вместо полного разделения ресурсов компания добавила приоритеты запросов и ограничения для перегруженных ключей. Azure, в свою очередь, увеличила лимит на физический раздел в serverless-режиме с 5000 до 10 000 RU/s и внедрила масштабирование в зависимости от нагрузки.

По данным OpenAI, в последние месяцы инцидентов, связанных с нехваткой ёмкости и «шумными соседями», не происходило. После региональных аварий компании также организовали совместный мониторинг, испытания на инфраструктуре производственного масштаба и прямые инженерные каналы связи.

Откуда взялось ускорение чтения

OpenAI связывает сокращение задержки с тремя изменениями. В 2026 году компания начала реплицировать наиболее чувствительные к задержке данные ближе к регионам вычислений. Для остальных нагрузок внедрили регионально распределённый кэш Valkey, а часть кода Habitat переписали с Python на Rust.

Изменения в Cosmos DB через change feed запускают инвалидацию устаревших записей в кэше. После этого следующий запрос получает значение из хранилища заново. Однако показатель в 12 раз относится к глобальной медиане внутренних чтений, а не к общей скорости ответа ChatGPT. Самые медленные запросы по-прежнему могут обращаться к удалённому хранилищу.

Остаётся и вопрос согласованности кэша. В архитектурном руководстве Microsoft для Cosmos DB описан сценарий, при котором запоздалое заполнение кэша возвращает старую версию записи уже после появления новой. Для защиты от этого подхода рекомендуются версионирование и атомарная проверка перед записью. Это предупреждение о целом классе архитектур, а не указание на обнаруженную ошибку в Habitat.

OpenAI сообщает, что инвалидация кэша происходит за секунды, но не приводит сопоставимой численной оценки редких устаревших чтений. Кроме того, в отчёте нет показателей p99 для чтений, времени восстановления региона и доли ответов, полученных из кэша в устаревшем состоянии. Отсутствие этих данных не опровергает заявленное ускорение, но не позволяет оценить поведение системы на хвостах распределения.

Масштаб меняет цену облачной инфраструктуры

Для крупных онлайн-сервисов важна не только медианная задержка, но и самые медленные запросы. На это указывает и работа Google The Tail at Scale: редкие задержки отдельных компонентов могут заметно ухудшать пользовательский опыт при большом количестве параллельных запросов.

Параллельно OpenAI разрабатывает отдельное хранилище эксабайтного масштаба на RocksDB Cloud от Rockset и Raft для объёмных типов данных. Оно должно снизить потребность во флеш-памяти, но ценой меньшей пиковой частоты запросов. В отчёте не говорится, что это решение должно заменить Azure Cosmos DB.

История Habitat показывает, что ускорение внутренних операций и надёжность аварийного восстановления — независимые задачи. Даже при использовании управляемого облачного сервиса на масштабе ChatGPT приходится отдельно контролировать ёмкость, взаимодействие регионов, поведение шлюзов и согласованность кэшей.

OpenAI и Azure теперь совместно проводят испытания, ведут мониторинг и готовятся к региональным авариям. Это снижает риски, но одновременно подчёркивает, что облачная инфраструктура на таком масштабе не становится полностью автономной: за её устойчивостью всё равно приходится следить как за отдельной инженерной системой.