Descripción general del balanceo de cargas HTTP(S) interno

El balanceo de cargas HTTP(S) interno de Google Cloud es un balanceador de cargas regional de capa 7 basado en proxy que te permite ejecutar y escalar los servicios detrás de una dirección IP de balanceo de cargas interno.

El balanceo de cargas HTTP(S) interno distribuye el tráfico HTTP y HTTPS a los backends alojados en Compute Engine y Google Kubernetes Engine (GKE). Solo se puede acceder al balanceador de cargas en la región elegida de la red de nube privada virtual (VPC) en una dirección IP interna.

El balanceo de cargas HTTP(S) interno es un servicio administrado basado en el proxy Envoy de código abierto. Esto permite funciones completas de control de tráfico basadas en parámetros HTTP(S). Después de configurar el balanceador de cargas, este asigna los proxies de Envoy de forma automática para satisfacer las necesidades de tráfico.

En un nivel alto, un balanceador de cargas HTTP(S) interno consta de los siguientes elementos:

  • Una dirección IP interna a la que los clientes envían tráfico. Solo los clientes que se encuentran en la misma región que el balanceador de cargas pueden acceder a esta dirección IP. Las solicitudes internas de clientes permanecen dentro de la red y la región.
  • Uno o más servicios de backend a los que el balanceador de cargas reenvía el tráfico. Los backends pueden ser VM de Compute Engine, grupos de VM de Compute Engine (mediante grupos de instancias) o nodos GKE (a través de grupos de extremos de red [NEG]). Estos backends deben estar ubicados en la misma región que el balanceador de cargas.
Servicios internos con balanceo de cargas basado en la capa 7 (haz clic para ampliar)
Servicios internos con balanceo de cargas basado en la capa 7 (haz clic para ampliar)

Se usan los siguientes componentes adicionales para entregar el servicio de balanceo de cargas:

  • Un mapa de URL, que define reglas de control de tráfico (basadas en parámetros de capa 7, como encabezados HTTP) que se asignan a servicios de backend específicos. El balanceador de cargas evalúa las solicitudes entrantes en el mapa de URL para enrutar el tráfico a servicios de backend o realizar acciones adicionales (como redireccionamientos).
  • Verificaciones de estado, que verifican de manera periódica el estado de los backends y reducen el riesgo de que el tráfico de clientes se envíe a un backend sin respuesta.

Para obtener información acerca de cómo los balanceadores de cargas de Google Cloud difieren entre sí, consulta los siguientes documentos:

Casos prácticos

El balanceo de cargas HTTP(S) interno aborda muchos casos prácticos. En esta sección, se proporcionan algunos ejemplos de alto nivel. Para ver ejemplos adicionales, consulta Casos prácticos de administración del tráfico.

Balanceo de cargas mediante el enrutamiento basado en ruta de acceso

Un caso práctico común es el tráfico de balanceo de cargas entre los servicios. En este ejemplo, un cliente interno puede solicitar contenido de video y de imagen mediante la misma URL base, mygcpservice.internal, con las rutas de acceso /video y /images.

El mapa de URL del balanceador de cargas HTTP(S) especifica que las solicitudes a la ruta de acceso /video deben enviarse al servicio de backend de video, mientras que las solicitudes a la ruta de acceso /images deben enviarse al servicio backend de imágenes. En el siguiente ejemplo, los servicios de backend de video y de imágenes se entregan con las VM de Compute Engine, pero también se puede hacer mediante pods de GKE.

Cuando un cliente interno envía una solicitud a la dirección IP interna del balanceador de cargas, el balanceador de cargas evalúa la solicitud según esta lógica y la envía al servicio de backend correcto.

En el siguiente diagrama, se ilustra este caso práctico.

Servicios internos (micro) con balanceo de cargas basado en la capa 7 (haz clic para ampliar)
Servicios internos (micro) con balanceo de cargas basado en la capa 7

Modernización de servicios heredados

El balanceo de cargas HTTP(S) interno puede ser una herramienta eficaz para modernizar las aplicaciones heredadas.

Un ejemplo de una aplicación heredada es una aplicación monolítica grande que no se puede actualizar con facilidad. En este caso, puedes implementar un balanceador de cargas HTTP(S) interno frente a la aplicación heredada. Luego, puedes usar las funciones de control de tráfico del balanceador de cargas para dirigir un subconjunto de tráfico a microservicios nuevos que reemplacen la funcionalidad que proporciona la aplicación heredada.

Para comenzar, debes configurar el mapa de URL del balanceador de cargas de forma predeterminada a fin de enrutar todo el tráfico a la aplicación heredada. Esto mantiene el comportamiento existente. A medida que se desarrollen los servicios de reemplazo, deberías actualizar el mapa de URL para enrutar partes del tráfico a estos servicios.

