Бөлісу құралы:

Диагностика и устранение неполадок в Azure Cosmos DB: слишком большая частота запросов (429) исключений

  • Мақала

ОБЛАСТЬ ПРИМЕНЕНИЯ: NoSQL

В этой статье содержатся известные причины и решения для различных ошибок кода состояния 429 для API для NoSQL. Если вы используете API для MongoDB, см. статью Устранение распространенных проблем в API для MongoDB, чтобы узнать, как выполнять отладку при поступлении кода состояния 16500.

Исключение "Слишком большая частота запросов", также известная как код ошибки 429, указывает на то, что ваши запросы к Azure Cosmos DB ограничены по скорости.

При использовании подготовленной пропускной способности вы устанавливаете пропускную способность, измеряемую в единицах запросов в секунду (RU/s), необходимую для вашей рабочей нагрузки. Операции базы данных с службой, такие как операции чтения, записи и запросы, используют некоторое количество единиц запросов (ЕЗ). Дополнительные сведения о единицах запроса.

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

Прежде чем предпринимать действия по изменению единиц RU/s, важно понять основную причину ограничения скорости и устранить основную проблему.

Совет

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

Существуют различные сообщения об ошибках, которые соответствуют разным типам 429 исключений:

Высокая частота запросов

Этот сценарий является наиболее распространенным. Это происходит, когда количество единиц запроса, потребляемых операциями с данными, превышает предоставленное количество единиц RU/с. При использовании подготавливаемой вручную пропускной способности это происходит, если потребляется больше ЕЗ/с, чем установлено для подготавливаемой вручную пропускной способности. При применении автомасштабирования это происходит, если вы использовали больше максимального числа подготовленных ЕЗ/с. Например, если у вас есть ресурс, подготовленный с ручной пропускной способностью 400 ЕЗ/с, вы увидите 429 при использовании более 400 единиц запросов за одну секунду. Если у вас есть ресурс, подготовленный с автомасштабированием max ЕЗ/с 4000 ЕЗ/с (масштабируется в диапазоне от 400 ЕЗ/с до 4000 ЕЗ/с), при использовании более 4000 единиц запросов за одну секунду вы увидите 429 ответов.

Совет

Все операции взимается в зависимости от количества потребляемых ресурсов. Эти расходы измеряются в единицах запросов. К этим расходам относятся запросы, которые не выполняются успешно из-за ошибок приложения, таких как 400, 412, 449и т. д. При просмотре регулирования или использования рекомендуется изучить, изменились ли некоторые шаблоны использования, что приведет к увеличению этих операций. В частности, проверьте наличие тегов 412 или 449 (фактический конфликт).

Дополнительные сведения о подготовленной пропускной способности см. в статье о подготовленной пропускной способности в Azure Cosmos DB.

Шаг 1. Проверьте показатели, чтобы определить процент запросов с ошибкой 429

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

Способ исследования

Определите, какой процент запросов к базе данных или контейнеру привел к 429 ответам по сравнению с общим числом успешных запросов. В учетной записи Azure Cosmos DB перейдите в раздел "Общие запросы>аналитики>" по коду состояния. Фильтр по конкретной базе данных и контейнеру.

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

Таблица общего числа запросов по коду состояния, отображающая количество запросов 429 и 2xx.

Как правило, для рабочей рабочей нагрузки, если вы видите от 1 до 5% запросов с 429 ответами, и конечные задержки приемлемы, это здоровый признак того, что ЕЗ/с полностью используются. Предпринимать какие-либо действия не требуется. В противном случае переходите к следующим шагам по устранению неполадок.

Внимание

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

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

