Descripción general de los grupos de extremos de red sin servidores

Un grupo de extremos de red (NEG) especifica un grupo de extremos de backend para un balanceador de cargas. Un NEG sin servidores es un backend que apunta a un servicio de Cloud Run, App Engine, Cloud Run Functions o API Gateway.

Un NEG sin servidores puede representar una de las siguientes opciones:

  • Un servicio de Cloud Run o un grupo de servicios
  • Una función de Cloud Run Functions o un grupo de funciones.
  • Una app de App Engine (estándar o flexible), un servicio específico dentro de una app, una versión específica de una app o un grupo de servicios.
  • Una API Gateway que proporciona acceso a tus servicios a través de una API de REST coherente en todos los servicios, sin importar la implementación de estos. Esta función se encuentra en vista previa.

Balanceadores de cargas compatibles

En la siguiente tabla, se enumeran los productos sin servidores que admite cada balanceador de cargas de aplicaciones. Los NEG sin servidores no son compatibles con los balanceadores de cargas de red de proxy y los balanceadores de cargas de red de transferencia.

Plataforma sin servidores Balanceadores de cargas de aplicaciones
Regional
interno		 Entre regiones
interno		 Global
externo		 Clásico Regional
externo
Cloud Run
App Engine
Funciones de Cloud Run

Casos de uso

Cuando el balanceador de cargas está habilitado para apps sin servidores, puedes hacer lo siguiente:

  • Configurar la app sin servidores para entregar desde una dirección IP IPv4 dedicada que no se comparta con otros servicios
  • Asignar una sola URL a varias funciones o servicios sin servidores que entregan en el mismo dominio. En este documento, consulta Máscaras de URL.
  • Compartir el espacio de URL con otras plataformas de procesamiento de Google Cloud. Mediante el uso de varios servicios de backend, un solo balanceador de cargas puede enviar tráfico a varios tipos de backend. El balanceador de cargas selecciona el servicio de backend correcto según el host o la ruta de acceso de la URL de la solicitud.
  • Volver a usar los mismos certificados SSL y claves privadas que usas para Compute Engine, Google Kubernetes Engine y Cloud Storage. Volver a usar los mismos certificados quita la necesidad de administrar certificados separados para las apps sin servidores.

Balanceador de cargas de aplicaciones externo global y balanceador de cargas de aplicaciones clásico

La configuración de un balanceador de cargas de aplicaciones externo global o un balanceador de cargas de aplicaciones clásico permite que tus aplicaciones sin servidores se integren en los servicios en la nube existentes. También puedes realizar las siguientes acciones:

  • Proteger el servicio con Google Cloud Armor, un producto de seguridad WAF y de defensa contra DDoS de conexión de integración disponible para todos los servicios a los que se accede a través de un balanceador de cargas de aplicaciones externo. Hay algunas limitaciones asociadas con esta capacidad, en especial para Cloud Run y App Engine.
  • Habilitar el servicio para optimizar la entrega con Cloud CDN. Cloud CDN almacena en caché el contenido cerca de los usuarios. Cloud CDN proporciona capacidades como la invalidación de caché y las URL firmadas de Cloud CDN.
  • Usar la infraestructura perimetral de Google para establecer las conexiones de HTTP(S) del usuario más cerca de este, lo que disminuye la latencia.

Para obtener información sobre cómo configurar un balanceador de cargas con un backend de computación sin servidores, consulta la siguiente documentación:

La integración de un balanceador de cargas de aplicaciones externo con API Gateway permite que tus backends sin servidores aprovechen todas las funciones de Cloud Load Balancing. Para obtener más información, consulta Balanceador de cargas de aplicaciones externo para API Gateway. Si deseas configurar un balanceador de cargas de aplicaciones externo para enrutar el tráfico a una API Gateway, consulta Comienza a usar un balanceador de cargas de aplicaciones externo para API Gateway. Esta función se encuentra en Vista previa.

Balanceador de cargas de aplicaciones externo regional

