Диагностика и устранение неполадок в 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 единиц запроса за одну секунду. Если у вас есть ресурс, подготовленный с максимальным автомасштабированием ЕЗ/с 4000 ЕЗ/с (масштабируется от 400 ЕЗ/с до 4000 ЕЗ/с), вы увидите 429 ответов при использовании более 4000 единиц запроса в одну секунду.

Совет

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

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

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

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

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

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

По умолчанию клиентские пакеты 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 документов
  • По умолчанию в 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.

Дальнейшие действия