Один из распространенных вопросов: "Почему я вижу 429 ответов в метриках Azure Monitor, но ни в одном из моих собственных мониторинга приложений?" Если метрики Azure Monitor показывают, что у вас есть 429 ответов, но вы не видели ни одного в своем приложении, это связано с тем, что по умолчанию клиентские пакеты SDK automatically retried internally on the 429 responses для Azure Cosmos DB и запрос успешно выполнен в последующих повторных попытках. В результате код состояния 429 не возвращается приложению. В таких случаях общая частота откликов 429 обычно минимальна и может быть безопасно проигнорирована, если общая скорость составляет от 1 до 5 % и заканчивается задержкой, приемлемой для вашего приложения.

Шаг 2. Определение наличия горячего раздела

Горячая секция возникает в момент, когда один или несколько ключей логических разделов потребляют непропорционально большое количество единиц запросов в секунду из-за большего объема запроса. Это может быть вызвано тем, что ключ раздела не распределяет запросы равномерно. Это приводит к тому, что многие запросы направляются в небольшое подмножество логических секций (что подразумевает физические) секции, которые становятся "горячими". Так как все данные для логической секции находятся на одной физической секции и общий ЕЗ/с равномерно распределяются между физическими секциями, горячая секция может привести к 429 ответам и неэффективному использованию пропускной способности.

Ниже приведены несколько примеров стратегий разделения, которые приводят к возникновению горячих секций:

  • У вас есть контейнер, в котором хранятся данные с устройств Интернета вещей для рабочей нагрузки с большим объемом записи, секционированной по значению date. Все данные за отдельно взятую дату будут расположены в одном логическом и физическом разделе. Поскольку все данные, записываемые каждый день, имеют одну и ту же дату, это приведет к ежедневному созданию горячей секции.
    • Вместо этого для такого сценария лучше применить ключ раздела id (например, GUID или идентификатор устройства) либо синтетический ключ раздела, объединяющий id и date. Это повысит кратность значений и позволит более равномерно распределить объем запросов.
  • Теперь рассмотрим сценарий с несколькими арендаторами, где секционирование выполнено по значению tenantId. Если один клиент гораздо более активен, чем другие, это приводит к созданию горячего раздела. Например, если крупнейший клиент имеет 100 000 пользователей, но большинство клиентов имеют менее 10 пользователей, при секционирование по разделу tenantIDбудет горячей секцией.
    • Для описанного выше сценария рекомендуется использовать выделенный контейнер для самого крупного клиента, а секционирование выполнять по более детализированному свойству, например UserId.

Как определить горячую секцию

Для проверки наличия горячей секции перейдите в раздел Аналитика>Пропускная способность>Нормализованное потребление на единицу запроса (%) по PartitionKeyRangeID. Фильтр по конкретной базе данных и контейнеру.

Каждое значение PartitionKeyRangeId соответствует одному физическому разделу. При наличии одного раздела PartitionKeyRangeId, у которого нормализованное потребление на единицу запроса гораздо выше, чем у других (например, одна постоянно загружена на 100 %, а другие — на 30 % или меньше), это может быть признаком наличия горячего раздела. Подробнее о Метрике нормализованного потребления единиц запросов.

Нормализованное потребление единиц запроса по PartitionKeyRangeId, схема с горячей секцией.

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

Внимание

При включении журналов диагностики взимается отдельная плата за службу Log Analytics, которая оплачивается в зависимости от объема полученных данных. Рекомендуется включать журналы диагностики на ограниченное время для отладки и выключать, когда они больше не требуются. Дополнительные сведения см. на странице цен.

 CDBPartitionKeyRUConsumption
 | where TimeGenerated >= ago(24hour)
 | where CollectionName == "CollectionName"
 | where isnotempty(PartitionKey)
 // Sum total request units consumed by logical partition key for each second
 | summarize sum(RequestCharge) by PartitionKey, OperationName, bin(TimeGenerated, 1s)
 | order by sum_RequestCharge desc

Этот пример выходных данных показывает, что в конкретную минуту ключ логического раздела со значением "Contoso" потреблял около 12 000 единиц запросов в секунду, в то время как ключ логического раздела со значением "Fabrikam" потреблял менее 600 единиц запросов в секунду. Если этот шаблон был постоянным в течение периода времени, когда произошло ограничение скорости, это указывало бы на наличие горячей секции.

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

