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 |
|---|---|---|---|
| Balanceador de cargas de aplicaciones externo | Admite el tráfico HTTP(S) y las funciones avanzadas, como el mapeo de URL y la descarga de SSL Usa un balanceador de cargas de red de proxy externo para el tráfico que no sea HTTP en 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 |
| Balanceador de cargas de red de transferencia externo | 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 Cloud Service Mesh 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 de un balanceador de cargas de aplicaciones externo.
- Curl: Curl mide el tiempo hasta el primer byte (TTFB). Emite un comando
curlde 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
- Balanceador de cargas de red de transferencia externo
- Balanceador de cargas de aplicaciones externo o balanceador de cargas de red de proxy externo
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.
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.
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:
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.
Balanceador de cargas de red de transferencia externo
Con un balanceador de cargas de red de transferencia extern, 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 VMs del proyecto, el tráfico primero fluye a través de un balanceador de cargas de red de transferencia externo. Luego, se reenvía sin cambios a la VM de backend de destino. El balanceador de cargas de red de transferencia externo 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.
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 de transferencia externo |
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 los balanceadores de cargas de aplicaciones externos, 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.
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 aplicaciones externo |
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 balanceador de cargas de aplicaciones externo son bastante diferentes. Cuando hagas ping al balanceador de cargas de aplicaciones externo, 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:
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.
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.
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 |
| Balanceador de cargas de red de transferencia externo | 110 ms al balanceador de cargas de red de transferencia externo dentro de la región | 230 ms |
| Balanceador de cargas de aplicaciones externo | 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 balanceador de cargas de aplicaciones externo
Los efectos adicionales que se pueden observar con el balanceador de cargas de aplicaciones externo dependen de los patrones de tráfico.
El balanceador de cargas de aplicaciones externo tiene menos latencia para los elementos complejos que el balanceador de cargas de red de transferencia externo 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 balanceador de cargas de red de transferencia externo es de 1,911 ms. Con el balanceador de cargas de aplicaciones, la latencia promedio es de 1,341 ms. 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 balanceador de cargas de aplicaciones externo reduce de forma significativa la latencia adicional para un protocolo de enlace TLS (por lo general, 1 o 2 recorridos de ida y vuelta adicionales). Esto se debe a que el balanceador de cargas de aplicaciones externo usa la descarga de SSL, y solo es relevante la latencia en el PoP perimetral. Para el usuario en Alemania, la latencia mínima detectada fue de 201 ms con el balanceador de cargas de aplicaciones externo, en comparación con los 525 ms con HTTP(S) a través del balanceador de cargas de red de transferencia externa.
El balanceador de cargas de aplicaciones externo permite una actualización automática de la sesión orientada al usuario a HTTP/2. HTTP/2 puede reducir la cantidad de paquetes necesarios mediante mejoras en el protocolo binario, la compresión del encabezado y la multiplexación de conexiones. Estas mejoras pueden reducir la latencia observada aún más que la que se observa con el cambio al balanceador de cargas de aplicaciones externo. 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 los balanceadores de cargas de aplicaciones externos
Puedes optimizar la latencia de la aplicación con el balanceador de cargas de aplicaciones 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 balanceador de cargas de aplicaciones externo.
Puedes usar cualquier socio de CDN con Google Cloud. Si usas uno de los socios de CDN Interconnect de Google, obtendrás el beneficio de descuentos en los costos de transferencia de datos.
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 balanceador de cargas de aplicaciones. Esta opción se combina con Cloud CDN.
Implementar los servidores web en varias regiones cercanas a los usuarios puede reducir la latencia, ya que el balanceador de cargas dirige 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 los balanceadores de cargas de red de proxy externos se basan en GFE, el efecto en la latencia es el mismo que se observa con el balanceador de cargas de aplicaciones externo. Debido a que el balanceador de cargas de aplicaciones externo tiene más funciones que el balanceador de cargas de red de proxy externo, recomendamos usar balanceadores de cargas de aplicaciones externos 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:
- Balanceador de cargas de red de transferencia externo
- Balanceador de cargas de aplicaciones externo
- Balanceador de cargas de red del proxy externo