Présentation de l'équilibreur de charge d'application

L'équilibreur de charge d'application est un équilibreur de charge de couche 7 basé sur un proxy qui vous permet d'exécuter et d'effectuer le scaling de vos services. L'équilibreur de charge d'application répartit le trafic HTTP et HTTPS entre les backends hébergés sur diverses plates-formes Google Cloud, telles que Compute Engine, Google Kubernetes Engine (GKE), Cloud Storage et Cloud Run, et les backends externes connectés à Internet ou via une connectivité hybride.

Les équilibreurs de charge d'application sont disponibles dans les modes de déploiement suivants :

  • Équilibreur de charge d'application externe: équilibre la charge du trafic provenant des clients sur Internet. Pour en savoir plus sur l'architecture, consultez la section Architecture de l'équilibreur de charge d'application externe.

    Mode de déploiement Niveau de service réseau Schéma d'équilibrage de charge Adresse IP Ports d'interface
    Externe global Niveau Premium EXTERNAL_MANAGED IPv4
    IPv6

    Peut faire référence à un seul port dans la plage 1-65535.
    Externe régional Niveau Premium ou Standard EXTERNAL_MANAGED IPv4
    Classique

    Global au niveau Premium

    Régional au niveau Standard

    		 EXTERNE* IPv4
    IPv6 nécessite le niveau Premium
    * Il est possible d'associer des services de backend EXTERNAL_MANAGED à des règles de transfert EXTERNAL. Toutefois, les services de backend EXTERNAL ne peuvent pas être associés à des règles de transfert EXTERNAL_MANAGED. Pour profiter des nouvelles fonctionnalités disponibles uniquement avec l'équilibreur de charge d'application externe mondial, nous vous recommandons de migrer vos ressources EXTERNAL existantes vers EXTERNAL_MANAGED à l'aide du processus de migration décrit dans la section Migrer des ressources de l'équilibreur de charge d'application classique vers l'équilibreur de charge d'application externe mondial.

  • Équilibreur de charge d'application interne: équilibre la charge du trafic au sein de votre réseau VPC ou de réseaux connectés à votre réseau VPC. Pour en savoir plus sur l'architecture, consultez la section Architecture de l'équilibreur de charge d'application interne.

    Mode de déploiement Niveau de service réseau Schéma d'équilibrage de charge Adresse IP Ports d'interface
    Régional interne Niveau Premium INTERNAL_MANAGED IPv4

    Peut faire référence à un seul port dans la plage 1-65535.

    Interne interrégional*

    		 Niveau Premium INTERNAL_MANAGED IPv4

    * L'équilibreur de charge utilise des ressources globales et peut être déployé dans la ou les régions Google Cloud de votre choix.

Le schéma d'équilibrage de charge est un attribut de la règle de transfert et du service de backend d'un équilibreur de charge qui indique si l'équilibreur de charge peut être utilisé pour le trafic interne ou externe. Le terme _MANAGED dans le schéma d'équilibrage de charge indique que l'équilibreur de charge est mis en œuvre en tant que service géré sur des Google Front End (GFE) ou sur le proxy Envoy Open Source. Dans un schéma d'équilibrage de charge _MANAGED, les requêtes sont acheminées vers GFE ou vers le proxy Envoy.

Équilibreur de charge d'application externe

Les équilibreurs de charge d'application externes sont mis en œuvre à l'aide des GFE (Google Front End) ou de proxys gérés. Les équilibreurs de charge d'application externe et la version classique des équilibreurs de charge d'applications utilisent des GFE distribués dans le monde entier, en utilisant le réseau mondial et le plan de contrôle de Google. Les GFE offrent un équilibrage de charge multirégional au niveau Premium, en dirigeant le trafic vers le backend opérationnel le plus proche ayant la capacité suffisante, et terminent le trafic HTTP(S) le plus près possible de vos utilisateurs. Les équilibreurs de charge d'application externes mondiaux et les équilibreurs de charge d'application externes régionaux utilisent le logiciel Open Source Proxy Envoy pour activer des fonctionnalités avancées de gestion du trafic.

Ces équilibreurs de charge peuvent être déployés dans l'un des modes suivants : global, régional ou classique.

Les équilibreurs de charge d'applications externes offrent les fonctionnalités suivantes :

Le schéma suivant montre un exemple d'architecture de l'équilibreur de charge d'application externe.

Architecture de l'équilibreur de charge d'application externe.
Architecture de l'équilibreur de charge d'application externe.

Pour une présentation complète, consultez la page Présentation de l'architecture pour les équilibreurs de charge d'application externes.

Équilibreur de charge d'application interne