Совет

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

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

При наличии высокого процента запросов с ограничением скорости и отсутствии горячей секции:

При наличии высокого процента запросов с ограничением скорости и наличии соответствующей горячей секции:

  • В долгосрочной перспективе для обеспечения максимальной стоимости и производительности рекомендуется изменить ключ секции. Ключ секции нельзя обновить на месте, поэтому необходимо перенести данные в новый контейнер с другим ключом секции. Для этой цели Azure Cosmos DB поддерживает инструмент миграции данных в реальном времени.
  • В краткосрочной перспективе можно временно увеличить общий ЕЗ/с ресурса, чтобы обеспечить большую пропускную способность к горячей секции. Это не рекомендуется в качестве долгосрочной стратегии, поскольку это приводит к избыточному выделению единиц запросов в секунду и более высокой стоимости.
  • В краткосрочной перспективе можно использовать распространение пропускной способности между функциями секций (предварительная версия) для назначения дополнительных единиц запросов в секунду физической секции, которая является горячей. Это рекомендуется только в том случае, если горячая физическая секция предсказуема и согласована.

Совет

Когда вы увеличиваете пропускную способность, операция масштабирования завершается мгновенно или требует до 5-6 часов, в зависимости от количества единиц запросов в секунду, до которого вы хотите масштабироваться. Если вы хотите узнать максимальное количество единиц запросов в секунду, которое вы можете установить без запуска операции асинхронного масштабирования (для которой требуется, чтобы Azure Cosmos DB подготовила больше физических разделов), умножьте количество отдельных PartitionKeyRangeIds на 10,0000 единиц запросов в секунду. Например, если у вас выделено 30 000 единиц запросов в секунду и 5 физических разделов (6000 единиц запросов в секунду выделено на физический раздел), вы можете увеличить до 50 000 единиц запросов в секунду (10 000 единиц запросов в секунду на физический раздел) в операции мгновенного масштабирования. Увеличение до более чем 50 000 единиц запросов в секунду потребует асинхронной операции масштабирования. См. дополнительные сведения о рекомендациях по масштабированию подготовленной пропускной способности (ЕЗ/с).

Шаг 3. Определение того, какие запросы возвращают 429 ответов

Как исследовать запросы с помощью 429 ответов

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

Внимание

За включение журналов диагностики взимается отдельная плата за службу Log Analytics, которая оплачивается в зависимости от объема полученных данных. Рекомендуется включать журналы диагностики на ограниченное время для отладки и выключать, когда они больше не требуются. Дополнительные сведения см. на странице цен.

 CDBDataPlaneRequests
 | where TimeGenerated >= ago(24h)
 | summarize throttledOperations = dcountif(ActivityId, StatusCode == 429), totalOperations = dcount(ActivityId), totalConsumedRUPerMinute = sum(RequestCharge) by DatabaseName, CollectionName, OperationName, RequestResourceType, bin(TimeGenerated, 1min)
 | extend averageRUPerOperation = 1.0 * totalConsumedRUPerMinute / totalOperations
 | extend fractionOf429s = 1.0 * throttledOperations / totalOperations
 | order by fractionOf429s desc

Так, этот пример выходных данных показывает, что каждую минуту 30% запросов на создание документов были ограничены по скорости, при этом каждый запрос потреблял в среднем 17 единиц запросов. Запросы с ошибками 429 в журналах диагностики.

Использование планировщика ресурсов Azure Cosmos DB

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

429 ответов на запросы на создание, замена или upsert document
  • По умолчанию в API для NoSQL все свойства индексируются по умолчанию. Настройте политику индексирования, чтобы индексировать только необходимые свойства. Это приведет к снижению единиц запросов, необходимых для каждой операции создания документа, что приведет к снижению вероятности просмотра 429 ответов или позволяет достичь более высоких операций в секунду для того же количества подготовленных единиц запросов в секунду.
