Optimizar la latencia de las aplicaciones mediante el balanceo de carga

Opciones de balanceo de carga

En función del tipo de tráfico que se envíe a tu aplicación, tienes varias opciones de balanceo de carga externo. En la siguiente tabla se resumen las opciones:

Como los balanceadores de carga internos y Cloud Service Mesh no admiten tráfico visible para los usuarios, no se incluyen en este artículo.

En las mediciones de este artículo se usa el nivel Premium de los niveles de servicio de red porque el balanceo de carga global requiere este nivel de servicio.

Medir la latencia

Cuando accede a un sitio web alojado en us-central1, un usuario de Alemania utiliza los siguientes métodos para probar la latencia:

• Ping: aunque el ping ICMP es una forma habitual de medir la accesibilidad de los servidores, no mide la latencia del usuario final. Para obtener más información, consulta Efectos adicionales de latencia de un balanceador de carga de aplicación externo.
• Curl: mide el tiempo hasta el primer byte (TTFB). Envía un comando curl al servidor repetidamente.

Al comparar los resultados, ten en cuenta que la latencia de los enlaces de fibra está limitada por la distancia y la velocidad de la luz en la fibra, que es de aproximadamente 200.000 km por segundo (o 124.724 millas por segundo).

La distancia entre Fráncfort (Alemania) y Council Bluffs (Iowa), en la región us-central1, es de unos 7500 km. Con fibra directa entre las ubicaciones, la latencia de ida y vuelta es la siguiente:

7,500 km * 2 / 200,000 km/s * 1000 ms/s = 75 milliseconds (ms)

El cable de fibra óptica no sigue una ruta recta entre el usuario y el centro de datos. La luz del cable de fibra pasa por equipos activos y pasivos a lo largo de su recorrido. Una latencia observada de aproximadamente 1, 5 veces la ideal (112, 5 ms) indica una configuración casi ideal.

Comparar la latencia

En esta sección se compara el balanceo de carga en las siguientes configuraciones:

• Sin balanceo de carga
• Balanceador de carga de red de paso a través externo
• Balanceador de carga de aplicación externo o Balanceador de carga de red con proxy externo

En este caso, la aplicación consta de un grupo de instancias gestionadas regional de servidores web HTTP. Como la aplicación depende de llamadas de baja latencia a una base de datos central, los servidores web deben alojarse en una ubicación. La aplicación se ha implementado en la región us-central1 y los usuarios están distribuidos por todo el mundo. La latencia que observa el usuario de Alemania en este caso ilustra lo que pueden experimentar los usuarios de todo el mundo.

Sin balanceo de carga

Cuando un usuario hace una solicitud HTTP, a menos que se haya configurado el balanceo de carga, el tráfico fluye directamente desde la red del usuario a la máquina virtual alojada en Compute Engine. En el nivel Premium, el tráfico entra en la red de Google por un punto de presencia (PoP) perimetral cercano a la ubicación del usuario. En el nivel estándar, el tráfico de los usuarios entra en la red de Google en un PoP cercano a la región de destino. Para obtener más información, consulta la documentación sobre los niveles de servicio de red.

