Optimiser la latence des applications avec l'équilibrage de charge

Ce document traite des options d'équilibrage de charge et montre comment votre choix d'un équilibreur de charge spécifique sur Google Cloud affecte la latence de bout en bout.

Options d'équilibrage de charge

En fonction du type de trafic envoyé à votre application, vous disposez de plusieurs options d'équilibrage de charge externe. Vous trouverez le récapitulatif des options dans le tableau suivant :

Option Description Flux du trafic Champ d'application
Équilibrage de charge HTTP(S) Compatible avec le trafic HTTP(S) et les fonctionnalités avancées, telles que le mappage d'URL et le déchargement SSL, l'
équilibrage de charge proxy TCP ou l'équilibrage de charge proxy SSL pour le trafic non HTTP sur des ports spécifiques.
La session TCP ou SSL (TLS) est arrêtée au niveau des Google Front Ends (GFE) en périphérie du réseau de Google, puis le trafic est transmis par proxy aux backends. Mondial
Équilibrage de charge au niveau du réseau Permet au trafic TCP/UDP passant par n'importe quel port de transiter par l'équilibreur de charge. Diffusé à l'aide de la technologie Maglev de Google pour répartir le trafic entre les backends. Disques

Comme les équilibreurs de charge internes et Traffic Director ne sont pas compatibles avec le trafic utilisateur, ils ne sont pas couverts par cet article.

Les mesures de cet article utilisent le niveau Premium dans les niveaux de service réseau, car l'équilibrage de charge au niveau mondial nécessite ce niveau de service.

Mesurer la latence

Pour l'accès à un site Web hébergé dans la région us-central1, un utilisateur situé en Allemagne utilise les méthodes suivantes pour tester la latence :

  • Ping : bien qu'il s'agisse d'un moyen courant de mesurer l'accessibilité du serveur, le ping ICMP ne mesure pas la latence de l'utilisateur final. Pour en savoir plus, consultez la section Autres effets de latence de l'équilibrage de charge HTTP(S).
  • Curl : mesure le temps de latence du premier octet (TTFB). Exécutez une commande curl plusieurs fois sur le serveur.

Lorsque vous comparez les résultats, sachez que la latence des liens en fibre optique est limitée par la distance et la vitesse de la lumière dans la fibre, soit environ 200 000 km/s (ou 124 724 miles/s).

La distance entre Francfort, en Allemagne, et Council Bluffs, en Iowa (région us-central1), est d'environ 7 500 km. Avec une fibre droite entre les emplacements, la latence aller-retour est la suivante :

7,500 km * 2 / 200,000 km/s * 1000 ms/s = 75 milliseconds (ms)

Le câble à fibre optique ne suit pas un chemin direct entre l'utilisateur et le centre de données. La lumière sur le câble à fibre optique passe à travers les équipements actifs et passifs sur son chemin. Une latence observée d'environ 1,5 fois le chemin idéal, ou 112,5 ms, indique une configuration presque idéale.

Comparer la latence

Cette section compare l'équilibrage de charge dans les configurations suivantes :

  • Aucun équilibrage de charge
  • Équilibrage de charge au niveau du réseau
  • Équilibrage de charge HTTP(S) ou Équilibrage de charge proxy TCP

Dans ce scénario, l'application se compose d'un groupe d'instances géré régional de serveurs Web HTTP. Étant donné que l'application repose sur des appels à faible latence vers une base de données centrale, les serveurs Web doivent être hébergés dans un emplacement unique. L'application est déployée dans la région us-central1 et les utilisateurs sont répartis dans le monde entier. La latence constatée par l'utilisateur situé en Allemagne dans ce scénario illustre potentiellement l'expérience des utilisateurs du monde entier.

Schéma du scénario de latence (cliquez pour agrandir)
Schéma du scénario de latence (cliquez pour agrandir)

Aucun équilibrage de charge

Lorsqu'un utilisateur effectue une requête HTTP, sauf si l'équilibrage de charge est configuré, le trafic s'écoule directement du réseau de l'utilisateur vers la machine virtuelle (VM) hébergée sur Compute Engine. Pour le niveau Premium, le trafic entre ensuite dans le réseau de Google à un point de présence périphérique (POP) proche de l'emplacement de l'utilisateur. Pour le niveau Standard, le trafic utilisateur entre dans le réseau de Google au niveau d'un POP proche de la région de destination. Pour en savoir plus, consultez la documentation sur les niveaux de service réseau.

