Présentation des groupes de points de terminaison du réseau sans serveur

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 service Cloud Run, App Engine ou Cloud Functions.

Un NEG sans serveur peut représenter l'un des éléments suivants:

  • Un service Cloud Run ou un groupe de services.
  • Une fonction Cloud Functions ou un groupe de fonctions.
  • Une application App Engine (standard ou Flex), un service spécifique au sein d'une application, une version spécifique d'une application ou un groupe de services.

Lorsque l'équilibrage de charge HTTP(S) externe est activé pour les applications sans serveur, vous pouvez effectuer les opérations suivantes :

  • Configurer votre application sans serveur pour qu'elle soit diffusée à partir d'une adresse IP IPv4 et/ou IPv6 dédiée qui n'est pas partagée avec d'autres services.
  • Mapper une URL unique vers plusieurs applications sans serveur fonctionnellement identiques. Exécuter les applications dans différentes régions permet d'acheminer les requêtes vers la région la plus proche de l'utilisateur. Le mappage d'une URL unique vers plusieurs applications sans serveur fonctionnellement identiques n'est possible que pour Cloud Run et Cloud Functions.
  • Réutiliser les mêmes certificats SSL et clés privées que pour Compute Engine, Google Kubernetes Engine et Cloud Storage. La réutilisation des mêmes certificats élimine le besoin de gérer des certificats distincts pour les applications sans serveur.

La configuration de l'équilibrage de charge HTTP(S) externe permet également d'intégrer vos applications sans serveur aux services cloud existants. Vous pouvez procéder comme suit :

  • Partager l'espace URL avec d'autres technologies Google Cloud. En utilisant plusieurs services de backend, un même équilibreur de charge HTTP(S) externe peut envoyer du trafic vers plusieurs types de backend. L'équilibreur de charge sélectionne le service de backend approprié en fonction de l'hôte ou du chemin d'accès de l'URL de requête.
  • Protéger votre service avec Google Cloud Armor, un produit de sécurité WAF/défense contre les attaques DDoS de périphérie disponible pour tous les services accessibles via un équilibreur de charge HTTP(S) externe. Cette fonctionnalité fait l'objet de certaines limitations, en particulier pour Cloud Run et App Engine.
  • Activer votre service pour optimiser la diffusion à l'aide de Cloud CDN. Cloud CDN met le contenu en cache à proximité de vos utilisateurs. Cloud CDN offre des fonctionnalités telles que l'invalidation de cache et des URL signées Cloud CDN.
  • Utiliser l'infrastructure périphérique de Google pour interrompre les connexions HTTP(S) les plus proches de l'utilisateur, ce qui réduit la latence.

Le reste du présent document explique comment utiliser des groupes de points de terminaison du réseau (NEG) sans serveur avec des équilibreurs de charge HTTP(S) externes. Vous ne pouvez pas utiliser les NEG sans serveur avec d'autres types d'équilibreurs de charge.

Pour en savoir plus sur les autres types de NEG, consultez les pages suivantes :

Types de points de terminaison

Les NEG sans serveur ne possèdent pas de points de terminaison de réseau, tels que des ports ou des adresses IP. Ils peuvent uniquement pointer vers un service Cloud Run, App Engine ou Cloud Functions existant résidant dans la même région que le NEG.

Lorsque vous créez un NEG sans serveur, vous spécifiez le nom de domaine complet du service Cloud Run, App Engine ou Cloud Functions. Le point de terminaison est de type SERVERLESS. Les autres types de points de terminaison ne sont pas compatibles avec un NEG sans serveur.

Un NEG sans serveur ne peut pas avoir plusieurs points de terminaison. Étant donné que chaque NEG sans serveur ne peut comporter qu'un seul point de terminaison, l'équilibreur de charge sert uniquement d'interface et redirige le trafic vers le point de terminaison sans serveur spécifié. Toutefois, si le service de backend contient plusieurs NEG sans serveur, l'équilibreur de charge équilibre le trafic entre ces NEG, réduisant la latence des requêtes.

Niveau de réseau

Vous pouvez utiliser un NEG sans serveur dans un équilibreur de charge à l'aide des niveaux de service réseau Standard ou Premium. Le niveau Premium n'est requis que si vous souhaitez configurer des NEG sans serveur dans plusieurs régions.

Composants d'équilibrage de charge

Ce schéma montre comment un NEG sans serveur s'intègre dans le modèle d'équilibrage de charge HTTP(S).

