Información general sobre Application Load Balancer

El balanceador de carga de aplicación es un balanceador de carga de capa 7 basado en proxy que te permite ejecutar y escalar tus servicios. El balanceador de carga de aplicaciones distribuye el tráfico HTTP y HTTPS a los backends alojados en una variedad de Google Cloud plataformas, como Compute Engine, Google Kubernetes Engine (GKE), Cloud Storage y Cloud Run, así como a los backends externos conectados a través de Internet o mediante conectividad híbrida.

Los balanceadores de carga de aplicaciones están disponibles en los siguientes modos de implementación:

  • Balanceador de carga de aplicación externo: balancea la carga del tráfico procedente de clientes en Internet. Para obtener información sobre la arquitectura, consulta el artículo sobre la arquitectura del balanceador de carga de aplicación externo.

    Modo de despliegue Nivel de servicio de red Esquema de balanceo de carga Dirección IP Puertos de frontend
    Global external Nivel premium EXTERNAL_MANAGED IPv4
    IPv6

    Puede hacer referencia a un puerto entre 1 y 65535.

    Regional externa Nivel Premium o Estándar EXTERNAL_MANAGED IPv4
    Clásico

    Global en el nivel Premium

    Regional en el nivel Estándar

    EXTERNA* IPv4
    IPv6 (requiere el nivel Premium)
    * Es posible adjuntar EXTERNAL_MANAGED servicios de backend a EXTERNAL reglas de reenvío. Sin embargo, los servicios de backend de EXTERNAL no se pueden adjuntar a reglas de reenvío de EXTERNAL_MANAGED. Para aprovechar las nuevas funciones disponibles solo con el balanceador de carga de aplicación externo global, te recomendamos que migres tus recursos de EXTERNAL a EXTERNAL_MANAGED mediante el proceso de migración descrito en el artículo Migrar recursos del balanceador de carga de aplicación clásico al balanceador de carga de aplicación externo global.
  • Balanceador de carga de aplicaciones interno: balancea la carga del tráfico dentro de tu red de VPC o de las redes conectadas a ella. Para obtener información sobre la arquitectura, consulta el artículo sobre la arquitectura del balanceador de carga de aplicación interno.

    Modo de despliegue Nivel de servicio de red Esquema de balanceo de carga Dirección IP Puertos de frontend
    Regional interna Nivel premium INTERNAL_MANAGED IPv4

    Puede hacer referencia a un puerto entre 1 y 65535.

    Interno entre regiones*

    Nivel premium INTERNAL_MANAGED IPv4

    * El balanceador de carga usa recursos globales y se puede desplegar en una o varias Google Cloud regiones que elijas.

El esquema de balanceo de carga es un atributo de la regla de reenvío y del servicio de backend de un balanceador de carga, e indica si el balanceador de carga se puede usar para el tráfico interno o externo. El término _MANAGED en el esquema de balanceo de carga indica que el balanceador de carga se implementa como un servicio gestionado en Google Front Ends (GFEs) o en el proxy de código abierto Envoy. En un esquema de balanceo de carga _MANAGED, las solicitudes se enrutan a GFE o al proxy de Envoy.

Balanceador de carga de aplicación externo

Los balanceadores de carga de aplicaciones externos se implementan mediante Google Front Ends (GFEs) o proxies gestionados. Los balanceadores de carga de aplicación externos globales y los balanceadores de carga de aplicación clásicos usan GFEs que están distribuidos a nivel mundial y que operan conjuntamente mediante la red y el plano de control globales de Google. Las GFEs ofrecen balanceo de carga multirregional en el nivel Premium, que dirige el tráfico al backend en buen estado más cercano que tenga capacidad y termina el tráfico HTTP(S) lo más cerca posible de tus usuarios. Los balanceadores de carga de aplicación externos globales y regionales usan el software de proxy Envoy de código abierto para habilitar funciones avanzadas de gestión del tráfico.

Estos balanceadores de carga se pueden implementar en uno de los siguientes modos: global, regional o clásico.

Los balanceadores de carga de aplicaciones externos admiten las siguientes funciones:

  • Gestión avanzada del tráfico, como la proyección del tráfico, la división del tráfico basada en el peso y las transformaciones de encabezados basadas en solicitudes y respuestas. Para obtener más información, consulta el artículo Descripción general de la gestión del tráfico.
  • Equilibrar la carga del tráfico a back-ends alojados en varias plataformas, como Compute Engine, Google Kubernetes Engine (GKE) y Cloud Run, entre otras. Google Cloud La compatibilidad con el backend depende del modo de implementación del balanceador de carga. Para obtener más información, consulta la descripción general del balanceador de carga de aplicación externo.
  • Respuestas almacenadas en caché con Cloud CDN.
  • Protección frente a ataques DDoS u otros ataques web mediante Google Cloud Armor.
  • Balanceo de carga en GKE mediante Ingress o Gateway (totalmente orquestado) o NEGs independientes.
  • Organización de balanceadores de carga de aplicaciones externos regionales en aplicaciones de App Hub para comprender las interacciones de los balanceadores de carga de aplicaciones externos regionales y admitir funciones empresariales.

