Быстрое масштабирование онлайн-хранилища для обслуживания более 1 миллиарда пользователей ChatGPT | OpenAI

Как мы адаптировали нашу платформу хранения данных для приложений Habitat на языке Python для управления беспрецедентным ростом.

Джон Ли, Чаомин Ю и Бен Рис, члены технического персонала.

• Что такое среда обитания?
• Создайте сервис для более эффективной поддержки множества сложных продуктов.
• Запуск Python-сервиса в масштабе предприятия
  • Отслеживание задержки asyncio
  • Уменьшение задержки в хвосте распределения в конфигурациях флагов функций.
  • Балансировка нагрузки и управление пулами подключений
  • Предотвращение затопления ресурсов, расположенных ниже по течению.
• Почему организация Habitat делает меньше
• Переход с Python на Rust
• Оптимизация нашего уровня базы данных, Azure Cosmos DB.

• Что такое среда обитания?
• Создайте сервис для более эффективной поддержки множества сложных продуктов.
• Запуск Python-сервиса в масштабе предприятия
  • Отслеживание задержки asyncio
  • Уменьшение задержки в хвосте распределения в конфигурациях флагов функций.
  • Балансировка нагрузки и управление пулами подключений
  • Предотвращение затопления ресурсов, расположенных ниже по течению.
• Почему организация Habitat делает меньше
• Переход с Python на Rust
• Оптимизация нашего уровня базы данных, Azure Cosmos DB.

Каждый продукт OpenAI зависит от быстрого и надежного доступа к данным, независимо от того, входит ли пользователь в систему, проверяет свои настройки Codex или начинает новый разговор в ChatGPT. Каждое из этих действий может потребовать множества отдельных запросов к данным, прежде чем продукт сможет ответить. Если эти запросы выполняются медленно, продукт работает медленно. Если же запросы завершаются неудачей, продукт полностью перестает работать.

Habitat — это онлайн-платформа для хранения данных, которую мы создали, чтобы продукты OpenAI могли быстро и надежно получать доступ к необходимой информации. Сейчас Habitat обрабатывает более 70 миллионов запросов в секунду, поддерживая продукты, используемые более чем миллиардом человек каждую неделю почти в 40 географических регионах. Два года назад Habitat начинался как простая клиентская библиотека на Python, подключенная к одной базе данных. Сегодня это сложная распределенная система, которая обслуживает более 500 петабайт данных.

Создание и эксплуатация инфраструктуры такого масштаба — непростая задача, но и не особенно сложная. Уникальность нашей ситуации заключается в беспрецедентной скорости масштабирования, с которой нам пришлось поддерживать ошеломляющий рост числа пользователей и спроса на продукт, одновременно создавая зрелую платформу. Часто системные инженеры строят систему с расчетом на десятикратное увеличение масштаба, надеясь, что она продержится несколько лет, готовясь к следующему десятикратному росту. В нашем случае мы росли более чем в 10 раз в год на протяжении последних трех лет. В результате создание и эксплуатация Habitat представляли собой серию тактических решений и последовательностей: понимание каждого компонента на самом низком уровне, чтобы выжать максимум из существующего стека, одновременно преодолевая нехватку места для хранения данных и вычислительных мощностей, чтобы выиграть время для фундаментальных инвестиций.

• 70 млн+

  запросов в секунду

• 1Б+

  людей каждую неделю

• 500 ПБ+

  данные

По мере роста OpenAI, Habitat также должен был расти вместе с ним: сначала, став достаточно надежным для критически важных задач, затем достаточно быстрым для глобальных пользователей, и, наконец, чтобы умело работать в огромных масштабах. Эта статья — первая в серии из двух частей о том, как мы масштабировали онлайн-хранилище. В этой статье мы расскажем о том, как развивался Habitat, почему мы превратили его из библиотеки в сервис и как мы расширили возможности сервиса, написанного на редком языке стека обслуживания — Python — до надежного уровня платформы хранения данных.

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

Что такое среда обитания?

Habitat начинался с простой идеи: инженерам-разработчикам не нужно было думать об управлении базами данных. Habitat появился в середине 2024 года как небольшая библиотека на Python, взаимодействующая с основным сервером ChatGPT. Она поддерживала небольшой набор операций, которые по своей сути соответствовали приложению базы данных Azure Cosmos DB.

Задача библиотеки заключалась в том, чтобы предоставить командам разработчиков простой способ хранения и извлечения данных без необходимости разбираться в тонкостях процесса. Habitat брала на себя необходимую работу: определяла, какие данные необходимы, откуда они должны поступать (или куда должны направляться), разрешен ли запрос и так далее.

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