Équilibrage de charge HTTPS simple (cliquez pour agrandir)
Équilibrage de charge HTTP(S) pour les applications sans serveur

Règle de transfert

La règle de transfert fait partie de la configuration de l'interface. Chaque règle de transfert possède une adresse IP externe, une version IP (IPv4 ou IPv6), un protocole (HTTP ou HTTPS, inclut HTTP/2) et un numéro de port (80 ou 443).

Proxy cible

Les NEG sans serveur ne peuvent être utilisés qu'avec des proxys cibles HTTP et HTTPS. Les services qui utilisent des NEG sans serveur ne peuvent pas être utilisés avec des proxys cibles TCP ou SSL.

Mappage d'URL

La sélection de transfert d'un équilibreur de charge HTTP(S) externe est basée sur un mappage d'URL. Avec un mappage d'URL, les proxys HTTP(S) cibles déterminent le service de backend à utiliser en vérifiant le nom d'hôte et le chemin d'accès de la requête dans le mappage d'URL. Les équilibreurs de charge peuvent disposer de plusieurs services de backend référencés dans le mappage d'URL. Chaque service de backend peut être associé à un type de backend différent. Par exemple, vous pouvez disposer d'un service de backend pour un NEG sans serveur et d'un autre pour les groupes d'instances Compute Engine.

Service backend

Les NEG sans serveur peuvent être utilisés comme backends dans un équilibreur de charge. Un service de backend peut comporter plusieurs NEG sans serveur. Chaque NEG sans serveur peut pointer vers l'un des éléments suivants :

  • Un nom de domaine complet d'une fonction ou d'un service unique.
  • Un masque d'URL qui pointe vers plusieurs fonctions ou services diffusés sur un même domaine.

Un masque d'URL est un modèle de schéma d'URL qui indique au backend de NEG sans serveur comment mapper la requête de l'utilisateur au service approprié. Les masques d'URL sont utiles si vous utilisez un domaine personnalisé pour votre application et si plusieurs services Cloud Run, Cloud Functions ou App Engine sont diffusés sur le même domaine. Au lieu de créer un NEG sans serveur distinct pour chaque fonction ou service, vous pouvez créer le NEG avec un masque d'URL générique pour le domaine personnalisé. Pour plus d'informations et d'exemples, consultez la page Masques d'URL.

Pour découvrir les restrictions supplémentaires qui s'appliquent à l'ajout d'un NEG sans serveur en tant que backend, consultez la section Limitations.

Masques d'URL

Les masques d'URL facultatifs facilitent la configuration des NEG sans serveur lorsque votre application dispose de plusieurs services Cloud Run, Cloud Functions ou App Engine. Un backend de NEG sans serveur peut pointer vers un seul service Cloud Run (ou App Engine ou Cloud Functions) ou vers un masque d'URL pointant vers plusieurs services.

Un masque d'URL est un modèle de votre schéma d'URL. Le NEG sans serveur utilise ce modèle pour mapper la requête au service approprié.

Les masques d'URL sont utiles si votre application sans serveur est mappée sur un domaine personnalisé plutôt que sur l'adresse par défaut fournie par Google Cloud. Avec un domaine personnalisé tel que example.com, vous pouvez déployer plusieurs services sur différents sous-domaines ou chemins du même domaine. Dans ce cas, au lieu de créer un backend de NEG sans serveur distinct pour chaque service, vous pouvez créer un seul NEG sans serveur avec un masque d'URL générique pour le domaine personnalisé (par exemple, example.com/<service>), auquel cas le NEG extrait le nom du service à partir de l'URL de requête.

L'illustration suivante montre un équilibreur de charge HTTP(S) externe avec un seul service de backend et un NEG sans serveur qui utilise un masque d'URL pour mapper les requêtes utilisateur à différents services.

Répartition du trafic vers des applications sans serveur (cliquez pour agrandir)
Utilisation d'un masque d'URL pour répartir le trafic entre différents services

Les masques d'URL fonctionnent mieux lorsque les services de votre application utilisent un schéma d'URL prévisible. L'avantage d'utiliser un masque d'URL au lieu d'un mappage d'URL est qu'il n'est pas nécessaire de créer des NEG sans serveur distincts pour les services login et search. Vous n'avez pas non plus besoin de modifier la configuration de votre équilibreur de charge chaque fois que vous ajoutez un service à votre application.

Pour savoir comment créer et configurer un masque d'URL pour un NEG sans serveur, consultez la page Configurer des NEG sans serveur.

