Balanceo de carga para API Gateway

La integración del balanceador de carga de aplicaciones externo global y del balanceador de carga de aplicaciones clásico con API Gateway permite que tus backends sin servidor aprovechen todas las funciones que ofrece Cloud Load Balancing. Si combinas API Gateway con un balanceador de carga de aplicaciones externo global o un balanceador de carga de aplicaciones clásico mediante un grupo de puntos finales de red (NEG) sin servidor, puedes hacer lo siguiente:

  • Alojar pasarelas con dominios de marca personalizados
  • Configurar TLS para las pasarelas con certificados emitidos por una autoridad de certificación preferida
  • Crear un punto de entrada común para una pasarela que enruta a varios back-ends
  • Despliega pasarelas en varias regiones geográficas para conseguir una alta disponibilidad sin tener que gestionar las URLs de cada región.
  • Proteger las pasarelas con Cloud Armor
  • Mejorar el tiempo de respuesta de la pasarela aprovechando Cloud CDN

Usar un NEG sin servidor para API Gateway

Un grupo de puntos finales 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 backend sin servidor alojado en Google, como Cloud Run, App Engine o API Gateway. Un backend de NEG sin servidor para API Gateway puede representar lo siguiente:

  • Una instancia de API Gateway
  • Un grupo de pasarelas configuradas con la misma configuración de API

En la siguiente figura se muestra cómo se pueden usar los NEGs sin servidor en el modelo de Cloud Load Balancing:

Diagrama de NEG sin servidor como backend de pasarelas multirregión

Como se ha ilustrado en un ejemplo anterior, un servicio backend puede gestionarse mediante varios NEG sin servidor. Cada NEG sin servidor puede contener una sola instancia de API Gateway o usar una máscara de URL para dirigir a varias pasarelas. Como todos los NEGs que actúan como un servicio de backend se usan para el balanceo de carga, deben representar implementaciones de pasarela funcionalmente equivalentes. Por ejemplo, todas las NEGs deben tener la misma configuración de API desplegada en cada pasarela de diferentes regiones. Si un servicio de backend contiene varios NEGs, el balanceador de carga equilibrará el tráfico entre ellos y minimizará la latencia de las solicitudes.

Limitaciones de los NEGs sin servidor y API Gateway

Debes tener en cuenta algunas limitaciones al usar NEGs sin servidor para integrar Cloud Load Balancing en API Gateway. En particular:

  • Los NEG sin servidor no pueden tener ningún endpoint de red asociado, como direcciones IP o puertos.
  • Los NEGs sin servidor solo pueden apuntar a instancias de API Gateway que residan en la misma región en la que se crea el NEG.
  • Los NEGs sin servidor solo pueden apuntar a instancias de API Gateway creadas en el mismo proyecto que el balanceador de carga que usa el backend del NEG sin servidor.
  • API Gateway no admite la configuración de control de entrada. Por lo tanto, no hay forma de inhabilitar el acceso a tu API Gateway mediante una URL de gateway generada por el servicio y asegurarte de que el balanceador de carga gestione todo el tráfico.

Para obtener más información sobre las restricciones relativas a los NEGs sin servidor y los servicios backend en general, consulta Limitaciones.

Limitaciones de los NEGs sin servidor en las configuraciones de servicios de backend

Un servicio de backend define cómo distribuye el tráfico Cloud Load Balancing. La configuración del servicio de backend contiene un conjunto de valores, como el protocolo usado para conectarse a los backends, varios ajustes de distribución y de sesión, comprobaciones de estado y tiempos de espera. En el caso de las NEGs sin servidor que se usan como servicio de backend de API Gateway, estos ajustes proporcionan un control pormenorizado sobre el comportamiento del balanceador de carga.

La definición de recursos de un servicio de backend tiene las siguientes implicaciones para el diseño del balanceo de carga:

  • Los NEG sin servidor no se pueden usar con otros tipos de NEG en el mismo servicio de backend. Por ejemplo, no puedes enrutar a un clúster de GKE y a una instancia de API Gateway desde el mismo servicio de backend.
  • Todos los NEGs sin servidor combinados en un servicio de backend deben usar el mismo tipo de backend. Esto significa que los NEGs sin servidor de API Gateway solo se pueden combinar con otros NEGs sin servidor de API Gateway, y los NEGs sin servidor de App Engine solo se pueden combinar con otros NEGs sin servidor de App Engine.
  • Un servicio de backend solo puede contener un NEG sin servidor por región.

Cuando se define una configuración de servicio de backend que se dirige a un NEG sin servidor, se aplican las siguientes limitaciones de campo:

  • No se puede especificar balancingMode
  • El campo healthCheck debe estar vacío y no se puede especificar.
  • No se pueden especificar puertos
  • Solo se admiten los protocolos HTTP y HTTPS.
  • No se admiten los valores especificados en los campos relacionados con utilization o connection.

Los campos IAP, cdnPolicy y securityPolicy de la configuración del servicio de backend son válidos para los NEGs sin servidor. Estos campos se pueden usar para configurar Identity-Aware Proxy, Cloud CDN y Cloud Armor respectivamente con tu servicio API Gateway.

Siguientes pasos