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, Cloud Run Functions ou API Gateway.

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 Run 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.
  • Un service API Gateway qui permet d'accéder à vos services via une API REST cohérente entre tous les services, indépendamment de leur mise en œuvre. Cette fonctionnalité est en version Bêta.

Équilibreurs de charge compatibles

Le tableau suivant répertorie les produits sans serveur pris en charge par chaque équilibreur de charge d'application. Les NEG sans serveur ne sont pas compatibles avec les équilibreurs de charge réseau proxy ni avec les équilibreurs de charge réseau passthrough.

Plate-forme sans serveur Équilibreurs de charge d'application

Régional, interne
Interrégional, interne
Mondial, externe		 Classique
Régional, externe
Cloud Run
App Engine
Cloud Run Functions

Cas d'utilisation

Lorsque votre équilibreur de charge 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 IPv4 dédiée non partagée avec d'autres services.
  • Mapper une URL unique vers plusieurs fonctions ou services sans serveur diffusés sur le même domaine. Dans ce document, consultez la section Masques d'URL.
  • Partager l'espace URL avec d'autres plates-formes de calcul Google Cloud. En utilisant plusieurs services de backend, un seul équilibreur de charge 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.
  • 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.

Équilibreur de charge d'application externe mondial et équilibreur de charge d'application classique.

La configuration d'un équilibreur de charge d'application externe global ou d'un équilibreur de charge d'application classique permet d'intégrer vos applications sans serveur aux services cloud existants. Vous pouvez procéder comme suit :

  • Protéger votre service avec Google Cloud Armor, un produit de sécurité WAF et de défense contre les attaques DDoS de périphérie disponible pour tous les services accessibles via un équilibreur de charge d'application 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.

Pour savoir comment configurer un équilibreur de charge avec un backend de calcul sans serveur, consultez la documentation suivante :

L'intégration d'un équilibreur de charge d'application externe à API Gateway permet à vos backends sans serveur de profiter de toutes les fonctionnalités fournies par Cloud Load Balancing. Pour en savoir plus, consultez Équilibreur de charge d'application externe pour API Gateway. Pour configurer un équilibreur de charge d'application externe afin d'acheminer le trafic vers API Gateway, consultez la page Premiers pas avec un équilibreur de charge d'application externe pour API Gateway. Cette fonctionnalité est en version Bêta.

Équilibreur de charge d'application externe régional

L'utilisation d'un équilibreur de charge d'application externe régional vous permet d'exécuter des charges de travail avec des exigences réglementaires ou de conformité sur des backends Cloud Run. Par exemple, si vous exigez que les configurations réseau et la terminaison de trafic de votre application résident dans une région spécifique, un équilibreur de charge d'application externe régional est souvent l'option recommandée pour respecter les contrôles juridictionnels nécessaires.

Pour apprendre à configurer un équilibreur de charge d'application externe régional avec un backend de calcul sans serveur, consultez la page Configurer un équilibreur de charge d'application externe régional avec Cloud Run.

Équilibreur de charge d'application interne régional et équilibreur de charge d'application interne interrégional.

Lorsqu'un équilibreur de charge d'application interne est configuré avec des backends Cloud Run, vous pouvez effectuer les opérations suivantes :

  • Activer les fonctionnalités avancées de gestion du trafic pour vos services Cloud Run, telles que l'injection de pannes, les réécritures d'en-tête, les redirections, la répartition du trafic, etc.
  • Migrer en toute transparence vos anciens services depuis Compute Engine, GKE ou sur site vers Cloud Run, et profiter de la répartition du trafic basée sur la pondération pour déplacer progressivement le trafic vers Cloud Run sans aucun temps d'arrêt.
  • Protéger vos services Cloud Run avec VPC Service Controls.
  • Établir un point d'entrée interne unique, appliquant la règle, pour vos services exécutés dans Cloud Run, Compute Engine et GKE.

Pour apprendre à configurer un équilibreur de charge d'application interne régional avec un backend de calcul sans serveur, consultez la page Configurer un équilibreur de charge d'application interne régional avec Cloud Run.

Le reste de cette page explique comment utiliser des NEG sans serveur avec vos équilibreurs de charge d'application. Pour plus d'informations sur les autres types de NEG, consultez la page Présentation des groupes de points de terminaison du réseau.

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, API Gateway ou Cloud Run 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, API Gateway ou Cloud Run 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. Le point de terminaison pointe vers une application sans serveur ou un masque d'URL. L'équilibreur de charge sert d'interface à l'application d'informatique sans serveur et joue le rôle de proxy pour le trafic vers le point de terminaison spécifié. Toutefois, si le service de backend contient plusieurs NEG sans serveur dans différentes régions, l'équilibreur de charge envoie le trafic au NEG dans la région la plus proche afin de minimiser la latence des requêtes.

