Cloud Load Balancing proporciona mecanismos para distribuir el tráfico de los usuarios entre varias instancias de una aplicación. Para ello, distribuyen la carga entre las instancias de la aplicación y ofrecen un rendimiento óptimo a los usuarios finales. En esta página se describen algunas prácticas recomendadas para asegurarse de que el balanceador de carga esté optimizado para su aplicación. Para asegurar un rendimiento óptimo, te recomendamos que compares los patrones de tráfico de tu aplicación.
Colocar back-ends cerca de los clientes
Cuanto más cerca estén tus usuarios o aplicaciones cliente de tus cargas de trabajo (backends del balanceador de carga), menor será la latencia de red entre ellos. Por lo tanto, crea las back-ends de tu balanceador de carga en la región más cercana al lugar donde preveas que llegará el tráfico de tus usuarios al frontend de Google. En muchos casos, es necesario ejecutar los backends en varias regiones para minimizar la latencia de los clientes de diferentes partes del mundo.
Para obtener más información, consulta los siguientes temas:
- Distribución del tráfico de los balanceadores de carga de aplicación externos
- Prácticas recomendadas para seleccionar la región de Compute Engine
Habilitar 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 carga de aplicación externo global. Para obtener más información, consulta Cloud CDN.
Cuando habilitas Cloud CDN, pueden pasar unos minutos antes de que las respuestas empiecen a almacenarse en caché. Cloud CDN solo almacena en caché las respuestas con contenido almacenable en caché. Si las respuestas de una URL no se almacenan en caché, comprueba qué encabezados de respuesta se devuelven para esa URL y cómo se configura la capacidad de almacenamiento en caché en tu backend. Para obtener más información, consulta la sección Solución de problemas de Cloud CDN.
Selección del protocolo de la regla de reenvío
En el caso del balanceador de carga de aplicaciones externo global y del balanceador de carga de aplicaciones clásico, recomendamos HTTP/3, un protocolo de Internet basado en IETF QUIC. HTTP/3 está habilitado de forma predeterminada en los principales navegadores, Android Cronet y iOS. Para usar HTTP/3 en tus aplicaciones, asegúrate de que el tráfico UDP no esté bloqueado ni limitado por la velocidad en tu red y de que HTTP/3 no se haya inhabilitado anteriormente en tus balanceadores de carga de aplicaciones externos globales. Los clientes que aún no admiten HTTP/3, como los navegadores o las bibliotecas de redes antiguos, no se verán afectados. Para obtener más información, consulta HTTP/3 QUIC.
En el caso del balanceador de carga de aplicaciones externo regional, admitimos HTTP/1.1, HTTPS y HTTP/2. Tanto HTTPS como HTTP/2 requieren una sobrecarga inicial para configurar TLS.
Selección de protocolo de servicio de backend
El protocolo de backend que elijas (HTTP, HTTPS o HTTP/2) influye en la latencia de la aplicación y en el ancho de banda de red disponible para tu aplicación. Por ejemplo, usar HTTP/2 entre el balanceador de carga y la instancia de backend puede requerir muchas más conexiones TCP a la instancia que HTTP(S). El pooling de conexiones, una optimización que reduce el número de estas conexiones con HTTP(S), no está disponible con HTTP/2. Por lo tanto, es posible que observes latencias de backend altas porque las conexiones de backend se realizan con más frecuencia.
El protocolo del servicio de backend también influye en cómo se cifra el tráfico en tránsito. Con los balanceadores de carga HTTP(S) externos, todo el tráfico que se dirige a los backends que residen en redes de VPC se cifra automáticamente. Google Cloud Esto se denomina encriptado automático a nivel de red. Sin embargo, el cifrado automático a nivel de red solo está disponible para las comunicaciones con grupos de instancias y back-ends de NEG zonales. En el resto de los tipos de backend, te recomendamos que uses opciones de protocolo seguro, como HTTPS y HTTP/2, para cifrar la comunicación con el servicio de backend. Para obtener más información, consulta Cifrado del balanceador de carga a los back-ends.
Duración de la conexión recomendada
Las condiciones de la red cambian y el conjunto de back-ends 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 la configuración óptima. En lugar de usar una sola conexión al backend indefinidamente, te recomendamos que elijas un tiempo de vida máximo de la conexión (por ejemplo, entre 10 y 20 minutos) o un número máximo de solicitudes (por ejemplo, entre 1000 y 2000 solicitudes). Después de ese tiempo o número, se usará una nueva conexión para las nuevas solicitudes. La conexión antigua se cierra cuando se completan todas las solicitudes activas que la usan.
De esta forma, la aplicación cliente puede beneficiarse de los cambios en el conjunto de backends, que incluyen los proxies del balanceador de carga y cualquier reoptimización de la red que sea necesaria para atender a los clientes.
Criterios de selección del modo de balanceo
Para mejorar el rendimiento, te recomendamos que elijas el grupo de backend de cada nueva solicitud en función del backend que responda más rápido. Para ello, puedes usar el modo de balanceo RATE. En este caso, se elige el grupo de backend con la latencia media más baja de las solicitudes recientes o, en el caso de HTTP/2 y HTTP/3, el grupo de backend con el menor número de solicitudes pendientes.
El modo de balanceo UTILIZATION solo se aplica a los backends de grupos de instancias y distribuye el tráfico en función de la utilización de las instancias de VM de un grupo de instancias.
Configurar la afinidad de sesión
En algunos casos, puede ser útil que el mismo backend gestione las solicitudes de los mismos usuarios finales o relacionadas con el mismo usuario final, al menos durante un breve periodo. Para ello, puedes usar la afinidad de sesión, un ajuste configurado 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 carga. Puede usar la afinidad de sesión para asegurarse de que el mismo backend gestione las solicitudes del mismo recurso, por ejemplo, las relacionadas con la misma cuenta de usuario o las del mismo documento.
La afinidad de sesión se especifica para todo el recurso de servicio de backend, no para cada backend. Sin embargo, un mapa de URLs puede apuntar a varios servicios de backend. Por lo tanto, no tienes que usar un solo tipo de afinidad de sesión para el balanceador de carga. En función de tu aplicación, puedes usar diferentes servicios backend con diferentes ajustes de afinidad de sesión. Por ejemplo, si una parte de tu aplicación sirve contenido estático a muchos usuarios, es poco probable que se beneficie de la afinidad de sesión. En su lugar, usarías un servicio de backend con Cloud CDN habilitado para servir respuestas almacenadas en caché.
Para obtener más información, consulta Afinidad de sesión.