Узнайте, как Azure Resource Manager регулирует запросы

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

Алгоритм регионального ограничения пропускной способности и ведра токенов.

Корпорация Майкрософт осуществила перенос подписок Azure на обновленную архитектуру ограничения в 2024 году. Теперь ограничения пропускной способности применяются для каждого региона, а не для каждого экземпляра Azure Resource Manager. Эта новая архитектура использует алгоритм контейнера маркеров для управления регулированием API.

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

Эти обновленные ограничения упрощают обновление квоты и управление ими.

Обновленные ограничения для общедоступных и национальных облаков:

Ограничения подписки применяются для каждой подписки, для каждого субъекта-службы и типа операции. Существуют также глобальные ограничения подписки, эквивалентные 15-кратным индивидуальным ограничениям учетной записи службы для каждого типа операции. Глобальные ограничения применяются ко всем сервисам-принципалам. Запросы ограничиваются, если превышены глобальные ограничения, ограничения основного объекта службы или конкретные ограничения арендатора.

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

Например, предположим, что размер контейнера составляет 250 токенов для запросов на чтение, а скорость пополнения составляет 25 токенов в секунду. При отправке 250 запросов на чтение в секунду хранилище пустое, и ваши запросы ограничиваются. Каждую секунду 25 маркеров становятся доступными, пока контейнер не достигнет максимальной емкости 250 маркеров. Вы можете использовать маркеры по мере их доступности.

Чтение метрик с помощью */providers/microsoft.insights/metrics API значительно влияет на общий трафик Azure Resource Manager и является распространенной причиной событий регулирования подписки. Если вы интенсивно используете этот API, рекомендуется переключиться на API getBatch. Вы можете запрашивать несколько ресурсов в рамках одного запроса REST, что улучшает производительность и снижает ограничение. Дополнительные сведения о преобразовании операций см. в статье "Как перейти из API метрик в API getBatch".

Как просмотреть ограниченные запросы?

Чтобы просмотреть регулируемые запросы и другие метрики Resource Manager, ознакомьтесь с метриками Azure Resource Manager.

Почему регулирование выполняется для каждого региона, а не для каждого экземпляра?

Так как разные регионы имеют другое количество экземпляров Resource Manager, регулирование для каждого экземпляра приводит к несогласованному регулированию производительности. Ограничение по регионам делает ограничения согласованными и предсказуемыми.

Как обновленный интерфейс регулирования влияет на мои ограничения?

Вы можете отправлять дополнительные запросы. Количество запросов на запись увеличилось в 30 раз. Увеличение числа запросов на удаление в 2,4 раза. Число запросов на чтение увеличивается на 7,5 раза.

Ограничение фоновых заданий

Фоновые задания в Azure Resource Manager (ARM) — это автоматические задачи, которые выполняются за кулисами для поддержки таких операций, как развертывание ресурсов, диагностика и обслуживание системы. Эти задания важны для обработки запросов пользователей и обеспечения функциональности службы. Для обеспечения стабильности и надежности платформы ARM использует ограничение фоновых заданий для управления нагрузкой от этих задач.

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

The request for subscription '{0}' could not be processed due to an excessive volume of traffic. Please try again later.

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

Ограничения поставщика ресурсов

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

В этом разделе обсуждаются пределы пропускной способности наиболее распространенных поставщиков ресурсов.

Контроль скорости работы хранилища

Следующие ограничения применяются только при выполнении операций управления с помощью Azure Resource Manager со службой хранения Azure и поставщиком ресурсов хранения. Ограничения применяются для каждой подписки для каждого региона ресурса в запросе.

Ограничение пропускной способности сети

Поставщик ресурсов Microsoft.Network применяет следующие ограничения:

Помимо этих общих ограничений, ознакомьтесь с ограничениями использования для Azure DNS.

Ограничение вычислительных ресурсов

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

Регулирование Azure Resource Graph

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