En la siguiente tabla se muestran los resultados cuando el usuario de Alemania probó la latencia de un sistema sin balanceo de carga:

  ping -c 5 compute-engine-vm
  

  PING compute-engine-vm (xxx.xxx.xxx.xxx) 56(84) bytes of data.
  64 bytes from compute-engine-vm (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=56 time=111 ms
  64 bytes from compute-engine-vm (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=56 time=110 ms
  [...]
  --- compute-engine-vm ping statistics ---
  5 packets transmitted, 5 received, 0% packet loss, time 4004ms
  rtt min/avg/max/mdev = 110.818/110.944/111.265/0.451 ms
  

  for ((i=0; i < 500; i++)); do curl -w  /
  "%{time_starttransfer}\n" -o /dev/null -s compute-engine-vm; done
  

  0.230
  0.230
  0.231
  0.231
  0.230
  [...]
  0.232
  0.231
  0.231
  

La latencia TTFB es estable, como se muestra en el siguiente gráfico de las primeras 500 solicitudes:

Al hacer ping a la dirección IP de la VM, la respuesta procede directamente del servidor web. El tiempo de respuesta del servidor web es mínimo en comparación con la latencia de la red (TTFB). Esto se debe a que se abre una nueva conexión TCP para cada solicitud HTTP. Se necesita un handshake inicial de tres vías antes de enviar la respuesta HTTP, como se muestra en el siguiente diagrama. Por lo tanto, la latencia observada es casi el doble de la latencia de ping.

Balanceador de carga de red de paso a través externo

Con los balanceadores de carga de red de pases externos, las solicitudes de los usuarios siguen entrando en la red de Google en el PoP de extremo más cercano (en el nivel Premium). En la región en la que se encuentran las VMs del proyecto, el tráfico fluye primero a través de un balanceador de carga de red de paso a través externo. A continuación, se reenvía sin cambios a la VM de backend de destino. El balanceador de carga de red de paso a través externo distribuye el tráfico en función de un algoritmo de hash estable. El algoritmo usa una combinación de puerto de origen y de destino, dirección IP y protocolo. Las VMs escuchan la IP del balanceador de carga y aceptan el tráfico sin modificarlo.

En la siguiente tabla se muestran los resultados cuando el usuario de Alemania probó la latencia de la opción de balanceo de carga de red.

  ping -c 5 net-lb
  

  PING net-lb (xxx.xxx.xxx.xxx) 56(84) bytes of data.
  64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=44 time=110 ms
  64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=44 time=110 ms
  [...]
  64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=5 ttl=44 time=110 ms
  --- net-lb ping statistics ---
  5 packets transmitted, 5 received, 0% packet loss, time 4007ms
  rtt min/avg/max/mdev = 110.658/110.705/110.756/0.299 ms
  

 for ((i=0; i < 500; i++)); do curl -w /
    "%{time_starttransfer}\n" -o /dev/null -s net-lb
 

 0.231
 0.232
 0.230
 0.230
 0.232
 [...]
 0.232
 0.231
 

Como el balanceo de carga se realiza en una región y el tráfico solo se reenvía, no hay un impacto significativo en la latencia en comparación con no tener ningún balanceador de carga.

Balanceo de carga externo

Con los balanceadores de carga de aplicación externos, los GFEs proxyizan el tráfico. Estos GFE se encuentran en el extremo de la red mundial de Google. GFE finaliza la sesión TCP y se conecta a un backend de la región más cercana que pueda atender el tráfico.

En la siguiente tabla se muestran los resultados cuando el usuario de Alemania probó la latencia de la opción de balanceo de carga HTTP.

 ping -c 5 http-lb
 

 PING http-lb (xxx.xxx.xxx.xxx) 56(84) bytes of data.
 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=56 time=1.22 ms
 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=56 time=1.20 ms
 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=3 ttl=56 time=1.16 ms
 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=4 ttl=56 time=1.17 ms
 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=5 ttl=56 time=1.20 ms
 --- http-lb ping statistics ---
 5 packets transmitted, 5 received, 0% packet loss, time 4005ms
 rtt min/avg/max/mdev = 1.163/1.195/1.229/0.039 ms
 

 for ((i=0; i < 500; i++)); do curl -w /
    "%{time_starttransfer}\n" -o /dev/null -s http-lb; done
 

 0.309
 0.230
 0.229
 0.233
 0.230
 [...]
 0.123
 0.124
 0.126
 

Los resultados del balanceador de carga de aplicación externo son significativamente diferentes. Al hacer ping al balanceador de carga de aplicaciones externo, la latencia de ida y vuelta es ligeramente superior a 1 ms. Este resultado representa la latencia del GFE más cercano, que se encuentra en la misma ciudad que el usuario. Este resultado no refleja la latencia real que experimenta el usuario al intentar acceder a la aplicación alojada en la región us-central1. Los experimentos que usan protocolos (ICMP) diferentes del protocolo de comunicación de tu aplicación (HTTP) pueden ser engañosos.

Al medir el TTFB, las solicitudes iniciales muestran una latencia de respuesta similar. Algunas solicitudes alcanzan la latencia mínima de 123 ms, como se muestra en el siguiente gráfico:

Se necesitan dos viajes de ida y vuelta entre el cliente y la VM, que tardan más de 123 ms, incluso con fibra directa. La latencia es menor porque los GFEs actúan como proxy del tráfico. Los GFE mantienen conexiones persistentes con las VMs backend. Por lo tanto, solo la primera solicitud de un GFE específico a un backend específico requiere un handshake de tres pasos.

Cada ubicación tiene varios GFEs. El gráfico de latencia muestra varios picos fluctuantes la primera vez que el tráfico llega a cada par de backend de GFE. A continuación, el GFE debe establecer una nueva conexión con ese backend. Estos picos reflejan diferentes hashes de solicitudes. Las solicitudes posteriores muestran una latencia menor.

Estos casos prácticos demuestran la latencia reducida que pueden experimentar los usuarios en un entorno de producción. En la siguiente tabla se resumen los resultados:

Cuando una aplicación en buen estado sirve a los usuarios de una región específica, los GFEs de esa región mantienen una conexión persistente abierta a todos los back-ends que sirven contenido. Por este motivo, los usuarios de esa región notan una latencia reducida en su primera solicitud HTTP si se encuentran lejos del backend de la aplicación. Si los usuarios están cerca del backend de la aplicación, no notarán ninguna mejora en la latencia.

En las solicitudes posteriores, como hacer clic en un enlace de una página, no se produce ninguna mejora de la latencia, ya que los navegadores modernos mantienen una conexión persistente con el servicio. Esto es diferente de un comando curl emitido desde la línea de comandos.

Efectos adicionales de latencia del balanceador de carga de aplicación externo

Los efectos observables adicionales con el balanceador de carga de aplicación externo dependen de los patrones de tráfico.

• El balanceador de carga de aplicaciones externo tiene menos latencia para los recursos complejos que el balanceador de carga de red de paso a través externo, ya que se necesitan menos viajes de ida y vuelta para que se complete una respuesta. Por ejemplo, cuando el usuario de Alemania mide la latencia en la misma conexión descargando repetidamente un archivo de 10 MB, la latencia media del balanceador de carga de red de paso a través externo es de 1911 ms. Con el balanceador de carga de aplicaciones externo, la latencia media es de 1341 ms. De esta forma, se ahorran aproximadamente 5 viajes de ida y vuelta por solicitud. Las conexiones persistentes entre los GFEs y los back-ends de servicio reducen los efectos de TCP Slow Start.

• El balanceador de carga de aplicaciones externo reduce significativamente la latencia adicional de una negociación de TLS (normalmente, 1 o 2 transferencias de ida y vuelta adicionales). Esto se debe a que el balanceador de carga de aplicaciones externo usa la descarga de SSL y solo es relevante la latencia al PoP de extremo. En el caso del usuario de Alemania, la latencia mínima observada es de 201 ms con el balanceador de carga de aplicaciones externo, frente a los 525 ms con HTTP(S) a través del balanceador de carga de red de paso a través externo.

• El balanceador de carga de aplicaciones externo permite actualizar automáticamente la sesión de cara al usuario a HTTP/2. HTTP/2 puede reducir el número de paquetes necesarios mediante mejoras en el protocolo binario, la compresión de encabezados y la multiplexación de conexiones. Estas mejoras pueden reducir la latencia observada incluso más que la que se observa al cambiar al balanceador de carga de aplicaciones externo. HTTP/2 es compatible con los navegadores actuales que usan SSL/TLS. En el caso del usuario de Alemania, la latencia mínima se redujo aún más, de 201 ms a 145 ms, al usar HTTP/2 en lugar de HTTPS.

Optimizar los balanceadores de carga de aplicación externos

Puedes optimizar la latencia de tu aplicación usando el balanceador de carga de aplicación externo de la siguiente manera:

• Si parte del tráfico que sirves se puede almacenar en caché, puedes integrarlo con Cloud CDN. Cloud CDN reduce la latencia sirviendo recursos directamente en el perímetro de la red de Google. Cloud CDN también usa las optimizaciones de TCP y HTTP de HTTP/2 que se mencionan en la sección Efectos adicionales de latencia del balanceador de carga de aplicaciones externo.

• Puedes usar cualquier partner de CDN con Google Cloud. Si usas uno de los partners de CDN Interconnect de Google, te beneficiarás de costes de transferencia de datos con descuento.

• Si el contenido es estático, puedes reducir la carga de los servidores web sirviendo el contenido directamente desde Cloud Storage a través del balanceador de carga de aplicaciones externo. Esta opción se combina con Cloud CDN.

• Si despliegas tus servidores web en varias regiones cercanas a tus usuarios, puedes reducir la latencia, ya que el balanceador de carga dirige automáticamente a los usuarios a la región más cercana. Sin embargo, si tu aplicación está centralizada parcialmente, diséñala para reducir el número de viajes de ida y vuelta entre regiones.

• Para reducir la latencia en tus aplicaciones, examina las llamadas a procedimientos remotos (RPCs) que se comunican entre máquinas virtuales. Esta latencia suele producirse cuando las aplicaciones se comunican entre niveles o servicios. Herramientas como Cloud Trace pueden ayudarte a reducir la latencia causada por las solicitudes de servicio de aplicaciones.

• Como los balanceadores de carga de red de proxy externo se basan en GFE, el efecto en la latencia es el mismo que se observa con el balanceador de carga de aplicaciones externo. Como el balanceador de carga de aplicaciones externo tiene más funciones que el balanceador de carga de red de proxy externo, te recomendamos que utilices balanceadores de carga de aplicaciones externos para el tráfico HTTP(S).

Pasos siguientes

Te recomendamos que despliegues tu aplicación cerca de la mayoría de tus usuarios. Para obtener más información sobre las distintas opciones de balanceo de carga enGoogle Cloud, consulta los siguientes documentos:

• Balanceador de carga de red de paso a través externo
• Balanceador de carga de aplicación externo
• Balanceador de carga de red de proxy externo