El uso de un balanceador de cargas de aplicaciones externo regional te permite ejecutar cargas de trabajo con requisitos reglamentarios o de cumplimiento en los backends de Cloud Run. Por ejemplo, si necesitas que la configuración de red y la finalización del tráfico de tu aplicación residan en una región específica, un balanceador de cargas de aplicaciones externo regional suele ser la opción preferida para cumplir con los controles jurisdiccionales necesarios.

Si deseas obtener información sobre cómo configurar un balanceador de cargas de aplicaciones externo regional con un backend de computación sin servidores, consulta Configura un balanceador de cargas de aplicaciones externo regional con Cloud Run.

Balanceador de cargas de aplicaciones interno regional en comparación con el balanceador de cargas de aplicaciones interno entre regiones.

Cuando se configura un balanceador de cargas de aplicaciones interno con backends de Cloud Run, puedes hacer lo siguiente:

  • Habilita las funciones avanzadas de administración de tráfico, como la inserción de errores, las reescrituras de encabezados, los redireccionamientos, la división de tráfico y mucho más para tus servicios de Cloud Run.
  • Migra sin problemas servicios heredados de Compute Engine, GKE o entornos locales a Cloud Run y aprovecha la división del tráfico basada en el peso para cambiar el tráfico de forma gradual a Cloud Run sin tiempo de inactividad.
  • Protege tus servicios de Cloud Run con los Controles del servicio de VPC.
  • Establece un punto de entrada interno único que aplique la política para los servicios que se ejecutan en Cloud Run, Compute Engine y GKE.

Si deseas obtener información sobre cómo configurar un balanceador de cargas de aplicaciones interno regional con un backend de computación sin servidores, consulta Configura un balanceador de cargas de aplicaciones interno regional con Cloud Run.

En el resto de esta página, se analiza cómo usar NEG sin servidores con tus balanceadores de cargas de aplicaciones. Para obtener más información sobre otros tipos de NEG, consulta Descripción general de los grupos de extremos de red.

Tipos de extremos

Los NEG sin servidores no tienen extremos de red, como puertos o direcciones IP. Solo pueden apuntar a un servicio existente de Cloud Run, App Engine, API Gateway o Cloud Run Functions que resida en la misma región que el NEG.

Cuando creas un NEG sin servidores, debes especificar el nombre de dominio completamente calificado (FQDN) del servicio de Cloud Run, App Engine, API Gateway o Cloud Run Functions. El extremo es de tipo SERVERLESS. Otros tipos de extremos no son compatibles con un NEG sin servidores.

Un NEG sin servidores no puede tener más de un extremo. El extremo apunta a una aplicación sin servidores o a una máscara de URL. El balanceador de cargas funciona como frontend para la aplicación de computación sin servidores y actúa como proxy para el tráfico al extremo especificado. Sin embargo, si el servicio de backend contiene varios NEG sin servidores en diferentes regiones, el balanceador de cargas envía tráfico al NEG en la región más cercana para minimizar la latencia de la solicitud.

Nivel de red

Para los balanceadores de cargas de aplicaciones externos globales, puedes usar un NEG sin servidores en un balanceador de cargas con Niveles de servicio de red Estándar o Premium. El nivel Premium solo es necesario si deseas configurar NEG sin servidores en varias regiones.

Los balanceadores de cargas de aplicaciones externos regionales siempre son nivel Estándar.

Los balanceadores de cargas de aplicaciones internos entre regiones y los balanceadores de cargas de aplicaciones internos regionales siempre son de nivel Premium.

Componentes del balanceo de cargas

Un balanceador de cargas con un backend de NEG sin servidores requiere una configuración especial solo para el servicio de backend. La configuración de frontend es la misma que la de cualquier otro balanceador de cargas de Google Cloud basado en proxy. Además, los balanceadores de cargas de aplicaciones internos requieren una subred de solo proxy para ejecutar proxies de Envoy en tu nombre.

En los siguientes diagramas, se muestra un ejemplo de implementación de NEG sin servidores.

Global externo

En este diagrama, se muestra cómo un NEG sin servidores se ajusta a una arquitectura del balanceador de cargas de aplicaciones externo global.

Balanceador de cargas de aplicaciones externo global para apps sin servidores.
Balanceador de cargas de aplicaciones externo global para apps sin servidores (haz clic para ampliar).

Regional y externo

