Présentation de l'équilibrage de charge HTTP(S) interne

L'équilibrage de charge HTTP(S) interne de Google Cloud est un équilibreur de charge régional de couche 7 basé sur un proxy qui vous permet d'exécuter et de faire évoluer vos services derrière une adresse IP interne.

L'équilibrage de charge HTTP(S) interne répartit le trafic HTTP et HTTPS entre les backends hébergés sur Compute Engine et Google Kubernetes Engine (GKE). L'équilibreur de charge n'est accessible que dans la région choisie de votre réseau de cloud privé virtuel (VPC), sur une adresse IP interne.

L'équilibrage de charge HTTP(S) interne est un service géré basé sur le proxy Envoy Open Source, ce qui permet de bénéficier de fonctionnalités avancées de contrôle du trafic s'appuyant sur les paramètres HTTP(S). Une fois l'équilibreur de charge configuré, il alloue automatiquement des proxys Envoy pour satisfaire vos besoins en termes de trafic.

De manière générale, un équilibreur de charge HTTP(S) interne se compose des éléments suivants :

  • Une adresse IP interne vers laquelle les clients envoient du trafic. Seuls les clients situés dans la même région que l'équilibreur de charge peuvent accéder à cette adresse IP. Les requêtes de clients internes restent en interne dans votre réseau et dans votre région.
  • Un ou plusieurs services de backend vers lesquels l'équilibreur de charge transmet le trafic. Les backends peuvent être des VM Compute Engine, des groupes de VM Compute Engine (via des groupes d'instances) ou des nœuds GKE (via des groupes de points de terminaison du réseau [NEG]). Ces backends doivent être situés dans la même région que l'équilibreur de charge.
Services internes avec un équilibrage de charge basé sur la couche 7 (cliquez pour agrandir)
Services internes avec un équilibrage de charge basé sur la couche 7 (cliquez pour agrandir)

Deux composants supplémentaires permettent de fournir le service d'équilibrage de charge :

  • Un mappage d'URL, qui définit des règles de contrôle du trafic (basées sur des paramètres de couche 7 tels que les en-têtes HTTP) correspondant à des services de backend spécifiques. L'équilibreur de charge évalue les requêtes entrantes en fonction du mappage d'URL afin d'acheminer le trafic vers les services de backend ou d'effectuer des actions supplémentaires (telles que des redirections).
  • Des vérifications d'état, qui vérifient régulièrement l'état des backends et réduisent le risque que le trafic client soit envoyé à un backend non réactif.

Pour connaître les limites spécifiques à l'équilibrage de charge HTTP(S) interne, consultez la section Limites.

Pour en savoir plus sur les différences entre les équilibreurs de charge Google Cloud, consultez les documents suivants :

Cas d'utilisation

L'équilibrage de charge HTTP(S) interne convient à de nombreux cas d'utilisation. Cette section fournit quelques exemples généraux. Pour découvrir d'autres exemples, consultez les cas d'utilisation de la gestion du trafic.

Équilibrage de charge à l'aide du routage basé sur un chemin d'accès

Un cas d'utilisation courant consiste à équilibrer la charge du trafic entre les services. Dans cet exemple, un client interne peut demander des vidéos et des images en utilisant la même URL de base, mygcpservice.internal, avec les chemins /video et /images.

Le mappage d'URL de l'équilibreur de charge HTTP(S) interne spécifie que les requêtes vers le chemin /video doivent être envoyées au service de backend des vidéos, et que les requêtes vers le chemin /images doivent être envoyées au service de backend des images. Dans l'exemple suivant, les services de backend des vidéos et des images sont diffusés à l'aide de VM Compute Engine, mais ils peuvent également être diffusés à l'aide de pods GKE.

Lorsqu'un client interne envoie une requête à l'adresse IP interne de l'équilibreur de charge, cet équilibreur évalue la requête selon cette logique avant de la transmettre au service de backend approprié.

Le schéma suivant illustre ce cas d'utilisation.

