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

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

Эта серия из двух частей объясняет, как мы развили Habitat из простой клиентской библиотеки и базы данных в глобально распределенную платформу хранения, обслуживающую более 500 петабайт данных. Часть I была посвящена эволюции Habitat от Python-клиента до полноценного сервиса. В ней также рассматривались методы, которые позволили нам вывести сервис на базе Python далеко за пределы того, что многие считали практичным.

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

Рисунок 01 · Что такое Habitat?

Платформа онлайн-хранилища

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

• Запрос
• Ответ
• Изменения (CDC)

Обеспечение надежности многопользовательской архитектуры в масштабе

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

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

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

Упрощенный букварь по контейнерам Azure Cosmos DB

Прежде чем перейти к нашему пути в Azure Cosmos DB, немного базового контекста:

• Учетная запись Azure Cosmos DB определяет набор контейнеров и политику репликации

Учетная запись Azure Cosmos DB определяет набор контейнеров и политику репликации

• Каждый контейнер подготавливается для определенного объема пропускной способности в единицах запроса в секунду (RU/s)

Каждый контейнер подготавливается для определенного объема пропускной способности в единицах запроса в секунду (RU/s)

• Данные внутри каждого контейнера хранятся обычным способом шардирования по указанному ключу логического раздела с документированными ограничениями на хранение и пропускную способность для каждого ключа логического раздела

Данные внутри каждого контейнера хранятся обычным способом шардирования по указанному ключу логического раздела с документированными ограничениями на хранение и пропускную способность для каждого ключа логического раздела

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

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

Фаза I: Опора на примитивы Azure Cosmos DB

Изначально мы разрешали любую клиентскую нагрузку, полагаясь на заявленный лимит в 10 тыс. RU/s на ключ логического раздела для обеспечения обратного давления. Когда мы только начинали, мы также использовали только один контейнер Azure Cosmos DB по умолчанию в каждой учетной записи. Это работало достаточно хорошо, но оказалось проблематичным по нескольким причинам:

Ограничения ключей логических разделов

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

Одной из распространенных проблем, с которой мы столкнулись при масштабировании Postgres до перехода на Habitat и Azure Cosmos DB, была способность множества запросов от очень «горячей» организации или «горячего» ключа — одного арендатора, создающего непропорционально высокую нагрузку — вывести из строя всю базу данных. Значительные коллективные усилия были потрачены на кэширование этих ключей и создание механизмов аренды при промахах кэша, чтобы возникающая нагрузка от промахов кэша не перегружала базовую базу данных.

Рисунок 02a · Ограничения ключей логических разделов

Разные клиенты, один и тот же ключ раздела

Шумные соседи

Хотя документированные ограничения на размер данных и пропускную способность применяются к ключам логических разделов, ограничения фактически применяются на уровне физического раздела. На практике это означает, что логические разделы не могут достичь 10 000 RU/s. Вместо этого они делят ограничения физического раздела с каждым другим ключом логического раздела, размещенным на этом физическом разделе.

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

Рисунок 02b · Шумные соседи

Разные пользователи, один и тот же физический раздел

Слабые разделы

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

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

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

Рисунок 02C · Слабые разделы

Лимит падает ниже спроса

Раздел разделяется при достижении лимита хранения. Каждый потомок получает половину пропускной способности.

Фаза II: Попытка изоляции рабочей нагрузки и одноарендности

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

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

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

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

Отсутствие стабильного совокупного роста

В старом общем контейнере по умолчанию любой отдельно взятый новый сценарий использования, переходящий от 0 QPS к 1 миллиону QPS, вряд ли мог существенно изменить общий совокупный объем использования. Однако в изолированном контейнере новый сценарий использования, переходящий от 0 до 1 миллиона QPS, может представлять нагрузку в 1000 раз превышающую базовую, обусловленную только внутренним использованием (dogfooding).

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

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

Рисунок 03 · Отсутствие стабильного совокупного роста

Такая же рабочая нагрузка, разный запас

1 тыс. ЕЗ/с при нагрузочном тестировании → 1 млн ЕЗ/с при запуске

Планирование емкости

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

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

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

Фаза III: Использование многоарендности по умолчанию с возможностью перемещения данных

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

Регулирование горячих ключей

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

Качество обслуживания (QoS)

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

Серверный режим

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

Новый улучшенный серверный режим, созданный для нас командой Azure Cosmos DB, позволил каждому физическому разделу масштабироваться до 10 тыс. ЕЗ/с и представил разделение на основе использования ЕЗ в дополнение к разделению на основе использования хранилища, что позволило нам прекратить мониторинг и ручное масштабирование контейнеров.

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

Повышение надежности в качестве совместно управляемых сервисов

