OpenAI раскрыла архитектуру Habitat для миллиарда пользователей ChatGPT

Один слой хранения обслуживает все продукты OpenAI

OpenAI впервые подробно описала Habitat — внутреннюю платформу, через которую продукты компании получают быстрый и надёжный доступ к пользовательским данным. Она обслуживает ChatGPT, API, Codex и внутренние сервисы, беря на себя маршрутизацию, кэширование, авторизацию, шифрование, размещение данных, rate limiting и Change Data Capture. Платформа уже обрабатывает более 70 млн запросов в секунду для продуктов с аудиторией свыше 1 млрд человек в неделю, работает почти в 40 регионах и обслуживает более 500 ПБ данных.

Масштаб важен не только сам по себе. Одно действие пользователя — вход, открытие настроек Codex или начало нового разговора — может потребовать сотен обращений к данным, поэтому ощущаемую задержку определяет самый медленный запрос. OpenAI пишет, что нагрузка Habitat росла более чем в десять раз год к году три года подряд: команде приходилось одновременно устранять ближайшие ограничения и строить основу для следующего этапа.

Публикация стала первой частью серии. В ней компания сосредоточилась на эволюции управляющего сервиса и эксплуатации Python под высокой нагрузкой. Отдельный материал обещан про multi-tenancy, ускорение чтения и совместное масштабирование storage layer на Azure Cosmos DB. Поэтому нынешний текст раскрывает важную, но не всю архитектуру Habitat.

Python-библиотека перестала успевать за десятками сервисов

Habitat началась в середине 2024 года как небольшая Python-библиотека внутри основного сервера ChatGPT. Она давала продуктовым командам простой интерфейс к Azure Cosmos DB и скрывала schema lookup, routing, authorization, serialization, connection pooling и выбор между базой и кэшем. Подход ускорял разработку: инженерам продукта не требовалось становиться специалистами по каждой детали хранилища.

К середине 2025 года client-side модель стала тормозить развитие. Любое изменение протокола требовало согласованного обновления десятков сервисов. OpenAI приводит пример распределения критичных наборов данных по региональным аккаунтам Azure Cosmos DB: rollout новой маршрутизации, shadowing и исправлений занимал дни, а откат одного стороннего сервиса мог вернуть старый ошибочный клиент и создать именно тот сбой, которого пытались избежать.

Команда вынесла Habitat в самостоятельный централизованный сервис. Это создало единую точку для deployment, observability и обновлений платформы, а заодно — контролируемое место для access policies, audit logging и ограничения прямого доступа к storage resources. Цена решения была очевидна: сетевой Python-сервис расходовал больше CPU и памяти и добавлял latency по сравнению с локальным вызовом библиотеки.

Tail latency оказалась проблемой планировщика, а не только базы

OpenAI сознательно приняла этот технический долг, чтобы сначала стабилизировать API и разблокировать продуктовые команды. Главной эксплуатационной проблемой стала tail latency. `asyncio` хорошо совмещает ожидание ввода-вывода, но не даёт CPU parallelism в одном процессе из-за GIL. Между сетевыми вызовами Habitat также выполняла routing, compression, encryption, checksumming, health checks, shadowing и hedging — и готовый ответ базы мог ждать, пока event loop снова передаст управление нужной coroutine.

Команда стала измерять scheduling delay напрямую: периодическая задача сравнивала ожидаемое и фактическое время запуска. При высокой загрузке задержка event loop достигала сотен миллисекунд, а в отдельных случаях — нескольких секунд. Вместо большого числа конкурентных запросов в одном процессе OpenAI ограничила concurrency и масштабировала количество Python workers, одновременно наблюдая CPU, память, сеть, диски и состояние самого loop.