Эта библиотека Python хорошо себя зарекомендовала, и Habitat быстро получила распространение среди инженеров-разработчиков OpenAI, несмотря на отсутствие целенаправленных централизованных мер по отказу от использования самообслуживаемых баз данных Postgres и Azure Cosmos DB.

По мере развития потребностей продукта разработчикам стало легко добавлять в общую библиотеку поддержку таких функций, как кэширование на стороне клиента, сжатие или шифрование.

Создайте сервис для более эффективной поддержки множества сложных продуктов.

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

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

Координация развертывания десятков сервисов и работа с каждой командой над внедрением заняли несколько дней. Прежде чем включить эту функцию, мы поняли, что нам нужно ввести теневое копирование, чтобы убедиться в корректности логики шардирования. На это ушло еще несколько дней. Исправление ошибки, которую мы обнаружили? Еще пара дней. В конце концов, мы были готовы включить флаг, но одна из команд по несвязанным причинам откатила свой сервис к ранее проблемному клиенту, что привело к сбою, которого мы так старались избежать.

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

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

Централизованная служба также предоставляет нам единую точку доступа для обеспечения максимально надежной защиты данных и конфиденциальности. Служба Habitat позволяет централизованно применять политики контроля доступа, вести аудит и ограничивать доступ к базовым ресурсам хранения, таким как Azure Cosmos DB. Habitat играет критически важную роль в защите пользовательских данных и предотвращении несанкционированного доступа со стороны внешних, внутренних и агентских субъектов.

Запуск Python-сервиса в масштабе предприятия

Мы понимали, что нам нужен сервис, но пока не хотели полностью отказываться от Python, даже с учетом дополнительных затрат на его использование в качестве сервиса. Применение Python для высокопроизводительного сервиса увеличивало задержку в сети и существенно повышало затраты на процессор и память по сравнению с локальным выполнением библиотек. Более того, мы осознавали, что неэффективность Python будет неприемлема при масштабировании в 100 раз, что делало в конечном итоге практически неизбежным переписывание кода.

Однако мы рассматривали это как стратегическое накопление технического долга. Нашей главной целью тогда была не оптимизация затрат или ресурсов, а скорее разблокировка разработчиков продукта и обеспечение стабильности платформы. Приняв во внимание компромиссы в производительности сервиса на Python в краткосрочной перспективе, мы смогли уделить приоритетное внимание более насущным задачам, создать основные API и построить надежную инфраструктуру.

Мы также сделали взвешенную ставку на то, что быстрое развитие наших собственных моделей кодирования упростит технический путь в будущем. Мы рассчитывали, что к тому времени, когда потребуется полная миграция с Python, Codex и GPT сделают эту миграцию осуществимой. В итоге эта ставка оказалась верной.

Запуск Habitat в качестве сервиса на Python был бы неоптимальным с точки зрения производительности, но необходимым решением. Python позволяет нам работать быстро, но это не означает, что мы можем пренебречь осторожностью и смириться со значительно большими задержками. Когда средний запрос пользователя приводит к сотням обращений к базе данных, самое медленное обращение к базе данных ощущается пользователем. Мы обнаружили, что главная проблема при запуске сервиса на Python в таком масштабе заключается в управлении этими задержками в конце временной кривой.

Отслеживание задержки asyncio

Asyncio помогает Python выполнять ресурсоемкие задачи ввода-вывода параллельно, но не помогает обойти GIL Python и обеспечить параллелизм на ЦП. Помимо обработки запросов с высокой интенсивностью ввода-вывода, Habitat обрабатывает множество ресурсоемких задач и фоновых процессов: маршрутизацию, сжатие, шифрование, контрольные суммы, проверку работоспособности нижестоящих систем, теневое копирование запросов и хеджирование.

В нашем сервисе так много ресурсоемких задач и фоновых процессов, что задержка планирования asyncio легко может стать доминирующей в задержке обработки запросов. Перед первоначальной настройкой сервиса мы заметили в трассировках запросов с задержкой p99 и выше, что, хотя хранилище отвечало быстро, запросы часто зависали в ожидании перепланирования соответствующей сопрограммы для обработки ответа.

В OpenAI, при работе с Python-сервисами, мы обнаружили, что помимо измерения стандартных показателей использования и насыщения памяти, ЦП, сети и диска, крайне важно также отслеживать цикл asyncio и его загруженность, а затем соответствующим образом настраивать его.

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

В результате мы прибегаем к тому, чтобы каждый процесс обрабатывал лишь небольшое количество одновременных запросов, и вместо этого значительно увеличиваем количество рабочих процессов Python.

Уменьшение задержки в хвосте распределения в конфигурациях флагов функций.

В ходе первоначального запуска нашего сервиса мы обнаружили с помощью профилирования ЦП в реальном времени одну из основных причин высокой задержки asyncio (и, как следствие, высокой задержки в хвостовой части графика): периодический анализ JSON-данных конфигураций флагов функций с помощью Statsig (инструмента, управляющего флагами функций и используемого для проведения A/B-тестов и многого другого).