Когда компании вырастают до масштабов OpenAI, управляемые сервисы перестают быть таковыми в полной мере. Многие рабочие нагрузки становятся нестандартными в инфраструктуре облачного провайдера. Поскольку OpenAI стала одним из крупнейших пользователей Azure Cosmos DB, ее успешная эксплуатация потребовала иной модели: общих тестов, общих панелей мониторинга, прямых инженерных каналов и совместной ответственности за режимы сбоев, которые проявляются только в нашем масштабе. Сегодня наш крупнейший аккаунт Azure Cosmos DB хранит десятки петабайт данных и обслуживает более 20 млн QPS. Насколько нам известно, мы являемся единственной компанией, развернувшей Azure Cosmos DB в таком масштабе.

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

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

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

Сегодня инженерные команды Habitat и Azure совместно мониторят каждый слой Habitat — от наших сервисных слоев до физических уровней хранения Azure Cosmos DB. Мы эксплуатируем систему и тестируем изменения на учетной записи Azure Cosmos DB производственного размера, но не используемой в продакшене. Мы вместе тестируем и итеративно улучшаем SDK, а также определяем лучшие практики масштабирования и определения размера наших учетных записей Azure Cosmos DB. У нас есть прямой инженерный доступ друг к другу через Teams, и мы даже настроили возможность напрямую вызывать друг друга по пейджеру, минуя уровни поддержки.

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

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

Повышение производительности в глобальном масштабе

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

Вычислительная мощность и емкость хранилища часто располагались в разных регионах, что делало межрегиональные запросы неизбежными.

Рисунок 04 · Повышение производительности в глобальном масштабе

Глобальный трафик

Вычислительная мощность и емкость хранилища часто располагались в разных регионах, что делало межрегиональные запросы неизбежными.

ВычисленияХранилищеИллюстративные маршруты · Более длинные пути занимают больше времени

Географическое расположение вычислений и хранилища приведено исключительно в иллюстративных целях.

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

Это было большим фокусом для нас в 2026 году, и мы разработали многоуровневую стратегию оптимизации производительности чтения, на которую приходится более 90% запросов Habitat:

Хранение данных рядом с пользователями при наличии емкости

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

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

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

В результате решения о размещении часто представляют собой продуктовый компромисс между: А) оптимизацией задержки для различных продуктов и подмножеств пользователей и Б) сырой емкостью хранилища и вычислений.

Широкая репликация только самых маленьких и чувствительных к задержке наборов данных

Для наиболее критичных к задержке рабочих нагрузок, таких как метаданные аутентификации, которые необходимы при каждом запросе, мы сокращаем RTT между вычислениями и Habitat, используя высокореплицированные учетные записи Azure Cosmos DB со множеством вторичных регионов. Некоторые учетные записи реплицируются во все 40 регионов Azure, где мы обслуживаем трафик; другие реплицируются как минимум в один регион на каждом континенте.

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

Тем не менее этот подход в конечном итоге также ограничен емкостью и поэтому применим лишь к нескольким специально отобранным наборам данных.

Опора на интегрированное кэширование для всего остального

Рабочие нагрузки Habitat в подавляющем большинстве состоят из операций чтения: приложения постоянно запрашивают настройки, состояние и другие свойства; непропорционально большая доля трафика приходится на относительно небольшой рабочий набор часто используемых типов. Это делает систему особенно хорошо подходящей для распределенного кэширования. Хотя кэширование повышает производительность в инфраструктуре одного региона, этот эффект многократно усиливается при работе в нескольких регионах, где его можно использовать для «скрытия» межрегиональной задержки.

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

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

Мы применили более продвинутый подход к инвалидации, пойдя по стопам таких систем, как TAO от Meta. Интегрированный кэш Habitat опирается на захват измененных данных (CDC) через ленту изменений Azure Cosmos DB для глобального распространения инвалидаций в течение нескольких секунд, достигая высоких показателей попадания в кэш при минимальном устаревании данных. Сервис в нашей инфраструктуре обрабатывает эту ленту изменений и выполняет инвалидацию локальных кэшей при обновлении базовых данных. Это приводит к промаху при следующем чтении данных, и кэш заполняется последней версией данных.

Снижение накладных расходов прокси с помощью Rust

Мы также значительно снизили задержку, устранив накладные расходы в самом сервисе Habitat путем переписывания кода на Rust, который работает производительнее исходного Python.

В совокупности эти изменения позволили снизить общую глобальную медианную задержку (p50) чтения примерно со 120 мс до примерно 10 мс, что представляет собой 12-кратное улучшение с тех пор, как в начале этого года мы начали уделять особое внимание производительности.

Рисунок 05 · Повышение производительности в глобальном масштабе

Задержка p50 для чтения

Три важных изменения в дизайне улучшили задержку чтения

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

Масштабирование захвата измененных данных (CDC)

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

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

Взгляд в будущее

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