Поделиться через

Создание контейнеров и баз данных Azure Cosmos DB с пропускной способностью автомасштабирования

Область применения: NoSQL Mongodb Кассандра Гремлин Таблица

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

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

Преимущества автоматического масштабирования

Базы данных и контейнеры Azure Cosmos DB, настроенные с автомасштабированием подготовленной пропускной способности, имеют следующие преимущества:

  • Просто: Автомасштабирование упрощает управление числом запросов в секунду (RU/s), избавляя от необходимости использовать пользовательские сценарии или вручную масштабировать емкость.

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

  • Экономичность: Автомасштабирование помогает оптимизировать использование RU/s и сократить расходы, снижая масштаб в периоды простоя. Вы платите только за те ресурсы, которые нужны вашим рабочим нагрузкам, на почасовой основе. Из всех часов в месяц, если вы устанавливаете максимальное значение ЕЗ/с (Tmax) и используете полную сумму Tmax в течение 66 % часов или меньше, можно сэкономить с автомасштабированием. Помимо динамического масштабирования, добавление дополнительного региона для обеспечения высокой доступности является более экономичным, так как каждый регион и секции масштабируются независимо на основе фактического использования. См. дополнительную информацию в статье о том, как выбрать между стандартной (ручной) настройкой пропускной способности и автомасштабированием.

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

Сценарии использования автомасштабирования

Возможные случаи использования автомасштабирования включают:

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

  • Новые приложения. Если вы разрабатываете новое приложение и вам неизвестна требуемая пропускная способность (число единиц запросов в секунду), автомасштабирование упростит начальный этап работы. Можно начать с точки входа автомасштабирования в 100 – 1000 RU/s, отслеживать использование и определить оптимальное значение RU/s со временем.

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

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

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

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

Варианты использования динамического масштабирования

Ниже описаны варианты использования динамического масштабирования.

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

Как работает предоставляемая автомасштабируемая пропускная способность

При настройке контейнеров и баз данных с автомасштабированием указывается максимальная требуемая пропускная способность Tmax. Azure Cosmos DB масштабирует пропускную способность T таким образом 0.1*Tmax <= T <= Tmax. Например, если задана максимальная пропускная способность 20 000 ЕЗ/с, пропускная способность масштабируется в диапазоне от 2000 до 20 000 ЕЗ/с. Поскольку масштабирование происходит автоматически и мгновенно, в любой момент времени вы можете использовать до предусмотренного объёма Tmax без задержки.

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

Точка входа для настройки максимальной пропускной способности автомасштабирования Tmax начинается с 1000 ЕЗ/с, обеспечивая масштабирование в диапазоне от 100 до 1000 ЕЗ/с. Можно задать Tmax с шагом в 1000 единиц запросов в секунду (RU/s) и в любое время изменить это значение.

Например, если у нас есть коллекция с 1000 ЕЗ/с и 2 разделами, каждый раздел может поддерживать до 500 ЕЗ/с. За один час активности использование будет выглядеть следующим образом:

Область/регион Раздел Пропускная способность Загруженность Примечания.
Написать П1 <= 500 RU/с 100% 500 ЕЗ/с, из которых 50 ЕЗ/с используются для операций записи и 450 ЕЗ/с — для операций чтения.
Написать P2 <= 200 руб./с 40% 200 ЕЗ/с, состоящие из всех операций чтения.
Читать П1 <= 150 ЕЗ/с 30% 150 ЕЗ/с, из которых 50 ЕЗ/с используются для записи, реплицируемой из региона записи. 100 RU/с для операций чтения в этом регионе.
Читать P2 <= 50 RU/с 10%

Без динамического масштабирования все секции масштабируются равномерно на основе самой горячей секции. В этом примере, так как самый горячий раздел имел 100 % использования, все секции в регионах записи и чтения масштабируются до 1000 ЕЗ/с, что делает общее число единиц запросов в секунду до 2000 ЕЗ/с.

При динамическом масштабировании, так как пропускная способность каждого раздела и региона масштабируется независимо, общий объем единиц запросов в секунду, до которого масштабируется система, составляет 900 ЕЗ/с, что лучше отражает фактический шаблон трафика и снижает затраты.

Включение автомасштабирования для существующих ресурсов

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

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

Для любого значения Tmax в базе данных или контейнере может храниться всего 0.1 * Tmax GB. После достижения этого объема хранилища максимальное значение RU/с будет автоматически увеличено на основе нового объема, не влияя на ваше приложение.

Например, если вы начинаете с максимальной производительности 50 000 ЕЗ/с (масштабируется в диапазоне от 5000 до 50 000 ЕЗ/с), вы можете хранить до 5000 ГБ данных. Если вы превысили 5000 ГБ, например, когда объём хранения составляет 6000 ГБ, новое максимальное значение ЕЗ/с будет равно 60 000 ЕЗ/с, с масштабом от 6000 до 60 000 ЕЗ/с.