Limites

  • Un NEG sans serveur ne possède pas de points de terminaison de réseau, tels qu'une adresse IP ou un port.
  • Les NEG sans serveur peuvent uniquement pointer vers des services Cloud Run, App Engine ou Cloud Functions qui résident dans la même région que le NEG.
  • Les équilibreurs de charge utilisant des backends NEG sans serveur doivent être créés dans le même projet que les services Cloud Run, App Engine ou Cloud Functions vers lesquels pointe le NEG.
  • Un équilibreur de charge HTTP(S) externe configuré avec un NEG sans serveur ne peut pas détecter si le service sous-jacent fonctionne comme prévu. Cela signifie que si votre service dans une région renvoie des erreurs, mais que l'infrastructure globale de cette région fonctionne normalement, votre équilibreur de charge HTTP(S) externe ne peut pas rediriger automatiquement le trafic vers d'autres régions. Veillez à tester soigneusement les nouvelles versions de vos services avant d'y acheminer le trafic de vos utilisateurs.

Limites associées aux services de backend dotés d'un backend de NEG sans serveur

  • Un service de backend peut comporter un NEG sans serveur par région. Pour combiner plusieurs NEG sans serveur dans un seul service de backend, tous les NEG doivent représenter des déploiements fonctionnellement équivalents dans différentes régions. Par exemple, les NEG peuvent pointer vers le même service Cloud Run, App Engine ou Cloud Functions déployé dans différentes régions.
  • Le paramètre de délai avant expiration du service de backend ne s'applique pas aux services de backend avec des backends NEG sans serveur. Toute tentative de modification de la propriété resource.timeoutSec du service de backend génère l'erreur suivante : Timeout sec is not supported for a backend service with Serverless network endpoint groups.
  • Tous les NEG sans serveur combinés dans un service de backend doivent également utiliser le même type de backend. Cela signifie que les NEG sans serveur Cloud Run ne peuvent être associés qu'à d'autres NEG sans serveur Cloud Run, et qu'ils ne peuvent être associés qu'à des NEG sans serveur App Engine, etc.
  • Vous ne pouvez pas combiner des NEG sans serveur avec d'autres types de NEG (NEG zonaux ou Internet) dans le même service de backend. Par exemple, vous ne pouvez pas accéder à un cluster GKE et à un service Cloud Run à partir du même service de backend.
  • Lorsque vous configurez des services de backend qui acheminent vers des NEG sans serveur, certains champs ne peuvent pas être utilisés :
    • Vous ne pouvez pas spécifier de mode d'équilibrage. Autrement dit, les valeurs RATE, UTILIZATION et CONNECTION n'ont aucun effet sur la répartition du trafic de l'équilibreur de charge.
    • Les vérifications d'état ne sont pas compatibles avec les backends sans serveur. Par conséquent, les services de backend contenant des backends NEG sans serveur ne peuvent pas être configurés avec des vérifications d'état.
  • Vous ne pouvez pas utiliser la commande gcloud compute backend-services edit pour modifier un service de backend avec un backend de NEG sans serveur. Pour contourner ce problème, utilisez plutôt la commande gcloud compute backend-services update.

Des limites supplémentaires peuvent s'appliquer en fonction de la plate-forme d'informatique sans serveur que vous utilisez.

Limites avec Cloud Run

  • L'équilibrage de charge HTTP(S) externe avec des NEG sans serveur n'est pas compatible avec Cloud Run for Anthos.

Limites avec Cloud Functions

  • IAP ne fonctionne pas avec Cloud Functions.

Limites avec App Engine

  • L'équilibrage de charge multirégional n'est pas compatible avec App Engine. En effet, App Engine requiert une région par projet.
  • Une seule stratégie IAP est autorisée sur le chemin de la requête. Par exemple, si vous avez déjà défini une stratégie IAP dans le service de backend, vous ne devez pas en définir une autre dans l'application App Engine.
  • Nous vous recommandons d'utiliser des contrôles d'entrée afin que votre application ne reçoive que les requêtes envoyées par l'équilibreur de charge (et par le VPC le cas échéant). Sinon, les utilisateurs peuvent se servir de l'URL App Engine de votre application pour contourner l'équilibreur de charge, les règles de sécurité Google Cloud Armor, les certificats SSL et les clés privées qui sont transmises via l'équilibreur de charge.

Tarifs

Pour afficher les informations de tarification des équilibreurs de charge HTTP(S) externes avec des NEG sans serveur, consultez la page Tarifs du réseau.

Étape suivante