429 ответов на запросы документов запроса
429 ответов на выполнение хранимых процедур
  • Хранимые процедуры предназначены для операций, требующих транзакций записи по значению ключа раздела. Не рекомендуется использовать хранимые процедуры для большого количества операций чтения или запросов. Для повышения производительности эти операции чтения или запроса должны выполняться на стороне клиента с помощью пакетов SDK Azure Cosmos DB.

Значительное повышение скорости запросов при автомасштабировании

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

При использовании автомасштабирования часто возникает вопрос: "Можно ли просмотреть 429 ответов с автомасштабированием?"

Да. Ниже описаны два основных сценария, в которых это может произойти.

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

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

Например, если максимальная пропускная способность составляет 20 000 ЕЗ/с и у вас есть 200 ГБ хранилища с четырьмя физическими разделами, каждый физический раздел будет автоматически масштабироваться до 5000 ЕЗ/с. Если на определенном логическом ключе секции был горячий раздел, вы увидите 429 ответов, когда базовая физическая секция находится в более чем 5000 ЕЗ/с, то есть превышает 100 % нормализованного использования.

Следуйте инструкциям, приведенным в шаге 1, шаге 2 и шаге 3, чтобы выполнить отладку в этих сценариях.

Еще один распространенный вопрос: Почему нормализованный показатель потребления ЕЗ составляет 100 %, но при автомасштабировании не выполнено масштабирование до максимального числа ЕЗ/с?

Обычно это происходит при выполнении рабочих нагрузок с временными или периодическими скачками в использовании. При использовании автомасштабирования Azure Cosmos DB масштабирует только ЕЗ/с до максимальной пропускной способности, если нормализованное потребление ЕЗ равно 100 % для устойчивого непрерывного периода времени в 5-секундном интервале. Это обеспечивает экономичную логику масштабирования для пользователя, так как гарантируется, что отдельные пиковые скачки не будут приводить к ненужному масштабированию и повышению затрат. При пиковых скачках система обычно масштабируется до значения, превышающего значение, установленное ранее для масштабирования ЕЗ/с, но меньшего, чем максимальное число ЕЗ/с. Получите дополнительные сведения о том, как интерпретировать нормализованную метрику потребления ЕЗ с помощью автомасштабирования.

Ограничение скорости запросов метаданных

Ограничение скорости метаданных может возникать при выполнении больших объемов операций метаданных с базами данных и (или) контейнерами. Операции с метаданными включают:

  • Создание, чтение, обновление или удаление контейнера или базы данных
  • Вывод списка баз данных или контейнеров в учетной записи Azure Cosmos DB
  • Запрос предложений для просмотра текущей подготовленной пропускной способности

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

Способ исследования

Перейдите в раздел Аналитика>Система>Запросы метаданных по коду состояния. При необходимости выполните фильтрацию по конкретной базе данных и контейнеру.

Запросы метаданных по диаграмме кода состояния в аналитике.

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

  • Используйте статические экземпляры клиента Azure Cosmos DB. При инициализации DocumentClient или CosmosClient пакет SDK Azure Cosmos DB извлекает метаданные о учетной записи, включая сведения о уровне согласованности, базах данных, контейнерах, секциях и предложениях. При инициализации может использоваться большое число ЕЗ. Поэтому ее не следует выполнять часто. Используйте один экземпляр DocumentClient на протяжении времени существования приложения.

  • Кэшируйте имена баз данных и контейнеров. Извлеките имена ваших баз данных и контейнеров из конфигурации или кэшируйте их при запуске. Такие вызовы, как ReadDatabaseAsync/ReadDocumentCollectionAsync или CreateDatabaseQuery/CreateDocumentCollectionQuery, приведут к вызовам метаданных к службе, которые потребляют из зарезервированного системой ограничения единиц запросов. Не стоит выполнять эти операции слишком часто.

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

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

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

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