Les équilibreurs de charge d'application internes sont des équilibreurs de charge régionaux de couche 7 basés sur un proxy Envoy qui vous permettent d'exécuter et d'effectuer le scaling de votre trafic d'application HTTP derrière une adresse IP interne. Les équilibreurs de charge d'application internes sont compatibles avec les backends d'une région, mais peuvent être configurés pour être accessibles dans le monde entier par les clients de n'importe quelle région Google Cloud.

L'équilibreur de charge distribue le trafic vers les backends hébergés sur Google Cloud, sur site ou dans d'autres environnements cloud. Les équilibreurs de charge d'application internes sont également compatibles avec les fonctionnalités suivantes :

  • Règles de localité. Dans un groupe d'instances backend ou un point de terminaison du réseau, vous pouvez configurer la manière dont les requêtes sont distribuées aux instances membres ou aux points de terminaison. Pour en savoir plus, consultez la section Gestion du trafic.
  • Accès mondial. Lorsque l'accès mondial est activé, les clients de n'importe quelle région peuvent accéder à l'équilibreur de charge. Pour en savoir plus, consultez Activer l'accès mondial.
  • Accès depuis des réseaux connectés. Vous pouvez rendre votre équilibreur de charge accessible aux clients à partir de réseaux autres que votre propre réseau cloud privé virtuel (VPC) Google Cloud. Les autres réseaux doivent être connectés au réseau VPC de l'équilibreur de charge à l'aide de l'appairage de réseaux VPC, de Cloud VPN ou de Cloud Interconnect. Pour en savoir plus, consultez la page Accéder aux réseaux connectés.
  • Compatibilité avec GKE à l'aide d'Ingress (entièrement orchestré). Pour plus d'informations, consultez la page Configurer Ingress pour les équilibreurs de charge d'application internes.
  • Les équilibreurs de charge d'application internes régionaux sont compatibles avec App Hub, qui est la version bêta.
Architecture de l'équilibreur de charge d'application interne.
Architecture de l'équilibreur de charge d'application interne.

Pour une présentation complète, consultez la page Présentation de l'architecture pour les équilibreurs de charge d'application internes.

Cas d'utilisation

Les sections suivantes décrivent quelques cas d'utilisation courants des équilibreurs de charge d'application.

Services Web à trois niveaux

Vous pouvez déployer une combinaison d'équilibreurs de charge d'application et d'équilibreurs de charge réseau pour assurer la compatibilité avec les services Web classiques à trois niveaux. L'exemple suivant montre comment déployer chaque niveau en fonction de votre type de trafic :

  • Niveau Web : La partie frontale de l'application est gérée par un équilibreur de charge d'application externe avec des backends de groupes d'instances. Le trafic provient d'Internet et est mis en proxy par l'équilibreur de charge vers un ensemble de backends de groupe d'instances dans différentes régions. Ces backends envoient le trafic HTTP(S) vers un ensemble d'équilibreurs de charge d'application internes.
  • Niveau d'application : Le middleware de l'application est déployé et mis à l'échelle à l'aide d'un équilibreur de charge d'application interne et de backends de groupe d'instances. Les équilibreurs de charge distribuent le trafic entre les groupes d'instances middleware. Ces groupes d'instances middleware envoient ensuite le trafic aux équilibreurs de charge réseau passthrough internes.
  • Niveau base de données : Les équilibreurs de charge réseau servent d'interfaces pour le niveau base de données. Ils distribuent le trafic vers les backends de stockage de données dans différentes régions.
Routage basé sur la couche 7 dans une application Web à trois niveaux
Routage basé sur la couche 7 dans une application Web à trois niveaux

Accès mondial pour les équilibreurs de charge d'application internes régionaux

Si vous activez l'accès mondial pour votre équilibreur de charge d'application interne régional, vos VM clientes de niveau Web peuvent se trouver dans une autre région.

Cet exemple d'application multiniveau présente les éléments suivants :

  • Un niveau Web disponible dans le monde entier qui gère l'équilibrage de charge du trafic via un équilibreur de charge d'application externe
  • Un niveau de base de données backend soumis à l'équilibrage de charge interne dans la région us-east1 auquel accède le niveau Web mondial
  • Une VM cliente qui fait partie du niveau Web dans la région europe-west1 qui accède au niveau de base de données soumis à l'équilibrage de charge interne situé dans us-east1
Application Web à trois niveaux avec un équilibreur de charge d'application externe, un accès mondial et un équilibreur de charge d'application interne.
Application Web à trois niveaux avec un équilibreur de charge d'application externe, accès mondial et un équilibreur de charge d'application interne (cliquez pour agrandir)

Charges de travail avec exigences de conformité avec la loi

