Como soluciono problemas de alta latência no meu Application Load Balancer no Elastic Load Balancing?

Breve descrição

A seguir estão listadas as causas da alta latência em um Application Load Balancer:

• Problemas de rede, como problemas de conectividade, perda de pacotes ou atrasos na resolução de DNS entre o cliente e o Application Load Balancer
• Configuração incorreta do Application Load Balancer ou da infraestrutura, como configurações de tempo limite de inatividade, capacidade de sub-rede insuficiente, rotas perdidas ou regras restritivas de grupo de segurança ou lista de controle de acesso (ACL) à rede
• Sobrecarga do AWS WAF para processar solicitações POST
• Sobrecarga de handshake SSL/TLS ou problemas de certificado
• Falhas na verificação de integridade que causam sobrecarga de tráfego nos destinos íntegros restantes
• Problemas de backend, como alto uso de CPU ou memória, configurações incorretas do servidor web ou lentidão nas dependências de aplicações

Resolução

Para solucionar problemas de alta latência em seu Application Load Balancer, execute as seguintes ações.

Identifique a fase em que a latência está ocorrendo

Para identificar a fase em que a latência está ocorrendo, verifique os logs de acesso do Application Load Balancer para ver os valores dos seguintes campos:

• request_processing_time
• target_processing_time
• response_processing_time

Exemplo de entrada de log de acesso:

loadbalancer/50dc6c495c0c9188  
 192.168.131.39:2817 10.0.0.1:80 0.001 12.401  0.001 200 200 34 366  
 "GET http://www.example.com:80/ HTTP/1.1" "curl/7.46.0" - -  
 arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/example-targets/73e2d6bc24d8a067  
 "Root=1-58337262-36d228ad5d99923122bbe354"  "-" "-"  
 0 2024-04-01T22:22:48.364000Z  "forward" "-" "-" "10.0.0.1:80"  "200" "-" "-"

Neste exemplo, request_processing_time é 0,001, target_processing_time é 12,401 e response_processing_time é 0,001. O target_processing_time alto indica que o destino do backend causou a latência. Para obter mais informações, consulte Entradas do log de acesso. Compare a latência total observada pelo cliente com a soma dos três campos de tempo. Uma grande diferença indica problemas de rede entre o cliente e o Application Load Balancer.

Verifique suas métricas do CloudWatch para conferir o seguinte:

• A estatística Média de TargetResponseTime. Valores altos indicam problemas de backend ou dependência. Para obter mais informações, consulte Como soluciono problemas de aumento na métrica TargetResponseTime para um Application Load Balancer?
• UnHealthyHostCount. Se os destinos estão falhando nas verificações de integridade, o Application Load Balancer direciona o tráfego somente para destinos íntegros, o que pode sobrecarregá-los e aumentar a latência.

Verifique as métricas nas zonas de disponibilidade para determinar se a latência é específica da zona de disponibilidade. Se uma zona de disponibilidade específica tiver alta latência, investigue a integridade do destino nas dependências dessa zona de disponibilidade e entre zonas de disponibilidade.

Verifique se há problemas de rede e DNS

Problemas de conectividade de rede entre o cliente e o Application Load Balancer podem causar alta latência. Para verificar se há problemas de rede e de DNS, conclua as seguintes etapas:

• Verifique a conectividade básica com seu Application Load Balancer. Para obter mais informações, consulte Solucionar problemas em seus Application Load Balancers.

• Use My Traceroute (MTR) para verificar a perda de pacotes e a latência entre o cliente e o Application Load Balancer. Execute o seguinte comando:

  mtr -rw  example-alb.us-east-1.elb.amazonaws.com -report-cycles 100

  Observação: substitua example-alb.us-east-1.elb.amazonaws.com pelo nome de DNS do seu Application Load Balancer.

  Exemplo de saída:

  HOST: ip-10-0-1-50                Loss%   Snt    Last   Avg  Best   Wrst StDev  
   1.|-- 10.0.1.1                    0.0%   100     0.5    0.6   0.4      1.2   0.1  
   2.|-- 52.93.1.100                 0.0%   100     1.2    1.3   1.0      3.5   0.3  
   3.|-- 54.239.110.5                2.0%   100     1.5    1.8   1.2      5.1   0.5  
   4.|-- example-alb.us-east-1.elb.amazonaws.com   0.0%   100    2.1    2.3   1.8   4.2    0.4

  Cada linha numerada corresponde a um dispositivo de rede pelo qual o tráfego passa entre o cliente e o Application Load Balancer.

