¿Cómo puedo solucionar los problemas de latencia alta en mi equilibrador de carga de aplicación en Elastic Load Balancing?

Descripción corta

A continuación, se indican las causas de la latencia alta en un equilibrador de carga de aplicación:

• Problemas de red, como problemas de conectividad, pérdida de paquetes o retrasos en la resolución de DNS entre el cliente y el equilibrador de carga de aplicación
• Equilibrador de carga de aplicación o mala configuración de la infraestructura, como la configuración del tiempo de espera de inactividad, la capacidad insuficiente de la subred, la falta de rutas o las reglas restrictivas de grupos de seguridad o de listas de control de acceso de red (ACL)
• Sobrecarga de AWS WAF al procesar solicitudes POST
• Problemas con los certificados o la sobrecarga del protocolo de enlace SSL/TLS
• Fallos en las comprobaciones de estado que provocan una sobrecarga de tráfico en los objetivos que permanecen en buen estado
• Problemas de backend, como un uso elevado de CPU o memoria, configuraciones incorrectas del servidor web o dependencias lentas de las aplicaciones

Resolución

Para solucionar problemas de alta latencia en tu equilibrador de carga de aplicación, toma las siguientes medidas.

Identificación de la fase en la que se produce la latencia

Para identificar la fase en la que se produce la latencia, consulta los registros de acceso del equilibrador de carga de aplicación para ver los valores de los siguientes campos:

• request_processing_time
• target_processing_time
• response_processing_time

Ejemplo de entrada de registro de acceso:

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

En este ejemplo, request_processing_time es 0.001, target_processing_time es 12.401, y response_processing_time es 0.001. El target_processing_time elevado indica que el objetivo del backend ha provocado la latencia. Para obtener más información, consulta Entradas de los registros de acceso. Compara la latencia total observada por el cliente con la suma de los tres campos de temporización. Una gran diferencia indica problemas de red entre el cliente y el equilibrador de carga de aplicación.

Comprueba las métricas de CloudWatch para ver lo siguiente:

• La estadística Average de TargetResponseTime. Los valores altos indican problemas de backend o de dependencia. Para obtener más información, consulta ¿Cómo soluciono un aumento en la métrica TargetResponseTime para un equilibrador de carga de aplicación?
• UnHealthyHostCount. Si los objetivos no superan las comprobaciones de estado, el equilibrador de carga de aplicación dirige el tráfico solo a los objetivos en buen estado, lo que puede sobrecargarlos y aumentar la latencia.

Comprueba las métricas en todas las zonas de disponibilidad para determinar si la latencia es específica de una zona de disponibilidad. Si una zona de disponibilidad específica tiene una latencia elevada, investiga el estado de los objetivos en esa zona de disponibilidad y las dependencias entre zonas de disponibilidad.

Cómo comprobar si hay problemas de red y DNS

Los problemas de conectividad de red entre el cliente y el equilibrador de carga de aplicación pueden provocar una latencia elevada. Para comprobar si hay problemas de red y DNS, sigue estos pasos:

• Verifica la conectividad básica con el equilibrador de carga de aplicación. Para obtener más información, consulta Solución de problemas de Equilibrador de carga de aplicación.

• Utiliza My Traceroute (MTR) para comprobar la pérdida de paquetes y la latencia entre el cliente y el equilibrador de carga de aplicación. Ejecuta el siguiente comando:

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

  Nota: Sustituye example-alb.us-east-1.elb.amazonaws.com por el nombre DNS de tu equilibrador de carga de aplicación.

  Resultado de ejemplo:

  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 fila numerada corresponde a un dispositivo de red por el que pasa el tráfico entre el cliente y el equilibrador de carga de aplicación.

• Busca dispositivos de red con valores Loss% elevados o proporciones elevadas de valores de latencia Avg a Wrst. La pérdida de paquetes en los dispositivos de red intermedios muestra la congestión de la red. Si se produce una pérdida de paquetes en el dispositivo de red final, el problema está relacionado con la ruta de red o la configuración de subred del equilibrador de carga de aplicación.