En el siguiente diagrama se muestra una arquitectura de balanceador de carga de aplicaciones externo de ejemplo.

Arquitectura del balanceador de carga de aplicación externo.
Arquitectura del balanceador de carga de aplicación externo.

Para obtener una descripción completa, consulta Información general sobre la arquitectura de los balanceadores de carga de aplicación externos.

Balanceador de carga de aplicación interno

Los balanceadores de carga de aplicaciones internos son balanceadores de carga regionales de capa 7 basados en el proxy Envoy que te permiten ejecutar y escalar el tráfico de aplicaciones HTTP mediante una dirección IP interna. Los balanceadores de carga de aplicaciones internos admiten backends en una región, pero se pueden configurar para que los clientes de cualquierGoogle Cloud región puedan acceder a ellos de forma global.

El balanceador de carga distribuye el tráfico a los backends alojados en Google Cloud, en instalaciones locales o en otros entornos de nube. Los balanceadores de carga de aplicaciones internos también admiten las siguientes funciones:

  • Políticas de localidad. En un grupo de instancias de backend o en un grupo de puntos de conexión de red, puedes configurar cómo se distribuyen las solicitudes a las instancias o los endpoints miembros. Para obtener más información, consulta Gestión del tráfico.
  • Acceso global. Cuando el acceso global está habilitado, los clientes de cualquier región pueden acceder al balanceador de carga. Para obtener más información, consulta Habilitar el acceso global.
  • Acceso desde redes conectadas. Puedes hacer que tu balanceador de carga sea accesible para los clientes de redes que no sean su propia red de nube privada virtual (VPC). Google CloudLas otras redes deben estar conectadas a la red de VPC del balanceador de carga mediante el emparejamiento entre redes de VPC, Cloud VPN o Cloud Interconnect. Para obtener más información, consulta Acceder a redes conectadas.
  • Compatibilidad con GKE mediante Ingress (totalmente orquestado). Para obtener más información, consulta Configurar Ingress para balanceadores de carga de aplicaciones internos.
  • Organización de los balanceadores de carga de aplicación internos regionales en las aplicaciones de App Hub para comprender las interacciones de los balanceadores de carga de aplicación internos regionales y las funciones empresariales de asistencia.
Arquitectura del balanceador de carga de aplicación interno.
Arquitectura del balanceador de carga de aplicación interno.

Para obtener una descripción completa, consulta Información general sobre la arquitectura de los balanceadores de carga de aplicación internos.

Casos prácticos

En las siguientes secciones se describen algunos casos prácticos habituales de los balanceadores de carga de aplicaciones.

Servicios web de tres niveles

Puedes implementar una combinación de balanceadores de carga de aplicaciones y de red para admitir servicios web convencionales de tres niveles. En el siguiente ejemplo se muestra cómo puedes implementar cada nivel en función del tipo de tráfico:

  • Nivel web. El frontend de la aplicación se sirve mediante un balanceador de carga de aplicación externo con backends de grupos de instancias. El tráfico entra desde Internet y se envía a través de un proxy desde el balanceador de carga a un conjunto de back-ends de grupos de instancias en varias regiones. Estos backends envían tráfico HTTP(S) a un conjunto de balanceadores de carga de aplicaciones internos.
  • Nivel de aplicación. El middleware de la aplicación se despliega y se escala mediante un balanceador de carga de aplicaciones interno y backends de grupos de instancias. Los balanceadores de carga distribuyen el tráfico a los grupos de instancias de middleware. Estos grupos de instancias de middleware envían el tráfico a balanceadores de carga de red de paso a través internos.
  • Nivel de base de datos. Los balanceadores de carga de red actúan como front-ends para el nivel de base de datos. Distribuyen el tráfico a los back-ends de almacenamiento de datos en varias regiones.
Enrutamiento basado en la capa 7 en una aplicación web de tres niveles.
Enrutamiento basado en la capa 7 en una aplicación web de tres niveles.

Acceso global a los balanceadores de carga de aplicaciones internos regionales

Si habilitas el acceso global en tu balanceador de carga de aplicaciones interno regional, las VMs de cliente de tu nivel web pueden estar en otra región.