При использовании пропускной способности на уровне базы данных с автомасштабированием первые 25 контейнеров могут совместно использовать максимум 1000 RU/c (масштабируется от 100 до 1000 RU/c), при условии, что вы не превышаете 100 ГБ хранилища. Дополнительные сведения см. в этой документации.

Включение динамического масштабирования

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

  1. Перейдите к учетной записи Azure Cosmos DB в портал Azure.

  2. Перейдите на страницу "Компоненты ".

  3. Найдите и включите функцию динамического масштабирования (для каждого региона и автомасштабирования секций).

    Снимок экрана функции

    Внимание

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

Мониторинг метрик

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

Имя метрики Определение Использование метрик
Подготовленная пропускная способность Отображает агрегированное максимальное число ЕЗ/с, приведённое к часовому интервалу, и отображает общее число ЕЗ/с, после масштабирования в течение часа. Вы можете использовать Provisioned Throughput метрику, чтобы увидеть, сколько RU/с взимается с вас за каждый час. С автомасштабированием оплата осуществляется на основе наиболее активного раздела в течение каждого часа, и то же самое применяется ко всем разделам и регионам. С динамическим автомасштабированием вам выставляется счет за максимальные агрегированные RU/с, масштабированные в течение каждого часа на уровне каждого раздела и региона.
Нормализованное потребление RU Эта метрика представляет собой соотношение потребляемых единиц запросов в секунду к предоставленным единицам запросов в секунду на каждом уровне раздела и региона. Используйте эту метрику, чтобы определить, является ли максимальная пропускная способность автомасштабирования недостаточной или избыточной.

Если значение метрики постоянно составляет 100% и приложение сталкивается с ограничением скорости (код ошибки 429), может потребоваться больше RU/s. В отличие от этого, если значение этой метрики низкое и нет ограничения скорости, то может быть возможность для оптимизации и уменьшения единиц запроса в секунду (ЕЗ/с). Узнайте, как интерпретировать и устранять ошибки ограничения скорости код 429.

Normalized RU Consumption Метрика отражает RU/с, потребляемые в вторичном регионе из-за записи трафика репликации из основного региона, а также любого трафика чтения в этом регионе.
Автомасштабированный РУ Отображает динамически масштабируемую подготовленную пропускную способность на каждом уровне секции и региона только для учетных записей с поддержкой динамического автомасштабирования. Используйте эту метрику, чтобы узнать, как секции в каждом регионе масштабируются независимо от их использования.

Используйте метрики Azure Monitor для анализа применения нового автомасштабирования в различных разделах и регионах. Отфильтруйте нужную учетную запись базы данных и контейнер, а затем отфильтруйте или разделите по метрике Physical PartitionID. Эта метрика отображает все разделы в их различных регионах.

Внимание

Рекомендуется использовать собственные возможности динамического масштабирования Azure Cosmos DB для управления емкостью. Однако при необходимости в Azure Monitor можно использовать метрику нормализованного потребления единиц запросов (RU) для принятия решений по программному масштабированию. Другие подходы, такие как вызов ReadThroughputAsync() в SDK для Azure Cosmos DB для получения предоставленной пропускной способности или использование ProvisionedThroughput в Azure Monitor, не рекомендуются и приведут к неточным результатам. Эти метрики представляют оплачиваемую пропускную способность с задержкой и не следует использовать для принятия решений по масштабированию.

Сравнение — контейнеры, настроенные с масштабируемой вручную или автомасштабируемой пропускной способностью

Дополнительные сведения см. в этой документации, описывающей выбор между стандартно (вручную) масштабируемой и автомасштабируемой пропускной способностью.

Контейнеры со стандартно (вручную) масштабируемой пропускной способностью Контейнеры с автомасштабируемой пропускной способностью
Подготовленная пропускная способность (единиц запросов в секунду) Настроено вручную. Масштабируемая автоматически и мгновенно на основе моделей использования рабочих нагрузок.
Ограничение скорости запросов и операций (429) Это возможно, если потребление превышает подготовленную емкость. Не произойдет, если вы используете RU/с в рамках диапазона пропускной способности, настроенного для автомасштабирования.
Планирование ресурсов Необходимо выполнить планирование емкости и задать необходимую пропускную способность. Система автоматически принимает меры по планированию ресурсов и управлению емкостью.
Цены Вы оплачиваете вручную предоставленные единицы запросов в секунду (ЕЗ/с) за час, используя стандартный тариф за оплату вручную предоставленных ЕЗ/с в час. Вы платите за самый высокий показатель RU/с, до которого система масштабировалась в течение часа.

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

За учетные записи с несколькими регионами записи не взимается дополнительная плата за автомасштабирование. Вы платите за использование пропускной способности почасово, используя одну и ту же ставку записи RU/s для нескольких регионов.

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

Перевод стандартной предоставленной пропускной способности на автомасштабирование

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

Следующие шаги