• Ejecuta MTR desde el lado del cliente y desde una instancia de Amazon EC2 en la misma Amazon Virtual Private Cloud (Amazon VPC) que el equilibrador de carga de aplicación. Compara los resultados para identificar si el problema es externo o interno a AWS. Para obtener más información, consulta Diagnosing packet loss and latency with mtr (Diagnóstico de la pérdida de paquetes y la latencia con MTR).

  Ejecuta el siguiente 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/  
  

  Nota: Sustituye example.com por tu nombre de DNS.
  Resultado de ejemplo:

  ===============| 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 aislar la causa de la latencia, ejecuta el comando anterior con el equilibrador de carga de aplicación y, a continuación, ejecútalo de nuevo y omite el equilibrador de carga de aplicación. Para obtener más información, consulta la página del manual de curl en el sitio web de curl. Si el tiempo de App connect (protocolo de enlace TLS) es significativamente mayor que el tiempo de Connect (protocolo de enlace TCP), la negociación de TLS es lenta.

Comprobación de la configuración del equilibrador de carga de aplicación y de la infraestructura

Tiempo de espera de inactividad

• Si target_processing_time en los registros de acceso es exactamente igual al valor del tiempo de espera de inactividad, aumenta el tiempo de espera de inactividad del equilibrador de carga de aplicación u optimiza el tiempo de respuesta de la aplicación. Para modificar el tiempo de espera de inactividad, consulta Edit attributes for your Application Load Balancer (Edición de los atributos del equilibrador de carga de aplicación). El tiempo de espera de inactividad predeterminado es de 60 segundos. Para comprobar el valor actual del tiempo de espera de inactividad, ejecuta el siguiente comando:

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

  Nota: Sustituye example-alb-arn por el nombre de recurso de Amazon (ARN) de tu equilibrador de carga de aplicación.

• Asegúrate de que el tiempo de espera de mantenimiento del servidor web de backend sea superior al tiempo de espera de inactividad del equilibrador de carga de aplicación para evitar errores de HTTP 502.

• Comprueba si hay errores HTTP 460 en los registros de acceso, que indican que el cliente ha cerrado la conexión antes de que transcurriera el tiempo de espera de inactividad.

Capacidad de subred
Cada subred del equilibrador de carga de aplicación requiere al menos un bloque de enrutamiento entre dominios sin clases (CIDR) /27 con al menos 8 direcciones IP libres. Durante los picos de tráfico, el equilibrador de carga de aplicación se amplía y requiere direcciones IP adicionales. Si la subred se agota, el equilibrador de carga de aplicación no puede escalar, lo que provoca latencia o errores 5xx. Para los aumentos repentinos esperados, utiliza las reservas de LCU para aprovisionar previamente la capacidad.

AWS WAF
Si AWS WAF está asociado a tu equilibrador de carga de aplicación, la evaluación de reglas de WAF se añade al campo request_processing_time. Este aumento es mayor en las solicitudes POST con cuerpos de solicitud grandes, ya que el WAF inspecciona el cuerpo antes de enviarlo a los objetivos. Para obtener más información, consulta Load balancer shows elevated processing times (El equilibrador de carga muestra tiempos de procesamiento elevados).

Configuración SSL/TLS
Comprueba que el equilibrador de carga de aplicación utilice una política de seguridad moderna para protocolos de enlace más rápidos. Para los certificados personalizados, asegúrate de que la cadena de certificados completa esté configurada. La falta de un certificado intermedio añade latencia al protocolo de enlace TLS.

Infraestructura de red
Verifica que las subredes del equilibrador de carga de aplicación tengan una ruta a una puerta de enlace de Internet externa o a rutas internas apropiadas.

