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

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

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

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

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

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

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

Квоты

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

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

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

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

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

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

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

Следующие политики ограничивают один IP-адрес клиента только 10 вызовов каждую минуту, в общей сложности 1000 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)" />

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

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

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

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

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

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

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

Сводка

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

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

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