• Procure dispositivos de rede com altos valores de Loss% ou altas proporções de valores de latência Avg para Wrst. A perda de pacotes em dispositivos de rede intermediários mostra congestionamento da rede. Se ocorrer perda de pacotes no dispositivo de rede final, o problema está na configuração da sub-rede ou no caminho da rede do Application Load Balancer.

• Execute o MTR do lado do cliente e de uma instância do Amazon EC2 na mesma Amazon Virtual Private Cloud (Amazon VPC) do Application Load Balancer. Compare os resultados para identificar se o problema é externo ou interno à AWS. Para obter mais informações, consulte Diagnosing packet loss and latency with MTR (Diagnóstico de perda de pacotes e latência com MTR).

  Execute o seguinte comando curl:

  curl -kso /dev/null -w  "\n===============\n  
   | DNS lookup: %{time_namelookup}\n  
   | Connect: %{time_connect}\n  
   | App connect: %{time_appconnect}\n  
   | Pre-transfer: %{time_pretransfer}\n  
   | Start transfer: %{time_starttransfer}\n  
   | Total: %{time_total}\n  
   | HTTP Code:  %{http_code}\n===============\n" https://example.com/  
  

  Observação: substitua example.com pelo seu nome de DNS.
  Exemplo de saída:

  ===============| DNS lookup: 0.002346| Connect: 0.003080| App connect: 0.008422| Pre-transfer: 0.008587| Start transfer: 0.050238| Total: 0.057486| HTTP Code: 200===============

• Para isolar o que está causando a latência, execute o comando anterior com o Application Load Balancer e, em seguida, execute-o novamente e ignore o Application Load Balancer. Para obter mais informações, consulte a curl man page (documentação do curl) no site do curl. Se o tempo de Conexão da aplicação (handshake TLS) for significativamente maior do que o tempo de Conexão (handshake TCP), a negociação TLS está lenta.

Verifique o Application Load Balancer e a configuração da infraestrutura

Tempo limite de inatividade

• Se o target_processing_time nos logs de acesso for exatamente igual ao valor do tempo limite de inatividade, aumente o tempo limite de inatividade do Application Load Balancer ou otimize o tempo de resposta da aplicação. Para modificar o tempo limite de inatividade, consulte Editar atributos do Application Load Balancer. O tempo limite de inatividade padrão é de 60 segundos. Para verificar o valor do tempo limite de inatividade atual, execute o seguinte comando:

  aws elbv2  describe-load-balancer-attributes --load-balancer-arn  example-alb-arn --query  "Attributes[?Key=='idle_timeout.timeout_seconds']"

  Observação: substitua example-alb-arn pelo nome do recurso da Amazon (ARN) do Application Load Balancer.

• Certifique-se de que o tempo limite de manutenção de atividade do servidor web de backend seja maior do que o tempo limite de inatividade do Application Load Balancer para evitar erros de HTTP 502.

• Verifique se há erros de HTTP 460 em seus logs de acesso, que indicam que o cliente encerrou a conexão antes que o tempo limite de inatividade terminasse.

Capacidade de sub-rede
Cada sub-rede do Application Load Balancer exige pelo menos um bloco de encaminhamento entre domínios sem classificação (CIDR) /27 com pelo menos 8 endereços IP livres. Durante picos de tráfego, o Application Load Balancer escala e exige IPs adicionais. Se a sub-rede acabar, o Application Load Balancer não poderá escalar, o que causa latência ou erros de 5xx. Para picos esperados, use as reservas de LCU para pré-provisionar a capacidade.

AWS WAF
Se o AWS WAF estiver associado ao seu Application Load Balancer, a avaliação da regra do WAF será adicionada ao campo request_processing_time. Esse aumento é maior para solicitações de POST com grandes corpos de solicitação, pois o WAF inspeciona o corpo antes de encaminhá-lo aos destinos. Para obter mais informações, consulte O balanceador de carga mostra tempos elevados de processamento.

Configuração SSL/TLS
Verifique se o Application Load Balancer usa uma política de segurança moderna para handshakes mais rápidos. Para certificados personalizados, certifique-se de que toda a cadeia de certificados esteja configurada. Um certificado intermediário ausente adiciona latência ao handshake TLS.