По умолчанию Statsig был настроен на ежеминутный опрос обновленных конфигураций без задержек, и конфигурация включала все правила для каждой производственной среды и каждого сервиса. Кроме того, было принято архитектурное решение запускать до 8 процессов Python на каждый под, чтобы увеличить загрузку ЦП и обеспечить меньшие задержки. В совокупности это означало, что каждую минуту в каждом поде возникал момент, когда все его рабочие процессы приостанавливали обработку текущих запросов и вместо этого тратили свои ресурсы ЦП на разбор огромного файла конфигурации.

Решение оказалось простым, как только профилирование ЦП помогло нам выявить первопричину проблемы: развернули меньшую целевую конфигурацию, увеличили интервал обновления и добавили некоторую нестабильность фоновым задачам, подобным этой.

Балансировка нагрузки и управление пулами подключений

Для поддержания низкой задержки asyncio также крайне важно обеспечить эффективную балансировку нагрузки запросов между серверными процессами; без соответствующей настройки пулинг соединений может оказаться неэффективным.

При использовании пула соединений на стороне клиента один клиентский процесс, выполняющий множество одновременных запросов, может установить лишь небольшое количество серверных соединений и, как следствие, перенаправить всю нагрузку только на это небольшое количество процессов. До изменения подхода к балансировке нагрузки наш сервис демонстрировал значительные колебания загрузки, при этом некоторые процессы обрабатывали в 5-10 раз больше одновременных запросов, чем в среднем.

Мы обнаружили это в результате случайного инцидента, когда, несмотря на остановку клиента, перегружавшего часть нашего сервиса, подмножество процессов оставалось в состоянии деградации даже после пиковых нагрузок. Фактически, мы заметили, что эти процессы испытывали неконтролируемую деградацию, получая все больше запросов, пока мы их не перезапустили. Как только под становился перегруженным, какое-то поведение перенаправляло на него дополнительный трафик. Это был класс сбоев, с которыми некоторые из наших коллег были хорошо знакомы по предыдущей работе: метастабильный сбой (открывается в новом окне) .

Мы предположили, что виной всему пул соединений, и проверили это предположение, ограничив максимальную продолжительность повторного использования соединений, что действительно ограничило ухудшение производительности и подтвердило правильность нашего направления исследования. Дальнейшее исследование показало, что в Python компонент aiohttp TCPConnector по умолчанию использует принцип LIFO (последний вошел — первый вышел): для следующего запроса выбирается наиболее недавно возвращенное соединение. Обычно это разумное значение по умолчанию: повторное использование последних соединений позволяет дополнительным соединениям, созданным для обработки пикового трафика, доходить до таймаута простоя, снижая накладные расходы на поддержание дополнительных соединений. В данном случае это привело к метастабильной ошибке. Во время всплеска запросов запросы к более медленным перегруженным серверам возвращали соединения в пул позже и, следовательно, выбирались чаще последующими запросами, постепенно концентрируя больший трафик на подах, которые и без того испытывали трудности. Изменение пула соединений на принцип FIFO (первый вышел — первый вышел) разорвало этот замкнутый цикл обратной связи и даже уменьшило вариативность запросов в установившемся режиме.

Сегодня мы в основном полагаемся на Istio и Envoy для обеспечения объединения соединений и более эффективных стратегий балансировки нагрузки на серверы в рамках инфраструктуры OpenAI, что позволяет полностью избежать этой проблемы.

Предотвращение затопления ресурсов, расположенных ниже по течению.

Одним из побочных эффектов настройки на низкую задержку asyncio и наличия большого количества процессов Python является то, что становится очень легко перегрузить нижестоящие зависимости огромным количеством соединений (это явление известно как «грохочущее стадо»).

Регулярное ежедневное развертывание — если оно не настроено на медленную работу — может привести к значительной нагрузке на ЦП из-за циклических подключений. Или утечка соединения может вывести сеть из строя, перегрузив NAT-шлюз. Эти проблемы нередки и для других сервисов, но порог срабатывания значительно снижается при увеличении количества процессов на порядок, что часто приводит к перегрузке сетевых ресурсов, которые клиенты не ожидают обрабатывать в стабильном режиме, исходя только из пропускной способности.

Мы также используем Envoy для максимизации количества подключений. Мы применяем его для преобразования HTTP/1-соединений Python в HTTP/2, чтобы воспользоваться преимуществами мультиплексирования, а затем для объединения этих соединений и продления срока их действия. Envoy также предоставляет нам централизованное место для реализации ограничений скорости и механизмов защиты от сбоев, которые были бы менее эффективны в каждом отдельном процессе Python.

