Как OpenAI удержала Azure Cosmos DB под нагрузкой 1 млрд пользователей ChatGPT

Habitat — это внутренняя платформа хранения данных OpenAI, через которую проходят запросы ChatGPT, API, Codex и десятков внутренних сервисов. Она должна отвечать за миллисекунды, обслуживая больше миллиарда пользователей по всему миру, и хранит свыше 500 петабайт данных. Основной движок под капотом — Azure Cosmos DB. Инженеры OpenAI Джон Ли, Грачья Акопян и Чаомин Юй описали, как три раза перестраивали принцип распределения нагрузки между продуктами внутри этой базы, прежде чем нашли рабочую схему.

Проблема общей базы и «шумных соседей»

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

• Разные продукты, использующие одинаковые по смыслу ключи (например, user_id), делили между собой этот лимит, хотя логически не должны были пересекаться.
• Если один клиент резко увеличивал нагрузку на «свой» раздел, страдали вообще все остальные пользователи и фичи, чьи данные случайно лежали рядом — вплоть до сбоев входа в систему.

Дополнительно обнаружилась проблема «слабых разделов»: когда раздел диска разрастался и Cosmos DB делила его на два, пропускная способность каждого делилась пополам — то есть рост объёма данных сам по себе снижал скорость, даже если число запросов не менялось.

Изоляция через отдельные базы — и её цена

Решением стало создание отдельных баз для каждого крупного нового продукта или фичи. Это действительно убрало эффект «шумных соседей» — теперь перегрузка одного сервиса не сбивала остальные. Но у подхода оказалась обратная сторона:

• Команды продуктов должны были сами заранее заказывать нужную пропускную способность под запуск — и часто забывали это делать, из-за чего запуски сопровождались экстренными совещаниями по масштабированию в последний момент.
• Нагрузка, которая в общей базе была бы незаметной каплей (рост с 1 тысячи до миллиона запросов в секунду — это всего 5% от общей ёмкости), в отдельной базе могла составлять тысячекратное превышение запланированных ресурсов.
• Планирование капасити размылось по всей компании вместо одной центральной команды, и качество этого планирования сильно разнилось от команды к команде.

Возврат к общей базе — но с умной балансировкой

Поняв, что ни один из подходов не масштабируется организационно, команда Habitat вместе с инженерами Microsoft переработала саму механику Cosmos DB:

• Добавили троттлинг самых «горячих» ключей в первую очередь — так, чтобы один агрессивный клиент не мог забрать всю пропускную способность раздела.
• Ввели приоритизацию запросов (QoS): фоновые задачи вроде массовых выгрузок данных теперь обрезаются первыми, а интерактивные запросы пользователей — в последнюю очередь.
• Вместе с Azure доработали бессерверный режим Cosmos DB, поднявший лимит с 5 до 10 тысяч операций в секунду на раздел и добавивший автоматическое разделение по нагрузке, а не только по объёму данных.

Это позволило вернуться к одной общей базе без ручного планирования капасити — и, по словам авторов, за несколько месяцев после перехода не было ни одной аварии из-за перегрузки или «шумных соседей».

Совместная инженерия с Microsoft

Крупнейший аккаунт Cosmos DB у OpenAI хранит десятки петабайт и держит более 20 миллионов запросов в секунду — авторы называют это крупнейшим известным им развёртыванием сервиса. На таком масштабе типовая поддержка облачного провайдера перестаёт работать: в конце 2024 года авария с электропитанием в одном из регионов показала, что переключение на резервный регион для аккаунтов такого размера занимает несколько часов — это никто не тестировал на подобных объёмах. Месяц позже при обратном переключении возникла вторая авария: клиенты массово ринулись переподключаться к исходному региону и перегрузили его шлюз, хотя туда вернулась лишь часть данных.

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

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