OpenAI переписала хранилище Habitat: 500 ПБ данных и 1 млрд пользователей на Cosmos DB

Платформа Habitat, на которой держатся ChatGPT, API, Codex и внутренние сервисы OpenAI, обслуживает более 1 млрд пользователей в 40 географических регионах и хранит свыше 500 петабайт данных. Ответ нужен за миллисекунды. Во второй части инженерного разбора Jon Lee, Hrachya Hakobyan и Chaomin Yu рассказали, как команда выжимала максимум из Azure Cosmos DB, прошла через три модели мультитенантности и в итоге вернулась к одному общему контейнеру.

Фаза I: общий контейнер и три системные проблемы

Сначала OpenAI пускала любую клиентскую нагрузку и полагалась на документированный лимит Cosmos DB в 10K RU/s на логический ключ партиции как на естественный back pressure. Контейнер в каждом аккаунте был один, по умолчанию. Работало, пока масштаб не вскрыл три проблемы.

Первая: из-за ранних решений по API выбор ключа партиции отдали клиентам. Популярные ключи, такие как user_id или workspace_id, пересекались у разных продуктовых сценариев, и те делили лимит одного ключа. Вторая: лимиты реально применяются на уровне физической партиции, поэтому логический ключ до 10 000 RU/s не дотягивается, а соседи по партиции мешают друг другу. Побочные фичи задевали критичные потоки логина и регистрации. Третья: пропускная способность контейнера делится поровну между физическими партициями. Когда данные растут и партиции делятся, суммарный провижининг остаётся прежним, а лимит на партицию падает. Для тяжёлых blob-подобных сценариев рост хранилища сам по себе снижал доступную пропускную способность при стабильном трафике.

Фаза II: изоляция, которая не масштабировалась организационно

Отдельные контейнеры решали часть проблем. У каждого свои физические партиции, а шумными соседями могут быть только нагрузки внутри него. Для критичных новых сценариев контейнеры выделяли, а скрипт синхронизировал провижининг с числом физических партиций и лечил слабые партиции. Это спасло от общесайтовых аварий: сбои ограничивались деградацией фичи или сервиса.

Но накладные расходы росли. Главная причина: в общем контейнере переход нового сценария с 0 до 1 млн QPS почти не двигал агрегат. В выделенном контейнере на 10K RU/s тот же скачок с 1K RU/s при нагрузочном тесте до 1M RU/s на запуске означал 10 000% от запаса, тогда как в общем контейнере на 100M RU/s при 80% загрузки он занимал около 5%. Команды выпускали фичи и забывали заранее масштабироваться, а в день запуска инженеры сидели в SEV-комнатах. Планирование ёмкости требовало знания продукта от каждой команды, и качество этой работы сильно различалось.

Фаза III: возврат к общему контейнеру вместе с Azure

OpenAI вернулась к мультитенантности по умолчанию и совместно с командой Azure устранила исходные недостатки:

• Hot key throttling. Троттлинг самых горячих ключей в первую очередь не даёт одному ключу съесть всю пропускную способность физической партиции.
• Quality of Service. Многоуровневые запросы: офлайн-нагрузки вроде bulk-вставок и выгрузок получают низкий приоритет и троттлятся первыми, интерактивный трафик пользователей остаётся нетронутым.
• Новый serverless-режим. Прежний масштабировался только по хранилищу и ограничивал 5K RU/s на физическую партицию. Новый разрешает каждой партиции расти до 10K RU/s и добавляет сплиты по RU-нагрузке в дополнение к сплитам по объёму. Ручной мониторинг и поднятие провижининга больше не нужны.

Итог: один общий контейнер, сильно упрощённое планирование ёмкости для продуктовых команд и сохранённая изоляция нагрузок. За месяцы после перехода не было инцидентов с провижинингом или шумными соседями, хотя разработка продуктов ускорилась.

Что можно забрать себе

Историю OpenAI полезно прочитать как чек-лист для любой команды, строящей общую платформу данных.

• Не отдавайте клиентам выбор ключа партиции. Этот ранний API-выбор потом пришлось компенсировать целой инфраструктурой.
• Следите за эффективным лимитом на физическую партицию, а не на логический ключ. При сплитах он падает без изменения трафика.
• Изоляция контейнерами дорога организационно: каждая команда становится планировщиком ёмкости, и стабильного агрегатного роста больше нет.
• Приоритизируйте трафик. Bulk-вставки и выгрузки должны троттлиться раньше пользовательских запросов.
• Если масштаб большой, добивайтесь доработок у вендора. OpenAI получила специальный serverless-режим от Azure, а не обошла ограничения на своей стороне.

Сама OpenAI называет себя в мультитенантности ещё в начале пути. Но пока выигрыш очевиден: меньше SEV-комнат при запусках и меньше ручной работы у продуктовых команд.