En este ejemplo de aplicación multinivel se muestra lo siguiente:

  • Una capa web accesible desde Internet y disponible en todo el mundo que balancea la carga del tráfico mediante un balanceador de carga de aplicación externo.
  • Una capa de base de datos con balanceo de carga de backend interno en la región us-east1 a la que accede la capa web global.
  • Una VM cliente que forma parte del nivel web de la región europe-west1 y que accede al nivel de base de datos interno con balanceo de carga ubicado en us-east1.
Aplicación web de tres niveles con un balanceador de carga de aplicación externo, acceso global y un balanceador de carga de aplicación interno.
Aplicación web de tres niveles con un balanceador de carga de aplicación externo, acceso global y un balanceador de carga de aplicación interno (haz clic para ampliar).

Cargas de trabajo con cumplimiento de la jurisdicción

Algunas cargas de trabajo con requisitos normativos o de cumplimiento requieren que las configuraciones de red y la terminación del tráfico se encuentren en una región específica. Para estas cargas de trabajo, un balanceador de carga de aplicaciones externo regional suele ser la opción preferida para proporcionar los controles jurisdiccionales que requieren estas cargas de trabajo.

Gestión avanzada del tráfico

Los balanceadores de carga de aplicaciones admiten funciones avanzadas de gestión del tráfico que le permiten controlar con precisión cómo se gestiona el tráfico. Entre estas funciones se incluyen las siguientes:

  • Puedes actualizar la forma en que se gestiona el tráfico sin tener que modificar el código de tu aplicación.
  • Puede enrutar el tráfico de forma inteligente en función de los parámetros HTTP(S), como el host, la ruta, los encabezados y otros parámetros de solicitud. Por ejemplo, puedes usar segmentos de Cloud Storage para gestionar el contenido de vídeo estático y grupos de instancias o NEGs para gestionar el resto de las solicitudes.
  • Puedes mitigar los riesgos al desplegar una nueva versión de tu aplicación usando la división del tráfico basada en el peso. Por ejemplo, puedes enviar el 95% del tráfico a la versión anterior de tu servicio y el 5% a la nueva. Una vez que haya validado que la nueva versión funciona correctamente, puede ir cambiando los porcentajes hasta que el 100% del tráfico llegue a la nueva versión de su servicio. La división del tráfico se suele usar para desplegar versiones nuevas, hacer pruebas A/B, migrar servicios, modernizar servicios antiguos y procesos similares.

A continuación, se muestra un ejemplo de enrutamiento basado en rutas implementado mediante un balanceador de carga de aplicaciones interno. Cada ruta se gestiona mediante un backend diferente.

Enrutamiento basado en rutas con balanceadores de carga de aplicación internos.
Rutas basadas en rutas con balanceadores de carga de aplicación internos.

Para obtener más información, consulta lo siguiente:

Extensibilidad con extensiones de servicio

La integración con extensiones de servicio te permite insertar lógica personalizada en la ruta de balanceo de carga de los balanceadores de carga de aplicación compatibles.

Para obtener más información, consulta Información general de las extensiones de servicio.

Migrar servicios antiguos a Google Cloud

Migrar un servicio a Google Cloud te permite liberar capacidad local y reducir el coste y la carga de mantener una infraestructura local. Puedes configurar temporalmente una implementación híbrida que te permita dirigir el tráfico tanto a tu servicio local actual como a un endpoint de servicio correspondiente. Google Cloud

En el siguiente diagrama se muestra esta configuración con un balanceador de carga de aplicaciones interno. Si usas un balanceador de carga interno, puedes configurarlo para que use la división del tráfico basada en el peso y divida el tráfico entre los dos servicios. Google Cloud La división del tráfico te permite empezar enviando el 0% del tráfico al servicioGoogle Cloud y el 100% al servicio local. Después, puedes aumentar gradualmente la proporción del tráfico enviado al servicio Google Cloud. Finalmente, envías el 100% del tráfico al servicio Google Cloud y puedes retirar el servicio local.

Migra los servicios antiguos a Google Cloud.
Migra servicios antiguos a Google Cloud.

Balanceo de carga para aplicaciones de GKE

Hay tres formas de desplegar balanceadores de carga de aplicaciones para clústeres de GKE:

Balanceo de carga para aplicaciones de Cloud Run, Cloud Run functions y App Engine

Puedes usar un balanceador de carga de aplicaciones como frontend de tus Google Cloud aplicaciones sin servidor. De esta forma, puedes configurar tus aplicaciones sin servidor para que atiendan solicitudes desde una dirección IP dedicada que no se comparta con ningún otro servicio.

Para configurarlo, utiliza un NEG sin servidor como backend del balanceador de carga. En los siguientes diagramas se muestra cómo se integra una aplicación sin servidor con un balanceador de carga de aplicaciones.

