Descripción general de los grupos de puntos finales de red sin servidor

Un grupo de endpoints de red (NEG) especifica un grupo de endpoints de backend para un balanceador de carga. Un NEG sin servidor es un backend que apunta a un recurso de Cloud Run, App Engine, Cloud Run functions o API Gateway.

Un NEG sin servidor puede representar uno de los siguientes elementos:

  • Un recurso de Cloud Run o un grupo de recursos.
  • Una función o un grupo de funciones de Cloud Run (antes, Cloud Run Functions de 2.ª gen.).
  • Una función de Cloud Run (1.ª gen.) o un grupo de funciones
  • Una aplicación del entorno estándar o del entorno flexible de App Engine, un servicio específico de una aplicación, una versión específica de una aplicación o un grupo de servicios.
  • Una API Gateway que proporciona acceso a tus servicios a través de una API REST coherente en todos los servicios, independientemente de la implementación del servicio. Esta función está en versión preliminar.

Balanceadores de carga admitidos

En la siguiente tabla se indican los productos sin servidor compatibles con cada balanceador de carga de aplicaciones. Los NEGs sin servidor no son compatibles con los balanceadores de carga de red de proxy ni con los balanceadores de carga de red con paso a través.

Tipo de NEG sin servidor Balanceadores de carga de aplicación
Regional
internal		 Entre regiones
interno		 Global
externo		 Clásico Regional
externa

Cloud Run

Compatible con Cloud Run y Cloud Run Functions (2.ª gen.)
App Engine

Cloud Functions

Admite funciones de Cloud Run (1.ª gen.), antes conocidas como Cloud Functions (1.ª gen.)

Casos prácticos

Cuando el balanceador de carga esté habilitado para aplicaciones sin servidor, podrás hacer lo siguiente:

  • Configura tu aplicación sin servidor para que sirva contenido desde una dirección IP IPv4 dedicada que no se comparta con otros servicios.
  • Asigna una sola URL a varias funciones o servicios sin servidor que se ejecuten en el mismo dominio. Consulta Máscaras de URL en este documento.
  • Compartir el espacio de URLs con otras plataformas de computación de Google Cloud . Si se usan varios servicios de backend, un único balanceador de carga puede enviar tráfico a varios tipos de backend. El balanceador de carga selecciona el servicio de backend correcto en función del host o la ruta de la URL de la solicitud.
  • Reutiliza los mismos certificados SSL y claves privadas que usas en Compute Engine, Google Kubernetes Engine y Cloud Storage. Al reutilizar los mismos certificados, no es necesario gestionar certificados independientes para las aplicaciones sin servidor.

Balanceador de carga de aplicación externo global y balanceador de carga de aplicación clásico

Configurar un balanceador de carga de aplicación externo global o un balanceador de carga de aplicación clásico permite que tus aplicaciones sin servidor se integren con los servicios en la nube. Puedes hacer lo siguiente:

  • Protege tu servicio con Google Cloud Armor, un producto de seguridad de WAF y defensa contra ataques DDoS perimetrales disponible para todos los servicios a los que se accede a través de un balanceador de carga de aplicaciones externo. Esta función tiene algunas limitaciones, sobre todo en Cloud Run y App Engine.
  • Habilita tu servicio para optimizar la entrega mediante Cloud CDN. Cloud CDN almacena el contenido en caché cerca de los usuarios. Cloud CDN ofrece funciones como la invalidación de caché y las URLs firmadas de Cloud CDN.
  • Usa la infraestructura perimetral de Google para finalizar las conexiones HTTP(S) de los usuarios más cerca de ellos, lo que reduce la latencia.

Para saber cómo configurar un balanceador de carga con un backend de computación sin servidor, consulta la siguiente documentación:

Al integrar un balanceador de carga de aplicaciones externo con API Gateway, tus backends sin servidor pueden aprovechar todas las funciones que ofrece Cloud Load Balancing. Para obtener más información, consulta Balanceador de carga de aplicación externo para API Gateway. Para configurar un balanceador de carga de aplicación externo que dirija el tráfico a una API Gateway, consulta Primeros pasos con un balanceador de carga de aplicación externo para API Gateway. Esta función está en versión preliminar.

Balanceador de carga de aplicación externo regional

Con un balanceador de carga de aplicaciones externo regional, puedes ejecutar cargas de trabajo con requisitos normativos o de cumplimiento en backends de Cloud Run o Cloud Run functions (2.ª gen.). Por ejemplo, si necesitas que las configuraciones de red de tu aplicación y la terminación del tráfico se encuentren en una región específica, un balanceador de carga de aplicación externo regional suele ser la opción preferida para cumplir los controles jurisdiccionales necesarios.