Niveau de réseau

Pour les équilibreurs de charge d'application externes globaux, vous pouvez utiliser un NEG sans serveur dans un équilibreur de charge avec les 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.

Les équilibreurs de charge d'application externes régionaux sont toujours associés au niveau Standard.

Les équilibreurs de charge d'application internes interrégionaux et les équilibreurs de charge d'application internes régionaux sont toujours associés au niveau Premium.

Composants d'équilibrage de charge

Un équilibreur de charge utilisant un backend de NEG sans serveur nécessite une configuration spéciale uniquement pour le service de backend. La configuration du frontend est identique à celle de tout autre équilibreur de charge Google Cloud basé sur un proxy. De plus, les équilibreurs de charge d'application internes nécessitent un sous-réseau proxy réservé pour exécuter des proxys Envoy en votre nom.

Le schéma suivant présente un exemple de déploiement de NEG sans serveur.

Mondial, externe

Ce schéma montre comment un NEG sans serveur s'intègre dans une architecture d'équilibreur de charge d'application externe mondial.

Équilibreur de charge d'application externe mondial pour les applications sans serveur.
Équilibreur de charge d'application externe global pour les applications sans serveur (cliquez pour agrandir)

Externe régional

Ce schéma montre comment un NEG sans serveur s'intègre dans une architecture d'équilibreur de charge d'application externe régional.

Équilibreur de charge d'application externe régional pour les applications sans serveur.
Équilibreur de charge d'application externe régional pour les applications sans serveur (cliquez pour agrandir).

Régional interne

Ce schéma montre comment un NEG sans serveur s'intègre dans le modèle d'équilibreur de charge d'application interne régional.

Équilibreur de charge d'application interne régional pour les applications sans serveur.
Équilibreur de charge d'application interne régional pour les applications sans serveur (cliquez pour agrandir).

Interrégional

Ce schéma montre comment un NEG sans serveur s'intègre dans le modèle d'équilibreur de charge d'application interne interrégional.

Équilibreur de charge d'application interne interrégional avec un déploiement Cloud Run.
Équilibreur de charge d'application interne interrégional avec un déploiement Cloud Run (cliquez pour agrandir).

Composants d'interface

Aucune configuration d'interface spéciale n'est requise pour l'équilibrage de charge avec des backends de NEG sans serveur. Les règles de transfert permettent d'acheminer le trafic vers un proxy cible sur la base de l'adresse IP, du port et du protocole. Le proxy cible met ensuite fin aux connexions des clients.

Les mappages d'URL sont utilisés par les équilibreurs de charge d'application pour configurer le routage basé sur l'URL des requêtes vers les services de backend appropriés.

Pour en savoir plus sur chacun de ces composants, consultez les sections d'architecture des présentations spécifiques de l'équilibreur de charge :

Service de backend

Les services de backend fournissent des informations de configuration à l'équilibreur de charge. Les équilibreurs de charge utilisent les informations d'un service de backend pour rediriger le trafic entrant vers un ou plusieurs backends associés. Les NEG sans serveur peuvent être utilisés comme backends pour certains équilibreurs de charge.

Les restrictions suivantes s'appliquent en fonction du type d'équilibreur de charge :

  • Un service de backend global utilisé par les équilibreurs de charge HTTP(S) externes globaux peut être associé à plusieurs NEG sans serveur, mais à raison d'un seul NEG sans serveur par région.
  • Un service de backend régional utilisé par les équilibreurs de charge d'application internes régionaux et externes régionaux ne peut être associé qu'à un seul NEG sans serveur.
  • Un service de backend global utilisé par les équilibreurs de charge d'application internes interrégionaux ne peut être associé qu'à des services Cloud Run.

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 sans serveur et que plusieurs services 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.

Détection des anomalies pour les NEG sans serveur

