Как OpenAI масштабировала хранилище ChatGPT: 70 млн запросов в секунду и переход с Python на Rust
OpenAI 11 сентября 2026 года опубликовала первый технический разбор платформы Habitat, через которую ChatGPT, Codex, API и внутренние сервисы получают оперативные данные. По данным самой компании, система обрабатывает более 70 млн запросов в секунду, хранит свыше 500 петабайт и поддерживает продукты, которыми еженедельно пользуются более миллиарда человек почти в 40 географических регионах.
Материал интересен не только рекордными числами. Habitat показывает, как быстрорастущая компания последовательно принимала заведомо временные решения, централизовала контроль над данными и лишь затем переписала критический сервис с Python на Rust. Для банков, финтеха, операторов связи и крупных онлайн-сервисов Узбекистана это полезный пример того, как масштабировать инфраструктуру без попытки заранее построить «идеальную» платформу.
От библиотеки к общей платформе хранения
Habitat появилась к DevDay 2023 как небольшая Python-библиотека поверх Azure Cosmos DB. Она скрывала от продуктовых команд выбор источника данных, маршрутизацию, авторизацию, шифрование, сериализацию, ограничение запросов и управление соединениями. Разработчику достаточно было использовать простой интерфейс чтения и записи.
По мере роста числа продуктов клиентская модель стала источником операционного риска. Любое изменение маршрутизации требовало обновить библиотеку в десятках сервисов. Развёртывание занимало дни, а откат одной команды мог вернуть ошибочную версию и сорвать защиту от регионального сбоя.
OpenAI вынесла Habitat в отдельный сервис. Это создало единую точку для обновлений, наблюдаемости и платформенных улучшений. Там же централизовали контроль доступа, аудит и ограничения на обращение к базовым хранилищам. Такой слой особенно важен, когда к данным получают доступ не только сотрудники и приложения, но и AI-агенты.
Почему Python оставили как осознанный технический долг
Для высоконагруженного сетевого сервиса Python означает дополнительные расходы процессора и памяти. Однако немедленная смена языка отложила бы стабилизацию API и мешала продуктовым командам. OpenAI называет принятое решение осознанным техническим долгом: сначала зафиксировать архитектуру и процессы, затем оптимизировать реализацию.
Главной проблемой стала не средняя, а хвостовая задержка. Один пользовательский запрос может вызвать сотни обращений к данным, поэтому итоговое время определяется самым медленным вызовом. Asyncio хорошо совмещает ожидание ввода-вывода, но не даёт параллельного выполнения CPU-задач в одном потоке. Шифрование, сжатие, контрольные суммы, маршрутизация и фоновые проверки задерживали возврат уже готовых ответов.
Команда измеряла задержку цикла событий напрямую и ограничивала число одновременных запросов на процесс, компенсируя это большим количеством процессов. Такой подход увеличивает стоимость, зато позволяет удерживать предсказуемые задержки до появления более эффективной реализации.
Какие сбои обнаружило профилирование
Один из заметных эпизодов был связан с конфигурацией feature flags. Каждый процесс раз в минуту без случайного сдвига загружал и разбирал большой JSON-файл. До восьми процессов в каждом контейнере делали это одновременно, вызывая регулярную остановку обработки запросов. Исправление состояло из трёх простых мер: уменьшить конфигурацию, увеличить интервал обновления и добавить jitter, чтобы фоновые задачи не запускались синхронно.
Другая проблема возникла из-за повторного использования TCP-соединений по принципу LIFO. После всплеска нагрузки более медленные процессы возвращали соединения позднее и поэтому чаще получали следующие запросы. Образовывалась петля обратной связи: перегруженные экземпляры притягивали ещё больше работы. Переход к FIFO разорвал этот цикл, а позднее управление соединениями и балансировкой в основном перенесли в Istio и Envoy.
Envoy также объединил множество HTTP/1-соединений Python в меньшее число долгоживущих HTTP/2-соединений с мультиплексированием. Это снизило давление на базы, сеть и NAT-шлюзы и дало общую точку для rate limiting и circuit breakers.
Ограниченный API как инструмент надёжности
Habitat намеренно не предоставляет произвольный SQL. Вместо этого сервис использует простой NoSQL-интерфейс с заранее определёнными объектами и связями. Отказ от сложных запросов ограничивает гибкость, но делает стоимость операции предсказуемой и не позволяет случайному сканированию или join на горячем пути перегрузить всю систему.
Сложную аналитику отделили от транзакционного контура. Изменения передаются через CDC в изолированные экземпляры Rockset, за масштабирование которых отвечают команды-потребители. Это добавляет трение, зато аналитические запросы не конкурируют с входом пользователей, настройками и диалогами за один ресурс.
Что дал переход на Rust
К пику Python-версия Habitat обслуживала более 20 млн запросов в секунду. Во втором квартале 2026 года два инженера при поддержке Codex и GPT‑5.5 переписали сервис на Rust. На момент публикации новая версия принимала 95% производственного трафика, а полный вывод Python из эксплуатации планировался в ближайшие недели.
Согласно измерениям OpenAI, Rust-реализация оказалась в шесть раз эффективнее по процессору и в 15 раз эффективнее по памяти, одновременно снизив средние и хвостовые задержки. Эти результаты относятся к конкретной архитектуре Habitat и не означают, что любой сервис автоматически получит такой же выигрыш после смены языка.
Практические выводы для компаний Узбекистана
Опыт Habitat полезно переводить не в лозунг «переписывайте всё на Rust», а в последовательность управленческих решений:
- централизовать маршрутизацию, права, аудит и ограничение нагрузки раньше, чем число сервисов сделает согласованные обновления слишком дорогими;
- измерять p95 и p99, задержку event loop и дисбаланс между экземплярами, а не ориентироваться только на средние значения CPU;
- добавлять jitter к периодическим задачам и проверять, не синхронизируются ли они во всём кластере;
- ограничивать выразительность API на критическом пути, если произвольный запрос способен создать непропорциональную нагрузку;
- физически отделять аналитику от транзакционных операций и заранее проектировать деградацию зависимостей;
- откладывать дорогую миграцию языка до стабилизации контрактов, но закреплять измеримые условия, при которых технический долг должен быть погашен.
Для локального бизнеса важны также размещение данных, требования договора с облачным провайдером, резервирование каналов и сценарии регионального отказа. Масштаб OpenAI уникален, но описанные классы проблем появляются намного раньше — как только один сервис становится общей зависимостью нескольких продуктов.
Ограничения разбора
Все количественные показатели опубликованы OpenAI и не проходили независимый аудит. Компания не раскрывает полную стоимость Habitat, число серверов, конфигурацию кластеров и детальные показатели задержки до и после миграции. Публикация является первой частью серии; отдельный разбор многоарендности, чтения и работы с Azure Cosmos DB обещан позднее.
Главный урок Habitat — оптимизация начинается не с выбора языка. Сначала команда уменьшает число неконтролируемых вариантов, делает нагрузку наблюдаемой и создаёт единый контур управления. Только после этого переписывание критического компонента становится измеримым инженерным проектом, а не дорогостоящей ставкой на технологию.