Para saber cómo configurar un balanceador de carga de aplicaciones externo regional con un backend de computación sin servidor, consulta Configurar un balanceador de carga de aplicaciones externo regional con Cloud Run.

Balanceador de carga de aplicación interno regional y balanceador de carga de aplicación interno entre regiones

Cuando se configura un balanceador de carga de aplicaciones interno con backends de Cloud Run o Cloud Run functions (2.ª gen.), puedes hacer lo siguiente:

  • Habilita las funciones avanzadas de gestión del tráfico, como la inyección de fallos, la reescritura de encabezados, las redirecciones, la división del tráfico y más, para tus servicios de Cloud Run y Cloud Functions (2.ª gen.).
  • Migra sin problemas los servicios antiguos de Compute Engine, GKE u on-premise a Cloud Run y Cloud Functions (2.ª gen.) para aprovechar la división del tráfico basada en el peso y transferir gradualmente el tráfico a Cloud Run sin tiempo de inactividad.
  • Protege tus servicios de Cloud Run y Cloud Run functions (2.ª gen.) con loscontroles de servicio de VPC.
  • Establece un único punto de entrada interno que aplique las políticas para tus servicios que se ejecutan en Cloud Run, Cloud Run Functions (2.ª gen.), Compute Engine y GKE.

Para saber cómo configurar un balanceador de carga de aplicaciones interno regional con un backend de computación sin servidor, consulta Configurar un balanceador de carga de aplicaciones interno regional con Cloud Run.

En el resto de esta página se explica cómo usar los NEG sin servidor con los balanceadores de carga de aplicaciones. Para obtener más información sobre otros tipos de NEGs, consulta la información general sobre los grupos de puntos finales de red.

Tipos de endpoints

Los NEGs sin servidor no tienen ningún endpoint de red, como puertos o direcciones IP. Solo pueden apuntar a un recurso de Cloud Run, App Engine, API Gateway o funciones de Cloud Run que se encuentre en la misma región que el NEG.

Cuando creas un NEG sin servidor, especificas el nombre de dominio completo (FQDN) del recurso de Cloud Run, App Engine, API Gateway o Cloud Functions. El endpoint es de tipo SERVERLESS. No se admiten otros tipos de endpoint en un NEG sin servidor.

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

Nivel de red

En el caso de los balanceadores de carga de aplicación externos globales, puedes usar un NEG sin servidor en un balanceador de carga con los niveles de servicio de red Estándar o Premium. El nivel Premium solo es necesario si quieres configurar NEGs sin servidor en varias regiones.

Los balanceadores de carga de aplicación externos regionales siempre son de nivel Standard.

Los balanceadores de carga de aplicación internos entre regiones y los balanceadores de carga de aplicación internos regionales siempre son de nivel Premium.

Componentes del balanceo de carga

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

En los siguientes diagramas se muestra una implementación de NEG sin servidor de ejemplo.

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.

Balanceador de carga de aplicación externo global para aplicaciones sin servidor.
Balanceador de carga de aplicaciones externo global para aplicaciones sin servidor (haz clic en la imagen para ampliarla).

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.

Balanceador de carga de aplicación externo regional para aplicaciones sin servidor.
Balanceador de carga de aplicación externo regional para aplicaciones sin servidor (haz clic para ampliar).

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.

Balanceador de carga de aplicaciones interno regional para aplicaciones sin servidor.
Balanceador de carga de aplicación interno regional para aplicaciones sin servidor (haz clic en la imagen para ampliarla).

Interregional

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

Balanceador de carga de aplicación interno entre regiones con un despliegue de Cloud Run.
Balanceador de carga de aplicación interno entre regiones con despliegue de Cloud Run (haz clic para ampliar).

Componentes de frontend

No es necesario configurar el frontend de forma especial para balancear la carga con backends de NEG sin servidor. Las reglas de reenvío se usan para dirigir el tráfico a un proxy de destino según la dirección IP, el puerto y el protocolo. A continuación, el proxy de destino finaliza las conexiones de los clientes.

Los mapas de URLs se usan en los balanceadores de carga de aplicaciones para configurar el enrutamiento de solicitudes basado en URLs a los servicios de backend adecuados.

Para obtener más información sobre cada uno de estos componentes, consulta las secciones de arquitectura de los resúmenes de los balanceadores de carga específicos:

Servicio de backend