La détection des anomalies est une configuration facultative qui peut être activée sur un service de backend global auquel sont associés des NEG sans serveur. L'analyse de la détection des anomalies n'est disponible que pour un équilibreur de charge d'application interne interrégional et un équilibreur de charge d'application externe global, et non pour un équilibreur de charge d'application classique. L'analyse de détection des anomalies identifie les NEG sans serveur non opérationnels en fonction de leurs modèles de réponse HTTP, et réduit le taux d'erreur en acheminant la plupart des nouvelles requêtes provenant de services non opérationnels vers des services opérationnels. Pour comprendre le fonctionnement de l'algorithme de détection des valeurs aberrantes et ses limites, consultez l'exemple suivant.

Supposons qu'un service de backend soit associé à deux NEG sans serveur, l'un dans la région REGION_A et l'autre dans la région REGION_B. Si le NEG sans serveur qui sert de backend à un équilibreur de charge d'application externe global dans la région REGION_A ne répond pas, la détection des anomalies identifie le NEG sans serveur comme étant non opérationnel. En fonction de l'analyse de détection des anomalies, certaines des nouvelles requêtes sont ensuite envoyées au NEG sans serveur de la région REGION_B.

Selon le type d'erreur du serveur qui est rencontrée, vous pouvez utiliser l'une des méthodes de détection des anomalies suivantes pour activer la détection des anomalies :

  • Erreurs 5xx consécutives : Un code d'état HTTP de la série 5xx est considéré comme une erreur.
  • Erreurs de passerelle consécutives : Seuls les codes d'état HTTP 502, 503 et 504 sont considérés comme des erreurs.

Sachez que même après l'activation de la détection des anomalies, il est probable que certaines requêtes soient envoyées au service non opérationnel et qu'elles renvoient donc des erreurs 5XX aux clients. En effet, les résultats de l'algorithme de détection des anomalies (exclusion des points de terminaison du pool d'équilibrage de charge et retour de ceux-ci au pool) sont exécutés indépendamment par chaque instance de proxy de l'équilibreur de charge. Dans la plupart des cas, plusieurs instances de proxy gèrent le trafic reçu par un service de backend. Ainsi, il est possible qu'un point de terminaison non opérationnel soit détecté et exclu par certains des proxys seulement, même si dans le même temps d'autres proxys peuvent continuer à envoyer des requêtes au même point de terminaison non opérationnel.

Pour réduire davantage les taux d'erreur, vous pouvez configurer des paramètres de détection des anomalies plus agressifs. Nous vous recommandons de configurer des valeurs plus élevées pour les seuils d'exclusion (outlierDetection.baseEjectionTime). Par exemple, nos tests montrent que la définition de outlierDetection.baseEjectionTime sur 180 secondes avec un nombre de requêtes par seconde soutenu supérieur à 100 entraîne des taux d'erreur observés inférieurs à 5 %. Pour en savoir plus sur l'API de détection des anomalies, consultez la section outlierDetection dans la documentation de l'API sur le service de backend global.

Les champs outlierDetection suivants ne sont pas disponibles lorsque le service de backend est associé à un NEG sans serveur :

  • outlierDetection.enforcingSuccessRate
  • outlierDetection.successRateMinimumHosts
  • outlierDetection.successRateRequestVolume
  • outlierDetection.successRateStdevFactor

Pour en savoir plus sur la configuration de la détection des anomalies, consultez la section "Activer la détection des anomalies" de la page "Configurer un équilibreur de charge d'application externe global avec un backend sans serveur.

Masques d'URL

Un backend de NEG sans serveur peut pointer vers un seul service Cloud Run (ou App Engine ou Cloud Run Functions le cas échéant) 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 une fonctionnalité facultative qui facilite la configuration des NEG sans serveur lorsque vos applications sans serveur comprennent plusieurs services Cloud Run, Cloud Run Functions ou App Engine. Les NEG sans serveur utilisés avec les équilibreurs de charge d'application internes ne peuvent utiliser qu'un masque d'URL qui pointe vers des services Cloud Run.

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 d'application 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.
Utilisation d'un masque d'URL pour répartir le trafic entre différents services (cliquez pour agrandir)

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.

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 applications sans serveur résidant dans la même région que le NEG.
  • Pour un équilibreur de charge qui utilise un backend de NEG sans serveur, le NEG sans serveur doit être créé dans le même projet que les services Cloud Run, App Engine, API Gateway ou Cloud Run Functions de sauvegarde vers lesquels pointe le NEG. Les requêtes peuvent échouer si vous connectez un service qui ne se trouve pas dans le même projet que le NEG sans serveur.
  • Un équilibreur de charge configuré avec un NEG sans serveur ne peut pas détecter si l'application ou le service sans serveur sous-jacent fonctionne comme prévu. Cela signifie que même si votre service renvoie des erreurs, l'équilibreur de charge continue de diriger le trafic vers celui-ci. Veillez à tester soigneusement les nouvelles versions de vos services avant d'y acheminer le trafic de vos utilisateurs.