Services (microservices) internes avec un équilibrage de charge basé sur la couche 7 (cliquez pour agrandir)
Services (microservices) internes avec un équilibrage de charge basé sur la couche 7

Moderniser les anciens services

L'équilibrage de charge HTTP(S) interne peut constituer un outil efficace pour la modernisation des anciennes applications.

Votre ancienne application peut par exemple être une grande application monolithique difficile à mettre à jour. Dans ce cas, vous pouvez déployer un équilibreur de charge HTTP(S) interne devant votre ancienne application. Vous pouvez ensuite utiliser les fonctionnalités de contrôle du trafic de l'équilibreur de charge pour diriger un sous-ensemble du trafic vers de nouveaux microservices qui remplacent les fonctionnalités fournies par votre ancienne application.

Pour commencer, vous devez configurer le mappage d'URL de l'équilibreur de charge afin d'acheminer par défaut l'ensemble du trafic vers l'ancienne application. Cela permet de conserver le comportement existant. Au fil du développement des services de remplacement, vous devez mettre à jour le mappage d'URL pour acheminer des parties du trafic vers ces services de remplacement.

Imaginons que votre ancienne application comprend une fonctionnalité de traitement vidéo qui est diffusée lorsque des clients internes envoient des requêtes à /video. Vous pouvez séparer ce service vidéo dans un microservice distinct comme suit :

  1. Ajoutez l'équilibrage de charge HTTP(S) interne devant votre ancienne application.
  2. Créez un microservice de traitement vidéo de remplacement.
  3. Mettez à jour le mappage d'URL de l'équilibreur de charge pour que toutes les requêtes vers le chemin /video soient transmises au nouveau microservice plutôt qu'à l'ancienne application.

Lorsque vous développez des services de remplacement supplémentaires, vous devez continuer de mettre à jour le mappage d'URL. Au fil du temps, moins de requêtes seront acheminées vers l'ancienne application. À terme, vous disposerez de services de remplacement pour toutes les fonctionnalités fournies par l'ancienne application. À ce stade, vous pourrez supprimer l'ancienne application.

Services Web à trois niveaux

L'équilibrage de charge HTTP(S) interne vous permet d'assurer la compatibilité avec les services Web classiques à trois niveaux. L'exemple suivant décrit comment effectuer le scaling de trois niveaux à l'aide de trois types d'équilibreurs de charge Google Cloud. À chaque niveau, le type d'équilibreur de charge dépend de votre type de trafic :

Le schéma suivant illustre la façon dont le trafic transite par les différents niveaux :

  1. Un équilibreur de charge HTTP(S) externe répartit le trafic provenant d'Internet entre un ensemble de groupes d'instances frontend Web dans différentes régions.
  2. Ces interfaces envoient le trafic HTTP(S) vers un ensemble d'équilibreurs de charge HTTP(S) internes régionaux (sujet de cette présentation).
  3. Les équilibreurs de charge HTTP(S) internes répartissent le trafic entre les groupes d'instances middleware.
  4. Ces groupes d'instances middleware envoient le trafic aux équilibreurs de charge TCP/UDP internes qui équilibrent la charge du trafic entre les clusters de stockage de données.
Routage basé sur la couche 7 pour les niveaux internes d'une application à plusieurs niveaux (cliquez pour agrandir)
Routage basé sur la couche 7 pour les niveaux internes d'une application à plusieurs niveaux

Exemples d'accès

Vous pouvez accéder à un équilibreur de charge HTTP(S) interne dans votre réseau VPC à partir d'un réseau connecté à l'aide des éléments suivants :

  • Appairage de réseaux VPC
  • Cloud VPN et Cloud Interconnect

Pour obtenir des exemples détaillés, consultez la page Équilibrage de charge HTTP(S) interne et réseaux connectés.

Architecture et ressources

Le schéma suivant présente les ressources Google Cloud requises pour un équilibreur de charge HTTP(S) interne.

