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
Este artigo ajuda você a solucionar problemas de erros de conexão intermitente e problemas de latência relacionados no Gerenciamento de API do Azure. Especificamente, este artigo fornece informações e solução de problemas para o esgotamento das portas SNAT (conversão de endereços de rede de origem). Se precisar de mais ajuda, entre em contato com os especialistas do Azure no Suporte da Comunidade do Azure ou faça uma solicitação de suporte ao Suporte do Azure.
Sintomas
Aplicativos cliente que chamam APIs por meio de seu serviço de Gerenciamento de API podem apresentar um ou mais dos seguintes sintomas:
- Erros de HTTP 500 intermitente
- Mensagens de erro de tempo limite
Esses sintomas são manifestados como instâncias do BackendConnectionFailure nos logs de recursos do Azure Monitor.
Em determinadas camadas de serviço de Gerenciamento de API, você também pode ver informações de diagnóstico relacionadas ao esgotamento da porta SNAT no portal do Azure na página Diagnosticar e resolver problemas> deAnálise de Porta SNAT para sua instância de Gerenciamento de API.
Causa
Esse padrão de sintomas geralmente ocorre devido aos limites de porta SNAT com o seu serviço do Gerenciamento de API.
Sempre que um cliente chama uma de suas APIs de Gerenciamento de API, o serviço de Gerenciamento de API do Azure abre uma porta SNAT para acessar sua API de back-end. Conforme discutido em conexões de saída no Azure, o Azure usa a SNAT (conversão de endereços de rede de origem) e um balanceador de carga (não exposto aos clientes) para se comunicar com pontos de extremidade fora do Azure no espaço de endereço IP público e para pontos de extremidade internos do Azure que não estão usando pontos de extremidade de serviço de Rede Virtual. Essa situação só é aplicável a APIs de back-end expostas em IPs públicos.
Cada instância do serviço de Gerenciamento de API recebe inicialmente um número pré-alocado de portas SNAT. Esse limite afeta a abertura de conexões com a mesma combinação de host e porta. As portas SNAT são usadas quando há chamadas repetidas para a mesma combinação de endereço e porta. Depois que uma porta SNAT for liberada, a porta estará disponível para reutilização conforme necessário. O balanceador de carga de rede do Azure recupera portas SNAT de conexões fechadas somente depois de esperar quatro minutos.
Uma rápida sucessão de solicitações de cliente para suas APIs poderá esgotar a cota pré-alocada de portas SNAT se essas portas não forem fechadas e recicladas com rapidez suficiente, impedindo que seu serviço de Gerenciamento de API processe solicitações de cliente em tempo hábil.
Mitigações e soluções
Estratégias gerais para atenuar o esgotamento da porta SNAT são discutidas na solução de problemas de falhas de conexões de saída na documentação do Azure Load Balancer. Dessas estratégias, as seguintes são aplicáveis ao Gerenciamento de API.
Habilitar o Gateway NAT do Azure
Para uma instância injetada em rede virtual na camada Premium do Gerenciamento de API, você pode habilitar o Gateway nat do Azure para fornecer um número maior de portas SNAT (até 64K) do que estão disponíveis por padrão no Gerenciamento de API. Se houver suporte em seu cenário, essa solução é a maneira mais eficaz de evitar o esgotamento da porta SNAT.
Para habilitar o Gateway de NAT do Azure na rede virtual da instância de Gerenciamento de API, defina a propriedade natGatewayState da instância para enabled usando a API REST Serviço de Gerenciamento de API – Criar ou Atualizar.
Observação
- Atualmente, para definir a
natGatewayStatepropriedade, a instância não pode estar em uma configuração zonal ou com redundância de zona. - Para uma instância injetada em uma rede virtual no modo interno, o Gateway da NAT funciona apenas para o tráfego de saída para a Internet.
- O Gateway nat do Azure pode incorrer em custos extras.
O tempo limite ocioso padrão definido no gateway nat é de 4 minutos. Você pode alterar o tempo limite ocioso para um máximo de 120 minutos. Para obter mais informações, consulte Gerenciar o Gateway de NAT.
Se não for possível usar um gateway NAT para conectividade de saída, consulte as outras opções de mitigação descritas nesta seção.
Dimensione sua instância de Gerenciamento de API
Cada instância do Gerenciamento de API recebe um número de portas SNAT, com base em unidades do Gerenciamento de API. Você pode alocar mais portas SNAT dimensionando sua instância de Gerenciamento de API com mais unidades. Para obter mais informações, consulte Dimensionar seu serviço de Gerenciamento de API.
Observação
O uso da porta SNAT não está disponível no momento como uma métrica para unidades de Gerenciamento de API de dimensionamento automático.
Usar vários IPs para as URLs de back-end
Cada conexão da instância de Gerenciamento de API com o mesmo IP de destino e a porta de destino do serviço de back-end usa uma porta SNAT, a fim de manter um fluxo de tráfego distinto. Sem portas SNAT diferentes para o tráfego de retorno do serviço em segundo plano, o Gerenciamento de API não tem como separar uma resposta de outra.
Como as portas SNAT podem ser reutilizadas se o IP de destino ou porta de destino forem diferentes, outra maneira de evitar o esgotamento de porta SNAT é usar vários IPs para as URLs de serviço de back-end.
Para mais informações, confira Azure Load Balancer do proxy de saída.
Coloque o gerenciamento de API e o serviço de back-end na mesma VNet
Se a API de back-end estiver hospedada em um serviço do Azure que dê suporte a pontos de extremidade de serviço , como o Serviço de Aplicativo, você poderá evitar problemas de esgotamento da porta SNAT colocando sua instância de Gerenciamento de API e o serviço de back-end na mesma rede virtual e expondo-a por meio de pontos de extremidade de serviço ou pontos de extremidade privados. Quando você usa uma VNet comum e coloca pontos de extremidade de serviço na sub-rede de integração, o tráfego de saída da instância do Gerenciamento de API para esses serviços ignora a Internet, evitando as restrições de porta SNAT. Da mesma forma, se você usar uma VNet e pontos de extremidade privados, não terá nenhum problema de porta SNAT de saída para esse destino.
Para obter detalhes, confira Como usar o Gerenciamento de API do Azure com redes virtuais e Integrar o Serviço de Aplicativo com uma rede virtual do Azure.
Coloque seu serviço de Gerenciamento de API em uma rede virtual e encaminhe chamadas de saída para o Firewall do Azure
Semelhante a colocar o Gerenciamento de API e os serviços de back-end em uma rede virtual, você pode empregar o Firewall do Azure em uma VNet com seu serviço de Gerenciamento de API e, em seguida, rotear chamadas de Gerenciamento de API de saída para o Firewall do Azure. Entre o Gerenciamento de API e o Firewall do Azure (quando colocado na mesma VNet), nenhuma porta SNAT é necessária. Para conexões SNAT com seus serviços de back-end, o Firewall do Azure tem 64.000 portas disponíveis, uma quantidade muito maior do que é alocada para instâncias de Gerenciamento de API.
Consulte a documentação do Firewall do Azure para obter mais informações.
Considerar o cache de resposta e outro ajuste de desempenho de back-end
Outra mitigação potencial é melhorar os tempos de processamento para suas APIs de back-end. Uma maneira de fazer isso é configurando determinadas APIs com cache de resposta para reduzir a latência entre aplicativos cliente que chamam sua API e sua carga de back-end do Gerenciamento de API.
Para mais informações, confira Adicionar cache para melhorar o desempenho no Gerenciamento de API do Azure.
Considere implementar políticas de restrição de acesso
Se fizer sentido para seu cenário de negócios, você poderá implementar políticas de restrição de acesso para seu produto de Gerenciamento de API. Por exemplo, a política rate-limit-by-key pode ser usada para evitar picos de uso de API por chave limitando a taxa de chamada por um período de tempo especificado.
Consulte políticas de limitação de taxa e cota para obter mais informações.