Équilibrage de charge pour API Gateway

L'intégration de l'équilibreur de charge d'application externe mondial et de l'équilibreur de charge d'application classique à API Gateway permet à vos backends sans serveur de profiter de toutes les fonctionnalités fournies par Cloud Load Balancing. En combinant API Gateway avec 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 émis par une autorité de certification de votre choix
  • Créer un point d'entrée commun pour une passerelle acheminant le trafic 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
  • 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é 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 passerelle 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

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

  • Les NEG sans serveur ne peuvent pas être associés à des points de terminaison 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 Ingress. Par conséquent, il n'est pas possible 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 s'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 Limites.

Limites sur les 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 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 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, et que les NEG sans serveur App Engine ne peuvent être associés qu'à des 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 lié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