Los servicios de backend proporcionan información de configuración al balanceador de carga. Los balanceadores de carga usan la información de un servicio de backend para dirigir el tráfico entrante a uno o varios backends vinculados. Los NEG sin servidor se pueden usar como backends de determinados balanceadores de carga.

Se aplican las siguientes restricciones en función del tipo de balanceador de carga:

  • Un servicio de backend global usado por balanceadores de carga de aplicaciones externos globales puede tener varios NEGs sin servidor asociados, pero solo un NEG sin servidor por región.
  • Un servicio de backend regional usado por balanceadores de carga de aplicación internos regionales y balanceadores de carga de aplicación externos regionales solo puede tener un NEG sin servidor asociado.
  • Un servicio de backend global usado por balanceadores de carga de aplicaciones internos entre regiones solo puede tener recursos de Cloud Run y Cloud Run functions (2.ª gen.) asociados.

Cada NEG sin servidor puede apuntar a uno de los siguientes elementos:

  • El FQDN de un solo recurso
  • Una máscara de URL que apunta a varios recursos que se sirven en el mismo dominio

Una máscara de URL es una plantilla de esquema de URL que indica al backend del NEG sin servidor cómo asignar la solicitud del usuario al servicio correcto. Las máscaras de URL son útiles si usas un dominio personalizado para tu aplicación sin servidor y tienes varios servicios que se ofrecen en el mismo dominio. En lugar de crear un NEG sin servidor independiente para cada recurso, puede 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 ver las restricciones adicionales que se aplican al añadir un NEG sin servidor como backend, consulta Limitaciones.

Detección de valores atípicos en NEGs sin servidor

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 servidor asociados. El análisis de detección de valores atípicos solo está disponible para los balanceadores de carga de aplicación internos entre regiones y los balanceadores de carga de aplicación externos globales, pero no para los balanceadores de carga de aplicación clásicos. El análisis de detección de valores atípicos identifica los grupos de puntos finales de red sin servidor que no están en buen estado en función de sus patrones de respuesta HTTP y reduce la tasa de errores al enrutar la mayoría de las solicitudes nuevas de recursos que no están en buen estado a recursos que sí lo están. Para saber cómo funciona el algoritmo de detección de valores atípicos y conocer sus limitaciones, consulta el siguiente ejemplo.

Supongamos que hay un servicio de backend con dos NEGs sin servidor asociados: uno en la región REGION_A y otro en la región REGION_B. Si el NEG sin servidor que actúa como backend de un balanceador de carga de aplicaciones externo global en la región REGION_A no responde, la detección de valores atípicos lo identificará como no operativo. Según el análisis de detección de valores atípicos, algunas de las nuevas solicitudes se envían al NEG sin servidor de la región REGION_B.

En función del tipo de error del servidor que se produzca, puede usar uno de los siguientes métodos de detección de valores atípicos para habilitarla:

  • Errores 5xx consecutivos. Los códigos de estado HTTP de la serie 5xx se consideran errores.
  • Errores de pasarela consecutivos. Solo los códigos de estado HTTP 502, 503 y 504 se consideran errores.

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 recurso no disponible y, por lo tanto, devuelvan errores 5XX a los clientes. Esto se debe a que los resultados del algoritmo de detección de valores atípicos (expulsión de endpoints del grupo de balanceo de carga y devolución al grupo) se ejecutan de forma independiente en cada instancia de proxy del balanceador de carga. En la mayoría de los casos, más de una instancia de proxy gestiona el tráfico recibido por un servicio backend. Por lo tanto, es posible que solo algunos de los proxies detecten y expulsen un endpoint en mal estado, mientras que otros proxies sigan enviando solicitudes al mismo endpoint.

Para reducir aún más las tasas de error, puedes configurar parámetros de detección de valores atípicos más agresivos. Te recomendamos que configures valores más altos para los umbrales de expulsión (outlierDetection.baseEjectionTime). Por ejemplo, nuestras pruebas muestran que si se define outlierDetection.baseEjectionTime en 180 segundos con un QPS sostenido superior a 100, se obtienen tasas de error observadas inferiores al 5 %. 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 de outlierDetection no se admiten cuando el servicio backend tiene un NEG sin servidor asociado:

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

Para saber cómo configurar la detección de valores atípicos, consulta Configurar un balanceador de carga de aplicación externo global con un backend sin servidor: habilitar la detección de valores atípicos.

Máscaras de URL