Nota: En el caso de los equilibradores de carga de aplicación internos, las subredes no requieren una ruta de puerta de enlace de Internet. Si los destinos de backend necesitan llegar a servicios externos, asegúrate de que las subredes tengan una ruta a una puerta de enlace NAT. También puedes usar VPC Reachability Analyzer para diagnosticar problemas de conectividad entre las interfaces de red elástica (ENI) del equilibrador de carga de aplicación y los destinos.

Comprobación de los servidores de backend y las dependencias

Para comprobar las dependencias y los servidores de backend, haz lo siguiente:

• Para identificar el uso elevado de la CPU, consulta la métrica CPUUtilization de CloudWatch de tus instancias de backend. Para resolver el uso elevado de la CPU, actualiza tu instancia a un tipo de instancia más grande.

• Para revisar los procesos que se están ejecutando en el backend y comprobar si hay problemas de memoria, ejecuta el siguiente comando de Linux.

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

  Nota: Sustituye httpd por el nombre del proceso de tu servidor.
  Resultado de ejemplo:

  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 comprobar cuántos procesos del servidor web se están ejecutando actualmente, ejecuta el siguiente comando de Linux:

  ps aux  | grep httpd | wc -l

  Nota: Sustituye httpd por el nombre del proceso de tu servidor.

  Resultado de ejemplo:

  7

• Comprueba los límites máximos de conexiones simultáneas o de procesos de trabajo de tu servidor web. Cada servidor web tiene una configuración que controla el número máximo de solicitudes simultáneas que puede gestionar. Si se alcanza este límite, las nuevas solicitudes del equilibrador de carga de aplicación se ponen en cola, lo que aumenta la latencia. Comprueba la configuración correspondiente al tipo de servidor web.

• Comprueba si hay dependencias en las instancias de backend que causen problemas de latencia. Entre los ejemplos de dependencias se incluyen los buckets de Amazon Simple Storage Service (Amazon S3), las instancias de traducción de direcciones de red (NAT) o servidores proxy, servicios web remotos y bases de datos.

Uso de las herramientas de Linux para identificar los cuellos de botella de rendimiento

Para identificar los cuellos de botella de rendimiento del servidor, utiliza los siguientes comandos de Linux:

• Ejecuta el comando uptime para comprobar si los promedios de carga del sistema son altos debido a la escasez de recursos.
• Ejecuta el comando mpstat -P ALL 1 para ver un desglose del uso de la CPU para cada núcleo y determinar el uso desequilibrado.
• Para identificar los procesos y patrones que consumen muchos recursos a lo largo del tiempo, ejecuta el comando pidstat 1.
• Ejecuta el comando dmesg | tail para identificar los eventos recientes a nivel del sistema que puedan afectar al rendimiento. El resultado muestra los últimos 10 mensajes del sistema.
• Ejecuta el comando iostat -xz 1 para identificar operaciones de lectura o escritura elevadas o un rendimiento lento del disco.
• Ejecuta el comando free -m para ver la memoria disponible del sistema. Si la memoria disponible es baja, es posible que el sistema dependa de la memoria de intercambio, lo que aumenta la E/S y la latencia del disco.
• Ejecuta el comando sar -n DEV 1 para identificar la saturación del ancho de banda. El resultado muestra el rendimiento de la interfaz de red.
• Ejecuta sar -n TCP,ETCP 1 para ver las métricas de TCP. La métrica retrans/s muestra las retransmisiones TCP por segundo. Cuando esta métrica es alta, es posible que experimentes pérdida de paquetes o congestión.
• Para identificar qué es lo que consume más ancho de banda en la red, ejecuta el comando iftop. El resultado muestra el uso activo del ancho de banda para cada conexión en tiempo real.
• El comando niftop es una variante de iftop que puede estar disponible en repositorios de terceros en distribuciones basadas en Red Hat Enterprise Linux (RHEL) y distribuciones basadas en Debian. Si iftop no está preinstalado en tu sistema, utiliza niftop.

Nota: En función de tu distribución de Linux, es posible que necesites instalar manualmente los comandos anteriores.