Создание контейнеров и баз данных Azure Cosmos DB с пропускной способностью автомасштабирования
Область применения: Nosql Mongodb Кассандра Гремлин Таблица
В Azure Cosmos DB вы можете настроить подготовленную пропускную способность со стандартным (выполняемым вручную) масштабированием или автомасштабированием для баз данных и контейнеров. Автомасштабирование подготовленной пропускной способности в Azure Cosmos DB позволяет автоматически и мгновенно масштабировать пропускную способность (количество единиц запросов в секунду) для базы данных или контейнера.
Подготовленная автомасштабируемая пропускная способность оптимальна для критически важных рабочих нагрузок с переменными или непредсказуемыми моделями трафика, и для высокой производительности и масштабирования в данном случае требуется соглашение об уровне обслуживания. Автомасштабирование по умолчанию масштабирует рабочие нагрузки на основе наиболее активного региона и секции. Для неуниформных рабочих нагрузок, имеющих разные шаблоны рабочих нагрузок в разных регионах и секциях, это масштабирование может привести к ненужным масштабированиям. Динамическое масштабирование или динамическое автомасштабирование — это улучшение автомасштабирования, подготовленное на протяжении всего процесса, которое помогает масштабировать такие неуниформные рабочие нагрузки независимо на основе использования, на каждом регионе и на уровне секции. Динамическое масштабирование позволяет сэкономить затраты, если часто возникают горячие секции и (или) несколько регионов.
Преимущества автомасштабирования
Базы данных и контейнеры Azure Cosmos DB, настроенные с автомасштабированием подготовленной пропускной способности, имеют следующие преимущества:
Простота. Автомасштабирование снижает сложность управления числом единиц запросов в секунду за счет пользовательских сценариев или масштабирования емкости вручную.
Масштабируемость. Базы данных и контейнеры автоматически масштабируют подготовленную пропускную способность по мере необходимости. Нет нарушений клиентских подключений, приложений или соглашений об уровне обслуживания Azure Cosmos DB.
Экономичность. Автомасштабирование помогает оптимизировать число единиц запросов в секунду и затраты за счет уменьшения масштаба в период неактивности. Вы платите только за ресурсы, потребляемые в час для рабочей нагрузки. Из всех часов в месяц, если вы устанавливаете максимальное значение ЕЗ/с (Tmax) и используете полную сумму Tmax в течение 66 % часов или меньше, можно сэкономить с автомасштабированием. Помимо динамического масштабирования, добавление дополнительного региона для обеспечения высокой доступности является более экономичным, так как каждый регион и секции масштабируются независимо на основе фактического использования. Дополнительные сведения см. в статье о том, как сделать правильный выбор между стандартной (ручной) подготовкой пропускной способности и автомасштабированием.
Высокий уровень доступности. Базы данных и контейнеры, для которых применяется автомасштабирование, используют одинаковую глобально распределенную, отказоустойчивую, высокодоступную серверную часть Azure Cosmos DB для обеспечения надежности и высокой доступности данных.
Сценарии использования автомасштабирования
Существуют следующие варианты использования автомасштабирования.
Переменные или непредсказуемые рабочие нагрузки. Если рабочие нагрузки предполагают переменные или непредсказуемые пиковые значения, автомасштабирование помогает сгладить пики за счет масштабирования по мере использования. В качестве примера можно привести интернет-магазины розничной торговли, в которых модели трафика меняются в зависимости от сезонности; рабочие нагрузки IOT с пиковыми значениями в разные моменты времени; бизнес-приложения, достигающие пиковых значений несколько раз в месяц или в год, и т. д. При использовании автомасштабирования больше не придется вручную подготавливать емкость для пиковых или средних нагрузок.
Новые приложения. Если вы разрабатываете новое приложение и вам неизвестна требуемая пропускная способность (число единиц запросов в секунду), автомасштабирование упростит начальный этап работы. Можно начать с точки входа автомасштабирования в 100 – 1000 ЕЗ/с, отслеживать использование и определять правильные ЕЗ/с с течением времени.
Редко используемые приложения: если у вас есть приложение, которое используется только в течение нескольких часов в день, неделю или месяц, например низкое количество приложений или веб-сайтов или блогов. Автомасштабирование настраивает емкость для обработки пикового использования и масштабирования при его завершении.
Разработка и тестирование рабочих нагрузок. Если вы или ваша команда используете базы данных и контейнеры Azure Cosmos DB в рабочее время, но не требует их в ночное время или в выходные дни, автомасштабирование помогает сэкономить затраты, уменьшая до минимума, если они не используются.
Запланированные производственные рабочие нагрузки/запросы. При наличии серии запланированных запросов или операций, которые необходимо выполнить во время простоя, можно легко сделать это с помощью автомасштабирования. Когда необходимо запустить рабочую нагрузку, пропускная способность автоматически масштабируется до необходимого значения и масштабируется после этого.
Создание настраиваемого решения для устранения этих проблем не только отнимает много времени, но также приводит к усложнению конфигурации или кода приложения. Автомасштабирование позволяет выполнять указанные выше сценарии и устраняет необходимость в настраиваемом или ручном масштабировании емкости.
Варианты использования динамического масштабирования
Ниже описаны варианты использования динамического масштабирования.
- Рабочие нагрузки базы данных с высоким уровнем трафика к основному региону и вторичному пассивному региону для аварийного восстановления.
- Благодаря динамическому масштабированию обеспечение высокой доступности с несколькими регионами является более экономичным. Дополнительный регион независимо и автоматически масштабируется во время простоя. Дополнительный регион также автоматически масштабируется по мере того, как он становится активным и при обработке трафика репликации записи из основного региона.
- Рабочие нагрузки базы данных с несколькими регионами.
- Эти рабочие нагрузки часто наблюдают неравномерное распределение запросов по регионам из-за естественного роста трафика и падения трафика в течение дня. Например, база данных может быть активной в рабочие часы в глобальных распределенных часовых поясах.
Принципы работы подготовленной автомасштабируемой пропускной способности
При настройке контейнеров и баз данных с автомасштабированием указывается максимальная требуемая пропускная способность Tmax
. Azure Cosmos DB масштабирует пропускную способность T
таким образом 0.1*Tmax <= T <= Tmax
. Например, если задана максимальная пропускная способность 20 000 ЕЗ/с, пропускная способность масштабируется в диапазоне от 2000 до 20 000 ЕЗ/с. Поскольку масштабирование происходит автоматически и мгновенно, выполнение всех запросов в пределах подготовленной пропускной способности Tmax
осуществляется без задержки.
Каждый час взимается плата за максимальную пропускную способность T
системы, масштабируемой в течение часа. При включении динамического масштабирования масштабирование зависит от использования единиц запросов в секунду на каждом физическом разделе и регионе. Так как каждый раздел и регион масштабируются независимо друг от друга, это может привести к экономии затрат для неуниформных рабочих нагрузок, так как не требуется масштабирование.
Точка входа для максимальной пропускной способности автомасштабирования Tmax
начинается с 1000 ЕЗ/с, которая масштабируется от 100 до 1000 ЕЗ/с. Можно задать Tmax
с шагом в 1000 единиц запросов в секунду и в любое время изменить это значение.
Например, если у нас есть коллекция с 1000 ЕЗ/с и 2 секциями, каждая секция может перейти до 500 ЕЗ/с. В течение одного часа действия использование будет выглядеть следующим образом:
Область/регион | Секция | Пропускная способность | Загруженность | Примечания. |
---|---|---|---|---|
Write | P1 | <= 500 ЕЗ/с | 100% | 500 ЕЗ/с, состоящих из 50 ЕЗ/с, используемых для операций записи и 450 ЕЗ/с для операций чтения. |
Write | P2 | <= 200 ЕЗ/с | 40% | 200 ЕЗ/с, состоящие из всех операций чтения. |
Читать | P1 | <= 150 ЕЗ/с | 30% | 150 ЕЗ/с, состоящих из 50 ЕЗ/с, используемых для записи, реплицированной из области записи. 100 ЕЗ/с используются для операций чтения в этом регионе. |
Читать | P2 | <= 50 ЕЗ/с | 10% |
Без динамического масштабирования все секции масштабируются равномерно на основе самой горячей секции. В этом примере, так как самый горячий раздел имел 100 % использования, все секции в регионах записи и чтения масштабируются до 1000 ЕЗ/с, что делает общее число единиц запросов в секунду до 2000 ЕЗ/с.
При динамическом масштабировании, так как пропускная способность каждой секции и региона масштабируется независимо, общий объем единиц запросов в секунду составляет 900 ЕЗ/с, что лучше отражает фактический шаблон трафика и снижает затраты.
Включение автомасштабирования для существующих ресурсов
Включить автомасштабирование для существующей базы данных или контейнера можно на портале Azure, а также с помощью CLI или PowerShell. Вы также можете в любое время переключаться между автомасштабированием и стандартной пропускной способностью, подготовленной вручную. Дополнительные сведения см. в этой документации .
Ограничения пропускной способности и хранилища при использовании автомасштабирования
Для любого значения Tmax
в базе данных или контейнере может храниться всего 0.1 * Tmax GB
. После достижения этого объема хранилища максимальное значение ЕЗ/с будет автоматически увеличиваться на основе нового значения хранилища, не влияя на приложение.
Например, если начать с максимального ЕЗ/с 50 000 ЕЗ/с (масштабируется от 5000 до 50 000 ЕЗ/с), можно хранить до 5000 ГБ данных. Если вы превышаете 5000 ГБ , например, хранилище составляет 6000 ГБ, новое максимальное значение ЕЗ/с становится 60 000 ЕЗ/с (масштабируется в диапазоне от 6000 до 60 000 ЕЗ/с).
При использовании пропускной способности на уровне базы данных с автомасштабированием первые 25 контейнеров могут совместно использовать автомасштабирование максимум ЕЗ/с 1000 (масштабируется от 100 до 1000 ЕЗ/с), если не превышает 100 ГБ хранилища. Дополнительные сведения см. в этой документации.
Включение динамического масштабирования
Динамическое масштабирование включено по умолчанию для всех учетных записей Azure Cosmos DB, созданных после 25 сентября 2024 г. Клиенты, желающие включить эту функцию для более старых учетных записей, могут сделать это программным способом с помощью Azure PowerShell/CLI/Rest API или из области функций портал Azure, как показано ниже.
Перейдите к учетной записи Azure Cosmos DB в портал Azure.
Перейдите на страницу "Компоненты ".
Найдите и включите функцию динамического масштабирования (для каждого региона и автомасштабирования секций).
Внимание
Эта функция включена на уровне учетной записи, поэтому все контейнеры автомасштабирования и базы данных общей пропускной способности в учетной записи будут автоматически применены. Включение этой функции не влияет на ресурсы в учетной записи, использующую пропускную способность вручную. Чтобы воспользоваться преимуществами динамического масштабирования, необходимо изменить ресурсы вручную на автомасштабирование. Включение этой функции имеет нулевое время простоя или влияние на производительность. Эта функция неприменима для бессерверных учетных записей.
Мониторинг метрик
Для мониторинга автомасштабирования и динамического масштабирования можно использовать следующие метрики:
Имя метрики | Определение | Использование метрик |
---|---|---|
Подготовленная пропускная способность | Отображает агрегированный максимальный размер ЕЗ/с, масштабируемый в течение часа, и представляет общее число единиц запросов в секунду в течение часа. | Вы можете использовать Provisioned Throughput метрику, чтобы просмотреть счета за ЕЗ/с, которые выставляются за каждый час. С автомасштабированием счета выставляются на основе наиболее активной секции в течение каждого часа, и то же самое применяется ко всем секциям и регионам. С динамическим автомасштабированием выставляются счета за агрегированные ЕЗ/с, масштабируемые в каждый час на каждом уровне секции и региона. |
Нормализованное потребление ЕЗ | Эта метрика представляет соотношение потребляемых единиц запросов в секунду на подготовленные ЕЗ/с на каждом уровне секции и региона. | Используйте эту метрику, чтобы определить, находится ли максимальная пропускная способность автомасштабирования в ней или не подготовлена. Если значение метрики стабильно равно 100 % и приложение видит ограничение скорости (код ошибки 429), может потребоваться больше единиц запросов в секунду. В отличие от этого, если это значение метрики низко, и нет ограничения скорости, то может быть место для оптимизации и масштабирования ЕЗ/с. Узнайте, как интерпретировать и отлаживать код 429 скорости ограничения ошибок. Normalized RU Consumption Метрика отражает ЕЗ/с, потребляемые в дополнительном регионе, из-за записи трафика репликации из основного, в дополнение к любому трафику чтения в дополнительном регионе. |
Автомасштабирование единиц запросов | Отображает динамически масштабируемую подготовленную пропускную способность на каждом уровне секции и региона только для учетных записей с поддержкой динамического автомасштабирования. | Используйте эту метрику, чтобы узнать, как секции в каждом регионе масштабируются независимо от их использования. Используйте метрики - Autoscaled RU Azure Monitor для анализа применения нового автомасштабирования между секциями и регионами. Отфильтруйте нужную учетную запись базы данных и контейнер, а затем отфильтруйте или разделите по метрику Physical PartitionID. Эта метрика отображает все секции в разных регионах. |
Сравнение — контейнеры, настроенные с масштабируемой вручную или автомасштабируемой пропускной способностью
Дополнительные сведения см. в этой документации, описывающей выбор между стандартно (вручную) масштабируемой и автомасштабируемой пропускной способностью.
Контейнеры со стандартно (вручную) масштабируемой пропускной способностью | Контейнеры с автомасштабируемой пропускной способностью | |
---|---|---|
Подготовленная пропускная способность (единиц запросов в секунду) | Подготовленная вручную. | Масштабируемая автоматически и мгновенно на основе моделей использования рабочих нагрузок. |
Ограничение скорости запросов и операций (429) | Это возможно, если потребление превышает подготовленную емкость. | Не происходит, если вы используете ЕЗ/с в пределах настроенного диапазона пропускной способности автомасштабирования. |
Планирование ресурсов | Необходимо выполнить планирование емкости и задать необходимую пропускную способность. | Система автоматически принимает меры по планированию ресурсов и управлению емкостью. |
Цены | Вы оплачиваете единицы запросов в секунду, подготовленных вручную, потребленные за час, используя тариф за стандартное (вручную) масштабирование в ЕЗ/с в час. | Вы платите за максимально потребленное за час число единиц запросов в секунду, до которого система масштабировалась в течение этого часа. Для учетных записей с одним регионом записи вы платите за число единиц запросов в секунду, потребляемых в час, используя функцию автомасштабирование числа единиц запросов в секунду за час. Для учетных записей с несколькими регионами записи не взимается дополнительная плата за автомасштабирование. Вы платите за пропускную способность по часам, используя один и тот же тариф по числу единиц запросов на секунду для операций записи в нескольких регионах. |
Оптимален для различных типов рабочих нагрузок | Прогнозируемые и стабильные рабочие нагрузки | Переменные или непредсказуемые рабочие нагрузки |
Перенос стандартной подготовленной пропускной способности в автомасштабирование
Пользователи, которые хотят перенести большое количество ресурсов из стандартной подготовленной пропускной способности в автомасштабирование, могут использовать скрипт Azure CLI для переноса каждого ресурса пропускной способности в подписке Azure на автомасштабирование. Дополнительные сведения см. в разделе "Преобразование в автомасштабирование".
Следующие шаги
- Изучитечасто задаваемые вопросы об автомасштабировании.
- Узнайте, как выбрать автомасштабируемую или масштабируемую вручную пропускную способность.
- Узнайте, как подготовить пропускную способность автомасштабирования в базе данных или контейнере Azure Cosmos DB.
- Дополнительные сведения о секционировании в Azure Cosmos DB.
- Если вы планируете ресурсы для миграции в Azure Cosmos DB, Для планирования ресурсов можно использовать сведения об имеющемся кластере базы данных.
- Если вам известно только количество виртуальных ядер и серверов в существующем кластере баз данных, см. сведения об оценке единиц запросов на основе виртуальных ядер и серверов.
- Если вам известна стандартная частота запросов для текущей рабочей нагрузки базы данных, ознакомьтесь со статьей о расчете единиц запросов с помощью планировщика ресурсов Azure Cosmos DB