Composants de l'équilibrage de charge HTTP(S) interne (cliquez pour agrandir)
Composants de l'équilibrage de charge HTTP(S) interne

Dans le diagramme ci-dessus, le sous-réseau proxy réservé fournit un ensemble d'adresses IP utilisées par Google pour exécuter des proxys Envoy en votre nom. Vous devez créer un sous-réseau proxy réservé dans chaque région du réseau VPC dans lequel vous utilisez des équilibreurs de charge HTTP(S) internes. Tous les équilibreurs de charge HTTP(S) internes d'une région et d'un réseau VPC partagent le même sous-réseau proxy réservé, car tous les équilibreurs de charge HTTP(S) internes de la région et du réseau VPC partagent un pool de proxys Envoy. En outre :

  • Les sous-réseaux proxy réservés ne sont utilisés que pour les proxys Envoy, et non pour vos backends.
  • Les VM de backend ou les points de terminaison de tous les équilibreurs de charge HTTP(S) internes d'une région et d'un réseau VPC reçoivent les connexions du sous-réseau proxy réservé.
  • L'adresse IP d'un équilibreur de charge HTTP(S) interne n'est pas située dans le sous-réseau proxy réservé. L'adresse IP de l'équilibreur de charge est définie par sa règle de transfert gérée interne, décrite ci-dessous.

