Limitación avanzada de solicitudes con Azure API Management

SE APLICA A: Todos los niveles de API Management

La capacidad de limitar las solicitudes entrantes es un rol clave de Azure API Management. API Management permite a los proveedores de API proteger sus API de abuso y crear valor para diferentes niveles de producto de API controlando la tasa de solicitudes o el total de solicitudes o datos transferidos. En este artículo se describe cómo crear y aplicar la limitación de cuota y velocidad.

Límites de frecuencia y cuotas

Los límites de frecuencia y las cuotas se utilizan para distintos fines.

Límites de tarifas

Los límites de velocidad se suelen usar para protegerse frente a ráfagas de volumen cortas e intensas. Por ejemplo, si sabe que el servicio back-end tiene un cuello de botella en su base de datos cuando los volúmenes de llamadas son altos, puede establecer una directiva rate-limit-by-key para no permitir grandes volúmenes de llamadas.

Cuotas

Normalmente, las cuotas se usan para controlar las tasas de llamadas durante un período de tiempo más largo. Por ejemplo, pueden determinar el número total de llamadas que un suscriptor puede realizar en un determinado mes. Si monetiza la API, también puede establecer cuotas de forma diferente para las suscripciones basadas en niveles. Por ejemplo, una suscripción de nivel Básico podría no realizar más de 10 000 llamadas al mes, pero un nivel Premium podría ser capaz de realizar 100 000 000 llamadas cada mes.

En API Management, los límites de velocidad normalmente se propagan más rápido entre los nodos para protegerse frente a picos. En cambio, la información de cuota de uso se usa a largo plazo, por lo que su implementación es diferente.

Limitación basada en producto

Los proveedores de API pueden usar funcionalidades de limitación de velocidad que tienen como ámbito una suscripción determinada para aplicar límites a los desarrolladores que se han registrado para usar su API. Sin embargo, este tipo de limitación no ayuda, por ejemplo, con la limitación de usuarios finales individuales de la API. Es posible que un único usuario de la aplicación del desarrollador consuma toda la cuota e impida que otros clientes del desarrollador puedan usar la aplicación. Además, varios clientes que generan un gran volumen de solicitudes pueden limitar el acceso a usuarios ocasionales.

Limitación por claves personalizadas

Las políticas rate-limit-by-key y quota-by-key proporcionan una solución más flexible para el control de tráfico. Estas directivas permiten definir expresiones para identificar las claves que se usan para realizar un seguimiento del uso del tráfico. Esta técnica se muestra en los ejemplos siguientes.

Limitación por dirección IP

Las siguientes directivas restringen una sola dirección IP de cliente a solo 10 llamadas cada minuto y aplican un total de 1000 000 llamadas y 10 000 kilobytes de ancho de banda al mes:

<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)" />

Si todos los clientes de Internet usan una dirección IP única, podría ser una manera eficaz de limitar el uso por parte del usuario. Sin embargo, es probable que varios usuarios compartan una sola dirección IP pública porque acceden a Internet a través de un dispositivo NAT. Sin embargo, en el caso de las API que permiten el acceso no autenticado, el uso IpAddress podría ser la mejor opción.

Limitación por identidad de usuario

Si se autentica un usuario final, puede generar una clave de control de velocidad basada en información que identifique de forma única al usuario:

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

En este ejemplo se muestra cómo extraer el encabezado Authorization, convertirlo en un JWT objeto y usar el asunto del token para identificar al usuario. A continuación, usa ese valor como clave de limitación de velocidad. Si la identidad del usuario se almacena en JWT como una de las otras declaraciones, ese valor se puede usar en su lugar.

Directivas combinadas

Aunque las directivas de limitación basadas en el usuario proporcionan más control que las directivas de limitación basadas en suscripciones, todavía hay valor en la combinación de ambas funcionalidades. Para las API monetizadas, la limitación por clave de suscripción de producto (limitar la tasa de llamadas por suscripción y Establecer la cuota de uso por suscripción) es una excelente manera de implementar tarifas basadas en niveles de uso. El control más preciso de poder limitar por usuario es complementario e impide que el comportamiento de un usuario degrade la experiencia de otro.

Limitación controlada por cliente

Cuando la clave de limitación se define a través de una expresión de directiva, el proveedor de API elige cómo se limita el ámbito de la limitación. Sin embargo, un desarrollador podría querer controlar cómo limitan la velocidad de sus propios clientes. El proveedor de API puede habilitar este tipo de control introduciendo un encabezado personalizado para permitir que la aplicación cliente del desarrollador comunique la clave a la API:

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

Esta técnica permite que la aplicación cliente del desarrollador determine cómo crear la clave de limitación de velocidad. Los desarrolladores cliente podrían crear sus propios niveles de tarifa asignando conjuntos de claves a los usuarios y rotando el uso de la clave.

Consideraciones para varias regiones o puertas de enlace

Las directivas de limitación de velocidad como rate-limit, rate-limit-by-key, azure-openai-token-limity llm-token-limit usan contadores en el nivel de la puerta de enlace de API Management. Por lo tanto, en implementaciones de varias regiones de API Management, cada puerta de enlace regional tiene un contador independiente y los límites de velocidad se aplican por separado para cada región. De forma similar, en las instancias de API Management con áreas de trabajo, los límites se aplican por separado para cada puerta de enlace de área de trabajo.

Las políticas de cuota como quota y quota-by-key son globales, lo que significa que se usa un único contador en el nivel de la instancia de API Management.

Resumen

API Management proporciona limitación de velocidad y de cuota para proteger y agregar valor a su servicio de API. Las directivas de limitación que tienen reglas de ámbito personalizadas proporcionan un control más preciso sobre esas directivas para permitir que los clientes desarrollen aplicaciones mejores aún. Los ejemplos de este artículo muestran el uso de estas directivas mediante la creación de claves de limitación de velocidad con direcciones IP de cliente, identidad de usuario y valores generados por el cliente. Sin embargo, puede usar muchas otras partes del mensaje, como el agente de usuario, los fragmentos de ruta de acceso url y el tamaño del mensaje.

Contenido relacionado

• Políticas de límites de tasa y cuota