En este diagrama, se muestra cómo un NEG sin servidores se ajusta a una arquitectura del balanceador de cargas de aplicaciones externo regional.

Balanceador de cargas de aplicaciones externo global para apps sin servidores.
Balanceador de cargas de aplicaciones regional externo para apps sin servidores (haz clic para ampliar).

Regional interno

En este diagrama, se muestra cómo un NEG sin servidores se ajusta al modelo del balanceador de cargas de aplicaciones interno regional.

Arquitectura del balanceador de cargas de aplicaciones interno regional para apps sin servidores.
Balanceador de cargas de aplicaciones interno regional para apps sin servidores (haz clic para ampliar).

Interregión

En este diagrama, se muestra cómo un NEG sin servidores se ajusta al modelo del balanceador de cargas de aplicaciones interno entre regiones.

Balanceador de cargas de aplicaciones interno entre regiones con la implementación de Cloud Run.
Balanceador de cargas de aplicaciones interno entre regiones con la implementación de Cloud Run (haz clic para ampliar).

Componentes de frontend

No se requiere ninguna configuración especial de frontend para el balanceo de cargas con backends de NEG sin servidores. Las reglas de reenvío se usan para enrutar el tráfico por dirección IP, puerto y protocolo a un proxy de destino. Luego, el proxy de destino finaliza las conexiones de los clientes.

Los balanceadores de cargas de aplicaciones usan los mapas de URL para configurar el enrutamiento basado en URL de las solicitudes a los servicios de backend correspondientes.

Para obtener más detalles sobre cada uno de estos componentes, consulta las secciones de arquitectura de las descripciones generales de los balanceadores de cargas específicos:

Servicio de backend

Los servicios de backend proporcionan información de configuración al balanceador de cargas. Los balanceadores de cargas usan la información en el servicio de backend para dirigir el tráfico entrante a uno o más backends conectados. Los NEG sin servidores se pueden usar como backends para ciertos balanceadores de cargas.

Se aplican las siguientes restricciones según el tipo de balanceador de cargas:

  • Un servicio de backend global que usan los balanceadores de cargas de aplicaciones externos globales puede tener varios NEG sin servidores conectados a él, pero solo un NEG sin servidores por región.
  • Un servicio de backend regional que usan los balanceadores de cargas de aplicaciones internos regionales y los balanceadores de cargas de aplicaciones externos regionales solo puede tener un NEG sin servidores conectado a él.
  • Un servicio de backend global que usan los balanceadores de cargas de aplicaciones internos entre regiones solo puede tener servicios de Cloud Run adjuntos.

Cada NEG sin servidores puede apuntar a cualquiera de las siguientes opciones:

  • El FQDN para una única función o servicio
  • Una máscara de URL que apunta a varias funciones o servicios que entregan en el mismo dominio

Una máscara de URL es una plantilla de esquema de URL que indica al backend de NEG sin servidores cómo mapear la solicitud del usuario al servicio correcto. Las máscaras de URL son útiles si usas un dominio personalizado para la aplicación sin servidores y tienes varios servicios que entregan en el mismo dominio. En lugar de crear un NEG sin servidores independiente para cada función o servicio, puedes crear el NEG con una máscara de URL genérica para el dominio personalizado. Para obtener más información y ejemplos, consulta Máscaras de URL.

Para conocer las restricciones adicionales cuando se agrega un NEG sin servidores como backend, consulta Limitaciones.

Detección de valores atípicos para NEGs sin servidores

La detección de valores atípicos es una configuración opcional que se puede habilitar en un servicio de backend global que tenga NEGs sin servidores adjuntos. El análisis de detección de valores atípicos solo está disponible para un balanceador de cargas de aplicaciones interno entre regiones, un balanceador de cargas de aplicaciones externo global pero no para un balanceador de cargas de aplicaciones clásico. El análisis de detección de valores atípicos identifica los NEGs sin servidores en buen estado según sus patrones de respuesta HTTP y reduce la tasa de error mediante el enrutamiento de la mayoría de las solicitudes nuevas de los servicios en mal estado a los servicios en buen estado. Para obtener información sobre cómo funciona el algoritmo de detección de valores atípicos y comprender sus limitaciones, consulta el siguiente ejemplo.

