Équilibrage de charge pour API Gateway

L'intégration de la compatibilité de l'équilibreur de charge d'application externe global et de l'équilibreur de charge d'application classique à API Gateway permet à vos backends sans serveur de bénéficier de toutes les fonctionnalités fournies par Cloud Load Balancing. En combinant API Gateway à un équilibreur de charge d'application externe global ou à un équilibreur de charge d'application classique à 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 délivrés par une autorité de certification privilégiée
  • Créer un point d'entrée commun pour une passerelle routant 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, comme 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 suivante montre comment utiliser des NEG sans serveur 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é dans un exemple précédent, 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 des régions différentes. Si un service de backend contient plusieurs NEG, l'équilibreur de charge équilibre le trafic entre ces NEG tout en réduisant la latence des requêtes.

Limites sur les NEG sans serveur et API Gateway

Certaines limites doivent être prises en compte lorsque vous utilisez des NEG sans serveur pour intégrer Cloud Load Balancing à API Gateway. et plus particulièrement:

  • 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 compatible avec les paramètres de contrôle d'accès. Par conséquent, il n'existe aucun moyen de désactiver l'accès à votre passerelle API à l'aide d'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 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, les vérifications de l'état et les délais avant expiration. Pour les NEG sans serveur utilisés comme 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 les requêtes vers un cluster GKE et une instance de passerelle API à 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, et que les NEG sans serveur App Engine ne peuvent être associés qu'avec les NEG sans serveur App Engine.
  • 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 permettent de configurer respectivement Identity-Aware Proxy, Cloud CDN et Cloud Armor avec votre service API Gateway.

Étape suivante