Limites avec les services de backend

Les limites suivantes s'appliquent aux services de backend dotés d'un backend de NEG sans serveur :

  • Un service de backend global utilisé par les équilibreurs de charge des applications externes mondiaux ne peut avoir qu'un seul 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 Run Functions déployé dans différentes régions.
  • Un service de backend global utilisé par les équilibreurs de charge d'application internes interrégionaux ne peut être associé qu'à un seul service Cloud Run.
  • Un service de backend régional ne peut être associé qu'à un seul NEG sans serveur.
  • Le référencement de services inter-projets dans un déploiement de VPC partagé est compatible avec les configurations contenant un NEG sans serveur. Pour utiliser cette fonctionnalité, vous devez créer les composants d'interface de l'équilibreur de charge (adresse IP, règle de transfert, proxy cible et mappage d'URL) dans un projet différent des composants backend de l'équilibreur de charge (service de backend et NEG sans serveur). Notez que le service de backend, les NEG sans serveur associés et le service de sauvegarde sans serveur (Cloud Run, App Engine, API Gateway ou Cloud Run Functions) doivent toujours être créés dans le même projet.
  • 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.
    Pour les services de backend avec des backends de NEG sans serveur, le délai avant expiration par défaut est de 60 minutes. Ce délai avant expiration n'est pas configurable. Si votre application nécessite des connexions de longue durée, configurez vos clients pour relancer les requêtes en cas d'échec.
  • 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 que les NEG sans serveur App Engine ne peuvent être associés qu'à des NEG sans serveur App Engine.
  • Vous ne pouvez pas combiner des NEG sans serveur 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 à 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 qui contiennent des backends NEG sans serveur ne peuvent pas être configurés avec des vérifications d'état. Cependant, vous pouvez éventuellement activer la détection des anomalies pour identifier les services sans serveur non opérationnels et acheminer les nouvelles requêtes vers un service sans serveur opérationnel.
  • 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 s'appliquent en fonction du type d'équilibreur de charge et du backend sans serveur.

Limites avec les équilibreurs de charge d'application internes régionaux et les équilibreurs de charge d'application externes régionaux

  • Les NEG sans serveur utilisés avec les équilibreurs de charge d'application internes régionaux ou externes régionaux ne peuvent pointer que vers des services Cloud Run.
  • Pour les projets utilisant des NEG sans serveur, la limite de requêtes par seconde (RPS) est de 5 000 RPS par projet pour le trafic envoyé à des NEG sans serveur configurés avec des équilibreurs de charge d'application externes régionaux ou internes régionaux. Cette limite est agrégée dans tous les équilibreurs de charge d'application externes régionaux et tous les équilibreurs de charge d'application internes régionaux du projet. Il ne s'agit pas d'une limite par équilibreur de charge.

Limites avec les équilibreurs de charge d'application internes interrégionaux

  • Les NEG sans serveur utilisés avec les équilibreurs de charge d'application internes interrégionaux ne peuvent pointer que vers des services Cloud Run.

Limites avec les équilibreurs de charge d'application externes globaux

Cette section répertorie les limites que vous rencontrerez lors de la configuration des NEG sans serveur avec des équilibreurs de charge d'application externes globaux.

Limites avec App Engine

  • Les équilibreurs de charge d'application externes globaux avec des backends d'environnement flexible App Engine et des backends d'environnement standard App Engine ne sont pas compatibles avec le référencement de services interprojets.

Limites avec Cloud Run

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.

Limites avec API Gateway

Pour en savoir plus, consultez la section Limites sur les NEG sans serveur et API Gateway.

Limites des fonctionnalités de gestion du trafic

  • Les fonctionnalités de gestion avancée du trafic telles que la règle d'équilibrage de charge de localité, l'affinité de session et la détection d'anomalies ne sont pas compatibles avec les backends NEG sans serveur.
  • Spécifier une affinité de session sur un service de backend avec un backend NEG sans serveur ne fonctionnera pas. Pour contourner ce problème avec Cloud Run, utilisez sa fonctionnalité spécifique d'affinité de session.

Tarifs

Pour afficher les informations de tarification des équilibreurs de charge avec des NEG sans serveur, consultez la page Tous les tarifs de mise en réseau : Cloud Load Balancing.

Étape suivante