Imagina que la aplicación heredada contiene alguna funcionalidad de procesamiento de video que se entrega cuando los clientes internos envían solicitudes a /video. Puedes dividir este servicio de video en un microservicio diferente de la siguiente manera:

  1. Agrega balanceo de cargas HTTP(S) interno frente a la aplicación heredada.
  2. Crea un microservicio de procesamiento de video de reemplazo.
  3. Actualiza el mapa de URL del balanceador de cargas para que todas las solicitudes a la ruta de acceso /video se dirijan al microservicio nuevo en lugar de a la aplicación heredada.

A medida que desarrolles servicios de reemplazo adicionales, se seguirá actualizando el mapa de URL. Con el tiempo, se enviarán menos solicitudes a la aplicación heredada. Además, los servicios de reemplazo existirán para todas las funcionalidades que proporciona la aplicación heredada. En este punto, puedes retirar tu aplicación heredada.

Servicios web de tres niveles

Puedes usar el balanceo de cargas HTTP(S) interno para admitir los servicios web tradicionales de tres niveles. En el siguiente ejemplo, se muestra cómo puedes usar tres tipos de balanceadores de cargas de Google Cloud para escalar tres niveles. En cada nivel, el tipo de balanceador de cargas depende del tipo de tráfico:

En el diagrama, se muestra cómo se mueve el tráfico por los niveles:

  1. Un balanceador de cargas HTTP(S) externo distribuye el tráfico de Internet a un conjunto de grupos de instancias de frontend web en varias regiones.
  2. Estos frontends envían el tráfico HTTP(S) a un conjunto de balanceadores de cargas HTTP(S) regionales internos (el asunto de esta descripción general).
  3. Los balanceadores de cargas HTTP(S) internos distribuyen el tráfico a grupos de instancias de middleware.
  4. Estos grupos de instancias de middleware envían el tráfico a balanceadores de cargas TCP/UDP internos, que balancean la carga del tráfico a los clústeres de almacenamiento de datos.
Enrutamiento basado en la capa 7 para niveles internos en una app de varios niveles (haz clic si deseas ampliar)
Enrutamiento basado en la capa 7 para niveles internos en una app de varios niveles

Ejemplos de acceso

Puedes acceder a un balanceador de cargas HTTP(S) interno en tu red de VPC desde una red conectada mediante el siguiente procedimiento:

  • Intercambio de tráfico entre redes de VPC
  • Cloud VPN y Cloud Interconnect

Para ver ejemplos detallados, consulta Balanceo de cargas interno y redes conectadas.

Arquitectura y recursos

En el siguiente diagrama, se muestran los recursos de Google Cloud necesarios para un balanceador de cargas HTTP(S) interno.

Componentes del balanceo de cargas HTTP(S) interno (haz clic para ampliar)
Componentes del balanceo de cargas  HTTP(S) interno

Los siguientes recursos definen un balanceador de cargas HTTP(S) interno:

  • Una regla interna de reenvío administrado especifica una dirección IP interna, un puerto y un proxy HTTP(S) de destino regional. Los clientes usan la dirección IP y el puerto para conectarse a los proxies Envoy del balanceador de cargas.

  • Un proxy HTTP(S) de destino regional recibe una solicitud del cliente. El proxy HTTP(S) evalúa la solicitud mediante el mapa de URL para tomar decisiones de enrutamiento de tráfico. El proxy también puede autenticar las comunicaciones mediante el uso de certificados SSL.

  • Si usas el balanceo de cargas HTTP(S) interno, el proxy HTTP(S) usa certificados SSL regionales para demostrar su identidad a los clientes. Un proxy HTTP(S) de destino admite hasta un número documentado de certificados SSL.

  • El proxy HTTP(S) usa un mapa de URL regional para realizar una determinación de enrutamiento basada en atributos HTTP (como la ruta de la solicitud, las cookies o los encabezados). En función de la decisión de enrutamiento, el proxy reenvía las solicitudes de los clientes a servicios de backend regionales específicos. En el mapa de URL se pueden especificar acciones adicionales, como volver a escribir encabezados, enviar redireccionamientos a clientes y configurar políticas de tiempo de espera (entre otras).

  • Un servicio de backend regional distribuye las solicitudes a backends en buen estado (ya sean grupos de instancias que contienen VM de Compute Engine o NEG que contienen contenedores de GKE).

  • Uno o más backends deben estar conectados al servicio de backend. Los backends pueden ser grupos de instancias o NEG con cualquiera de las siguientes opciones de configuración:

    • Grupos de instancias administrados (zonales o regionales)
    • Grupos de instancias no administrados (zonales)
    • Grupos de extremos de red (zonales)

    No puedes usar grupos de instancias y NEG en el mismo servicio de backend.

  • Una verificación de estado regional supervisa la preparación de las backends de manera periódica. Esto reduce el riesgo de que las solicitudes se envíen a backends que no pueden procesar la solicitud.

  • Una subred de solo proxy cuyas direcciones IP son la fuente de tráfico de los proxies del balanceador de cargas a tus backends. Debes crear una subred de solo proxy en cada región de una red de VPC en la que uses balanceadores de cargas HTTP(S) internos. Google administra esta subred, y todos tus balanceadores de cargas HTTP(S) internos en la región la comparten. No puedes usar esta subred para alojar tus backends.

  • También es necesario un firewall para que tus backends acepten conexiones desde la subred de solo proxy. Para obtener más información, consulta el ejemplo en Configuración de reglas de firewall.

