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

Ce document présente les concepts que vous devez maîtriser pour configurer l'équilibrage de charge HTTP(S) externe de Google Cloud.

Pour plus d'informations sur les différences entre les équilibreurs de charge Google Cloud, consultez les documents suivants :

Cas d'utilisation

Les équilibreurs de charge HTTP(S) externes permettent de répondre à de nombreux cas d'utilisation. Cette section fournit des exemples généraux.

Équilibrage de charge avec plusieurs types de backends

L'équilibrage de charge HTTP(S) externe est compatible avec les types de backend suivants :

Un cas d'utilisation courant consiste à équilibrer la charge du trafic entre les services. Dans l'exemple suivant, les clients IPv4 et IPv6 externes peuvent demander des vidéos, du contenu d'API et des images en utilisant la même URL de base, avec les chemins d'accès /api, /video et /images.

Le mappage d'URL de l'équilibreur de charge HTTP(S) externe spécifie que :

  • les requêtes vers le chemin /api sont envoyées au service de backend avec un groupe d'instances de VM ou un backend NEG zonal ;
  • les requêtes vers le chemin /images sont envoyées à un bucket backend à l'aide d'un backend Cloud Storage ;
  • les requêtes vers le chemin /video sont envoyées à un service de backend qui pointe vers un NEG Internet contenant un point de terminaison externe situé sur un site en dehors de Google Cloud.

Lorsqu'un client envoie une requête à l'adresse IPv4 ou IPv6 externe de l'équilibreur de charge, cet équilibreur évalue la requête en fonction du mappage d'URL et l'envoie au service approprié.

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

Schéma de l'équilibrage de charge avec une origine personnalisée (cliquez pour agrandir)
Schéma de l'équilibrage de charge avec une origine personnalisée (cliquez pour agrandir)

Sur chaque service de backend, vous pouvez éventuellement activer Cloud CDN et Google Cloud Armor. Si vous utilisez Google Cloud Armor avec Cloud CDN, les règles de sécurité ne sont appliquées que pour les requêtes de contenu dynamique, les défauts de cache (miss) ou d'autres requêtes destinées au serveur d'origine du CDN. Les succès de cache (hit) sont diffusés même si la règle de sécurité Google Cloud Armor en aval empêche cette requête d'atteindre le serveur CDN d'origine.

Cloud CDN est compatible avec les buckets backend, contrairement à Google Cloud Armor.

Services Web à trois niveaux

L'équilibrage de charge HTTP(S) externe 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 (sujet de cette présentation) 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.
  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 interrégional

Représentation de l'équilibrage de charge interrégional

Lorsque vous configurez un équilibreur de charge HTTP(S) externe de niveau Premium, celui-ci utilise une adresse IP externe globale et peut acheminer intelligemment les requêtes des utilisateurs vers le groupe d'instances de backend ou NEG le plus proche, en fonction de la proximité. Par exemple, si vous configurez des groupes d'instances en Amérique du Nord, en Europe et en Asie, et que vous les associez au service de backend d'un équilibreur de charge, les requêtes des utilisateurs du monde entier sont automatiquement envoyées aux VM les plus proches des utilisateurs, à condition que les VM réussissent les vérifications d'état et possèdent une capacité suffisante (définie par le mode d'équilibrage). Si les VM les plus proches sont toutes considérées comme non opérationnelles, ou si le groupe d'instances le plus proche est au maximum de sa capacité et qu'un autre groupe d'instances ne l'est pas, l'équilibreur de charge envoie automatiquement des requêtes à la prochaine région la plus proche disposant de la capacité nécessaire.


Équilibrage de charge basé sur le contenu

Représentation de l'équilibrage de charge basé sur le contenu

L'équilibrage de charge HTTP(S) est compatible avec l'équilibrage de charge basé sur le contenu, en utilisant des mappages d'URL pour sélectionner un service de backend selon le nom d'hôte demandé, le chemin d'accès demandé ou les deux. Vous pouvez par exemple utiliser un ensemble de groupes d'instances ou NEG pour gérer votre contenu vidéo et un autre ensemble pour gérer tout le reste.

Vous pouvez également utiliser l'équilibrage de charge HTTP(S) avec des buckets Cloud Storage. Une fois que vous avez configuré votre équilibreur de charge, vous pouvez y ajouter des buckets Cloud Storage.


Créer un équilibreur de charge combiné

Représentation de l'équilibrage de charge interrégional et basé sur le contenu

Vous pouvez configurer un équilibreur de charge HTTP(S) externe de niveau Premium pour fournir à la fois un équilibrage de charge basé sur le contenu et interrégional, en utilisant plusieurs services de backend, chacun avec des groupes d'instances de backend ou des NEG dans plusieurs régions. Vous pouvez combiner et étendre les cas d'utilisation afin de configurer un équilibreur de charge HTTP(S) externe adapté à vos besoins.


Exemple de configuration

Si vous souhaitez vous lancer directement et créer un équilibreur de charge opérationnel à des fins de test, consultez la page Configurer un simple équilibreur de charge HTTP externe ou la page Configurer un simple équilibreur de charge HTTPS externe.

Pour un exemple plus complexe présentant l'équilibrage de charge interrégional basé sur le contenu, consultez la page Créer un équilibreur de charge HTTPS.

Fonctionnement des connexions dans l'équilibrage de charge HTTP(S)

L'équilibrage de charge HTTP(S) externe est un service mis en œuvre par de nombreux proxys appelés GFE (Google Front End). Il n'y a pas qu'un seul proxy. Au niveau Premium, la même adresse IP externe globale est annoncée à partir de divers points de présence et le trafic est dirigé vers le GFE le plus proche du client.

Selon l'emplacement de vos clients, plusieurs GFE peuvent initier des connexions HTTP(S) à vos backends. Les paquets envoyés à partir des GFE ont des adresses IP sources de la même plage que celle utilisée par les vérificateurs d'état : 35.191.0.0/16 et 130.211.0.0/22.

Selon la configuration du service de backend, le protocole utilisé par chaque GFE pour se connecter aux backends peut être HTTP, HTTPS ou HTTP/2. Dans le cas de HTTP ou HTTPS, la version HTTP est HTTP 1.1. Le message HTTP keepalive est activé par défaut, comme indiqué dans la spécification HTTP 1.1. Le GFE utilise un délai avant expiration de 600 secondes pour le message keepalive, et vous ne pouvez pas le configurer. Vous pouvez toutefois configurer le délai avant expiration de la requête/réponse en définissant le délai avant expiration du service de backend. Pour en savoir plus, consultez la section Délais d'expiration et nouvelles tentatives.

Les messages keepalive HTTP tentent d'utiliser efficacement la même session TCP. mais il n'y a aucune garantie. Bien qu'ils soient étroitement liés, un message keepalive HTTP et un délai d'inactivité TCP ne sont pas identiques.

Le nombre de connexions HTTP et de sessions TCP varie en fonction du nombre de GFE connectés, du nombre de clients se connectant aux GFE, du protocole de communication avec les backends et de l'emplacement des backends.

Pour en savoir plus, consultez la section Fonctionnement de l'équilibrage de charge HTTP(S) du guide "Optimiser la capacité des applications avec l'équilibrage de charge global".

Architecture et ressources

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

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

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

  • Une règle de transfert externe spécifie une adresse IP externe, un port et un proxy HTTP(S) cible mondial. Les clients utilisent l'adresse IP et le port pour se connecter à 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 HTTPS, le proxy HTTPS cible prouve son identité aux clients à l'aide de certificats SSL mondiaux. Un proxy HTTP(S) cible accepte un nombre limité de certificats SSL.

  • Le proxy HTTP(S) exploite un mappage d'URL mondial 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 ou des buckets backend spécifiques. Le mappage d'URL peut spécifier des actions supplémentaires, telles que l'envoi de redirections à des clients.

  • Un service de backend ou un bucket backend répartit les requêtes entre les backends opérationnels.

  • Un ou plusieurs backends doivent être connectés au service de backend ou au bucket backend. Les backends peuvent être des groupes d'instances, des NEG ou des buckets 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)
    • Groupes de points de terminaison du réseau (Internet)
    • Buckets Cloud Storage

    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 pare-feu permettant aux backends d'accepter les vérifications d'état.

Adresses IP sources

Les adresses IP sources des paquets, telles qu'elles sont perçues par chaque instance de machine virtuelle (VM) ou conteneur backend, proviennent des plages suivantes :

  • 35.191.0.0/16
  • 130.211.0.0/22

L'adresse IP source du trafic réel à équilibrage de charge est identique à celle des plages d'adresses IP des vérifications d'état.

Les adresses IP sources du trafic, telles qu'elles sont perçues par les backends, sont différentes de l'adresse IP externe Google Cloud de l'équilibreur de charge. En d'autres termes, il existe deux sessions HTTP, SSL ou TCP :

  • Session 1, du client d'origine vers l'équilibreur de charge (GFE) :

    • Adresse IP source : le client d'origine (ou l'adresse IP externe si le client est protégé par la fonctionnalité NAT).
    • Adresse IP de destination : l'adresse IP de votre équilibreur de charge.
  • Session 2, de l'équilibreur de charge (GFE) vers la VM de backend ou le conteneur :

    • Adresse IP source : une adresse IP située dans l'une de ces plages : 35.191.0.0/16 ou 130.211.0.0/22.

      Vous ne pouvez pas prédire l'adresse source réelle.

    • Adresse IP de destination : une adresse IP interne de la VM de backend ou du conteneur dans le réseau cloud privé virtuel (VPC).

Communication entre les clients et l'équilibreur de charge

  • Les clients peuvent communiquer avec l'équilibreur de charge via le protocole HTTP 1.1 ou HTTP/2.
  • Lorsque HTTPS est utilisé, les clients modernes utilisent par défaut HTTP/2. Ce fonctionnement est contrôlé au niveau du client et non au niveau de l'équilibreur de charge HTTPS.
  • Vous ne pouvez pas désactiver HTTP/2 en modifiant la configuration sur l'équilibreur de charge. Toutefois, vous pouvez configurer certains clients pour qu'ils utilisent HTTP 1.1 au lieu de HTTP/2. Par exemple, avec curl, définissez le paramètre --http1.1.
  • Les équilibreurs de charge HTTPS n'acceptent pas l'authentification basée sur un certificat client, également appelée authentification TLS mutuelle.

Ports ouverts

Les équilibreurs de charge HTTP(S) externes sont des équilibreurs de charge de type proxy inverse. L'équilibreur de charge interrompt les connexions entrantes, puis ouvre de nouvelles connexions entre lui-même et les backends. La fonctionnalité de proxy inverse est fournie par Google Front End (GFE).

Les règles de pare-feu que vous définissez bloquent le trafic entre les GFE et les backends, mais elles ne bloquent pas le trafic entrant vers les GFE.

Les équilibreurs de charge HTTP(S) externes offrent un certain nombre de ports ouverts pour les autres services Google exécutés sur la même architecture. Si vous effectuez une analyse de sécurité ou de port sur l'adresse IP externe de votre équilibreur de charge HTTP(S) externe Google Cloud, vous allez constater que des ports supplémentaires semblent être ouverts.

Cela n'affecte en rien les équilibreurs de charge HTTP(S) externes. Les règles de transfert externes utilisées dans la définition d'un équilibreur de charge HTTP(S) externe ne peuvent faire référence qu'aux ports TCP 80, 8080 et 443. Le trafic associé aux autres ports de destination TCP n'est pas transféré vers le backend de l'équilibreur de charge.

Composants

Les éléments présentés ci-dessous sont les composants des équilibreurs de charge HTTP(S) externes.

Règles de transfert et adresses

Les règles de transfert permettent d'acheminer le trafic par adresse IP, port et protocole vers une configuration d'équilibrage de charge comprenant un proxy cible et un ou plusieurs services de backend.

Chaque règle de transfert fournit une adresse IP unique que vous pouvez utiliser dans les enregistrements DNS relatifs à votre application. Aucun équilibrage de charge DNS n'est requis. Vous pouvez soit spécifier une adresse IP qui sera utilisée par le service, soit laisser Cloud Load Balancing en attribuer une.

  • La règle de transfert d'un équilibreur de charge HTTP ne peut faire référence qu'aux ports TCP 80 et 8080.
  • La règle de transfert d'un équilibreur de charge HTTPS ne peut faire référence qu'au port TCP 443.

Le type de règle de transfert requis par les équilibreurs de charge HTTP(S) externes dépend du niveau de service réseau de l'équilibreur de charge.

  • Les équilibreurs de charge HTTP(S) externes de niveau Premium utilisent des règles de transfert externes mondiales.
  • Les équilibreurs de charge HTTP(S) externes de niveau Standard utilisent des règles de transfert externes régionales.

Proxy cibles

Les proxys cibles interrompent les connexions HTTP(S) des clients. Une ou plusieurs règles de transfert dirigent le trafic vers le proxy cible, qui consulte le mappage d'URL pour déterminer comment acheminer le trafic vers les backends.

Les proxys définissent les en-têtes de requête et de réponse HTTP comme suit :

  • Via: 1.1 google (requêtes et réponses)
  • X-Forwarded-Proto: [http | https] (requêtes uniquement)
  • X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options> (requêtes uniquement)
    Contient des paramètres pour Cloud Trace.

Vous pouvez créer des en-têtes de requête personnalisés si les en-têtes par défaut ne répondent pas à vos besoins. Pour en savoir plus sur cette fonctionnalité, consultez la page Créer des en-têtes de requête définis par l'utilisateur.

Ne vous attendez pas à ce que le proxy préserve la casse des noms dans les en-têtes de requête ou de réponse. Par exemple, un en-tête de réponse Server: Apache/1.0 peut se présenter sous la forme server: Apache/1.0 au niveau du client.

En-tête d'hôte

Lorsque l'équilibreur de charge effectue la requête HTTP, il conserve l'en-tête d'hôte de la requête d'origine.

En-tête "X-Forwarded-For"

L'équilibreur de charge ajoute deux adresses IP à l'en-tête "X-Forwarded-For" :

  • Adresse IP du client qui se connecte à l'équilibreur de charge

  • Adresse IP de l'équilibreur de charge

S'il n'y a pas d'en-tête "X-Forwarded-For" dans la requête entrante, ces deux adresses IP constituent la valeur entière de l'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 sur le chemin de 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 sur votre instance backend, ce proxy ajoute généralement plus d'informations à l'en-tête "X-Forwarded-For", et votre logiciel devra peut-être en tenir compte. Les requêtes proxy de l'équilibreur de charge proviennent d'une adresse IP comprise dans la plage 130.211.0.0/22 ou 35.191.0.0/16, et votre proxy sur l'instance backend peut enregistrer cette adresse, ainsi que l'adresse IP de l'instance backend elle-même.

Mappages d'URL

Les mappages d'URL définissent des modèles de correspondance pour le routage de requêtes vers les services de backend appropriés en fonction de l'URL de la requête. Un service par défaut est défini pour gérer toute requête qui ne correspond pas à une règle d'hôte ou à une règle de correspondance de chemin donnée. Dans certaines situations, par exemple celle décrite dans l'exemple d'équilibrage de charge interrégional, vous pouvez choisir de ne définir aucune règle d'URL et de vous appuyer seulement sur le service par défaut. Pour l'acheminement du trafic basé sur le contenu, le mappage d'URL vous permet de répartir votre trafic en examinant les éléments constituant l'URL afin d'envoyer les requêtes à différents ensembles de backends.

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 SSL

Les règles SSL vous permettent de contrôler les fonctionnalités SSL que votre équilibreur de charge HTTPS négocie avec les clients HTTPS.

Par défaut, l'équilibrage de charge HTTPS utilise un ensemble de fonctionnalités SSL offrant une bonne sécurité et une compatibilité étendue. Certaines applications requièrent davantage de contrôle sur les versions SSL et les algorithmes de chiffrement utilisés pour les connexions HTTPS ou SSL. Vous pouvez définir des règles SSL contrôlant les fonctionnalités SSL que votre équilibreur de charge négocie et associer une règle SSL à votre proxy HTTPS cible.

Contrôle géographique des emplacements où le protocole TLS est interrompu

L'équilibreur de charge HTTPS interrompt le protocole TLS dans les emplacements distribués à l'échelle mondiale, de manière à réduire la latence entre les clients et l'équilibreur de charge. Si vous avez besoin d'exercer un contrôle géographique sur ces emplacements, vous devez plutôt faire appel à l'équilibrage de charge au niveau du réseau de Google Cloud, et interrompre le protocole TLS sur les backends situés dans les régions correspondant à vos besoins.

Services de backend

Les services de backend fournissent des informations de configuration à l'équilibreur de charge. Un équilibreur de charge HTTP(S) externe doit comporter au moins un service de backend, et il peut en avoir plusieurs.

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 backends d'un service de backend sont soit des groupes d'instances, soit des groupes de points de terminaison de réseau (NEG), mais il ne peut pas s'agir d'une combinaison des deux. Lorsque vous ajoutez un groupe d'instances backend ou un NEG, vous spécifiez un mode d'équilibrage qui définit une méthode de répartition des requêtes et une capacité cible. Pour en savoir plus, consultez la section Algorithme de répartition de la charge.

L'équilibrage de charge HTTP(S) est compatible avec l'autoscaler Cloud Load Balancing, qui permet aux utilisateurs d'effectuer un autoscaling sur les groupes d'instances d'un service de backend. Pour en savoir plus, consultez la page Scaling basé sur la capacité de diffusion de l'équilibrage de charge HTTP(S).

Vous pouvez activer le drainage de connexion sur les services de backend afin de garantir à vos utilisateurs un temps d'interruption minimal lorsqu'une instance assurant la diffusion du trafic est arrêtée, supprimée manuellement ou supprimée par un autoscaler. Pour en savoir plus, consultez la page Activer le drainage de connexion.

Les modifications apportées à un service de backend associé à un équilibreur de charge HTTP(S) externe ne sont pas instantanées. Leur propagation sur le réseau peut prendre plusieurs minutes.

Comportement de l'équilibreur de charge dans différents niveaux de service réseau

L'équilibrage de charge HTTP(S) est un service à l'échelle mondiale disponible avec le niveau de service réseau Premium. Vous pouvez avoir plusieurs services de backend dans une région et créer des services de backend dans plusieurs régions, tous desservis par le même équilibreur de charge mondial. Le trafic est alloué aux services de backend de la manière suivante :

  1. Lorsqu'une requête utilisateur arrive, le service d'équilibrage de charge détermine son origine approximative à partir de l'adresse IP source.
  2. Le service d'équilibrage de charge connaît les emplacements des instances détenues par le service de backend, leur capacité globale et leur utilisation actuelle globale.
  3. Si les instances les plus proches de l'utilisateur ont de la capacité disponible, la requête est transmise à l'ensemble d'instances le plus proche.
  4. Les requêtes envoyées vers la région donnée sont distribuées de manière équitable entre l'ensemble des instances et des services de backend disponibles dans cette région. Toutefois, pour des charges très faibles, la distribution peut sembler non équitable.
  5. Si aucune instance opérationnelle d'une région donnée n'a de capacité disponible, l'équilibreur de charge envoie la requête à la région la plus proche avec de la capacité disponible.

L'équilibrage de charge HTTP(S) est un service régional disponible avec le niveau de service réseau Standard. Ses groupes d'instances backend ou ses NEG doivent tous être situés dans la région utilisée par l'adresse IP externe et la règle de transfert de l'équilibreur de charge.

Vérifications d'état

Chaque service de backend spécifie également les vérifications d'état à effectuer sur chaque instance disponible. Pour que les tests de vérification d'état fonctionnent correctement, vous devez créer une règle de pare-feu autorisant le trafic provenant de 130.211.0.0/22 et de 35.191.0.0/16 à accéder à vos instances.

Pour en savoir plus sur les vérifications d'état, consultez la page Créer des vérifications d'état.

Protocole de communication avec les backends

Lorsque vous configurez un service de backend pour l'équilibreur de charge HTTP(S) externe, vous définissez le protocole utilisé par le service de backend pour communiquer avec les backends. Vous pouvez choisir parmi HTTP, HTTPS ou HTTP/2. L'équilibreur de charge utilise uniquement le protocole que vous spécifiez. S'il ne parvient pas à négocier une connexion au backend avec le protocole spécifié, l'équilibreur de charge ne recourt pas à l'un des autres protocoles.

Si vous choisissez HTTP/2, vous devez utiliser TLS. Le protocole HTTP/2 sans chiffrement n'est pas accepté.

Bien que ce ne soit pas obligatoire, il est recommandé d'utiliser une vérification d'état dont le protocole correspond à celui du service de backend. Par exemple, une vérification d'état HTTP/2 permet de tester plus précisément la connectivité HTTP/2 aux backends.

Utiliser gRPC avec vos applications Google Cloud

gRPC est un framework Open Source pour les appels de procédure à distance. Il est basé sur le standard HTTP/2. Voici quelques exemples d'utilisation de gRPC :

  • Systèmes distribués à faible latence et hautement évolutifs
  • Développement de clients mobiles communiquant avec un serveur cloud
  • Conception de nouveaux protocoles devant être précis, efficaces et indépendants du langage
  • Conception à plusieurs couches pour permettre l'extension, l'authentification et la journalisation

Pour utiliser gRPC avec vos applications Google Cloud, vous devez relayer les requêtes par proxy de bout en bout via HTTP/2. Pour y parvenir avec un équilibreur de charge HTTP(S) externe, procédez comme suit :

  1. Configurez un équilibreur de charge HTTPS.
  2. Activez HTTP/2 comme protocole à utiliser entre l'équilibreur de charge et les backends.

L'équilibreur de charge négocie le protocole HTTP/2 avec les clients dans le cadre du handshake SSL à l'aide de l'extension TLS ALPN.

L'équilibreur de charge peut toujours négocier le protocole HTTPS avec certains clients ou accepter des requêtes HTTP non sécurisées sur un équilibreur de charge HTTP(S) externe configuré pour utiliser HTTP/2 entre l'équilibreur de charge et les instances backend. Ces requêtes HTTP ou HTTPS sont transformées par l'équilibreur de charge pour relayer les requêtes par proxy via HTTP/2 vers les instances backend.

Si vous souhaitez configurer un équilibreur de charge HTTP(S) externe en utilisant HTTP/2 avec un objet Ingress Google Kubernetes Engine, ou en associant gRPC et HTTP/2 avec un objet Ingress, consultez la page HTTP/2 pour l'équilibrage de charge avec l'objet Ingress.

Pour en savoir plus sur la résolution des problèmes liés à HTTP/2, consultez la section Résoudre les problèmes liés à l'utilisation de HTTP/2 avec les backends.

Pour plus d'informations sur les limites du protocole HTTP/2, consultez la section Limites liées à HTTP/2.

Buckets backend

Les buckets backend dirigent le trafic entrant vers des buckets Cloud Storage.

Comme illustré dans le schéma suivant, vous pouvez configurer l'équilibreur de charge pour envoyer le trafic présentant un chemin d'accès /static vers un bucket de stockage, et toute autre requête vers vos autres backends.

Répartition du trafic sur différents types de backends avec l'équilibrage de charge HTTP(S) (cliquez pour agrandir)
Répartition du trafic sur différents types de backends avec l'équilibrage de charge HTTP(S) (cliquez pour agrandir)

Pour obtenir un exemple d'ajout d'un bucket à un équilibreur de charge existant, consultez la page Configurer un équilibreur de charge avec des buckets backend.

Règles de pare-feu

Les instances backend doivent autoriser les connexions à partir des plages GFE ou de vérification d'état de l'équilibreur de charge. Cela signifie que vous devez créer une règle de pare-feu qui permet au trafic de 130.211.0.0/22 et 35.191.0.0/16 d'atteindre vos instances ou points de terminaison principaux. Ces plages d'adresses IP sont utilisées comme sources pour les paquets de vérification de l'état et pour tous les paquets à charge équilibrée envoyés à vos backends.

Les ports que vous configurez pour cette règle de pare-feu doivent autoriser l'acheminement du trafic vers des instances ou des points de terminaison :

  • Vous devez autoriser les ports utilisés par chaque règle de transfert.
  • Vous devez autoriser les ports utilisés par chaque vérification d'état configurée pour chaque service de backend.

Les règles de pare-feu sont mises en œuvre au niveau de l'instance de VM, et non sur les proxys Google Front End (GFE). Vous ne pouvez pas utiliser les règles de pare-feu Google Cloud pour empêcher le trafic d'atteindre l'équilibreur de charge.

Pour plus d'informations sur les vérifications de l'état et découvrir pourquoi il est nécessaire d'autoriser le trafic en provenance de 130.211.0.0/22 et de 35.191.0.0/16, consultez la section Plages d'adresses IP de vérification et règles de pare-feu.

Chemin de retour

Pour les vérifications d'état, Google Cloud utilise des routages spéciaux non définis dans votre réseau VPC. Pour en savoir plus, consultez la section Chemins de retour pour les équilibreurs de charge.

Algorithme de répartition de la charge

Lorsque vous ajoutez un groupe d'instances backend ou un NEG à un service de backend, vous spécifiez un mode d'équilibrage, qui définit une méthode mesurant la charge du backend et une capacité cible. L'équilibrage de charge HTTP(S) externe accepte deux modes d'équilibrage :

  • RATE, pour les groupes d'instances ou les NEG, est le nombre cible maximal de requêtes par seconde (RPS). La valeur RPS cible maximale peut être dépassée si tous les backends ont une capacité égale ou supérieure.

  • UTILIZATION est l'utilisation du backend des VM dans un groupe d'instances.

Avant qu'un serveur GFE (Google Front End) envoie des requêtes aux instances backend, le GFE estime quelles instances backend peuvent recevoir des requêtes. Cette estimation de la capacité est effectuée de manière proactive, et non au moment où les requêtes arrivent. Les GFE reçoivent régulièrement des informations sur la capacité disponible et distribuent les requêtes entrantes en conséquence.

La capacité dépend en partie du mode d'équilibrage. Pour le mode RATE, c'est relativement simple : un GFE détermine exactement le nombre de requêtes qu'il peut attribuer par seconde. L'équilibrage de charge basé sur UTILIZATION est plus complexe : l'équilibreur de charge vérifie l'utilisation actuelle des instances, puis estime une charge de requête que chaque instance peut gérer. Cette estimation évolue au fil du temps lorsque l'utilisation des instances et les modèles de trafic changent.

Ces deux facteurs (l'estimation de la capacité et l'attribution proactive) influencent la répartition entre les instances. Ainsi, Cloud Load Balancing se comporte différemment d'un simple équilibreur de charge round robin (à tour de rôle) qui répartit exactement les requêtes à 50/50 entre deux instances. Au lieu de cela, l'équilibrage de charge Google Cloud tente d'optimiser la sélection de l'instance backend pour chaque requête.

Pour en savoir plus, consultez la section Distribution du trafic.

Pour en savoir plus sur les modes d'équilibrage, consultez la section Mode d'équilibrage.

Niveaux de service réseau

Lorsqu'un équilibreur de charge HTTP(S) externe dispose du niveau Premium, les requêtes envoyées à l'équilibreur de charge sont transmises aux groupes d'instances backend ou aux NEG situés dans la région la plus proche de l'utilisateur, si un backend de cette région dispose de la capacité requise. (La capacité disponible est configurée par le mode d'équilibrage de l'équilibreur de charge.)

Lorsqu'un équilibreur de charge HTTP(S) externe dispose du niveau Standard, ses groupes d'instances backend ou ses NEG doivent tous être situés dans la région utilisée par l'adresse IP externe et la règle de transfert de l'équilibreur de charge.

Régions et zones