Chaque équilibreur de charge HTTP(S) interne utilise les ressources de configuration Google Cloud suivantes :

  • Une règle de transfert gérée interne spécifie une adresse IP interne, un port ainsi qu'un proxy HTTP(S) régional cible. Les clients utilisent l'adresse IP et le port pour se connecter aux proxys Envoy de l'équilibreur de charge. L'adresse IP de la règle de transfert correspond à l'adresse IP de l'équilibreur de charge (parfois appelée adresse IP virtuelle ou VIP).

  • Un proxy HTTP(S) régional cible reçoit une requête du client. Le proxy HTTP(S) évalue la requête à l'aide du mappage d'URL pour prendre des décisions d'acheminement du trafic. Le proxy peut également authentifier les communications avec des certificats SSL.

  • Le proxy HTTP(S) exploite un mappage d'URL régional pour déterminer le routage en fonction d'attributs HTTP (chemin de requête, cookies ou en-têtes, par exemple). En s'appuyant sur le routage choisi, le proxy transmet les requêtes des clients à des services de backend régionaux spécifiques. Le mappage d'URL peut spécifier des actions supplémentaires à effectuer, telles que la réécriture d'en-têtes, l'envoi de redirections à des clients et la configuration de règles de délais avant expiration, entre autres.

  • Un service de backend régional répartit les requêtes entre les backends opérationnels (groupes d'instances contenant des VM Compute Engine ou groupes de points de terminaison du réseau comprenant des conteneurs GKE).

  • Un ou plusieurs backends doivent être connectés au service de backend. Les backends peuvent être des groupes d'instances ou des groupes de points de terminaison du réseau ayant l'une des configurations suivantes :

    • Groupes d'instances gérés (zonaux ou régionaux)
    • Groupes d'instances non gérés (zonaux)
    • Groupes de points de terminaison du réseau (zonaux)

    Vous ne pouvez pas utiliser à la fois des groupes d'instances et des groupes de points de terminaison du réseau sur le même service de backend.

  • Une vérification d'état régionale surveille régulièrement la disponibilité de vos backends. Cela réduit le risque que des requêtes soient envoyées à des backends ne pouvant pas les traiter.

Certificats SSL

Si vous utilisez l'équilibrage de charge HTTPS, vous devez installer un ou plusieurs certificats SSL sur le proxy HTTPS cible.

Ces certificats sont utilisés par les proxys HTTPS cibles pour sécuriser les communications entre l'équilibreur de charge et le client.

Pour en savoir plus sur les limites et les quotas des certificats SSL, consultez la section Certificats SSL sur la page des quotas d'équilibrage de charge.

Pour une sécurité optimale, utilisez le chiffrement de bout en bout pour le déploiement de votre équilibreur de charge HTTPS. Pour en savoir plus, consultez la section Chiffrement entre l'équilibreur de charge et les backends.

Pour plus d'informations sur la façon dont Google chiffre le trafic des utilisateurs, consultez le livre blanc Chiffrement en transit sur Google Cloud.

Règles de pare-feu

Votre équilibreur de charge HTTP(S) interne nécessite les règles de pare-feu suivantes :

Délais d'expiration et nouvelles tentatives

Le délai avant expiration du service de backend est un délai avant expiration de requête/réponse pour le trafic HTTP(S). Il s'agit de la durée pendant laquelle l'équilibreur de charge attend qu'un backend renvoie une réponse complète à une requête.

Par exemple, si la valeur du délai avant expiration du service de backend est la valeur par défaut de 30 secondes, les backends ont 30 secondes pour répondre aux requêtes. L'équilibreur de charge réessaye la requête HTTP GET une fois si le backend ferme la connexion ou ne parvient pas à envoyer des en-têtes de réponse à l'équilibreur de charge avant expiration du délai. Si le backend envoie des en-têtes de réponse ou si la requête envoyée au backend n'est pas une requête HTTP GET, l'équilibreur de charge n'effectue pas de nouvelle tentative. Si le backend ne répond pas du tout, l'équilibreur de charge renvoie une requête HTTP 5xx au client. Pour ces équilibreurs de charge, modifiez la valeur du délai avant expiration si vous souhaitez accorder plus ou moins de temps aux backends pour répondre aux requêtes.

Types de trafic, schéma et champ d'application

Les services de backend sont compatibles avec les protocoles HTTP, HTTPS et HTTP/2. Les clients et les backends n'ont pas besoin d'utiliser le même protocole de requête. Par exemple, les clients peuvent envoyer des requêtes à l'équilibreur de charge à l'aide du protocole HTTP/2, et l'équilibreur de charge peut transférer ces requêtes aux backends en utilisant le protocole HTTP/1.1.

Comme le champ d'application d'un équilibreur de charge HTTP(S) interne est régional et non global, les VM des clients et du backend, ou les points de terminaison, doivent tous se trouver dans la même région.

Architectures de VPC partagé

L'équilibrage de charge HTTP(S) interne est compatible avec les réseaux qui utilisent un VPC partagé. Si vous n'êtes pas familiarisé avec le VPC partagé, consultez la présentation du VPC partagé. De manière générale :

  • Vous désignez un projet hôte et vous lui associez un ou plusieurs projets de service.
  • L'administrateur du projet hôte crée un ou plusieurs réseaux VPC partagés et sous-réseaux, puis les partage avec les projets de service.
  • Les ressources éligibles des projets de service peuvent utiliser des sous-réseaux du réseau VPC partagé.

Dans le cadre de l'équilibrage de charge HTTP(S) interne, deux options s'offrent à vous pour configurer l'équilibrage de charge au sein d'un réseau VPC partagé. Vous pouvez créer l'équilibreur de charge et ses instances backend dans le projet de service ou dans le projet hôte.

Équilibreur de charge et backends dans un projet de service

Dans ce modèle, vous déployez l'équilibreur de charge et les instances backend dans un projet de service. Vous configurez ensuite l'équilibreur de charge et les instances backend pour qu'ils utilisent le réseau VPC partagé.

Ce modèle de déploiement coïncide avec le cas d'utilisation classique du modèle de déploiement du réseau VPC partagé : la répartition des responsabilités entre les administrateurs réseau et les développeurs de services. Il permet aux administrateurs réseau d'allouer un espace d'adresses IP internes de manière sécurisée et efficace, et sépare clairement les responsabilités entre les administrateurs réseau et les développeurs de services.

Équilibrage de charge HTTP(S) interne sur un réseau VPC partagé
Équilibrage de charge HTTP(S) interne sur un réseau VPC partagé

Projet hôte

L'administrateur du projet hôte :

  • configure le réseau VPC partagé dans le projet hôte ;
  • provisionne les sous-réseaux du réseau VPC partagé ;
  • configure les règles de pare-feu dans le réseau VPC partagé.

Projet de service

  • L'administrateur du projet de service crée l'équilibreur de charge (règle de transfert, proxy HTTP(S) cible, mappage d'URL, service(s) de backend) et les instances backend dans le projet de service.
  • Les ressources d'équilibrage de charge et les instances backend font référence au réseau partagé et aux sous-réseaux du projet hôte du VPC partagé.

Ce modèle permet aux développeurs de services de créer des services à équilibrage de charge dans leurs propres projets de service. L'équipe en charge du développement de services peut également mettre à jour la configuration de l'équilibreur de charge et modifier les instances backend sans faire intervenir les administrateurs du projet hôte.

Si les clients se trouvent dans le même réseau VPC partagé que l'équilibreur de charge, ils peuvent se trouver dans le projet hôte ou dans un projet de service. Ces clients peuvent utiliser l'adresse IP privée de l'équilibreur de charge pour accéder aux services à équilibrage de charge.

Pour apprendre à configurer un équilibreur de charge HTTP(S) interne pour un réseau VPC partagé, consultez la page Configurer l'équilibrage de charge HTTP(S) interne avec un VPC partagé.

Équilibreur de charge et backends dans un projet hôte

Avec ce modèle de déploiement réseau, le réseau, l'équilibreur de charge et les backends sont tous situés dans le projet hôte. Bien que cette configuration fonctionne, elle n'est pas adaptée aux déploiements de VPC partagé classiques, car elle ne distingue pas les responsabilités des administrateurs réseau et des développeurs de services.

Si vous devez toutefois exécuter un équilibreur de charge et ses backends dans le projet hôte, vous pouvez suivre la procédure décrite sur la page Configurer l'équilibrage de charge HTTP(S) interne.

Limites

  • L'équilibrage de charge HTTP(S) interne fonctionne au niveau régional.

  • Rien ne garantit qu'une requête d'un client situé dans une zone de la région est envoyée à un backend situé dans la même zone que le client. L'affinité de session ne limite pas la communication entre les zones.

  • L'équilibrage de charge HTTP(S) interne n'est pas compatible avec les fonctionnalités suivantes :

  • Lors de la création d'un équilibreur de charge HTTP(S) interne dans un projet hôte ou de service de VPC partagé :

    • Tous les composants et les backends de l'équilibreur de charge doivent se trouver dans le même projet, qu'il s'agisse d'un projet hôte ou d'un projet de service. Par exemple, vous ne pouvez pas déployer la règle de transfert de l'équilibreur de charge dans un projet et créer des instances backend dans un autre projet.

    • Les clients peuvent se situer dans le projet hôte, dans n'importe quel projet de service associé ou n'importe quel réseau connecté. Les clients doivent utiliser le même réseau VPC partagé et se trouver dans la même région que l'équilibreur de charge.

    • Vous devez utiliser gcloud ou l'API pour créer ou afficher des équilibreurs de charge dans le projet de service. Vous ne pouvez pas créer ou afficher des équilibreurs de charge dans le projet de service à l'aide de Google Cloud Console.

  • Le protocole WebSocket n'est pas accepté.

  • Les équilibreurs de charge HTTP(S) internes ne sont compatibles avec le protocole HTTP/2 que via TLS.

  • Google Cloud ne vous avertit pas si votre sous-réseau proxy réservé manque d'adresses IP.

  • Au sein de chaque réseau VPC, chaque règle de transfert gérée interne doit posséder sa propre adresse IP. Pour en savoir plus, consultez la section Plusieurs règles de transfert avec une adresse IP commune.

  • La règle de transfert interne utilisée par votre équilibreur de charge HTTP(S) interne ne doit disposer que d'un port.

Étapes suivantes