Optimiza la latencia de las aplicaciones con el balanceo de cargas

En este documento, se analizan las opciones de balanceo de cargas y se muestra cómo tu elección de un balanceador de cargas específico en Google Cloud afecta la latencia de extremo a extremo.

Opciones de balanceo de cargas

Según el tipo de tráfico que se envía a la aplicación, tienes varias opciones para el balanceo de cargas externo. En la siguiente tabla, se resumen las opciones que tienes:

Opción Descripción Flujo de tráfico Alcance
Balanceo de cargas de HTTP(S) Admite el tráfico HTTP(S) y las funciones avanzadas, como el mapeo de URL y la descarga de SSL
Balanceo de cargas de proxy TCP o balanceo de cargas de proxy SSL para el tráfico que no es HTTP en puertos específicos.
La sesión de TCP o SSL (TLS) finaliza en Google Front End (GFE), en el perímetro de red de Google, y el tráfico se dirige mediante proxies a los backends. Global
Balanceo de cargas de red Permite que el tráfico de TCP/UDP use cualquier puerto para pasar por el balanceador de cargas. Se entrega mediante la tecnología Maglev de Google para distribuir el tráfico a los backends. Regional

Debido a que los balanceadores de cargas internos y Traffic Director no admiten el tráfico orientado al usuario, están fuera del alcance de este artículo.

En las medidas de este artículo, se usa el nivel Premium en los Niveles de servicio de red, ya que el balanceo de cargas global requiere este nivel de servicio.

Mide la latencia

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

  • Ping: Aunque el ping ICMP es una forma común de medir la accesibilidad del servidor, el ping ICMP no mide la latencia del usuario final. Para obtener más información, consulta Efectos de latencia adicionales del balanceo de cargas de HTTP(S).
  • Curl: Curl mide el tiempo hasta el primer byte (TTFB). Emite un comando curl de forma repetitiva al servidor.

Cuando se comparan los resultados, ten en cuenta que la latencia en los vínculos de fibra óptica está limitada por la distancia y la velocidad de la luz en la fibra, que es alrededor de 200,000 km por segundo (o 124,724 millas por segundo).

La distancia entre Fráncfort, Alemania y Council Bluffs, Iowa (la región us-central1), es de alrededor de 7,500 km. Con fibra óptica 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 directa entre el usuario y el centro de datos. La luz en el cable de fibra pasa por equipos activos y pasivos a lo largo de su ruta. Una latencia de alrededor de 1.5 veces la latencia ideal, o 112.5 ms, indica una configuración casi ideal.

Compara la latencia

En esta sección, se compara el balanceo de cargas en los siguientes parámetros de configuración:

  • Sin balanceo de cargas
  • Balanceo de cargas de red
  • Balanceo de cargas de HTTP(S) o balanceo de cargas de proxy TCP

En esta situación, la aplicación consta de un grupo de instancias administrado regional de servidores web HTTP. Debido a que la aplicación depende de llamadas con latencia baja a una base de datos central, los servidores web deben estar alojados en una ubicación. La aplicación se implementa en la región us-central1, y los usuarios se distribuyen por todo el mundo. La latencia que experimenta el usuario en Alemania en este caso ilustra lo que podrían experimentar los usuarios de todo el mundo.

Diagrama de una situación de latencia (haz clic para ampliar)
Diagrama de una situación de latencia (haz clic para ampliar)

Sin balanceo de cargas

Cuando un usuario realiza una solicitud HTTP, a menos que el balanceo de cargas esté configurado, el tráfico fluye directamente desde la red del usuario hasta la máquina virtual (VM) que se aloja en Compute Engine. En el nivel Premium, el tráfico ingresa a la red de Google en un punto de presencia perimetral (PoP) cercano a la ubicación del usuario. En el nivel Estándar, el tráfico de usuarios ingresa a la red de Google en un PoP cercano a la región de destino. Para obtener más información, consulta la documentación de los niveles de servicio de red.

Arquitectura sin balanceo de cargas (haz clic para ampliar)
Arquitectura sin balanceo de cargas (haz clic para ampliar)

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

Método Resultado Latencia mínima
Haz ping en la dirección IP de la VM (la respuesta proviene directamente del servidor web).

  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
  
110 ms
TTFB

  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
  
230 ms

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

Latencia de la VM en el gráfico de ms (haz clic para ampliar)
Latencia de la VM en el gráfico de ms (haz clic para ampliar)

Cuando se hace ping a la dirección IP de la VM, la respuesta proviene directamente del servidor web. El tiempo de respuesta del servidor web es mínimo en comparación con la latencia de red (TTFB). Esto se debe a que se abre una conexión TCP nueva para cada solicitud HTTP. Se necesita un protocolo de enlace inicial de tres vías antes de que se envíe la respuesta HTTP, como se muestra en el siguiente diagrama. Por lo tanto, la latencia observada está cerca de duplicar la latencia de ping.