Azure Resource Graph также имеет решение, которое позволяет дополнительному механизму получения данных ресурсов при достижении ограничений пропускной способности поставщика ресурсов путем простой интеграции с существующей плоскостью управления Azure Resource Manager GET и LIST API, предлагая мощное масштабируемое решение для доступа к данным ресурсов. Дополнительные сведения см. в разделе API ARG GET/LIST.

Другие поставщики ресурсов

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

• Руководство по регулированию Azure Key Vault
• Устранение неполадок с AKS
• Управляемые идентификации

Код ошибки

По достижении ограничения отображается код состояния HTTP 429 — слишком много запросов. Ответ содержит значение Retry-After , указывающее количество секунд, которое должно ждать приложение перед отправкой следующего запроса. Если вы отправляете запрос до истечения временного интервала повтора, запрос не обрабатывается, и возвращается новый временной интервал повтора.

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

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

Оставшиеся запросы

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

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

Получение значений заголовков

Получение этих значений заголовков в коде или сценарии ничем не отличается от извлечения любого другого значения заголовка.

Например, приведенный ниже код C# извлекает значение заголовка из объекта HttpWebResponse с именем response.

response.Headers.GetValues("x-ms-ratelimit-remaining-subscription-reads").GetValue(0)

В PowerShell извлеките значение заголовка Invoke-WebRequest из операции.

$r = Invoke-WebRequest -Uri https://management.azure.com/subscriptions/{guid}/resourcegroups?api-version=2016-09-01 -Method GET -Headers $authHeaders
$r.Headers["x-ms-ratelimit-remaining-subscription-reads"]

Полный пример PowerShell см. в разделе "Проверка ограничений ARM для данной подписки".

Чтобы просмотреть оставшиеся запросы на отладку, укажите параметр -Debug в командлете PowerShell .

Get-AzResourceGroup -Debug

Ответ содержит множество значений, включая следующее значение ответа:

DEBUG: ============================ HTTP RESPONSE ============================

Status Code:
OK

Headers:
Pragma                        : no-cache
x-ms-ratelimit-remaining-subscription-reads: 11999

Чтобы получить ограничение на запись, используйте операцию записи:

New-AzResourceGroup -Name myresourcegroup -Location westus -Debug

Ответ содержит множество значений, включая следующие значения:

DEBUG: ============================ HTTP RESPONSE ============================

Status Code:
Created

Headers:
Pragma                        : no-cache
x-ms-ratelimit-remaining-subscription-writes: 1199

В Azure CLI вы используете более подробный параметр для получения значения заголовка:

az group list --verbose --debug

Команда возвращает много значений, включая следующие значения:

msrest.http_logger : Response status: 200
msrest.http_logger : Response headers:
msrest.http_logger :     'Cache-Control': 'no-cache'
msrest.http_logger :     'Pragma': 'no-cache'
msrest.http_logger :     'Content-Type': 'application/json; charset=utf-8'
msrest.http_logger :     'Content-Encoding': 'gzip'
msrest.http_logger :     'Expires': '-1'
msrest.http_logger :     'Vary': 'Accept-Encoding'
msrest.http_logger :     'x-ms-ratelimit-remaining-subscription-reads': '11998'

Чтобы получить ограничение на запись, используйте операцию записи:

az group create -n myresourcegroup --location westus --verbose --debug

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

msrest.http_logger : Response status: 201
msrest.http_logger : Response headers:
msrest.http_logger :     'Cache-Control': 'no-cache'
msrest.http_logger :     'Pragma': 'no-cache'
msrest.http_logger :     'Content-Length': '163'
msrest.http_logger :     'Content-Type': 'application/json; charset=utf-8'
msrest.http_logger :     'Expires': '-1'
msrest.http_logger :     'x-ms-ratelimit-remaining-subscription-writes': '1199'

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

• Дополнительные сведения об ограничениях и квотах см. в статье Подписка Azure, границы, квоты и ограничения службы.
• Сведения об обработке асинхронных запросов REST см. в статье Track asynchronous Azure operations (Отслеживание асинхронных операций Azure).