Один источник периодических всплесков нашли через live CPU profiling. Statsig раз в минуту без jitter обновлял и разбирал большой JSON со всеми production-правилами, а в каждом pod работало до восьми Python-процессов. В результате все workers могли одновременно отвлечься от активных запросов. Исправление состояло из меньшей целевой конфигурации, более редкого обновления и jitter для фоновых задач.

LIFO в connection pool усиливал перегруженные процессы

Ещё одна проблема возникла из сочетания client-side connection pooling и неравномерной нагрузки. Некоторые процессы Habitat получали в 5–10 раз больше параллельных запросов, чем средний worker. После всплеска часть процессов продолжала деградировать даже после остановки клиента: новый трафик всё сильнее закреплялся за уже медленными узлами, формируя metastable failure.

Причиной оказался стандартный LIFO-порядок повторного использования соединений в `aiohttp.TCPConnector`. Медленный сервер возвращал соединение в pool позже остальных, после чего LIFO выбирал именно его для следующего запроса. Переход на FIFO разорвал положительную обратную связь и уменьшил разброс нагрузки в steady state. Сейчас OpenAI в основном полагается на Istio и Envoy с более подходящими server-load-aware стратегиями.

Большое число Python-процессов создавало и другую угрозу — thundering herd соединений к зависимостям. Envoy объединяет их, переводит Python HTTP/1 traffic на HTTP/2 с multiplexing, дольше удерживает подключения и централизует rate limits и circuit breakers. В иллюстрации OpenAI одинаковые шесть параллельных запросов требуют 18 открытых прямых соединений от pods, шесть через общий HTTP/1 pool или одно HTTP/2 соединение с несколькими streams.

Предсказуемый NoSQL API стал сознательным ограничением

Habitat масштабируется не только благодаря инфраструктуре, но и потому, что намеренно делает меньше. Вместо произвольного SQL сервис предлагает ограниченный NoSQL API с предсказуемой стоимостью операций. OpenAI связывает прежние outages в Postgres с дорогими запросами на горячем пути: по мере роста команды централизованная проверка всех schema и query changes перестала быть управляемой.

Модель Habitat построена вокруг определяемых клиентом объектов и рёбер, вдохновлена TAO и легко делится по горизонтали. Платформа умеет получать прямые связи объекта, но не выполняет произвольные graph traversals. Для сложной аналитики изменения через CDC почти в реальном времени отправляются в изолированные экземпляры Rockset, масштабирование которых остаётся ответственностью соответствующей продуктовой команды.

Такой разрыв отделяет короткие online-запросы от тяжёлого поиска и аналитики. Он добавляет разработчикам трение, зато сложная операция не может незаметно превратиться в неограниченный fanout внутри критического storage path. Это не универсальный отказ от SQL: это выбор безопасного интерфейса для общего слоя, который должен сохранять предсказуемость при экстремальном росте.

Rust уже принял 95% production-трафика

Отложенная миграция дала Habitat год на стабилизацию, но Python-версия всё же стала второй по числу CPU cores службой OpenAI и четвёртой по footprint Envoy. На пике она обслуживала более 20 млн запросов в секунду. В Q2 2026 два инженера при помощи Codex и GPT-5.5 переписали весь сервис на Rust.

На момент публикации Rust-реализация обрабатывает 95% production-запросов, а Python планируют полностью вывести из эксплуатации в ближайшие недели. По данным OpenAI, новая версия в шесть раз эффективнее по CPU и в 15 раз — по памяти, одновременно снижая среднюю и хвостовую задержку. Компания пока не публикует методику этих измерений и обещает отдельный рассказ о миграции, поэтому цифры следует читать как внутренние результаты производителя, а не независимый benchmark.

История Habitat показывает последовательность инженерных приоритетов: сначала простой интерфейс, затем единый service boundary, наблюдаемость и защита от каскадных отказов, после этого — дорогая смена языка. Rust здесь не заменил архитектурные ограничения, load balancing и контроль downstream connections; он стал следующим шагом после того, как API и эксплуатационная модель успели сформироваться на Python.