Diagrama de una solicitud HTTP de cliente y servidor (haz clic para ampliar)
Diagrama de una solicitud HTTP de cliente y servidor (haz clic para ampliar)

Balanceo de cargas de red

Con un balanceador de cargas de red, las solicitudes de los usuarios aún ingresan a la red de Google en el PoP perimetral más cercano (en el nivel Premium). En la región en la que se encuentran las VM del proyecto, el tráfico fluye primero a través de un balanceador de cargas de red. Luego, se reenvía sin cambios a la VM de backend de destino. El balanceador de cargas de red distribuye el tráfico según un algoritmo de hash estable. El algoritmo usa una combinación de puertos de origen y de destino, dirección IP y protocolo. Las VM escuchan la IP del balanceador de cargas y aceptan el tráfico sin cambios.

Arquitectura con balanceo de cargas de red (haz clic para ampliar)
Arquitectura con balanceo de cargas de red (haz clic para ampliar)

En la siguiente tabla, se muestran los resultados obtenidos cuando el usuario en Alemania probó la latencia para la opción de balanceo de cargas de red:

Método Resultado Latencia mínima
Haz ping en el balanceador de cargas 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
  
110 ms
TTFB

 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
 
230 ms

Debido a que el balanceo de cargas se realiza dentro de una región y el tráfico solo se reenvía, no hay un impacto de latencia significativo en comparación con no tener un balanceador de cargas.

Balanceo de cargas externo

Con el balanceo de cargas de HTTP(S), los GFE usan proxies para enviar el tráfico. Estos GFE se encuentran en el perímetro de la red global de Google. El GFE finaliza la sesión TCP y se conecta a un backend en la región más cercana que puede entregar el tráfico.

Diagrama de situación de balanceo de cargas de HTTP(S) (haz clic para agrandar)
Diagrama de situación de balanceo de cargas de HTTP(S) (haz clic para agrandar)

En la siguiente tabla, se muestran los resultados obtenidos cuando el usuario en Alemania probó la latencia para la opción de balanceo de cargas de HTTP:

Método Resultado Latencia mínima
Haz ping en el balanceador de cargas de HTTP(S)

 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
 
1 ms
TTFB

 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
 
123 ms

Los resultados del balanceo de cargas de HTTP(S) difieren de manera considerable. Cuando hagas ping al balanceo de cargas de HTTP(S), la latencia de ida y vuelta es un poco superior a 1 ms. Este resultado representa la latencia en el 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 cuando intenta acceder a la aplicación alojada en la región us-central1. Los experimentos que usan protocolos (ICMP) que difieren del protocolo de comunicación de la aplicación (HTTP) pueden ser engañosos.

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

Latencia para el balanceo de cargas de HTTP(S) en el gráfico de ms (haz clic a fin de agrandar)
Latencia para el balanceo de cargas de HTTP(S) en el gráfico de ms (haz clic a fin de agrandar)

Dos recorridos de ida y vuelta entre el cliente y la VM toman más de 123 ms, incluso con la fibra directa. La latencia es menor porque los GFE usan proxies para enviar el tráfico. Los GFE mantienen conexiones persistentes a las VM de backend. Por lo tanto, solo la primera solicitud de un GFE específico a un backend específico requiere un protocolo de enlace de tres vías.

Solicitud HTTP inicial a través del diagrama de GFE (haz clic para agrandar)
Solicitud HTTP inicial a través del diagrama de GFE (haz clic para agrandar)

Cada ubicación tiene varios GFE. En el gráfico de latencia, se muestran varios aumentos fluctuantes la primera vez que el tráfico llega a cada par de GFE y backend. Luego, el GFE debe establecer una conexión nueva a ese backend. Estos aumentos reflejan los diferentes hashes de solicitud. En las solicitudes posteriores, se muestra una latencia más baja.

Solicitud HTTP posterior a través del diagrama de GFE (haz clic para agrandar)
Solicitud HTTP posterior a través del diagrama de GFE (haz clic para agrandar)

Con estas situaciones, se demuestra una latencia reducida que los usuarios pueden experimentar en un entorno de producción. En la siguiente tabla, se resumen los resultados:

Opción Ping TTFB
Sin balanceo de cargas 110 ms al servidor web 230 ms
Balanceo de cargas de red 110 ms al balanceador de cargas de red dentro de la región 230 ms
Balanceo de cargas de HTTP(S) 1 ms al GFE más cercano 123 ms

Cuando una aplicación en buen estado entrega contenido a los usuarios en una región específica, los GFE en esa región mantienen una conexión persistente abierta a todos los backends activos. Debido a esto, los usuarios de esa región notan una latencia menor en su primera solicitud HTTP si están lejos del backend de la aplicación. Si los usuarios se encuentran cerca del backend de la aplicación, no notarán una mejora en la latencia.

