Стремительное масштабирование онлайн-хранилища для обслуживания более 1 миллиарда пользователей ChatGPT11.09.2026 10:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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