Un backend de NEG sin servidor puede apuntar a un solo recurso de Cloud Run (o App Engine o Cloud Run Functions, si procede) o a una máscara de URL que apunte a varios recursos. Una máscara de URL es una plantilla de su esquema de URL. El NEG sin servidor usa esta plantilla para asignar la solicitud al recurso adecuado.

Las máscaras de URL son una función opcional que facilita la configuración de los NEGs sin servidor cuando tu aplicación sin servidor se compone de varios recursos de Cloud Run, Cloud Functions o App Engine. Los NEGs sin servidor que se usan con balanceadores de carga de aplicaciones internos solo pueden usar una máscara de URL que dirija a servicios de Cloud Run o Cloud Functions (2.ª gen.).

Las máscaras de URL son útiles si tu aplicación sin servidor se asigna a un dominio personalizado en lugar de a la dirección predeterminada que proporciona Google Cloud . Con un dominio personalizado como example.com, puedes tener varios recursos desplegados en diferentes subdominios o rutas del mismo dominio. En estos casos, en lugar de crear un backend de NEG sin servidor independiente para cada recurso, puedes crear un único NEG sin servidor 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 carga de aplicaciones externo con un único servicio de backend y un NEG sin servidor que usa una máscara de URL para asignar solicitudes de usuarios a diferentes servicios.

Distribuir tráfico a aplicaciones sin servidor.
Uso de una máscara de URL para distribuir el tráfico a diferentes servicios (haz clic en la imagen para ampliarla).

Las máscaras de URL funcionan mejor cuando los recursos de tu aplicación usan un esquema de URL predecible. La ventaja de usar una máscara de URL en lugar de un mapa de URLs es que no tienes que crear NEGs sin servidor independientes para los servicios login y search. Tampoco es necesario que modifiques la configuración del balanceador de carga cada vez que añadas un recurso nuevo a tu aplicación.

Limitaciones

  • Un NEG sin servidor no puede tener ningún endpoint de red, como una dirección IP o un puerto.
  • Los NEGs sin servidor solo pueden apuntar a recursos sin servidor que se encuentren en la misma región en la que se crea el NEG.
  • En el caso de un balanceador de carga que utilice un backend de NEG sin servidor, el NEG sin servidor debe crearse en el mismo proyecto que los recursos de Cloud Run, App Engine, API Gateway o Cloud Run functions a los que apunta el NEG. Es posible que las solicitudes fallen si conectas un servicio que no está en el mismo proyecto que el NEG sin servidor.
  • Un balanceador de carga configurado con un NEG sin servidor no puede detectar si el recurso sin servidor subyacente funciona correctamente. Esto significa que, aunque tu recurso devuelva errores, el balanceador de carga seguirá dirigiendo tráfico a él. Asegúrate de probar a fondo las nuevas versiones de tus recursos antes de dirigir el tráfico de usuarios a ellas.

Limitaciones de los servicios de backend

Se aplican las siguientes limitaciones a los servicios de backend que tienen un backend de NEG sin servidor:

  • Un servicio de backend global usado por balanceadores de carga de aplicación externos globales solo puede tener un NEG sin servidor por región. Para combinar varios NEGs sin servidor en un solo servicio de backend, todos los NEGs deben representar implementaciones funcionalmente equivalentes en diferentes regiones. Por ejemplo, los NEGs pueden apuntar al mismo recurso de Cloud Run, App Engine o Cloud Functions desplegado en diferentes regiones.
  • Un servicio de backend global que usan los balanceadores de carga de aplicaciones internos entre regiones solo puede tener asociado un recurso de Cloud Run o Cloud Run functions (2.ª gen.).
  • Un servicio de backend regional solo puede tener un NEG sin servidor asociado.
  • La referencia de servicios entre proyectos en una implementación de VPC compartida se admite con configuraciones que contienen un NEG sin servidor. Para usar esta función, debes crear los componentes de frontend del balanceador de carga (dirección IP, regla de reenvío, proxy de destino y mapa de URLs) en un proyecto diferente de los componentes de backend del balanceador de carga (servicio de backend y NEGs sin servidor). Ten en cuenta que el servicio de backend, los NEGs sin servidor asociados y el recurso sin servidor subyacente (Cloud Run, App Engine, API Gateway o Cloud Run Functions) siempre se deben crear en el mismo proyecto.
  • El ajuste de tiempo de espera del servicio de backend no se aplica a los servicios de backend con backends de NEG sin servidor. Si intentas modificar la propiedad resource.timeoutSec del servicio backend, se producirá el siguiente error: Timeout sec is not supported for a backend service with Serverless network endpoint groups.
    En el caso de los servicios de backend con backends de NEG sin servidor, 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 vuelvan a intentar enviar solicitudes en caso de error.
  • Todos los NEGs sin servidor combinados en un servicio de backend también deben usar el mismo tipo de backend. Esto significa que los NEGs sin servidor de Cloud Run solo se pueden combinar con otros NEGs sin servidor de Cloud Run, y los NEGs sin servidor de App Engine solo se pueden combinar con otros NEGs sin servidor de App Engine.
  • No puedes mezclar NEGs sin servidor con otros tipos de NEGs en el mismo servicio de backend. Por ejemplo, no puedes enrutar a un clúster de GKE y a un servicio de Cloud Run desde el mismo servicio de backend.
  • Al configurar servicios de backend que se dirigen a NEGs sin servidor, se restringen ciertos campos:
    • No puedes especificar un modo de balanceo. Es decir, los valores RATE, UTILIZATION y CONNECTION no tienen ningún efecto en la distribución del tráfico del balanceador de carga.
    • Las comprobaciones de estado no se admiten en back-ends sin servidor. Por lo tanto, los servicios de backend que contengan backends de NEG sin servidor no se pueden configurar con comprobaciones de estado. Sin embargo, puedes habilitar la detección de valores atípicos para identificar los recursos sin servidor que no estén en buen estado y dirigir las nuevas solicitudes a un recurso sin servidor que sí lo esté.
  • No puedes usar el comando gcloud compute backend-services edit para modificar un servicio de backend con un backend de NEG sin servidor. Como solución alternativa, usa el comando gcloud compute backend-services update.