En las solicitudes posteriores, como hacer clic en un vínculo de página, no hay una mejora de latencia porque los navegadores modernos mantienen una conexión persistente al servicio. Esto difiere de un comando curl emitido desde la línea de comandos.

Efectos de latencia adicionales del balanceo de cargas de HTTP(S)

Los efectos adicionales que se pueden observar con el balanceo de cargas de HTTP(S) dependen de los patrones de tráfico.

  • El balanceo de cargas de HTTP(S) tiene menos latencia para los elementos complejos que el balanceo de cargas de red porque se necesitan menos recorridos de ida y vuelta antes de que se complete una respuesta. Por ejemplo, cuando el usuario en Alemania mide la latencia en la misma conexión mediante la descarga reiterada de un archivo de 10 MB, la latencia promedio para el balanceo de cargas de red es de 1,911 ms en comparación con los 1,341 ms del balanceo de cargas de HTTP(S). Esto ahorra alrededor de 5 recorridos de ida y vuelta por solicitud. Las conexiones persistentes entre los GFE y los backends activos reducen los efectos del inicio lento de TCP.

  • El balanceo de cargas de HTTP(S) reduce en gran medida la latencia adicional para un protocolo de enlace TLS (por lo general, entre 1 o 2 recorridos extra) porque el balanceo de cargas de HTTP(S) usa la descarga de SSL y solo la latencia al PoP perimetral es relevante. Para el usuario en Alemania, la latencia mínima observada es de 201 ms con el balanceo de cargas de HTTP(S), en comparación con los 525 ms con HTTP(S) a través del balanceo de cargas de red.

  • El balanceo de cargas de HTTP(S) permite actualizar de manera automática la sesión orientada al usuario a HTTP/2, que puede reducir la cantidad de paquetes necesarios mediante mejoras en el protocolo binario, la compresión de encabezado y la multiplexación de conexiones. Esto puede reducir aún más la latencia observada que la que se observa con el cambio al balanceo de cargas de HTTP(S). HTTP/2 es compatible con los navegadores actuales que usan SSL/TLS. Para el usuario en Alemania, la latencia mínima disminuye más allá de 201 ms a 145 ms cuando usa HTTP/2 en lugar de HTTPS.

Optimiza el balanceo de cargas de HTTP(S)

Puedes optimizar la latencia de la aplicación con el balanceador de cargas de HTTP(S) externo de la siguiente manera:

  • Si parte del tráfico que entregas se puede almacenar en caché, puedes integrarlo en Cloud CDN. Cloud CDN reduce la latencia, ya que entrega elementos directamente en la red perimetral de Google. Cloud CDN también usa las optimizaciones de TCP y HTTP de HTTP/2 que se mencionan en la sección Efectos de latencia adicionales del balanceo de cargas de HTTP(S).

  • Puedes usar cualquier socio de CDN con Google Cloud. Si usas uno de los socios de interconexión de CDN de Google, obtendrás descuentos en los costos de salida.

  • Si el contenido es estático, puedes reducir la carga en los servidores web mediante la entrega de contenido directamente desde Cloud Storage a través del balanceo de cargas de HTTP(S). Esta opción se combina con Cloud CDN.

  • La implementación de los servidores web en varias regiones cerca de los usuarios puede reducir la latencia, ya que el balanceo de cargas de HTTP(S), el balanceo de cargas de proxy SSL y el balanceo de cargas de proxy TCP dirigen a los usuarios a la región más cercana de forma automática. Sin embargo, si la aplicación está centralizada de forma parcial, diséñala para reducir la cantidad de recorridos ida y vuelta entre regiones.

  • Para reducir la latencia dentro de las aplicaciones, examina las llamadas de procedimiento remoto (RPC) que se comunican entre las VM. Por lo general, esta latencia ocurre cuando las aplicaciones se comunican entre niveles o servicios. Las herramientas como Cloud Trace pueden ayudarte a disminuir la latencia causada por las solicitudes de entrega de aplicaciones.

  • Debido a que el balanceo de cargas de proxy TCP y el balanceo de cargas de proxy SSL se basan en los GFE, el efecto en la latencia es el mismo que se observa con el balanceo de cargas de HTTP(S). Debido a que el balanceo de cargas de HTTP(S) tiene más funciones que el balanceo de cargas de proxy TCP y de proxy SSL, te recomendamos usar el balanceo de cargas de HTTP(S) para el tráfico HTTP(S).

Próximos pasos

Te recomendamos que implementes la aplicación cerca de la mayoría de los usuarios. Para obtener más información sobre las diferentes opciones de balanceo de cargas en Google Cloud, consulta los siguientes documentos: