Équilibrage de charge HTTP(S) pour API Gateway

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

L'intégration de la compatibilité avec l'équilibrage de charge HTTP(S) Google Cloud pour API Gateway permet à vos backends sans serveur de tirer parti de toutes les fonctionnalités fournies par Cloud Load Balancing. En combinant API Gateway 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 TLS pour les passerelles à l'aide de certificats émis par une autorité de certification préférée
  • 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 NEG 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, tel que Cloud Run, App Engine ou API Gateway. Un backend de NEG sans serveur pour API Gateway peut représenter :

  • 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 API Gateway 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 passerelles fonctionnellement équivalents. Par exemple, tous les NEG doivent avoir la même configuration d'API déployée sur chaque passerelle dans différentes régions. 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

Vous devez tenir compte de quelques limites lors de l'utilisation de NEG sans serveur pour intégrer Cloud Load Balancing pour API Gateway. Plus précisément :

  • 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 d'entrée. Par conséquent, il n'existe aucun moyen de désactiver l'accès à votre passerelle API via une URL de passerelle générée par le service et de vous assurer que tout le 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 page 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 répartition et de gestion des sessions, les vérifications d'état et les délais avant expiration. Pour les NEG sans serveur utilisés en tant que service de backend pour API Gateway, ces paramètres permettent un contrôle précis du 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 accéder à 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 associés qu'à d'autres NEG sans serveur API Gateway, que les NEG sans serveur App Engine ne peuvent être associés qu'à 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.
  • Les journaux ne sont disponibles que pour les protocoles HTTP et HTTPS.
  • 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 Identity-Aware Proxy, Cloud CDN et Cloud Armor respectivement avec votre service API Gateway.

Étape suivante