Certaines charges de travail présentant des exigences réglementaires ou de conformité exigent que les configurations réseau et la terminaison du trafic résident dans une région spécifique. Pour ces charges de travail, un équilibreur de charge d'application externe régional est souvent l'option recommandée pour fournir les contrôles juridictionnels requis par ces charges de travail.

Gestion avancée du trafic

Les équilibreurs de charge d'application sont compatibles avec des fonctionnalités avancées de gestion du trafic qui vous permettent de contrôler précisément la manière dont votre trafic est géré. Ces fonctionnalités incluent les suivantes :

  • Vous pouvez modifier la manière dont le trafic est géré sans avoir à modifier le code de votre application.
  • Vous pouvez acheminer intelligemment le trafic en fonction de paramètres HTTP(S) tels que l'hôte, le chemin d'accès, les en-têtes et les autres paramètres de requête. Par exemple, vous pouvez utiliser des buckets Cloud Storage pour gérer tout contenu vidéo statique, et des groupes d'instances ou NEG pour gérer toutes les autres requêtes.
  • Vous pouvez atténuer les risques lors du déploiement d'une nouvelle version de votre application en utilisant la répartition du trafic basée sur le poids. Par exemple, vous pouvez envoyer 95 % du trafic vers la version précédente de votre service et 5 % vers la nouvelle version. Une fois que vous avez vérifié que la nouvelle version fonctionne comme prévu, vous pouvez modifier progressivement les pourcentages jusqu'à ce que 100% du trafic atteigne la nouvelle version de votre service. La répartition du trafic est généralement utilisée pour le déploiement de nouvelles versions, les tests A/B, la migration de services, la modernisation d'anciens services et d'autres processus similaires.

Voici un exemple de routage basé sur un chemin d'accès implémenté à l'aide d'un équilibreur de charge d'application interne. Chaque chemin est géré par un backend différent.

Routage basé sur le chemin d'accès avec des équilibreurs de charge d'application internes.
Routage basé sur le chemin d'accès avec des équilibreurs de charge d'application internes

Pour en savoir plus, consultez les ressources suivantes :

Extensibilité avec des extensions de service

L'intégration avec les extensions de service vous permet d'injecter une logique personnalisée dans le chemin d'équilibrage de charge des équilibreurs de charge d'application compatibles.

Pour en savoir plus, consultez la page de Présentation des extensions de service.

Migrer d'anciens services vers Google Cloud

La migration d'un service existant vers Google Cloud vous permet de libérer la capacité sur site et de réduire la charge de travail et les coûts liés à la maintenance d'une infrastructure sur site. Vous pouvez configurer temporairement un déploiement hybride qui vous permet d'acheminer le trafic vers votre service sur site actuel et vers un point de terminaison de service Google Cloud correspondant.

Le schéma suivant illustre cette configuration avec un équilibreur de charge d'application interne. Si vous utilisez un équilibreur de charge interne, vous pouvez configurer l'équilibreur de charge Google Cloud pour répartir le trafic entre les deux services à l'aide de la répartition du trafic en fonction d'une pondération. La répartition du trafic vous permet de commencer par envoyer 0 % du trafic au service Google Cloud et 100 % au service sur site. Vous pouvez ensuite augmenter progressivement la proportion du trafic envoyée au service Google Cloud. Une fois que l'intégralité du trafic est envoyée vers le service Google Cloud, vous pouvez supprimer le service sur site.

Migrer d'anciens services vers Google Cloud.
Migrer d'anciens services vers Google Cloud.

Équilibrage de charge pour les applications GKE

Il existe trois façons de déployer des équilibreurs de charge d'application pour les clusters GKE :

  • GKE Gateway Controller. Compatible uniquement avec les équilibreurs de charge d'application externes globaux, les équilibreurs de charge d'application classiques et les équilibreurs de charge d'application internes régionaux. Pour obtenir des instructions de configuration, consultez Déployer des passerelles.
  • Contrôleur d'entrée GKE. Vous pouvez utiliser le contrôleur d'entrée GKE intégré, qui déploie des équilibreurs de charge Google Cloud pour le compte des utilisateurs de GKE. Il s'agit de la même architecture que l'architecture d'équilibrage de charge autonome, sauf que son cycle de vie est entièrement automatisé et contrôlé par GKE. Compatible avec les équilibreurs de charge d'application externes et internes. Pour obtenir des instructions de configuration, consultez les pages suivantes :
  • NEG zonaux autonomes. Les NEG autonomes sont déployés et gérés via le contrôleur NEG GKE, mais toutes les ressources d'équilibrage de charge (règles de transfert, vérifications d'état, etc.) sont déployées manuellement. Ils sont compatibles avec les équilibreurs de charge d'application externes et internes.