Global external

En este diagrama se muestra cómo encaja un NEG sin servidor en una arquitectura de balanceador de carga de aplicaciones externo global.

Arquitectura de balanceador de carga de aplicación externo global para aplicaciones sin servidor.
Arquitectura de balanceador de carga de aplicación externo global para aplicaciones sin servidor.

Regional externa

En este diagrama se muestra cómo se integra un NEG sin servidor en una arquitectura de balanceador de carga de aplicaciones externo regional. Este balanceador de carga solo admite backends de Cloud Run.

Arquitectura de balanceador de carga de aplicación externo regional para aplicaciones sin servidor.
Arquitectura de balanceador de carga de aplicación externo regional para aplicaciones sin servidor.

Regional interna

En este diagrama se muestra cómo se ajusta un NEG sin servidor al modelo de balanceador de carga de aplicaciones interno regional. Este balanceador de carga solo admite backends de Cloud Run.

Arquitectura de balanceador de carga de aplicación interno regional para aplicaciones sin servidor.
Arquitectura del balanceador de carga de aplicación interno regional para aplicaciones sin servidor.

Interno entre regiones

En este diagrama se muestra cómo encaja un NEG sin servidor en el modelo de balanceador de carga de aplicaciones interno entre regiones. Este balanceador de carga solo admite backends de Cloud Run.

Arquitectura de balanceador de carga de aplicación interno entre regiones para aplicaciones sin servidor.
Arquitectura de balanceador de carga de aplicación interno multirregional para aplicaciones sin servidor (haz clic para ampliar).

Documentación relacionada:

Balanceo de carga a backends externos Google Cloud

Los balanceadores de carga de aplicaciones admiten el tráfico de balanceo de carga a puntos finales que se extienden más allá de Google Cloud, como los centros de datos on-premise y otros entornos de nube. Normalmente, se puede acceder a los backends externos de una de las siguientes formas:

  • Se puede acceder a través de la red de Internet pública. En estos puntos finales, se usa un NEG de Internet como backend del balanceador de carga. El NEG de Internet se configura para que apunte a un único punto de conexión FQDN:Puerto o IP:Puerto en el backend externo. Los NEGs de Internet pueden ser globales o regionales.

    En el siguiente diagrama se muestra cómo conectarse a backends externos accesibles a través de Internet pública mediante un NEG de Internet global.

    Balanceador de carga de aplicación externo global con un backend externo.
    Balanceador de carga de aplicación externo global con un backend externo.

    Para obtener más información, consulta la descripción general de los NEGs de Internet.

  • Se puede acceder mediante conectividad híbrida (Cloud Interconnect o Cloud VPN). En estos puntos finales, se usa un NEG híbrido como backend del balanceador de carga. El NEG híbrido se configura para que apunte a los endpoints IP:Puerto del backend externo.

    En los siguientes diagramas se muestra cómo conectarse a back-ends externos a los que se puede acceder mediante Cloud Interconnect o Cloud VPN.

    Externo

    Conectividad híbrida con balanceadores de carga de aplicación externos globales.
    Conectividad híbrida con balanceadores de carga de aplicaciones externos globales.

    Interno

    Conectividad híbrida con balanceadores de carga de aplicación internos.
    Conectividad híbrida con balanceadores de carga de aplicaciones internos.

    Para obtener más información, consulta la descripción general de los NEGs híbridos.

Integración con Private Service Connect

Private Service Connect permite el consumo privado de servicios en redes de VPC que pertenecen a diferentes grupos, equipos, proyectos u organizaciones. Puedes usar Private Service Connect para acceder a las APIs y los servicios de Google, o a los servicios gestionados, de otra red de VPC.

Puedes usar un balanceador de carga de aplicaciones externo global para acceder a los servicios que se publican mediante Private Service Connect. Para obtener más información, consulta el artículo Acerca de los back-ends de Private Service Connect.

Puede usar un balanceador de carga de aplicaciones interno para enviar solicitudes a las APIs y los servicios regionales de Google compatibles. Para obtener más información, consulta Acceder a las APIs de Google a través de back-ends.

Alta disponibilidad y conmutación por error entre regiones

La conmutación por error entre regiones solo está disponible con los balanceadores de carga de aplicación externos globales, los balanceadores de carga de aplicación clásicos y los balanceadores de carga de aplicación internos entre regiones. Estos balanceadores de carga te permiten mejorar la disponibilidad del servicio cuando creas servicios de backend globales con backends en varias regiones. Si los back-ends de una región concreta no funcionan, el tráfico se transfiere a otra región de forma correcta.

Para obtener más información sobre cómo funciona la conmutación por error, consulta los siguientes temas: