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)

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.

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

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

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

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

Sous-réseau proxy réservé

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 réservé au proxy. L'adresse IP de l'équilibreur de charge est définie par sa règle de transfert gérée en interne et décrite ci-dessous.

Règle de transfert et adresse IP

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). Les clients se connectant à un équilibreur de charge HTTP(S) interne doivent utiliser HTTP version 1.1 ou ultérieure.

L'adresse IP interne associée à la règle de transfert peut provenir de n'importe quel sous-réseau (du même réseau et de la même région) dont l'option --purpose est définie sur PRIVATE. Remarques :

  • L'adresse IP peut (mais ne doit pas nécessairement) provenir du même sous-réseau que les groupes d'instances backend.
  • L'adresse IP ne doit pas provenir du sous-réseau réservé au proxy dont l'option --purpose est définie sur INTERNAL_HTTPS_LOAD_BALANCER.

Chaque règle de transfert que vous utilisez dans un équilibreur de charge HTTP(S) interne peut faire référence à un seul port TCP. Pour les équilibreurs de charge HTTP, utilisez le port 80 ou 8080. Pour les équilibreurs de charge HTTPS, utilisez le port 443.

Proxy cible

Un proxy HTTP(S) régional cible met fin aux connexions HTTP(S) des clients. Le proxy HTTP(S) consulte le mappage d'URL pour déterminer comment acheminer le trafic vers les backends. Un proxy HTTPS cible utilise un certificat SSL pour s'authentifier auprès des clients.

L'équilibreur de charge conserve l'en-tête "Host" de la requête du client d'origine. L'équilibreur de charge ajoute également deux adresses IP à l'en-tête X-Forwarded-For :

  • Adresse IP du client qui se connecte à l'équilibreur de charge
  • Adresse IP de la règle de transfert de l'équilibreur de charge

Si aucun en-tête X-Forwarded-For n'est présent dans la requête entrante, ces deux adresses IP correspondent à l'intégralité de la valeur d'en-tête. Si la requête comporte un en-tête X-Forwarded-For, d'autres informations, telles que les adresses IP enregistrées par les proxys au route vers l'équilibreur de charge, sont conservées avant les deux adresses IP. L'équilibreur de charge ne vérifie aucune adresse IP antérieure aux deux dernières adresses IP de cet en-tête.

Si vous exécutez un proxy en guise de serveur backend, ce proxy ajoute généralement plus d'informations à l'en-tête X-Forwarded-For. Votre logiciel devra peut-être en tenir compte. Les requêtes proxy de l'équilibreur de charge proviennent d'une adresse IP du sous-réseau proxy réservé, et votre proxy sur l'instance backend peut enregistrer cette adresse, ainsi que l'adresse IP de l'instance backend.

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.

Mappage d'URL

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.

Service backend

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

Les services de backend sont compatibles avec les protocoles HTTP, HTTPS et HTTP/2. Le protocole HTTP/2 n'est compatible qu'avec TLS. 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.

Un ou plusieurs backends doivent être connectés au service de backend. 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. 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.

Contrôle d'état

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.

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.