Équilibrage de charge pour les applications Cloud Run, Cloud Run Functions et App Engine

Vous pouvez utiliser un équilibreur de charge d'application comme interface pour vos applications sans serveur Google Cloud. Cela vous permet de configurer vos applications sans serveur pour diffuser des requêtes à partir d'une adresse IP dédiée qui n'est partagée avec aucun autre service.

Pour ce faire, vous utilisez un NEG sans serveur en tant que backend de l'équilibreur de charge. Les schémas suivants montrent comment une application sans serveur est intégrée à un équilibreur de charge d'application.

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.

Architecture d'équilibreur de charge d'application externe mondial pour les applications sans serveur
Architecture de l'équilibreur de charge d'application externe mondial pour les applications sans serveur

Régional, externe

Ce schéma montre comment un NEG sans serveur s'intègre dans une architecture d'équilibreur de charge d'application externe régional. Cet équilibreur de charge n'est compatible qu'avec les backends Cloud Run.

Architecture d'équilibreur de charge d'application interne régional pour les applications sans serveur.
Architecture de l'équilibreur de charge d'application externe régional pour les applications sans serveur.

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. Cet équilibreur de charge n'est compatible qu'avec les backends Cloud Run.

Architecture d'équilibreur de charge d'application interne régional pour les applications sans serveur.
Architecture d'équilibreur de charge d'application interne régional pour les applications sans serveur.

Interne 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. Cet équilibreur de charge n'est compatible qu'avec les backends Cloud Run.

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

Documentation associée :

Équilibrage de charge vers des backends extérieurs à Google Cloud

Les équilibreurs de charge d'application prennent en charge l'équilibrage de charge du trafic vers des points de terminaison qui vont au-delà de Google Cloud, tels que des centres de données sur site et d'autres environnements cloud. Les backends externes sont généralement accessibles de l'une des manières suivantes :

  • Accessible via l'Internet public. Pour ces points de terminaison, vous utilisez un NEG Internet en tant que backend de l'équilibreur de charge. Le NEG Internet est configuré pour pointer vers un seul point de terminaison FQDN:Port ou IP:Port sur le backend externe. Les NEG Internet peuvent être globaux ou régionaux.

    Le schéma suivant montre comment se connecter à des backends externes accessibles depuis l'Internet public à l'aide d'un NEG Internet global.

    Équilibreur de charge d'application externe mondial avec un backend externe.
    Équilibreur de charge d'application externe mondial avec un backend externe.

    Pour en savoir plus, consultez la présentation des NEG Internet.

  • Accessible via une connectivité hybride (Cloud Interconnect ou Cloud VPN). Pour ces points de terminaison, vous utilisez un NEG hybride en tant que backend de l'équilibreur de charge. Le NEG hybride est configuré pour pointer vers les points de terminaison IP:Port sur le backend externe.

    Les schémas suivants montrent comment se connecter à des backends externes accessibles à l'aide de Cloud Interconnect ou de Cloud VPN.

    Externe

    Connectivité hybride avec des équilibreurs de charge d'application externes mondiaux.
    Connectivité hybride avec des équilibreurs de charge d'application externes mondiaux.

    Interne

    Connectivité hybride avec des équilibreurs de charge d'application internes
    Connectivité hybride avec des équilibreurs de charge d'application internes

    Pour en savoir plus, consultez la présentation des NEG hybrides.

Intégration avec Private Service Connect

Private Service Connect permet la consommation privée de services sur des réseaux VPC appartenant à différents groupes, équipes, projets ou organisations. Vous pouvez utiliser Private Service Connect pour accéder aux API et services Google, ou à des services gérés dans un autre réseau VPC.

Vous pouvez utiliser un équilibreur de charge d'application externe mondial pour accéder aux services publiés à l'aide de Private Service Connect. Pour en savoir plus, consultez la page À propos des backends Private Service Connect.

Vous pouvez utiliser un équilibreur de charge d'application interne pour envoyer des requêtes aux Google API et services régionaux compatibles. Pour plus d'informations, consultez la page Accéder aux API Google via des backends.

Haute disponibilité et basculement interrégional

Le basculement interrégional n'est disponible qu'avec les équilibreurs de charge d'application externes globaux, les équilibreurs de charge d'application classiques et les équilibreurs de charge d'application internes interrégionaux. Ces équilibreurs de charge vous permettent d'améliorer la disponibilité des services lorsque vous créez des services de backend globaux avec des backends dans plusieurs régions. Si les backends d'une région spécifique sont indisponibles, le trafic bascule vers une autre région sans heurt.

Pour en savoir plus sur le fonctionnement du basculement, consultez les pages suivantes :