23 октября OpenAI сообщила, что глобальная медиана задержки чтения в Habitat сократилась со 120 до 10 мс. Habitat — сервис хранения данных для ChatGPT, Codex и других продуктов компании. Но в том же инженерном отчёте OpenAI рассказала о двух серьёзных инцидентах с Azure Cosmos DB. Они произошли раньше, чем удалось добиться нынешнего ускорения. И всё же соседство показательное: быстрое чтение и устойчивость к авариям — разные достижения.
Масштаб объясняет, почему здесь всё непросто. Habitat обслуживает продукты с аудиторией свыше миллиарда пользователей в 40 регионах и работает с 500 ПБ данных. Поначалу в каждом аккаунте Cosmos DB использовали один общий контейнер. Разные сервисы делили ресурсы физических разделов, и «шумные соседи» могли мешать даже входу пользователей и регистрации. По мере роста объёма данных разделов становилось больше, а выделенная контейнеру пропускная способность оставалась прежней. Каждому отдельному разделу доставалось меньше ресурсов.
В конце 2024 года отключение электропитания затронуло основной регион Azure для одного из крупнейших аккаунтов Cosmos DB. Инженеры выяснили, что аварийное переключение таких аккаунтов в резервный регион могло занять несколько часов. Ни OpenAI, ни Azure раньше не испытывали сценарий в сопоставимом масштабе. Месяц спустя произошёл второй серьёзный сбой, уже при возврате в исходный регион. Клиенты Cosmos DB в режиме gateway массово восстановили соединения и отправили запросы обратно, хотя туда успели перенести лишь часть физических разделов. Шлюз оказался перегружен. Несколько часов — это выявленный риск переключения, а не доказанная продолжительность простоя ChatGPT.
В борьбе с «шумными соседями» своя ирония. OpenAI стали выделять критичным сервисам отдельные контейнеры, чтобы те не зависели от чужих пиков нагрузки. Изоляция помогала, но теперь продуктовые команды должны были сами заранее выделять ёмкость под новые функции. По признанию OpenAI, команды порой выпускали обновления, забыв увеличить лимиты. Инженерам приходилось срочно наращивать ресурсы прямо в день запуска, на аварийных созвонах.
В итоге OpenAI вернулась к общим контейнерам по умолчанию, добавив приоритеты запросов и ограничения для перегруженных ключей. Azure повысила лимит на физический раздел в serverless-режиме с 5000 до 10 000 RU/s и добавила масштабирование по нагрузке. По словам OpenAI, в последние месяцы инцидентов из-за нехватки ёмкости и «шумных соседей» не было. После региональных аварий компании также наладили совместный мониторинг и испытания на инфраструктуре производственного масштаба.
А ускорение чтения обеспечили три апгрейда. В 2026 году OpenAI стали реплицировать самые чувствительные к задержке данные ближе к вычислительным регионам. Для остальных нагрузок внедрила региональный распределённый кэш Valkey. Часть кода Habitat переписала с Python на Rust. Изменения в Cosmos DB через change feed запускают инвалидацию устаревших записей в кэше, и следующий запрос заново получает значение. Но 12 раз — это улучшение глобальной медианы внутренних чтений, а не ускорение ответа ChatGPT. Самые медленные запросы по-прежнему обращаются к удалённому хранилищу.
Есть ещё вопрос согласованности кэша. Microsoft в архитектурном руководстве для Cosmos DB описывает гонку: запоздавшее заполнение кэша может вернуть старую версию записи после новой. Для защиты предлагают версионирование и атомарную проверку перед записью. Это предупреждение о классе архитектур, а не обнаруженная ошибка Habitat. OpenAI сообщает об инвалидации кэша за секунды, но не приводит сопоставимой численной оценки редких устаревших чтений. И работа Google «The Tail at Scale» напоминает, почему крупным онлайн-сервисам важно следить не только за медианой задержки, но и за самыми медленными запросами.
Тем временем OpenAI разрабатывает отдельное хранилище эксабайтного масштаба на RocksDB Cloud из Rockset и Raft для объёмных типов данных. Оно должно уменьшить потребность во флеш-памяти ценой меньшей пиковой частоты запросов. Это не объявленный отказ от Azure Cosmos DB. В отчёте также нет сопоставимых показателей по p99 чтений, времени восстановления региона и доле устаревших ответов из кэша. Отсутствие этих цифр не опровергает ускорение в 12 раз. Но история эксплуатации выглядит не менее любопытно, чем график p50. OpenAI и Azure теперь вместе проводят испытания, ведут мониторинг и имеют прямые инженерные каналы.
Если даже OpenAI приходится вместе с Azure следить за базой и готовиться к авариям, насколько «управляемым» остаётся такое облако? Или на масштабе ChatGPT по-другому просто не бывает?
Источник: habr.com