Расширенное ограничение частоты запросов с помощью службы "Azure API Management"

ОБЛАСТЬ ПРИМЕНЕНИЯ: все уровни управления API

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

Ограничения частоты и квоты

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

Ограничения скорости

Ограничения частоты обычно используются для защиты от коротких и интенсивных всплесков трафика. Например, если у вашей серверной службы есть узкое место в базе данных при высоких объемах вызовов, можно установить rate-limit-by-key политику, чтобы запретить высокие объемы вызовов.

Квоты

Квоты обычно используются для управления тарифами звонков за более длительный период времени. Например, можно задать общее число вызовов, которые конкретный подписчик может выполнить в течение данного месяца. Если вы монетизируете API, вы также можете задать квоты по-разному для подписок на основе уровней. Например, подписка уровня "Базовый" может выполнять не более 10 000 звонков в месяц, но уровень "Премиум" может составлять 100 000 000 звонков каждый месяц.

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

Регулирование на основе продукта

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

Регулирование на основе произвольных ключей

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

Ограничение скорости IP-адресов

Следующие политики ограничивают один IP-адрес клиента только 10 вызовов каждую минуту и применяют в общей сложности 1 000 000 вызовов и 10 000 килобайт пропускной способности в месяц:

<rate-limit-by-key  calls="10"
          renewal-period="60"
          counter-key="@(context.Request.IpAddress)" />

<quota-by-key calls="1000000"
          bandwidth="10000"
          renewal-period="2629800"
          counter-key="@(context.Request.IpAddress)" />

Если все клиенты в Интернете использовали уникальный IP-адрес, это может быть эффективным способом ограничения использования пользователем. Тем не менее, скорее всего, несколько пользователей совместно используют один общедоступный IP-адрес, так как они обращаются к Интернету через устройство NAT. Тем не менее, для API, разрешающих доступ без проверки подлинности, использование IpAddress может быть лучшим вариантом.

Управление частотой обработки удостоверений пользователя

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

<rate-limit-by-key calls="10"
    renewal-period="60"
    counter-key="@(context.Request.Headers.GetValueOrDefault("Authorization","").AsJwt()?.Subject)" />

В этом примере показано, как извлечь заголовок Authorization, преобразовать его в JWT объект и использовать субъект токена для идентификации пользователя. Затем он использует это значение в качестве ключа ограничения скорости. Если удостоверение пользователя хранится в JWT качестве одного из других утверждений, это значение можно использовать вместо этого.

Объединенные политики

Хотя политики регулирования на основе пользователей обеспечивают больший контроль, чем политики регулирования на основе подписки, все еще важно сочетать обе возможности. Для монетизированных API регулирование по ключу подписки продукта (ограничение частоты звонков по подписке и установка квоты использования по подписке) — отличный способ реализации сборов на основе уровней использования. Более детальное управление возможностью регулирования действий пользователей взаимодополняет систему и предотвращает ухудшение пользовательского опыта, вызванное действиями одного пользователя.

Регулирование на основе клиента

Если ключ регулирования определен через выражение политики, поставщик API выбирает область регулирования. Однако разработчику может потребоваться контролировать, как они ограничивают своих собственных клиентов. Поставщик API может включить этот тип управления, добавляя пользовательский заголовок для того, чтобы клиентское приложение разработчика могло обмениваться определённым ключом с API.

<rate-limit-by-key calls="100"
          renewal-period="60"
          counter-key="@(request.Headers.GetValueOrDefault("Rate-Key",""))"/>

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

Рекомендации по нескольким регионам или шлюзам

Политики ограничения скорости, такие как rate-limit, rate-limit-by-keyazure-openai-token-limitи llm-token-limit используют счетчики на уровне шлюза управления API. Таким образом, в развертываниях управления API в нескольких регионах каждый региональный шлюз имеет отдельный счетчик и ограничения скорости применяются отдельно для каждого региона. Аналогичным образом в экземплярах управления API с рабочими областями ограничения применяются отдельно для каждого шлюза рабочей области.

Политики квот, такие как quota и quota-by-key являются глобальными, что означает, что один счетчик используется на уровне экземпляра службы управления API.

Сводка

Управление API предоставляет ограничение скорости и квоты для защиты и увеличения ценности вашего API сервиса. Политики ограничения с пользовательскими правилами области предоставляют более точный контроль над этими политиками, что позволяет клиентам создавать еще более совершенные приложения. Примеры, приведенные в этой статье, демонстрируют использование этих политик путем создания ограничений скорости ключей с IP-адресами клиента, удостоверениями пользователя и значениями, созданными клиентом. Однако вы можете использовать множество других частей сообщения, таких как агент пользователя, фрагменты пути URL-адреса и размер сообщения.

Связанный контент

• Ограничения скорости и политики квот