Architecture sans équilibrage de charge (cliquez pour agrandir)
Architecture sans équilibrage de charge (cliquez pour agrandir)

Le tableau suivant montre les résultats lorsque l'utilisateur en Allemagne a testé la latence d'un système sans équilibrage de charge :

Méthode Résultat Temps de latence minimal
Pinguez l'adresse IP de la VM (la réponse provient directement du serveur Web).

  ping -c 5 compute-engine-vm
  

  PING compute-engine-vm (xxx.xxx.xxx.xxx) 56(84) bytes of data.
  64 bytes from compute-engine-vm (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=56 time=111 ms
  64 bytes from compute-engine-vm (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=56 time=110 ms
  [...]
  --- compute-engine-vm ping statistics ---
  5 packets transmitted, 5 received, 0% packet loss, time 4004ms
  rtt min/avg/max/mdev = 110.818/110.944/111.265/0.451 ms
  
110 ms
TTFB

  for ((i=0; i < 500; i++)); do curl -w  /
  "%{time_starttransfer}\n" -o /dev/null -s compute-engine-vm; done
  

  0.230
  0.230
  0.231
  0.231
  0.230
  [...]
  0.232
  0.231
  0.231
  
230 ms

La latence TTFB est stable, comme le montre le graphique suivant des 500 premières requêtes :

Graphique de la latence vers une VM en ms (cliquez pour agrandir)
Graphique de la latence vers une VM en ms (cliquez pour agrandir)

Lorsque vous pinguez l'adresse IP de la VM, la réponse provient directement du serveur Web. Le temps de réponse du serveur Web est minimal par rapport à la latence réseau (TTFB). Cela est dû au fait qu'une nouvelle connexion TCP est ouverte pour chaque requête HTTP. Un handshake initial à trois voies est nécessaire avant l'envoi de la réponse HTTP, comme illustré par le schéma ci-dessous. Par conséquent, la latence constatée est près du double de celle du ping.

Schéma de la requête HTTP client-serveur (cliquez pour agrandir)
Schéma de la requête HTTP client-serveur (cliquez pour agrandir)

Équilibrage de charge au niveau du réseau

Avec un équilibreur de charge réseau, les requêtes utilisateur entrent toujours dans le réseau Google au niveau du POP périphérique le plus proche (au niveau Premium). Dans la région où se trouvent les VM du projet, le trafic circule d'abord via un équilibreur de charge réseau. Il est ensuite transféré sans modification de la VM backend cible. L'équilibreur de charge réseau distribue le trafic en fonction d'un algorithme de hachage stable. L'algorithme utilise une combinaison de ports source et de destination, d'adresse IP et de protocole. Les VM écoutent l'adresse IP de l'équilibreur de charge et acceptent le trafic non modifié.

Architecture avec équilibrage de charge réseau (cliquez pour agrandir)
Architecture avec équilibrage de charge réseau (cliquez pour agrandir)

Le tableau suivant présente les résultats lorsque l'utilisateur en Allemagne a testé la latence pour l'option d'équilibrage de charge réseau.

Méthode Résultat Temps de latence minimal
Pinguer l'équilibreur de charge réseau

  ping -c 5 net-lb
  

  PING net-lb (xxx.xxx.xxx.xxx) 56(84) bytes of data.
  64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=44 time=110 ms
  64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=44 time=110 ms
  [...]
  64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=5 ttl=44 time=110 ms
  --- net-lb ping statistics ---
  5 packets transmitted, 5 received, 0% packet loss, time 4007ms
  rtt min/avg/max/mdev = 110.658/110.705/110.756/0.299 ms
  
110 ms
TTFB

 for ((i=0; i < 500; i++)); do curl -w /
    "%{time_starttransfer}\n" -o /dev/null -s net-lb
 

 0.231
 0.232
 0.230
 0.230
 0.232
 [...]
 0.232
 0.231
 
230 ms

Étant donné que l'équilibrage de charge a lieu dans la région et que le trafic est simplement transféré, il n'y a pas d'impact de latence important par rapport à l'option sans équilibreur de charge.

Équilibrage de charge externe

Avec l'équilibrage de charge HTTP(S), les GFE jouent le rôle de proxy pour le trafic. Ces GFE se trouvent à la périphérie du réseau mondial de Google. Les GFE interrompent la session TCP et se connectent à un backend dans la région la plus proche pouvant diffuser le trafic.

Schéma du scénario de l'équilibrage de charge HTTP(S) simple (cliquez pour agrandir)
Schéma du scénario de l'équilibrage de charge HTTP(S) simple (cliquez pour agrandir)

Le tableau suivant présente les résultats lorsque l'utilisateur en Allemagne a testé la latence pour l'option d'équilibrage de charge HTTP.

Méthode Résultat Temps de latence minimal
Pinguer l'équilibrage de charge HTTP(S)

 ping -c 5 http-lb
 

 PING http-lb (xxx.xxx.xxx.xxx) 56(84) bytes of data.
 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=56 time=1.22 ms
 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=56 time=1.20 ms
 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=3 ttl=56 time=1.16 ms
 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=4 ttl=56 time=1.17 ms
 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=5 ttl=56 time=1.20 ms
 --- http-lb ping statistics ---
 5 packets transmitted, 5 received, 0% packet loss, time 4005ms
 rtt min/avg/max/mdev = 1.163/1.195/1.229/0.039 ms
 
1 ms
TTFB

 for ((i=0; i < 500; i++)); do curl -w /
    "%{time_starttransfer}\n" -o /dev/null -s http-lb; done
 

 0.309
 0.230
 0.229
 0.233
 0.230
 [...]
 0.123
 0.124
 0.126
 
123 ms

Les résultats de l'équilibrage de charge HTTP(S) sont très différents. Lorsque vous pinguez l'équilibrage de charge HTTP(S), la latence aller-retour est légèrement supérieure à 1 ms. Ce résultat représente la latence vers le GFE le plus proche, qui se trouve dans la même ville que l'utilisateur Ce résultat ne reflète pas la latence réelle constatée par l'utilisateur lorsqu'il tente d'accéder à l'application hébergée dans la région us-central1. Les tests utilisant des protocoles (ICMP) différents de votre protocole de communication d'application (HTTP) peuvent être trompeurs.

Lors de l'évaluation de la TTFB, les requêtes initiales montrent la même latence de réponse. Certaines requêtes obtiennent une latence minimale inférieure de 123 ms, comme indiqué dans le graphique suivant :

Graphique de la latence vers l'équilibreur de charge HTTP(S) en ms (cliquez pour agrandir)
Graphique de la latence vers l'équilibreur de charge HTTP(S) en ms (cliquez pour agrandir)

Deux trajets aller-retour entre le client et la VM prennent plus de 123 ms, même avec une fibre droite. La latence est plus faible, car les GFE jouent le rôle de proxy pour le trafic. Les GFE maintiennent des connexions persistantes aux VM de backend. Par conséquent, seule la première requête d'un GFE spécifique à un backend spécifique nécessite un handshake à trois voies.

Schéma de la requête HTTP initiale via le GFE (cliquez pour agrandir)
Schéma de la requête HTTP initiale via le GFE (cliquez pour agrandir)

Chaque emplacement dispose de plusieurs GFE. Le graphique de latence montre plusieurs pics lorsque le trafic atteint chaque paire GFE-backend pour la première fois. Le GFE doit ensuite établir une nouvelle connexion à ce backend. Ces pics reflètent les différents hachages de requête. Les requêtes ultérieures indiquent une latence plus faible.

Schéma de la requête HTTP suivante via le GFE (cliquez pour agrandir)
Schéma de la requête HTTP suivante via le GFE (cliquez pour agrandir)

Ces scénarios illustrent la latence réduite que les utilisateurs peuvent rencontrer dans un environnement de production. Le tableau suivant récapitule les résultats :

Option Ping TTFB
Aucun équilibrage de charge 110 ms vers le serveur Web 230 ms
Équilibrage de charge au niveau du réseau 110 ms vers l'équilibreur de charge réseau local 230 ms
Équilibrage de charge HTTP(S) 1 ms vers le GFE le plus proche 123 ms

Lorsqu'une application opérationnelle dessert des utilisateurs dans une région spécifique, les GFE de cette région maintiennent une connexion persistante ouverte à tous les backends de diffusion. De ce fait, les utilisateurs de cette région constatent une réduction de la latence sur leur première requête HTTP s'ils sont éloignés du backend de l'application. Si les utilisateurs sont proches du backend de l'application, ils n'observent aucune latence.

Pour les requêtes ultérieures, telles que le clic sur un lien de page, aucune latence n'est constatée, car les navigateurs modernes maintiennent une connexion persistante au service. Cela diffère de la commande curl générée à partir de la ligne de commande.

Autres effets de latence de l'équilibrage de charge HTTP(S)

Les autres effets observables avec l'équilibrage de charge HTTP(S) dépendent des modèles de trafic.

  • L'équilibrage de charge HTTP(S) a moins de latence pour les éléments complexes que l'équilibrage de charge réseau car il nécessite moins d'aller-retours avant d'obtenir une réponse. Par exemple, lorsque l'utilisateur situé en Allemagne mesure sa latence sur la même connexion en téléchargeant régulièrement un fichier de 10 Mo, la latence moyenne de l'équilibrage de charge réseau est de 1 911 ms, contre 1 341 ms pour l'équilibrage de charge HTTP(S). Cela permet d'économiser environ 5 allers-retours par requête. Les connexions persistantes entre les GFE et les backends de diffusion réduisent les effets du démarrage lent TCP.

  • L'équilibrage de charge HTTP(S) réduit considérablement la latence supplémentaire pour un handshake TLS (généralement un ou deux aller-retours supplémentaires). Cette réduction est due au fait que l'équilibrage de charge HTTP(S) utilise le déchargement SSL et que seule la latence vers le POP périphérique est pertinente. Pour l'utilisateur en Allemagne, la latence minimale constatée est de 201 ms avec l'équilibrage de charge HTTP(S) et de 525 ms avec HTTP(S) via l'équilibreur de charge réseau.

  • L'équilibrage de charge HTTP(S) permet une mise à niveau automatique de la session utilisateur vers HTTP/2, ce qui peut réduire le nombre de paquets nécessaires, en améliorant le protocole binaire, la compression des en-têtes et le multiplexage de connexion. Cela peut encore réduire la latence observée par rapport au simple basculement vers l'équilibrage de charge HTTP(S). Le protocole HTTP/2 est compatible avec les navigateurs actuels utilisant SSL/TLS. Pour l'utilisateur en Allemagne, la latence minimale est passée de 201 ms à 145 ms lors de l'utilisation de HTTP/2 au lieu de HTTPS.

Optimiser l'équilibrage de charge HTTP(S)

Vous pouvez optimiser la latence de votre application à l'aide de l'équilibreur de charge HTTP(S) externe comme suit :

  • Si une partie du trafic que vous diffusez peut être mise en cache, vous pouvez l'intégrer à Cloud CDN. Cloud CDN réduit la latence en diffusant des éléments directement à la périphérie du réseau de Google. Cloud CDN utilise également les optimisations TCP et HTTP de HTTP/2 mentionnées dans la section Autres effets de latence de l'équilibrage de charge HTTP(S).

  • Vous pouvez utiliser n'importe quel partenaire CDN avec Google Cloud. En utilisant l'un des partenaires d'interconnexion CDN de Google, vous bénéficiez de coûts de sortie réduits.

  • Si le contenu est statique, vous pouvez réduire la charge sur les serveurs Web en diffusant le contenu directement à partir de Cloud Storage via l'équilibrage de charge HTTP(S). Cette option se combine avec Cloud CDN.

  • Le déploiement de vos serveurs Web dans plusieurs régions proches de vos utilisateurs peut réduire la latence, car l'équilibrage de charge HTTP(S), l'équilibrage de charge proxy SSL et l'équilibrage de charge proxy TCP redirigent automatiquement les utilisateurs vers la région la plus proche. Toutefois, si votre application est partiellement centralisée, concevez-la de manière à réduire le nombre d'aller-retours interrégionaux.

  • Pour réduire la latence au sein de vos applications, examinez tous les appels de procédure à distance (RPC) qui communiquent entre les VM. Cette latence se produit généralement lorsque les applications communiquent entre les niveaux ou les services. Des outils tels que Cloud Trace peuvent vous aider à réduire la latence provoquée par des requêtes de diffusion d'applications.

  • Étant donné que l'équilibrage de charge proxy TCP et l'équilibrage de charge proxy SSL sont basés sur des GFE, l'effet sur la latence est le même que celui observé avec l'équilibrage de charge HTTP(S). Comme l'équilibrage de charge HTTP(S) offre plus de fonctionnalités que l'équilibrage de charge proxy TCP et l'équilibrage de charge proxy SSL, nous vous recommandons d'utiliser l'équilibrage de charge HTTP(S) pour le trafic HTTP(S).

Étapes suivantes

Nous vous recommandons de déployer votre application auprès de la majorité de vos utilisateurs. Pour en savoir plus sur les différentes options d'équilibrage de charge dans Google Cloud, consultez les documents suivants :