Après avoir sélectionné une région :

  • Lorsque vous configurez des backends dans plusieurs zones de la région, un équilibreur de charge HTTP(S) externe tente d'équilibrer les requêtes aussi régulièrement que possible dans les zones, en fonction de la capacité de l'instance backend et de l'affinité de session.

  • Au sein d'une zone, un équilibreur de charge HTTP(S) externe tente de répartir les requêtes à l'aide de l'algorithme d'équilibrage de charge, en fonction de la capacité disponible et de l'affinité de session.

Affinité de session

L'affinité de session tente au mieux d'envoyer les requêtes d'un client donné au même backend, à condition qu'il soit opérationnel et dispose d'une capacité suffisante, en fonction du mode d'équilibrage configuré.

Dans Google Cloud, l'équilibrage de charge HTTP(S) propose trois types d'affinité de session :

Lorsque vous utilisez l'affinité de session, nous vous recommandons d'utiliser le mode d'équilibrage RATE au lieu de UTILIZATION. L'affinité de session est plus efficace si vous définissez le mode d'équilibrage sur le nombre de requêtes par seconde (RPS).

Compatibilité du proxy WebSocket

L'équilibrage de charge HTTP(S) est compatible en mode natif avec le protocole WebSocket lorsque vous utilisez HTTP ou HTTPS, et non HTTP/2, en tant que protocole avec le backend.

Les backends employant le protocole WebSocket pour communiquer avec les clients peuvent utiliser l'équilibreur de charge HTTP(S) externe comme interface à des fins d'évolutivité et de disponibilité. L'équilibreur de charge ne nécessite aucune configuration supplémentaire pour relayer les connexions WebSocket par proxy.

Le protocole WebSockets, défini dans le document RFC 6455, fournit un canal de communication en duplex intégral entre un client et un serveur. Le canal est mis en place à partir d'une requête HTTP(S).

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

Le délai d'expiration d'une connexion WebSocket dépend du délai avant expiration de la réponse configurable sur l'équilibreur de charge, qui est de 30 secondes par défaut. Ce délai est appliqué aux connexions WebSocket, qu'elles soient utilisées ou non. Pour en savoir plus sur le délai avant expiration de la réponse et sur sa configuration, consultez la section Délais d'expiration et nouvelles tentatives.

Si vous avez configuré l'affinité de session basée sur les adresses IP client ou sur les cookies générés pour votre équilibreur de charge HTTP(S) externe, toutes les connexions WebSocket d'un client sont envoyées à la même instance backend tant que ses vérifications d'état réussissent et qu'elle dispose de la capacité nécessaire.

Le protocole WebSocket est compatible avec les objets Ingress.

Utiliser le protocole QUIC pour l'équilibrage de charge HTTPS

L'équilibrage de charge HTTPS est compatible avec le protocole QUIC dans le cadre des connexions entre l'équilibreur de charge et les clients. QUIC est un protocole de couche de transport offrant un contrôle de congestion semblable à TCP et une sécurité équivalente à SSL/TLS pour HTTP/2, avec des performances améliorées. QUIC permet d'initier les connexions client plus rapidement, élimine le blocage en tête de ligne dans les flux multiplexés et permet de migrer la connexion lorsque l'adresse IP d'un client change.

QUIC affecte les connexions entre les clients et l'équilibreur de charge, et non les connexions entre l'équilibreur de charge et les backends.

Le paramètre de remplacement QUIC du proxy cible vous permet d'activer l'un des éléments suivants :

  • Lorsque c'est possible, négocier le protocole QUIC pour un équilibreur de charge.
  • Toujours désactiver QUIC pour un équilibreur de charge.

Si vous ne spécifiez pas la valeur du paramètre de remplacement QUIC, vous autorisez Google à gérer l'utilisation de QUIC. Google n'active QUIC que lorsque l'option --quic-override de l'outil de ligne de commande gcloud est définie sur ENABLE ou que l'option quicOverride de l'API REST est définie sur ENABLE.

Pour en savoir plus sur l'activation et la désactivation de la compatibilité QUIC, consultez la documentation sur les proxys cibles. Vous pouvez activer ou désactiver la compatibilité QUIC des façons suivantes :

Le certificat SSL doit répondre aux exigences suivantes de QUIC :

  • L'attribut CommonName (CN) du certificat SSL doit correspondre à un nom DNS qui pointe vers l'adresse IP de l'équilibreur de charge. Sinon, l'équilibreur de charge ne diffuse pas de contenu QUIC.
  • Le certificat SSL doit être signé par une autorité de certification (CA) reconnue par le client. Le transport QUIC ne peut pas être négocié si votre équilibreur de charge utilise un certificat autosigné ou un certificat signé par une autorité de certification non approuvée par le client.

Négociation du protocole QUIC