Supongamos que hay un servicio de backend con dos NEG sin servidores conectados a él: uno en la región REGION_A y otro en la región REGION_B. Si el NEG sin servidores que funciona como backend para un balanceador de cargas de aplicaciones externo global en la región REGION_A no responde, la detección de valores atípicos identifica el NEG sin servidores como en mal estado. Según el análisis de detección de valores atípicos, algunas de las solicitudes nuevas se envían al NEG sin servidores en la región REGION_B.

Según el tipo de error de servidor que se encuentre, puedes usar uno de los siguientes métodos de detección de valores atípicos para habilitar la detección de valores atípicos:

  • Errores 5xx consecutivos. Un código de estado HTTP de serie 5xx califica como un error.
  • Errores de puerta de enlace consecutivos. Solo los códigos de estado HTTP 502, 503 y 504 califican como un error.

Ten en cuenta que, incluso después de habilitar la detección de valores atípicos, es probable que veas algunas solicitudes que se envían al servicio deteriorado y, por lo tanto, se muestran errores 5XX a los clientes. Esto se debe a que los resultados del algoritmo de detección de valores atípicos (expulsión de extremos del grupo de balanceo de cargas y mostrarlos al grupo) se ejecutan de forma independiente por cada instancia de proxy del balanceador de cargas. En la mayoría de los casos, más de una instancia de proxy controla el tráfico que recibe un servicio de backend. Por lo tanto, es posible que solo algunos de los proxies detecten y expulsen un extremo en mal estado y, mientras que esto sucede, otros proxies pueden continuar enviando solicitudes al mismo extremo en mal estado.

Para reducir aún más las tasas de error, puedes configurar parámetros de detección de valores atípicos más agresivos. Recomendamos configurar valores más altos para los límites de expulsión (outlierDetection.baseEjectionTime). Por ejemplo, nuestras pruebas muestran que configurar outlierDetection.baseEjectionTime en 180 segundos con una QPS sostenida superior a 100 da como resultado menos del 5% de tasas de error observadas. Para obtener más información sobre la API de detección de valores atípicos, consulta outlierDetection en la documentación de la API del servicio de backend global.

Los siguientes campos outlierDetection no son compatibles cuando el servicio de backend tiene un NEG sin servidores conectado a él:

  • outlierDetection.enforcingSuccessRate
  • outlierDetection.successRateMinimumHosts
  • outlierDetection.successRateRequestVolume
  • outlierDetection.successRateStdevFactor

Para obtener información sobre cómo configurar la detección de valores atípicos, consulta Configura un balanceador de cargas de aplicaciones externo global con un backend sin servidores: Habilita la detección de valores atípicos.

Máscaras de URL

Un backend de NEG sin servidores puede apuntar a un solo servicio de Cloud Run (o App Engine o Cloud Run Functions, si corresponde) o a una máscara de URL que apunte a varios servicios. Una máscara de URL es una plantilla del esquema de URL. El NEG sin servidores usa esta plantilla para asignar la solicitud al servicio correspondiente.

Las máscaras de URL son una función opcional que facilita la configuración de NEG sin servidores cuando la aplicación sin servidores consta de varios servicios de Cloud Run, Cloud Run Functions o App Engine. Los NEG sin servidores que se usan con balanceadores de cargas de aplicaciones internos solo pueden usar una máscara de URL que apunte a servicios de Cloud Run.

Las máscaras de URL son útiles si la app sin servidores está asignada a un dominio personalizado en lugar de la dirección predeterminada que proporciona Google Cloud. Con un dominio personalizado como example.com, podrías tener varios servicios implementados en diferentes subdominios o rutas de acceso en el mismo dominio. En esos casos, en lugar de crear un backend de NEG sin servidores independiente para cada servicio, puedes crear un solo NEG sin servidores con una máscara de URL genérica para el dominio personalizado (por ejemplo, example.com/<service>). El NEG extrae el nombre del servicio de la URL de la solicitud.

En la siguiente ilustración, se muestra un balanceador de cargas de aplicaciones externo con un solo servicio de backend y NEG sin servidores que usa una máscara de URL para mapear solicitudes de usuarios a diferentes servicios.