Почему организация Habitat делает меньше

Одна из причин, по которой мы смогли масштабировать Python до таких размеров, — это ограниченный API Habitat, который обеспечивает предсказуемость стоимости запросов. Вместо того чтобы позволять клиентам создавать произвольные SQL-запросы, которые могли бы привести к масштабному сканированию таблиц или объединению множества таблиц, Habitat предоставляет простой NoSQL API. Отсутствие мощного API — это явный компромисс в дизайне Habitat.

Наша цель — оптимизировать системы для простых, предсказуемых запросов с постоянным объемом работы. По нашему опыту, такие системы значительно проще масштабировать и в них сложнее допустить ошибки или неправильно использовать. Запросы с непредсказуемым распределением нагрузки опасны с операционной точки зрения: они усложняют изоляцию, балансировку нагрузки и приводят к резкому увеличению задержки, что затрудняет масштабирование как для сервиса, так и для его клиентов.

До перехода на Habitat и Azure Cosmos DB большая часть онлайн-данных OpenAI хранилась в Postgres. В то время было легко проверять все изменения запросов и схем, чтобы убедиться в их корректной работе и использовании индексированных данных перед внедрением в производство. По мере роста команды и продуктов это быстро стало неуправляемым и часто приводило к сбоям, когда один дорогостоящий новый запрос на «горячей» ветви выводил базу данных из строя.

Проблема здесь заключается в дисбалансе затрат: легко и дешево писать SQL-запросы, которые, однако, являются дорогостоящими и сложными в выполнении. В Habitat мы избегаем этого и делаем дорогостоящие запросы предельно очевидными на стороне клиента. Нет неограниченного количества запросов, которые могли бы перегрузить Habitat, а сложные объединения и обходы графов требуют от продуктовых команд выполнения части ресурсоемкой работы, что в целом способствует оптимизации и повышению эффективности проектирования.

Habitat предоставляет NoSQL API, построенный на основе определяемых клиентом типов объектов и ребер, вдохновленный TAO (открывается в новом окне) . Клиенты предварительно определяют объекты и ребра, а также то, как они связаны друг с другом, но не содержимое каждого типа. Полученные отношения напоминают граф, но сам Habitat не поддерживает типичные запросы обхода графа, за исключением запросов к прямым ребрам конкретного объекта.

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

Для клиентов со сложными задачами запросов мы предоставляем офлайн-версию Habitat, доступную через Rockset. Мы используем технологию захвата изменений данных (CDC) для потоковой передачи изменений из онлайн-хранилища в изолированные экземпляры Rockset практически в режиме реального времени. Каждая команда клиента отвечает за масштабирование своего экземпляра Rockset для удовлетворения сложных потребностей в запросах.

Такой подход к выделению ресурсов в Rockset создает дополнительные сложности для наших клиентов, но мы считаем, что это правильный компромисс на данный момент: простые запросы становятся запросами по умолчанию, а для тех, кому нужны сложные запросы, предусмотрена возможность их обработки. Такая конструкция изолирует наше онлайн-хранилище от ресурсоемких аналитических и поисковых задач.

Переход с Python на Rust

Отложив переписывание кода на Python на год, мы смогли сосредоточиться на более неотложных и важных задачах в период нашего стремительного роста. По мере развития платформы и ускорения нашего роста, а также благодаря тому, что мы стали вторым по величине сервисом по количеству ядер в OpenAI (и четвертым в нашей сети Envoy), наконец-то пришло время отказаться от Python. На пике своего развития Python помогал нам обрабатывать более 20 миллионов запросов в секунду.

Во втором квартале 2026 года, имея всего 2 инженера, Codex и GPT-5.5, мы смогли полностью переписать сервис на Rust. Новый сервис на Rust теперь обрабатывает 95% наших запросов в производственной среде; в ближайшие недели мы полностью откажемся от Python. Наши данные показывают, что сервис на Rust в 6 раз эффективнее использует ЦП и в 15 раз эффективнее использует память, чем версия на Python, со значительно меньшими средними и экстремальными задержками. Мы планируем поделиться дополнительными результатами в будущем блоге.

Оптимизация нашего уровня базы данных, Azure Cosmos DB.

Сервис на Python, а теперь и на Rust, — это лишь одна из граней Habitat. Во второй части этой серии, посвященной тому, как мы быстро масштабировали наше онлайн-хранилище для обслуживания более 1 миллиарда пользователей ChatGPT, мы поговорим об уровне хранения и о том, как Habitat обрабатывает более 500 петабайт данных и более 70 миллионов запросов в секунду.

Если вы хотите работать над системами OLTP в масштабах, близких к передовым, и вас интересует этот вид инженерной деятельности, ознакомьтесь с открытой вакансией в нашей команде .

Источник: openai.com