Lorsque vous activez QUIC, l'équilibreur de charge HTTPS peut annoncer sa capacité QUIC aux clients, ce qui permet aux clients compatibles de tenter d'établir des connexions QUIC avec lui. Les clients correctement mis en œuvre peuvent toujours revenir au protocole HTTPS ou HTTP/2 lorsqu'ils ne parviennent pas à établir une connexion QUIC. Du fait de ce mécanisme, activer ou désactiver QUIC dans l'équilibreur de charge n'affecte pas sa capacité à se connecter aux clients.

Lorsque QUIC est activé dans votre équilibreur de charge HTTPS, certaines circonstances peuvent amener le client à revenir au protocole HTTPS ou HTTP/2 au lieu de négocier le protocole QUIC. En voici quelques exemples :

  • Lorsqu'un client est compatible avec des versions de QUIC qui ne sont pas acceptées par l'équilibreur de charge HTTPS.
  • Lorsque l'équilibreur de charge détecte que le trafic UDP est bloqué ou soumis à une limitation de débit, d'une manière qui empêcherait le bon fonctionnement de QUIC.
  • Si QUIC est désactivé de manière temporaire au niveau des équilibreurs de charge HTTPS en réponse à des bugs, des vulnérabilités ou d'autres problèmes.

Lorsqu'une connexion se rabat sur HTTPS ou HTTP/2 dans ces cas de figure, nous ne comptabilisons pas ce problème comme une défaillance de l'équilibreur de charge.

Avant d'activer QUIC, assurez-vous que les comportements décrits ci-dessus sont acceptables pour vos charges de travail.

Certificats SSL

Vous devez référencer 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 un système GFE (Google Front End) et le client. Il peut s'agir de certificats SSL autogérés ou gérés par Google.

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, vous pouvez également chiffrer le trafic des GFE vers vos backends. 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.

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. Vous pouvez utiliser des règles SSL pour modifier ce comportement par défaut et contrôler la manière dont votre équilibreur de charge négocie SSL avec les clients.

Lorsque l'équilibreur de charge utilise HTTPS en tant que protocole de service de backend, il peut négocier les protocoles TLS 1.0, 1.1 ou 1.2 vers le backend.

Délais d'expiration et nouvelles tentatives

L'équilibrage de charge HTTP(S) 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 charges 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 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;

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

Traitement des requêtes et réponses illégales

Il existe différentes raisons pour lesquelles l'équilibreur de charge HTTP(S) externe peut être amené à empêcher des requêtes client ou des réponses du backend d'atteindre, respectivement, le backend ou le client. Certaines raisons sont strictement liées à la conformité avec le protocole HTTP/1.1. D'autres visent à éviter de transmettre des données inattendues en provenance ou à destination des backends. Aucune vérification ne peut être désactivée.

L'équilibreur de charge bloque les requêtes dans les cas de figure suivants pour assurer la conformité avec le protocole HTTP/1.1 :

  • Il ne peut pas analyser la première ligne de la requête.
  • Le délimiteur : manque dans un en-tête.
  • Les en-têtes ou la première ligne contiennent des caractères non valides.
  • La longueur du contenu n'est pas un nombre valide, ou il existe plusieurs en-têtes de longueur de contenu.
  • Il existe plusieurs clés de codage de transfert ou des valeurs de codage de transfert non reconnues.
  • La requête présente un corps non découpé en blocs et aucune longueur de contenu n'est spécifiée.
  • Les blocs de corps ne peuvent pas être analysés. C'est le seul cas de figure où certaines données parviennent au backend. L'équilibreur de charge ferme les connexions au client et au backend lorsqu'il reçoit un bloc impossible à analyser.

L'équilibreur de charge bloque la requête si l'une des conditions suivantes est remplie :

L'équilibreur de charge bloque la réponse du backend si l'une des conditions suivantes est remplie :

  • La taille totale des en-têtes de réponse dépasse la taille d'en-tête de réponse maximale autorisée pour l'équilibrage de charge HTTP(S) externe.
  • La version de HTTP est inconnue.

Spécifications et limites

  • L'équilibrage de charge HTTP(S) accepte la réponse HTTP/1.1 100 Continue.

Limites liées à HTTP/2

  • Le protocole HTTP/2 entre l'équilibreur de charge et l'instance peut nécessiter beaucoup plus de connexions TCP à l'instance que HTTP(S). Le regroupement de connexions, une optimisation qui réduit le nombre de ces connexions avec HTTP(S), n'est pas disponible actuellement avec HTTP/2.
  • Le protocole HTTP/2 entre l'équilibreur de charge et le backend n'est pas compatible avec :
    • La fonctionnalité Server Push
    • WebSockets

Restriction d'utilisation de Cloud CDN

  • Vous ne pouvez pas activer Identity-Aware Proxy ou Cloud CDN sur le même service de backend. Si vous tentez de le faire, le processus de configuration échoue.

Étapes suivantes