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

L'équilibrage de charge HTTP(S) interne Google Cloud repose sur un équilibreur de charge régional de couche 7 basé sur un proxy qui vous permet d'assurer l'exécution et le scaling de vos services derrière une adresse IP d'équilibrage de charge 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 plus d'informations 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 comprenne 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 grâce à 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) interne 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 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

Les ressources suivantes définissent un équilibreur de charge HTTP(S) interne :

  • 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.

  • 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.

  • Si vous utilisez l'équilibrage de charge HTTP(S) interne, le proxy HTTP(S) prouve son identité aux clients à l'aide de certificats SSL régionaux. Un proxy HTTP(S) cible accepte un nombre limité de 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 d'expiration de délai, 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.

  • Un sous-réseau proxy réservé dont les adresses IP correspondent à la source du trafic entre les proxys de l'équilibreur de charge et vos backends. 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. Ce sous-réseau est géré par Google et partagé par tous vos équilibreurs de charge HTTP(S) internes de la région. Vous ne pouvez pas héberger vos backends à l'aide de ce sous-réseau.

  • Un pare-feu permettant aux backends d'accepter les connexions du sous-réseau proxy réservé. Pour en savoir plus, consultez l'exemple décrit dans la section Configurer les règles de pare-feu.

Délais d'expiration et nouvelles tentatives

L'équilibrage de charge HTTP(S) interne présente deux types de délais d'expiration distincts :
  • Un délai avant expiration de la réponse HTTP configurable, qui représente la durée pendant laquelle l'équilibreur de charge attend une réponse HTTP complète de la part de votre backend. La valeur par défaut du délai avant expiration de la réponse est de 30 secondes. Vous pouvez envisager d'augmenter ce délai dans les cas suivants :

    • si vous pensez qu'un backend va mettre plus de temps à renvoyer des réponses HTTP ;
    • si la connexion est mise à jour vers une connexion WebSocket (équilibrage de charge HTTP(S) uniquement).

    Lorsque vous envoyez le trafic WebSocket via l'équilibreur de charge, le délai avant expiration du service de backend est interprété comme la durée maximale pendant laquelle une connexion WebSocket peut rester ouverte, qu'elle soit active ou inactive. Pour en savoir plus, consultez la section Paramètres du service de backend.

  • Un délai d'expiration de la session TCP, dont la valeur est fixée à 10 minutes (600 secondes). Ce délai avant expiration de la session est parfois appelé message keepalive ou délai d'inactivité, et sa valeur ne peut pas être configurée par modification de votre service de backend. Pour empêcher la fermeture prématurée des connexions par le backend, vous devez configurer le logiciel de serveur Web utilisé par vos backends afin que son délai d'expiration "keepalive" soit supérieur à 600 secondes. Ce délai avant expiration ne s'applique pas aux connexions WebSockets.

Le tableau suivant présente les modifications à effectuer pour modifier les délais d'expiration "keepalive" des logiciels de serveur Web courants :

Logiciel de serveur Web Paramètre Réglage par défaut Réglage recommandé
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

Certaines circonstances d'échec de requêtes GET conduisent l'équilibreur de charge à effectuer de nouvelles tentatives, par exemple lorsqu'il y a expiration du délai de réponse. L'équilibreur ne tente pas de relancer les requêtes POST ayant échoué. La limite est de deux nouvelles tentatives. Les requêtes faisant l'objet d'une nouvelle tentative ne génèrent qu'une seule entrée de journal associée à la réponse finale.

Pour en savoir plus, consultez la page Journalisation et surveillance de l'équilibrage de charge HTTP(S) interne.

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.

Limites

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

  • Rien ne garantit que la requête d'un client 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 VPC partagé :

    • Les VM clientes peuvent se situer dans le projet hôte ou dans n'importe quel projet de service connecté. Les VM clientes doivent utiliser le même réseau VPC partagé et la même région que l'équilibreur de charge.
    • Tous les composants et les backends de l'équilibreur de charge doivent faire partie du projet hôte. Ce comportement est différent des autres équilibreurs de charge Google  Cloud, car aucun composant de l'équilibreur de charge HTTP(S) interne ne peut se trouver dans un projet de service lorsque l'équilibreur utilise un réseau VPC partagé.
    • Le projet hôte au sein du réseau VPC partagé possède et crée le sous-réseau proxy réservé (purpose=INTERNAL_HTTPS_LOAD_BALANCER).
  • 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.

Étape suivante