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 |
|---|---|---|---|
| Équilibreur de charge d'application externe | Compatible avec le trafic HTTP(S) et les fonctionnalités avancées, telles que le mappage d'URL et le déchargement SSL Utilisez un équilibreur de charge réseau proxy externe 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. | Monde |
| Équilibreur de charge réseau externe à stratégie directe | 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. | Régional |
Comme les équilibreurs de charge internes et Cloud Service Mesh 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'équilibreur de charge d'application externe.
- Curl : mesure le temps de latence du premier octet (TTFB). Exécutez une commande
curlplusieurs 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
- Équilibreur de charge réseau externe à stratégie directe
- Équilibreur de charge d'application externe ou équilibreur de charge réseau proxy externe
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.
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.
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 :
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.
Équilibreur de charge réseau passthrough externe
Avec les équilibreurs de charge réseau à stratégie directe, 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 externe à stratégie directe. Il est ensuite transféré sans modification de la VM backend cible. L'équilibreur de charge réseau externe à stratégie directe 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é.
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 |
|---|---|---|
| Pinguez l'équilibreur de charge réseau externe à stratégie directe |
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.
External load balancing
Avec les équilibreurs de charge d'application externes, 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.
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 |
|---|---|---|
| Pinguez l'équilibreur de charge d'application externe |
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 pour l'équilibreur de charge d'application externe sont très différents. Lorsque vous pinguez l'équilibreur de charge d'application externe, 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 :
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.
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.
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 |
| Équilibreur de charge réseau externe à stratégie directe | 110 ms vers l'équilibreur de charge réseau externe régional à stratégie directe | 230 ms |
| Équilibreur de charge d'application externe | 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.
Effets de latence supplémentaires de l'équilibreur de charge d'application externe
Les autres effets observables avec l'équilibreur de charge d'application externe dépendent des modèles de trafic.
L'équilibreur de charge d'application externe présente moins de latence pour les éléments complexes que l'équilibreur de charge réseau à stratégie directe, 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'équilibreur de charge réseau à stratégie directe est de 1 911 ms. Avec l'équilibreur de charge d'application, la latence moyenne est de 1 341 ms. 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'équilibreur de charge d'application externe réduit considérablement la latence supplémentaire pour un handshake TLS (généralement un ou deux allers-retours supplémentaires). En effet, l'équilibreur de charge d'application externe utilise le déchargement SSL, et 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'équilibreur de charge d'application externe et de 525 ms avec HTTP(S) via l'équilibreur de charge réseau externe à stratégie directe.
L'équilibreur de charge d'application externe permet la mise à niveau automatique de la session utilisateur vers HTTP/2. Le protocole HTTP/2 permet de 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. Ces améliorations peuvent réduire encore plus la latence observée par rapport au simple basculement vers l'équilibreur de charge d'application externe. 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 les équilibreurs de charge d'application externes
Vous pouvez optimiser la latence de votre application à l'aide de l'équilibreur de charge d'application 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'équilibreur de charge d'application externe.
Vous pouvez utiliser n'importe quel partenaire CDN avec Google Cloud. En utilisant l'un des partenaires CDN Interconnect de Google, vous bénéficiez de coûts de transfert de données 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'équilibreur de charge d'application externe. 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'équilibreur de charge redirige 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 les équilibreurs de charge réseau externes sont basés sur des GFE, l'effet sur la latence est identique à celui observé avec l'équilibreur de charge d'application externe. Comme l'équilibreur de charge d'application externe dispose de plus de fonctionnalités que l'équilibreur de charge réseau proxy externe, nous vous recommandons l'utilisation d'équilibreurs de charge d'application externes pour le trafic HTTP(S).
Étapes suivantes
Nous vous recommandons de déployer votre application auprès de la plupart de vos utilisateurs. Pour en savoir plus sur les différentes options d'équilibrage de charge dans Google Cloud, consultez les documents suivants :
- Équilibreur de charge réseau externe à stratégie directe
- Équilibreur de charge d'application externe
- Équilibreur de charge réseau proxy externe