Tiempos de espera y reintentos

El balanceo de cargas HTTP(S) interno tiene dos tipos de tiempos de espera distintos:
  • Un tiempo de espera de respuesta HTTP configurable, que representa la cantidad de tiempo que el balanceador de cargas espera a que el backend muestre una respuesta HTTP completa. El valor predeterminado para el tiempo de espera de respuesta es de 30 segundos. Considera aumentar este tiempo de espera en cualquiera de estas circunstancias:

    • Si esperas que un backend tarde más en mostrar respuestas HTTP
    • Si la conexión se actualiza a un WebSocket (solo balanceo de cargas HTTP[S])

    Para el tráfico de WebSocket enviado mediante un balanceador de cargas, el tiempo de espera del servicio de backend se interpreta como la cantidad máxima de tiempo que una conexión de WebSocket puede permanecer abierta, ya sea que esté activa o no. Para obtener más información, consulta la Configuración del servicio de backend.

  • Un tiempo de espera de sesión TCP, cuyo valor se fija en 10 minutos (600 segundos). A veces, este tiempo de espera de sesión se denomina tiempo de espera keepalive o inactivo, y su valor no se puede configurar mediante la modificación del servicio de backend. Debes configurar el software del servidor web que usan tus backends para que su tiempo de espera keepalive sea superior a 600 segundos y evitar que el backend cierre las conexiones antes de tiempo. Este tiempo de espera no se aplica a WebSockets.

En esta tabla, se ilustran los cambios necesarios a fin de modificar los tiempos de espera keepalive para el software de servidor web común:

Software de servidor web Parámetro Parámetro de configuración predeterminado Configuración recomendada
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

El balanceador de cargas reintenta las solicitudes GET que fallaron en ciertas circunstancias, como cuando se agota el tiempo de espera de respuesta. No se reintentan las solicitudes POST que fallaron. Solo se puede reintentar dos veces. Las solicitudes con reintentos generan solo una entrada de registro para la respuesta final.

Para obtener más información, consulta Registro y supervisión del balanceo de cargas HTTP(S) interno.

Tipos de tráfico, esquema y permisos

Los servicios de backend admiten los protocolos HTTP, HTTPS o HTTP/2. Los clientes y los backends no necesitan usar el mismo protocolo de solicitud. Por ejemplo, los clientes pueden enviar solicitudes al balanceador de cargas mediante HTTP/2, y el balanceador de cargas puede reenviar estas solicitudes a backends mediante HTTP/1.1.

Debido a que el alcance de un balanceador de cargas HTTP(S) interno es regional en vez de global, los clientes y los extremos o VM de backend deben estar todos en la misma región.

Limitaciones

  • El balanceo de cargas HTTP(S) interno opera a nivel regional.

  • No hay garantía de que una solicitud de un cliente en una zona de la región se envíe a un backend que se encuentre en la misma zona que el cliente. La afinidad de sesión no reduce la comunicación entre zonas.

  • El balanceo de cargas HTTP(S) interno no es compatible con las siguientes características:

  • Cuando se crea un balanceador de cargas HTTP(S) interno en un proyecto host de VPC compartida:

    • Las VM de cliente pueden estar ubicadas en el proyecto host o en cualquier proyecto de servicio conectado. Las VM de cliente deben usar la misma red de VPC compartida y la misma región que el balanceador de cargas.
    • Todos los componentes y backends del balanceador de cargas deben estar en el proyecto host. Esto difiere de otros balanceadores de cargas de Google Cloud porque ninguno de los componentes del balanceador de cargas HTTP(S) interno puede estar en un proyecto de servicio cuando el balanceador de cargas usa una red de VPC compartida.
    • El proyecto host dentro de la red de VPC compartida posee y crea la subred de solo proxy (propósito=INTERNAL_HTTPS_LOAD_BALANCER).
  • El protocolo WebSocket no es compatible.

  • Un balanceador de cargas HTTP(S) interno admite HTTP/2 solo a través de TLS.

  • Google Cloud no te advierte si tu subred de solo proxy se queda sin direcciones IP.

  • Dentro de cada red de VPC, cada regla de reenvío administrado interno debe tener su propia dirección IP. Para obtener más información, consulta Varias reglas de reenvío con una dirección IP común.

  • La regla de reenvío interno que usa el balanceador de cargas HTTP(S) interno debe tener exactamente un puerto.

Próximos pasos