Infraestrutura de rede
Verifique se as sub-redes do Application Load Balancer têm uma rota para um gateway da internet voltado para o exterior ou rotas internas apropriadas.

Observação: para Application Load Balancers internos, as sub-redes não exigem uma rota de gateway da internet. Se os destinos de backend precisarem alcançar serviços externos, certifique-se de que as sub-redes tenham uma rota para um gateway NAT. Você também pode usar o VPC Reachability Analyzer para diagnosticar problemas de conectividade entre as interfaces de rede elástica (ENIs) do Application Load Balancer e os destinos.

Verifique os servidores e dependências de backend

Para verificar os servidores e dependências de backend, execute as seguintes ações:

• Para identificar a alta utilização da CPU, verifique a métrica CPUUtilization do CloudWatch de suas instâncias de backend. Para resolver a alta utilização da CPU, atualize sua instância para um tipo de instância maior.

• Para analisar os processos que estão sendo executados em seu backend e verificar se há problemas de memória, execute o seguinte comando Linux.

  watch  -n 1 "echo -n 'Apache Processes:' && ps -C httpd --no-headers |  wc -l && free -m"

  Observação: substitua httpd pelo nome do processo do seu servidor.
  Exemplo de saída:

  Every  1.0s: echo -n 'Apache Processes:' && ps -C httpd --no-headers | wc -l  && free -m  Apache  Processes:6 total used free shared buff/cache availableMem:  961 332 78 3 550 483Swap:  0 0 0

• Para verificar quantos processos do servidor web estão em execução no momento, execute o seguinte comando Linux:

  ps aux  | grep httpd | wc -l

  Observação: substitua httpd pelo nome do processo do seu servidor.

  Exemplo de saída:

  7

• Verifique os limites máximos de conexão simultânea ou de processamento para seu servidor web. Cada servidor web tem uma configuração que controla o número máximo de solicitações simultâneas que ele pode processar. Se esse limite for atingido, novas solicitações do Application Load Balancer entrarão em fila, o que aumenta a latência. Verifique a configuração relevante para o seu tipo de servidor web.

• Verifique as dependências que causam problemas de latência nas suas instâncias de backend. Os exemplos de dependências incluem buckets do Amazon Simple Storage Service (Amazon S3), instâncias de conversão de endereços de rede (NAT) ou servidores proxy, serviços web remotos e bancos de dados.

Use ferramentas Linux para identificar gargalos de desempenho

Para identificar gargalos de desempenho no servidor, use os seguintes comandos do Linux:

• Execute o comando uptime para verificar as médias elevadas de carga do sistema devido à contenção de recursos.
• Execute o comando mpstat -P ALL 1 para ver um detalhamento do uso da CPU para cada núcleo e determinar o uso desequilibrado.
• Execute o comando pidstat 1 para identificar processos e padrões que consomem muitos recursos ao longo do tempo.
• Execute o comando dmesg | tail para identificar eventos recentes no nível do sistema que possam afetar o desempenho. A saída mostra as últimas 10 mensagens do sistema.
• Execute o comando iostat -xz 1 para identificar altas operações de leitura ou gravação ou desempenho lento do disco.
• Execute o comando free -m para visualizar a memória disponível do sistema. Se a memória disponível estiver baixa, o sistema poderá depender de uma troca que aumenta a E/S e a latência do disco.
• Execute o comando sar -n DEV 1 para identificar a saturação da largura de banda. A saída mostra o throughput da interface de rede.
• Execute o comando sar -n TCP,ETCP 1 para visualizar as métricas de TCP. A métrica retrans/s mostra as retransmissões de TCP por segundo. Se essa métrica for alta, você pode estar enfrentando perda ou congestionamento de pacotes.
• Para identificar o que está usando mais largura de banda na rede, execute o comando iftop. A saída mostra o uso ativo da largura de banda para cada conexão em tempo real.
• O comando niftop é uma variante do iftop que pode estar disponível em repositórios de terceiros no Red Hat Enterprise Linux (RHEL) e distribuições baseadas em Debian. Se o iftop não estiver pré-instalado no seu sistema, use o niftop.

Observação: dependendo da sua distribuição Linux, talvez seja necessário instalar manualmente os comandos anteriores.