L'équilibrage de charge HTTP(S) interne présente trois types de délais d'expiration distincts :
  • Un délai avant expiration HTTP du service de backend 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 du service de backend est de 30 secondes. La plage complète des valeurs de délai avant expiration autorisées est de 1 à 2 147 483 647 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 à niveau vers une connexion WebSocket.

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 d'expiration de session est parfois appelé "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 WebSocket.

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;
  • Délai d'inactivité du flux, dont la valeur est fixée à 5 minutes (300 secondes). Cette valeur n'est pas configurable. Les flux HTTP deviennent inactifs après 5 minutes sans activité.
  • Certaines circonstances d'échec de requêtes GET conduisent l'équilibreur de charge à effectuer de nouvelles tentatives, par exemple lorsque le délai avant expiration du service de backend est écoulé. 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.

    Accès aux réseaux connecté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.

    Basculement

    Si un backend n'est plus opérationnel, le trafic est automatiquement redirigé vers des backends opérationnels dans la même région. Si aucun des backends n'est opérationnel, l'équilibreur de charge affiche une réponse HTTP 503 Service Unavailable.

    Assistance WebSocket

    Les équilibreurs de charge HTTP(S) de Google Cloud sont compatibles en mode natif avec le protocole WebSocket lorsque vous utilisez HTTP ou HTTPS en tant que protocole avec le backend. L'équilibreur de charge ne nécessite aucune configuration pour relayer les connexions WebSocket par proxy.

    Le protocole WebSocket fournit un canal de communication en duplex intégral entre clients et serveurs. Une requête HTTP(S) initialise le canal. Pour en savoir plus sur le protocole, consultez la RFC 6455.

    Lorsque l'équilibreur de charge reconnaît une requête WebSocket Upgrade d'un client HTTP(S) suivie d'une réponse Upgrade réussie de la part de l'instance backend, l'équilibreur de charge relaie le trafic bidirectionnel par proxy pendant la durée de la connexion en cours. Si l'instance backend ne renvoie pas de réponse Upgrade réussie, l'équilibreur de charge ferme la connexion.

    Le délai avant expiration d'une connexion WebSocket dépend du délai avant expiration du service backend configurable de l'équilibreur de charge, qui est de 30 secondes par défaut. Ce délai s'applique aux connexions WebSocket, qu'elles soient utilisées ou non.

    L'affinité de session pour WebSockets fonctionne de la même manière que pour toute autre requête. Pour en savoir plus, consultez la section Affinité de session.

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

    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, l'équilibreur de charge et les backends existent dans un projet de service et utilisent des adresses IP dans les sous-réseaux d'un réseau VPC partagé.

    Ce modèle de déploiement est étroitement aligné avec les cas d'utilisation courants du VPC partagé :

    • En divisant la responsabilité entre l'administration réseau et le développement de services, une séparation claire des responsabilités est maintenue entre les administrateurs réseau et les développeurs de services.
    • Les administrateurs réseau peuvent gérer les adresses IP internes de manière sécurisée et efficace.
    É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

    Dans le projet hôte :

    Projet de service

    • Le propriétaire, l'éditeur ou un rôle plus précis sur le projet de service (par exemple, un administrateur Compute) crée des instances backend.
    • Le propriétaire, l'éditeur ou un rôle plus précis sur le projet de service (par exemple, administrateur réseau ou administrateur d'équilibreur de charge) crée les composants de l'équilibreur de charge (règle de transfert, proxy HTTP(S) cible, mappage d'URL, services de backend et vérifications d'état).
    • Ces ressources d'équilibrage de charge et instances backend font référence à un réseau VPC partagé et à des sous-réseaux du projet hôte.

    Les clients peuvent accéder à l'équilibreur de charge s'ils se trouvent dans le même réseau VPC partagé et la même région que l'équilibreur de charge. Les clients peuvent se trouver dans un projet de service ou dans le projet hôte.

    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

    Dans ce modèle, le réseau VPC partagé, les composants de l'équilibreur de charge et les backends sont tous dans le projet hôte. Ce modèle ne sépare pas les responsabilités d'administration réseau et de développement de services.

    La configuration de ce modèle est identique à celle de l'équilibreur de charge dans un réseau VPC autonome. Suivez les étapes de la section Configurer l'équilibrage de charge HTTP(S) interne.

    Compatibilité avec TLS

    Par défaut, lorsqu'il interrompt les requêtes SSL des clients, un proxy HTTPS cible n'accepte que les protocoles TLS 1.0, 1.1, 1.2 et 1.3.

    Lorsque l'équilibreur de charge HTTP(S) interne utilise HTTPS comme protocole de service de backend, il peut négocier les protocoles TLS 1.0, 1.1 ou 1.2 vers le backend.

    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.

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

    • Les clients se connectant à un équilibreur de charge HTTP(S) interne doivent utiliser HTTP version 1.1 ou ultérieure.

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

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

    • L'équilibrage de charge HTTP(S) interne n'est pas compatible avec Cloud Trace.

    Étape suivante