Distribución del tráfico a apps sin servidores.
Usa una máscara de URL para distribuir el tráfico a diferentes servicios (haz clic para agrandar).

Las máscaras de URL funcionan mejor cuando los servicios de la aplicación usan un esquema de URL predecible. La ventaja de usar una máscara de URL en lugar de un mapa de URL es que no necesitas crear NEG sin servidores separados para los servicios login y search. Tampoco necesitas modificar la configuración del balanceador de cargas cada vez que agregas un servicio nuevo a la aplicación.

Limitaciones

  • Un NEG sin servidores no puede tener ningún extremo de red, como una dirección IP o un puerto.
  • Los NEG sin servidores solo pueden apuntar a las aplicaciones sin servidores que residen en la misma región en la que se crea el NEG.
  • Para un balanceador de cargas que usa un backend de NEG sin servidores, el NEG sin servidores debe crearse en el mismo proyecto que los servicios de respaldo de Cloud Run, App Engine, API Gateway o Cloud Run Functions a los que apunta el NEG. Es posible que veas solicitudes que fallan si conectas un servicio que no está en el mismo proyecto que el NEG sin servidores.
  • Un balanceador de cargas configurado con un NEG sin servidores no puede detectar si la app o el servicio subyacentes sin servidores funcionan como se espera. Esto significa que, incluso si tu servicio muestra errores, el balanceador de cargas seguirá dirigiendo el tráfico hacia él. Asegúrate de probar de forma exhaustiva las versiones nuevas de los servicios antes de enrutar el tráfico de usuarios a ellos.

Limitaciones con los servicios de backend

Las siguientes limitaciones se aplican a los servicios de backend que tienen un backend de NEG sin servidores:

  • Un servicio de backend global que usan los balanceadores de cargas de aplicaciones externos globales solo puede tener un NEG sin servidores por región. Para combinar varios NEG sin servidores en un solo servicio de backend, todos los NEG deben representar implementaciones equivalentes en diferentes regiones de forma funcional. Por ejemplo, los NEG pueden apuntar al mismo servicio de Cloud Run, App Engine o Cloud Run Functions implementado en diferentes regiones.
  • Un servicio de backend global que usan los balanceadores de cargas de aplicaciones internos entre regiones solo puede tener un servicio de Cloud Run conectado a él.
  • Un servicio de backend regional solo puede tener un NEG sin servidores conectado a él.
  • La referencia del servicio entre proyectos en una implementación de VPC compartida es compatible con las configuraciones que contienen un NEG sin servidores. Para usar esta función, crea los componentes de frontend del balanceador de cargas (dirección IP, regla de reenvío, proxy de destino y mapa de URL) en un proyecto diferente de los componentes de backend del balanceador de cargas (servicio de backend y NEGs sin servidores). Ten en cuenta que el servicio de backend, los NEGs sin servidores asociados y el servicio sin servidores de respaldo (Cloud Run, App Engine, API Gateway o Cloud Run Functions) siempre deben crearse en el mismo proyecto.
  • La configuración de tiempo de espera del servicio de backend no se aplica a los servicios de backend con backends de NEG sin servidores. Intentar modificar la propiedad resource.timeoutSec del servicio de backend da como resultado el siguiente error: Timeout sec is not supported for a backend service with Serverless network endpoint groups.
    Para los servicios de backend con backends de NEG sin servidores, el tiempo de espera predeterminado es de 60 minutos. Este tiempo de espera no se puede configurar. Si tu aplicación necesita conexiones de larga duración, configura tus clientes para que reintenten las solicitudes en caso de falla.
  • Todos los NEG sin servidores combinados en un servicio de backend también deben usar el mismo tipo de backend. Esto significa que los NEG sin servidores de Cloud Run solo se pueden combinar con otros NEG sin servidores de Cloud Run, los NEG sin servidores de App Engine solo se pueden combinar con los NEG sin servidores de App Engine, etcétera.
  • No puedes mezclar NEG sin servidores con otros tipos de NEG en el mismo servicio de backend. Por ejemplo, no puedes enrutar a un clúster de GKE y un servicio de Cloud Run desde el mismo servicio de backend.
  • Cuando configuras servicios de backend que enrutan a NEG sin servidores, ciertos campos están restringidos:
    • No puedes especificar un modo de balanceo. Es decir, los valores RATE, UTILIZATION y CONNECTION no tienen efecto en la distribución de tráfico del balanceador de cargas.
    • Las verificaciones de estado no son compatibles con backends sin servidores. Por lo tanto, los servicios de backend que contienen backends de NEG sin servidores no se pueden configurar con verificaciones de estado. Sin embargo, de forma opcional, puedes habilitar la detección de valores atípicos para identificar servicios sin servidores en mal estado y enrutar las solicitudes nuevas a un servicio sin servidores en buen estado.
  • No puedes usar el comando gcloud compute backend-services edit para modificar un servicio de backend con un backend de NEG sin servidores. Como solución alternativa, usa el comando gcloud compute backend-services update en su lugar.

