Cloud Load Balancing proporciona mecanismos para distribuir el tráfico de usuarios a varias instancias de una aplicación. Para ello, distribuye la carga en las instancias de la aplicación y entrega un rendimiento óptimo de la aplicación a los usuarios finales. En esta página, se describen algunas prácticas recomendadas con el objetivo de garantizar que el balanceador de cargas esté optimizado para tu aplicación. Para garantizar un rendimiento óptimo, te recomendamos comparar los patrones de tráfico de tu aplicación.
Coloca backends cerca de los clientes
Cuanto más cerca estén los usuarios o las aplicaciones cliente de tus cargas de trabajo (backends del balanceador de cargas), menor será la latencia de la red entre ellos. Por lo tanto, crea tus backends del balanceador de cargas en la región más cercana a donde esperas que el tráfico de tus usuarios llegue al Google Front End. En muchos casos, es necesario ejecutar los backends en varias regiones para minimizar la latencia en clientes de diferentes partes del mundo.
Para obtener más información, consulta los siguientes temas:
- Distribución de tráfico para balanceadores de cargas de aplicaciones externos
- Prácticas recomendadas para seleccionar la región de Compute Engine
Habilita el almacenamiento en caché con Cloud CDN
Activa Cloud CDN y el almacenamiento en caché como parte de la configuración predeterminada del balanceador de cargas de aplicaciones externo. Para obtener más información, consulta Cloud CDN.
Cuando habilitas Cloud CDN, es posible que tarde unos minutos antes de que las respuestas comiencen a almacenarse en caché. Cloud CDN almacena en caché solo las respuestas con contenido en caché. Si las respuestas para una URL no se almacenan en caché, verifica cuáles encabezados de respuesta se muestran para esa URL y cómo está configurada la caché para tu backend. Para obtener más detalles, consulta Solución de problemas de Cloud CDN.
Selección de protocolo de regla de reenvío
Para el balanceador de cargas de aplicaciones externo global y el balanceador de cargas de aplicación clásico, recomendamos HTTP/3, que es un protocolo de Internet compilado en IETF QUIC. HTTP/3 está habilitado de forma predeterminada en todos los navegadores principales, Android Cronet y iOS. Para usar HTTP/3 en tus aplicaciones, asegúrate de que el tráfico de UDP no esté bloqueado o que tenga un límite de frecuencia en la red y de que HTTP/3 no lo haya inhabilitado en los balanceadores de cargas de aplicaciones externos globales. No se verán afectados los clientes que aún no admitan HTTP/3, como los navegadores o las bibliotecas de red más antiguos. Para obtener más información, consulta HTTP/3 QUIC.
Para el balanceador de cargas de aplicaciones externo regional, admitimos HTTP/1.1, HTTPS y HTTP/2. HTTPS y HTTP/2 requieren cierta sobrecarga por adelantado para configurar TLS.
Selección de protocolos de servicio de backend
El protocolo de backend (HTTP, HTTPS o HTTP/2) que elijas afecta la latencia de la aplicación y el ancho de banda de red disponible para tu aplicación. Por ejemplo, el uso de HTTP/2 entre el balanceador de cargas y la instancia de backend puede requerir una cantidad significativamente mayor de conexiones TCP a la instancia que HTTP(S). La agrupación de conexiones, una optimización que reduce la cantidad de conexiones con HTTP(S), no está disponible con HTTP/2 en este momento. Como resultado, es posible que veas latencias de backend altas porque las conexiones de backend se realizan con más frecuencia.
El protocolo de servicio de backend también afecta la forma en que el tráfico se encripta en tránsito. Con los balanceadores de cargas HTTP(S) externos, todo el tráfico que se dirige a los backends que residen en las redes de VPC de Google Cloud se encripta de forma automática. Esto se llama encriptación automática a nivel de la red. Sin embargo, la encriptación automática a nivel de red solo está disponible para las comunicaciones con grupos de instancias y backends de NEG zonales. Para todos los demás tipos de backend, Google Cloud recomienda usar opciones de protocolo seguras, como HTTPS y HTTP/2, con el objetivo de encriptar la comunicación con el servicio de backend. Para obtener más información, consulta Encriptación del balanceador de cargas a los backends.
Duración recomendada de la conexión
Las condiciones de red cambian y el conjunto de backends puede cambiar en función de la carga. En el caso de las aplicaciones que generan mucho tráfico a un solo servicio, una conexión de larga duración no siempre es una configuración óptima. En lugar de usar una sola conexión al backend de forma indefinida, te recomendamos que elijas una vida útil máxima de la conexión (por ejemplo, entre 10 y 20 minutos) o una cantidad máxima de solicitudes (por ejemplo, entre 1,000 y 2,000 solicitudes). Luego, se usa una conexión nueva para solicitudes nuevas. La conexión anterior se cierra cuando finalizan todas las solicitudes activas que la usan.
Esto permite que la aplicación cliente se beneficie de los cambios en el conjunto de backends, que incluyen los proxies del balanceador de cargas y cualquier reoptimización de red necesaria para entregar a los clientes.
Criterios de selección del modo de balanceo
Si deseas obtener un mejor rendimiento, considera elegir el grupo de backend para cada solicitud nueva en función del backend que tenga más capacidad de respuesta. Esto se puede lograr mediante el modo de balanceo RATE. En este caso, se elige el grupo de backend con la latencia promedio más baja en comparación con las solicitudes recientes o, para HTTP/2 y HTTP/3, el grupo de backend con la menor cantidad de solicitudes pendientes.
El modo de balanceo UTILIZATION solo se aplica a los backends de grupos de instancias y distribuye el tráfico según el uso de instancias de VM en un grupo de instancias.
Configura la afinidad de sesión
En algunos casos, podría ser beneficioso que el mismo backend maneje las solicitudes de los mismos usuarios finales o relacionadas con el mismo usuario final, al menos durante un período corto. Esto se puede configurar con la afinidad de sesión, una configuración establecida en el servicio de backend. La afinidad de sesión controla la distribución de las conexiones nuevas de los clientes a los backends del balanceador de cargas. Puedes usar la afinidad de sesión para asegurarte de que el mismo backend maneje las solicitudes del mismo recurso, por ejemplo, en relación con la misma cuenta de usuario o desde el mismo documento.
La afinidad de sesión se especifica para todo el recurso de servicio de backend, no por cada backend. Sin embargo, un mapa de URL puede apuntar a varios servicios de backend. Por lo tanto, no es necesario usar solo un tipo de afinidad de sesión para el balanceador de cargas. Según la aplicación, puedes usar diferentes servicios de backend con diferentes opciones de configuración de afinidad de sesión. Por ejemplo, si una parte de tu aplicación entrega contenido estático a muchos usuarios, es poco probable que se beneficie de la afinidad de sesión. En cambio, usarías un servicio de backend habilitado para Cloud CDN a fin de entregar respuestas almacenadas en caché.
Para obtener más información, consulta afinidad de sesión.