Équilibrage de charge HTTP(S) pour API Gateway

Grâce à l'intégration de l'équilibrage de charge HTTP(S) Google Cloud avec API Gateway, vos backends sans serveur peuvent bénéficier de toutes les fonctionnalités fournies par Cloud Load Balancing. En combinant la passerelle API et l'équilibrage de charge HTTP(S) à l'aide d'un groupe de points de terminaison du réseau sans serveur (NEG sans serveur), vous pouvez:

  • Héberger des passerelles hôtes avec domaines de marque personnalisés
  • Configurer le protocole TLS pour les passerelles à l'aide de certificats émis par l'autorité de certification de votre choix
  • Créer un point d'entrée commun pour le routage d'une passerelle vers plusieurs backends
  • Déployer des passerelles dans plusieurs régions pour assurer une haute disponibilité sans avoir à gérer des URL pour chaque région
  • Protéger les passerelles avec Cloud Armor
  • Améliorer le temps de réponse de la passerelle en tirant parti de Cloud CDN

Utiliser un groupe de points de terminaison du réseau sans serveur pour API Gateway

Un groupe de points de terminaison du réseau (NEG) spécifie un groupe de points de terminaison backend pour un équilibreur de charge. Un NEG sans serveur est un backend qui pointe vers un backend sans serveur hébergé par Google, comme Cloud Run, App Engine ou API Gateway. Un backend de NEG sans serveur pour API Gateway peut représenter les éléments suivants:

  • Une instance API Gateway
  • Un groupe de passerelles configurées avec la même configuration d'API

La figure ci-dessous montre comment les NEG sans serveur peuvent être utilisés dans le modèle Cloud Load Balancing :

Schéma d'un groupe de points de terminaison du réseau sans serveur comme backend de passerelles multirégionales

Comme illustré ci-dessus, un service de backend peut être géré par plusieurs NEG sans serveur. Chaque NEG sans serveur peut contenir une seule instance de passerelle API ou utiliser un masque d'URL pour pointer vers plusieurs passerelles. Étant donné que tous les NEG agissant en tant que service de backend sont utilisés pour l'équilibrage de charge, ils doivent représenter des déploiements de passerelle fonctionnellement équivalents. Par exemple, la même configuration d'API doit être déployée sur chaque passerelle dans des régions différentes pour tous les NEG. Si un service de backend contient plusieurs NEG, l'équilibreur de charge équilibre le trafic entre ces NEG tout en minimisant la latence des requêtes.

Limites sur les NEG sans serveur et API Gateway

Quelques limites doivent être prises en compte lorsque vous utilisez des NEG sans serveur afin d'intégrer Cloud Load Balancing pour API Gateway. En particulier:

  • Les NEG sans serveur ne peuvent pas être associés à des points de terminaison de réseau, tels que des adresses IP ou des ports.
  • Les NEG sans serveur peuvent uniquement pointer vers des instances API Gateway résidant dans la même région que le NEG.
  • Les NEG sans serveur peuvent uniquement pointer vers des instances API Gateway créées dans le même projet que l'équilibreur de charge à l'aide du backend de NEG sans serveur.
  • API Gateway n'est pas encore compatible avec les paramètres de contrôle Ingress. Par conséquent, il n'existe aucun moyen de désactiver l'accès à votre API Gateway via une URL de passerelle générée par le service et de vous assurer que l'ensemble du trafic est géré par l'équilibreur de charge.

Pour en savoir plus sur les restrictions concernant les NEG sans serveur et les services de backend en général, consultez la section Limites.

Limites applicables aux NEG sans serveur dans les configurations de service de backend

Un service de backend définit la manière dont Cloud Load Balancing répartit le trafic. La configuration du service de backend contient un ensemble de valeurs, telles que le protocole utilisé pour se connecter aux backends, divers paramètres de distribution et de session, des vérifications d'état et des délais avant expiration. Pour les NEG sans serveur utilisés en tant que service de backend pour API Gateway, ces paramètres permettent de contrôler précisément le comportement de votre équilibreur de charge.

La définition des ressources d'un service de backend a les conséquences suivantes pour votre conception d'équilibrage de charge :

  • Les NEG sans serveur ne peuvent pas être utilisés avec d'autres types de NEG dans le même service de backend. Par exemple, vous ne pouvez pas acheminer le trafic vers un cluster GKE et une instance API Gateway à partir du même service de backend.
  • Tous les NEG sans serveur combinés dans un service de backend doivent utiliser le même type de backend. Cela signifie que les NEG sans serveur API Gateway ne peuvent être combinés qu'avec d'autres NEG sans serveur API Gateway, les NEG sans serveur App Engine ne peuvent être combinés qu'avec des NEG sans serveur App Engine, etc.
  • Un service de backend ne peut contenir qu'un seul NEG sans serveur par région.

Lorsque vous définissez une configuration de service de backend qui dirige vers un NEG sans serveur, les limitations suivantes s'appliquent :

  • Impossible de spécifier balancingMode.
  • Le champ healthCheck doit être vide et ne peut pas être spécifié.
  • Les ports ne peuvent pas être spécifiés.
  • Seuls les protocoles HTTP et HTTPS sont acceptés.
  • Les valeurs spécifiées dans les champs associés à utilization ou connection ne sont pas acceptées.

Les champs IAP, cdnPolicy et securityPolicy de la configuration du service de backend sont valides pour les NEG sans serveur. Ces champs peuvent être utilisés pour configurer respectivement Identity-Aware Proxy, Cloud CDN et Cloud Armor avec votre service API Gateway.

Étape suivante