Se aplican limitaciones adicionales según el tipo de balanceador de cargas y el backend sin servidores.

Limitaciones con los balanceadores de cargas de aplicaciones internos regionales y los balanceadores de cargas de aplicaciones externos regionales

  • Los NEGs sin servidores que se usan con balanceadores de cargas de aplicaciones internos regionales o balanceadores de cargas de aplicaciones externos regionales solo pueden apuntar a servicios de Cloud Run.
  • Para los proyectos que usan NEG sin servidores, el límite de consultas por segundo (QPS) es de 5,000 QPS por proyecto para el tráfico enviado a cualquier NEG sin servidores configurado con balanceadores de cargas de aplicaciones externos regionales o balanceadores de cargas de aplicaciones internos regionales. Este límite se agrega en todos los balanceadores de cargas de aplicaciones externos regionales y balanceadores de cargas de aplicaciones internos regionales en el proyecto. Este no es un límite por balanceador de cargas.

Limitaciones con balanceadores de cargas de aplicaciones internos entre regiones

  • Los NEGs sin servidores que se usan con balanceadores de cargas de aplicaciones internos entre regiones solo pueden apuntar a servicios de Cloud Run.

Limitaciones con balanceadores de cargas de aplicaciones externos globales

En esta sección, se enumeran las limitaciones que encontrarás cuando configures NEG sin servidores con balanceadores de cargas de aplicaciones externos globales.

Limitaciones con App Engine

  • Los balanceadores de cargas de aplicaciones externos globales con backends del entorno flexible de App Engine no admiten el uso de la referencia de servicios entre proyectos. Compatible con el entorno estándar de App Engine.

Limitaciones con Cloud Run

Limitaciones con Cloud Run Functions

  • IAP no funciona con Cloud Run Functions.

Limitaciones con App Engine

  • App Engine no admite el balanceo de cargas multirregión. Esto se debe a que App Engine requiere 1 región por proyecto.
  • Solo se permite una política de IAP en la ruta de la solicitud. Por ejemplo, si ya configuraste una política de IAP en el servicio de backend, no debes establecer otra en la app de App Engine.
  • Te recomendamos usar controles de entrada para que la app solo reciba solicitudes enviadas desde el balanceador de cargas (y la VPC, si la usas). De lo contrario, los usuarios pueden usar la URL de App Engine de tu app para omitir el balanceador de cargas, las políticas de seguridad de Google Cloud Armor, los certificados SSL y las claves privadas que se pasan a través del balanceador de cargas.

Limitaciones con API Gateway

Para obtener más información, consulta Limitaciones en los NEG sin servidores y API Gateway.

Limitaciones con las funciones de administración del tráfico

  • Las funciones de administración avanzada de tráfico, como la política de localidad del balanceo de cargas, la afinidad de sesión y la detección de valores atípicos, no son compatibles con los backends de NEG sin servidores.
  • Especificar una afinidad de sesión en un servicio de backend con un backend de NEG sin servidores no funcionará. Como solución alternativa para Cloud Run, usa su función específica de afinidad de sesión.

Precios

Para ver la información de precios de los balanceadores de cargas con NEG sin servidores, consulta Todos los precios de herramientas de redes: Cloud Load Balancing.

¿Qué sigue?