Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
APLICA-SE A: todas as camadas do Gerenciamento de API
A capacidade de limitar as solicitações de entrada é uma função fundamental do Gerenciamento de API do Azure. O Gerenciamento de API permite que os provedores de API protejam suas APIs contra abusos e criem valor para diferentes camadas de produtos de API controlando a taxa de solicitações ou o total de solicitações/dados transferidos. Este artigo descreve como criar e aplicar a cota e a limitação de taxa.
Limites de taxa e cotas
Os limites de taxa e as cotas são usados para fins diferentes.
Limites de taxa
Os limites de taxa geralmente são usados para proteger contra intermitências de volume curtas e intensas. Por exemplo, se você souber que seu serviço de back-end tem um gargalo em seu banco de dados quando os volumes de chamadas são altos, você pode definir uma rate-limit-by-key política para não permitir grandes volumes de chamadas.
Para back-ends de modelo de idioma, você pode definir uma política llm-token-limit para limitar o número de tokens processados por minuto pelo seu back-end. Essa política ajuda a proteger contra picos repentinos no uso de token que podem levar a custos maiores, esgotar recursos ou degradar o desempenho.
Cuidado
Devido à natureza distribuída da arquitetura de limitação, a limitação de fluxo nunca é completamente precisa. A diferença entre o número configurado de solicitações permitidas e o número real varia dependendo do volume e da taxa da solicitação, da latência de back-end e de outros fatores.
Camadas clássicas versus versão 2
O Gerenciamento de API implementa a limitação de taxa de forma diferente dependendo se sua instância está em uma das camadas de serviço clássicas ou v2:
As camadas clássicas usam um algoritmo de janela deslizante.
As camadas V2 usam um algoritmo de bucket de token mais eficiente e alinhado com a limitação de taxa no Azure Resource Manager.
Embora o comportamento geral de limitação de taxa seja semelhante entre as camadas de Gerenciamento de API, as diferenças na implementação afetam alguns detalhes de uso de políticas de limitação de taxa, como rate-limit-by-key e llm-token-limit.
Cotas
As cotas geralmente são usadas para controlar as taxas de chamada por um período mais longo. Por exemplo, eles podem definir o número total de chamadas que um determinado assinante pode fazer dentro de um determinado mês. Se você monetizar sua API, também poderá definir cotas de forma diferente para assinaturas baseadas em camadas. Por exemplo, uma assinatura de camada Básica pode ser capaz de fazer no máximo 10.000 chamadas por mês, mas uma camada Premium pode ser capaz de fazer 100.000.000 chamadas por mês.
No Gerenciamento de API, os limites de taxa normalmente são propagados mais rapidamente entre os nós para proteger contra picos. Por outro lado, as informações de cota de uso são usadas a longo prazo, portanto, sua implementação é diferente.
Observação
Quando os recursos de computação subjacentes são reiniciados na plataforma de serviço, o Gerenciamento de API pode continuar a lidar com solicitações por um curto período depois que uma cota for atingida.
Limitação com base no produto
Os provedores de API podem usar recursos de limitação de taxa com escopo de uma assinatura específica para aplicar limites aos desenvolvedores que se inscreveram para usar sua API. No entanto, esse tipo de limitação não ajuda, por exemplo, com a limitação de usuários finais individuais da API. É possível que um único usuário do aplicativo do desenvolvedor consuma toda a cota e impeça que outros clientes do desenvolvedor possam usar o aplicativo. Além disso, vários clientes que geram um alto volume de solicitações podem limitar o acesso a usuários ocasionais.
Limitação baseada em chave personalizada
Observação
As políticas rate-limit-by-key e quota-by-key não estão disponíveis na Camada de Consumo do Gerenciamento de API do Azure.
As políticas rate-limit-by-key e quota-by-key fornecem uma solução mais flexível para o controle de tráfego. Essas políticas permitem que você defina expressões para identificar as chaves usadas para controlar o uso do tráfego. Essa técnica é ilustrada nos exemplos a seguir.
Limitação de endereço de IP
As políticas a seguir restringem um único endereço IP do cliente a apenas 10 chamadas por minuto e impõem um total de 1.000.000 chamadas e 10.000 quilobytes de largura de banda por mês:
<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)" />
Se todos os clientes na Internet usarem um endereço IP exclusivo, essa poderá ser uma maneira eficaz de limitar o uso pelo usuário. No entanto, é provável que vários usuários estejam compartilhando um único endereço IP público porque acessam a Internet por meio de um dispositivo NAT. Ainda assim, para APIs que permitem acesso não autenticado, usar IpAddress pode ser a melhor opção.
Limitação de identidade do usuário
Se um usuário final for autenticado, você poderá criar uma chave de restrição com base nas informações que identificam exclusivamente o usuário.
<rate-limit-by-key calls="10"
renewal-period="60"
counter-key="@(context.Request.Headers.GetValueOrDefault("Authorization","").AsJwt()?.Subject)" />
Este exemplo mostra como extrair o cabeçalho de autorização, convertê-lo em um JWT objeto e usar o assunto do token para identificar o usuário. Em seguida, ele usa esse valor como a chave de limitação de taxa. Se a identidade do usuário estiver armazenada no JWT como uma das outras declarações, esse valor poderá ser usado.
Políticas combinadas
Embora as políticas de limitação baseadas no usuário ofereçam mais controle do que as políticas de limitação baseadas em assinatura, ainda há valor na combinação de ambos os recursos. Para APIs monetizadas, a limitação por chave de assinatura do produto (taxa de chamada limite por assinatura e definir cota de uso por assinatura) é uma ótima maneira de implementar taxas baseadas nos níveis de uso. O controle mais refinado da capacidade de limitar por usuário é complementar e evita que o comportamento de um usuário degrade a experiência de outro.
Limitação controlada pelo cliente
Quando a chave de limitação é definida por meio de uma expressão de política, o provedor de API escolhe o escopo da limitação. No entanto, um desenvolvedor pode querer controlar como eles aplicam limites de taxa a seus próprios clientes. O provedor de API pode habilitar esse tipo de controle introduzindo um cabeçalho personalizado para permitir que o aplicativo cliente do desenvolvedor comunique a chave à API:
<rate-limit-by-key calls="100"
renewal-period="60"
counter-key="@(request.Headers.GetValueOrDefault("Rate-Key",""))"/>
Essa técnica permite que o aplicativo cliente do desenvolvedor determine como criar a chave de limitação de taxa. Os desenvolvedores do cliente podem criar seus próprios níveis de tarifas ao alocar conjuntos de chaves aos usuários e alternar o uso das chaves.
Considerações sobre várias regiões ou gateways
Políticas de limitação de taxa, como rate-limit, rate-limit-by-key, azure-openai-token-limit e llm-token-limit usam contadores no nível do gateway de Gerenciamento de API. Portanto, em implantações de várias regiões do Gerenciamento de API, cada gateway regional tem um contador separado e os limites de taxa são impostos separadamente para cada região. Da mesma forma, em instâncias de Gerenciamento de API com workspaces, os limites são impostos separadamente para cada gateway de workspace.
Políticas de cota como quota e quota-by-key são globais, o que significa que um único contador é usado no nível da instância de API Management.
Resumo
O Gerenciamento de API fornece limitação de cota e taxa para proteger e adicionar valor ao serviço de API. As políticas de limitação que têm regras de escopo personalizadas fornecem um controle mais refinado sobre essas políticas para permitir que seus clientes criem aplicativos ainda melhores. Os exemplos neste artigo demonstram o uso dessas políticas criando chaves de limitação de taxa com endereços IP do cliente, identidade do usuário e valores gerados pelo cliente. No entanto, você pode usar muitas outras partes da mensagem, como agente do usuário, fragmentos de caminho de URL e tamanho da mensagem.