Se aplican limitaciones adicionales en función del tipo de balanceador de carga y del backend sin servidor.

Limitaciones de los balanceadores de carga de aplicaciones internos regionales y los balanceadores de carga de aplicaciones externos regionales

  • Los NEG sin servidor que se usan con balanceadores de carga de aplicaciones internos regionales o balanceadores de carga de aplicaciones externos regionales solo pueden dirigir a recursos de Cloud Run o Cloud Run Functions (2.ª gen.).
  • En los proyectos que usan NEGs sin servidor, el límite de consultas por segundo (CPS) es de 5000 CPS por proyecto para el tráfico enviado a cualquier NEG sin servidor configurado con balanceadores de carga de aplicaciones externos regionales o balanceadores de carga de aplicaciones internos regionales. Este límite se agrega en todos los balanceadores de carga de aplicaciones externos regionales y los balanceadores de carga de aplicaciones internos regionales del proyecto. No se trata de un límite por balanceador de carga.

Limitaciones de los balanceadores de carga de aplicación internos entre regiones

  • Los NEGs sin servidor que se usan con balanceadores de carga de aplicaciones internos multirregión solo pueden dirigir a recursos de Cloud Run o Cloud Run Functions (2.ª gen.).

Limitaciones de los balanceadores de carga de aplicación externos globales

En esta sección se indican las limitaciones que encontrarás al configurar NEGs sin servidor con balanceadores de carga de aplicación externos globales.

Limitaciones de Cloud Run

Limitaciones de App Engine

  • El balanceo de carga multirregional no es compatible con App Engine. Esto se debe a que App Engine requiere una región por proyecto.
  • Si usas IAP, debes usar el mismo ID de cliente de OAuth para todos los servicios de App Engine asociados a un único balanceador de carga.
  • Solo se permite una política de IAP en la ruta de la solicitud. Por ejemplo, si ya has definido una política de IAP en el servicio backend, no debes definir otra política de IAP en la aplicación App Engine.
  • Los balanceadores de carga de aplicación externos globales con backends del entorno flexible de App Engine y backends del entorno estándar de App Engine no admiten la referencia a servicios entre proyectos.
  • Te recomendamos que uses controles de entrada para que tu aplicación solo reciba solicitudes enviadas desde el balanceador de carga (y la VPC, si la usas). De lo contrario, los usuarios podrán usar la URL de App Engine de tu aplicación para saltarse el balanceador de carga, las políticas de seguridad de Cloud Armor, los certificados SSL y las claves privadas que se transfieren a través del balanceador de carga.

Limitaciones de API Gateway

Para obtener más información, consulta Limitaciones de los NEGs sin servidor y de API Gateway.

Limitaciones de las funciones de gestión del tráfico

Precios

Para ver información sobre los precios de los balanceadores de carga con grupos de puntos finales de red sin servidor, consulta Todos los precios de redes: Cloud Load Balancing.

Siguientes pasos