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

Breve descrição

As possíveis causas da alta latência em um Application Load Balancer incluem:

• Problemas de conectividade ou congestionamento de rede
• Alto uso de memória (RAM) em instâncias backend
• Alto uso de CPU em instâncias backend
• Configuração incorreta do servidor web em instâncias backend
• Problemas com as dependências de aplicativos web que são executados em instâncias backend
• Grande distância geográfica entre clientes ou destinos on-premises e o Application Load Balancer

Resolução

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

• Verifique se há problemas de conectividade de rede. Para obter mais informações, consulte Solucionar problemas em seus Application Load Balancers.

• Meça a resposta do primeiro byte e verifique se a resolução do DNS está lenta, o que pode causar latência:

  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/

  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
  ===============

  Observação: para isolar o que está causando a latência, conclua a etapa anterior com o Application Load Balancer e, em seguida, conclua a etapa novamente e ignore o Application Load Balancer. Para obter mais informações, consulte a página principal do curl no site do curl.

• Verifique a estatística Média da métrica TargetResponseTime do Amazon CloudWatch para seu Application Load Balancer. Se o valor for alto, você terá um problema nas instâncias backend ou nos servidores de dependência de aplicações. Para mais informações, consulte Como soluciono problemas de aumento na métrica TargetResponseTime para um Application Load Balancer?

• Para identificar as instâncias de backend que têm alta latência, verifique as entradas do log de acesso do seu Application Load Balancer.

• Para identificar instâncias backend com problemas de latência, verifique target_processing_time de destino por um período maior do que o normal.

• Para confirmar problemas com o Application Load Balancer, revise os campos request_processing_time e response_processing_time por períodos mais longos do que o normal.

  Exemplo da entrada de log:

  http 2024-04-01T22:23:00.765170Z app/example-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" "-" "-"

  Observação: o exemplo da entrada do log anterior mostra que a request_processing_time é 0,001, o target_processing_time é 12,401 e a response_processing_time é 0,001. O valor de target_processing_time mostra um período de tempo maior do que o normal e que o alvo do Application Load Balancer causou latência. Para obter mais informações, consulte Sintaxe.

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

• Para revisar os processos do Apache em seu backend e verificar se há problemas de memória, execute o seguinte comando:

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

  Exemplo de saída:

  Every 1.0s: echo -;n 'Apache Processes: ' && ps -;C apache2 -;no-headers | wc -1 && free -;m
  Apache Processes: 27
            total     used     free     shared     buffers     cached
  Mem:      8204      7445     758      0          385         4567
  -/+ buffers/cache:  2402     5801
  Swap:     16383     189      16194

• Para verificar quantas solicitações simultâneas sua instância pode atender, veja a configuração MaxClient para os servidores web em suas instâncias de backend. Se sua instância tiver uma quantidade adequada de memória e utilização de CPU e ainda apresentar alta latência, aumente o valor de MaxClient.

• Compare o número de processos que o Apache (httpd) gera com o valor MaxClient. Se o número de processos do Apache frequentemente atingir o valor MaxClient, aumente o valor MaxClient.

  Exemplo de comando:

  [root@ip-192.0.2.0 conf]# ps aux | grep httpd | wc -l 15

  Exemplo de saída:

  <IfModule prefork.c>StartServers         10
  MinSpareServers      5
  MaxSpareServers      10
  ServerLimit          15
  MaxClients           15
  MaxRequestsPerChild  4000
  </IfModule>

Verifique as dependências backend

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

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 altas médias de carga do sistema devido à contenção de recursos. A saída mostra as médias de carga do sistema que são o número de tarefas que estão esperando para serem executadas ou estão bloqueadas na E/S.
• O comando mpstat -P ALL 1 mostra um detalhamento do uso da CPU para cada núcleo. Execute o comando para determinar o uso desequilibrado, como um único núcleo que está lidando com a maior parte do trabalho em uma aplicação de thread único.
• Para identificar processos e padrões que consomem muitos recursos ao longo do tempo, execute o comando pidstat 1. A saída mostra o uso da CPU em tempo real por processo.
• 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.
• Para identificar altas operações de leitura ou gravação ou desempenho lento do disco, execute o comando iostat -xz 1. A saída mostra as métricas e o uso de E/S 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.
• Para identificar a saturação da largura de banda, execute o comando da ferramenta sar -n DEV 1. A saída mostra o throughput da interface de rede que inclui tráfego recebido (rxkB/s) e transmitido (txkB/s).
• Execute sar -n TCP,ETCP 1 para visualizar as seguintes métricas principais de TCP que ajudam a determinar problemas de conexão:
  A métrica ativo/s é o número de conexões TCP iniciadas localmente por segundo.
  A métrica passivo/s é o número de conexões TCP iniciadas remotamente por segundo.
  A métrica retrans/s é o número de retransmissões TCP por segundo. Quando essa métrica é 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 alguns dos comandos anteriores.