Optionen für das Load-Balancing
Abhängig von der Art des Traffics, der an Ihre Anwendung gesendet wird, haben Sie mehrere Optionen für das externe Load-Balancing. In der folgenden Tabelle sind diese Optionen zusammengefasst:
| Option | Beschreibung | Datenverkehr | Geltungsbereich |
|---|---|---|---|
| HTTP(S)-Load-Balancing | Unterstützt HTTP(S)-Traffic und erweiterte Features wie URL-Zuordnung und SSL-Offloading TCP-Proxy-Load-Balancing oder SSL-Proxy-Load-Balancing für Nicht-HTTP-Traffic an bestimmten Ports. |
Die TCP- oder SSL-Sitzung (TLS-Sitzung) wird von Google Front Ends (GFEs) an den Edge-Punkten des Google-Netzwerks beendet und der Traffic wird an die Back-Ends weitergeleitet. | Global |
| Netzwerk-Load-Balancing | Lässt TCP/UDP-Traffic mit einem beliebigen Port über den Load-Balancer zu. | Der Traffic wird mithilfe der Maglev-Technologie von Google an die Back-Ends verteilt. | Regional |
Da die internen Load-Balancer und Traffic Director nutzerorientierten Traffic nicht unterstützen, werden sie in diesem Artikel nicht behandelt.
Für die Messungen in diesem Artikel wird die Premium-Stufe in Netzwerkdienststufen verwendet, da das globale Load-Balancing diese Dienststufe erfordert.
Latenz messen
Beim Zugriff auf eine Website, die in us-central1 gehostet wird, verwenden Nutzer in Deutschland die folgenden Methoden zum Testen der Latenz:
- Ping: Diese Methode eignet sich zwar zum Messen der Servererreichbarkeit, jedoch lässt ein ICMP-Ping keine wertvollen Rückschlüsse auf die Endnutzerlatenz zu. Weitere Informationen finden Sie unter Zusätzliche Latenzeffekte des HTTP(S)-Load-Balancing.
- Curl: Curl misst die Zeit bis zum ersten Byte (TTFB). Führen Sie wiederholt einen
curl-Befehl an den Server aus.
Beachten Sie beim Vergleichen der Ergebnisse, dass die Latenz für Glasfaserverbindungen durch die Entfernung und die Lichtgeschwindigkeit bei Glasfaser beschränkt ist; sie liegt bei ca. 200.000 km/s pro Sekunde.
Die Entfernung zwischen Frankfurt und Council Bluffs im US-Bundesstaat Iowa (Region us-central1) beträgt ca. 7.500 km. Die Umlauflatenz zwischen den Standorten sieht so aus:
7,500 km * 2 / 200,000 km/s * 1000 ms/s = 75 milliseconds (ms)
Das Glasfaserkabel folgt keinem direkten Pfad zwischen dem Nutzer und dem Rechenzentrum. Das Licht im Glasfaserkabel verläuft durch aktive und passive Vorrichtungen entlang des Pfads. Eine beobachtete Latenz von etwa dem 1,5-Fachen des Idealwerts, bzw. 112,5 ms würde eine nahezu ideale Konfiguration darstellen.
Latenz vergleichen
In diesem Abschnitt wird das Load-Balancing in den folgenden Konfigurationen verglichen:
- Ohne Load-Balancing
- Netzwerk-Load-Balancing
- HTTP(S)-Load-Balancing oder TCP-Proxy-Load-Balancing
In diesem Szenario besteht die Anwendung aus einer regional verwalteten Instanzgruppe von HTTP-Webservern. Da die Anwendung für Aufrufe bei einer zentralen Datenbank auf geringe Latenz angewiesen ist, müssen die Webserver an einem zentralen Ort gehostet werden. Die Anwendung wird in der Region us-central1 bereitgestellt und Nutzer sind auf der ganzen Welt verteilt. Die Latenz, die der Nutzer in Deutschland in diesem Szenario beobachtet, veranschaulicht, womit Nutzer in aller Welt rechnen können.
Ohne Load-Balancing
Wenn ein Nutzer eine HTTP-Anfrage sendet, wird der Traffic direkt aus dem Netzwerk des Nutzers zu der in Compute Engine gehosteten virtuellen Maschine (VM) geleitet, es sei denn, das Load-Balancing ist konfiguriert. Bei der Premium-Stufe erreicht der Traffic dann an einem Edge-Point of Presence (PoP) in der Nähe des Nutzerstandorts das Google-Netzwerk. Bei der Standard-Stufe erreicht der Nutzertraffic das Google-Netzwerk an einem PoP in der Nähe der Zielregion. Weitere Informationen finden Sie in der Dokumentation zu Netzwerkdienststufen.
Die folgende Tabelle zeigt die Ergebnisse eines Latenztests durch den Nutzer in Deutschland für ein System ohne Load-Balancing:
| Methode | Ergebnis | Minimale Latenz |
|---|---|---|
| Ping der VM-IP-Adresse (Antwort direkt vom Webserver) |
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 |
Die TTFB-Latenz ist stabil, wie das folgende Diagramm für die ersten 500 Anfragen zeigt:
Beim Pingen der VM-IP-Adresse kommt die Antwort direkt vom Webserver. Die Antwortzeit des Webservers ist minimal im Vergleich zur Netzwerklatenz (TTFB). Das liegt daran, dass für jede HTTP-Anfrage eine neue TCP-Verbindung geöffnet wird. Ein erster dreifacher Handshake ist erforderlich, bevor die HTTP-Antwort gesendet wird, wie im folgenden Diagramm dargestellt. Die Latenz liegt also nahe an der Verdoppelung der Ping-Latenz.
Netzwerk-Load-Balancing
Auch bei Verwendung eines Netzwerk-Load-Balancers gelangen die Nutzeranfragen am nächstgelegenen Edge-POP in das Netzwerk von Google (in der Premium-Stufe). In der Region, in der sich die VMs des Projekts befinden, fließt der Traffic zuerst über einen Netzwerk-Load-Balancer. Anschließend wird er ohne Änderungen an die Ziel-VM im Back-End weitergeleitet. Der Netzwerk-Load-Balancer verteilt den Traffic anhand eines stabilen Hash-Algorithmus. Der Algorithmus verwendet eine Kombination aus Quell- und Zielport, IP-Adresse und Protokoll. Die VMs überwachen die IP des Load-Balancers und akzeptieren den Traffic ohne Änderung.
In der folgenden Tabelle sind die Ergebnisse für einen Nutzer in Deutschland dargestellt, der die Latenz in Verbindung mit dem Netzwerk-Load-Balancing getestet hat:
| Methode | Ergebnis | Minimale Latenz |
|---|---|---|
| Ping des Netzwerk-Load-Balancers |
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 |
Da das Load-Balancing innerhalb einer Region erfolgt und nur der Traffic weitergeleitet wird, hat dies im Vergleich zu einem Load-Balancer keine bedeutenden Auswirkungen auf die Latenz.
Externes Load-Balancing
Mit HTTP(S)-Load-Balancing wird GFEs Proxy-Traffic ausgeführt. Diese GFEs befinden sich am Rand des globalen Google-Netzwerks. Das GFE beendet die TCP-Sitzung und stellt eine Verbindung zu einem Back-End in der nächstgelegenen Region her, die den Traffic verarbeiten kann.
In der folgenden Tabelle sind die Ergebnisse für einen Latenztest dargestellt, den ein Nutzer in Deutschland für die HTTP-Load-Balancing-Option durchführt:
| Methode | Ergebnis | Minimale Latenz |
|---|---|---|
| HTTP(S)-Load-Balancing anpingen |
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 |
Die mit dem HTTP(S)-Load-Balancing erzielten Ergebnisse fallen deutlich anders aus. Beim Anpingen des HTTP(S)-Load-Balancers liegt die Umlauflatenzzeit nur etwas über 1 ms. Dieses Ergebnis entspricht der Latenz zum nächstgelegenen GFE, der sich am selben Ort befindet wie der Nutzer. Dieses Ergebnis entspricht nicht der tatsächlichen Latenz, die eintritt, wenn der Nutzer auf die Anwendung zugreift, die in der Region us-central1 gehostet wird. Experimente mit anderen Protokollen (ICMP) als mit dem von der Anwendung verwendeten Kommunikationsprotokoll (HTTP) können zu irreführenden Ergebnissen führen.
Bei der Messung der TTFB zeigen die ersten Anfragen eine ähnliche Antwortlatenz. Einige Anfragen erreichen die niedrigste Mindestlatenz von 123 ms, wie in der folgenden Grafik dargestellt:
Zwei Umläufe zwischen Client und VM dauern länger als 123 ms, auch bei einer geraden Glasfaserleitung. Die Latenz ist geringer, weil GFEs den Traffic über einen Proxy weiterleiten. GFEs unterhalten nichtflüchtige Verbindungen zu den Back-End-VMs. Deshalb muss nur für die erste Anfrage eines bestimmten GFE bei einem bestimmten Back-End ein dreifacher Handshake erfolgen.
Jeder Standort hat mehrere GFEs. Das Latenzdiagramm zeigt mehrere schwankende Lastspitzen, wenn der Traffic das erste GFE-Back-End-Paar erreicht. Das GFE muss dann eine neue Verbindung zu diesem Back-End herstellen. Diese Spitzen entsprechen auf unterschiedlichen Anfrage-Hash-Werten. Nachfolgende Anfragen haben eine niedrigere Latenz.
Diese Szenarien zeigen die verringerte Latenz, mit der Nutzer in einer Produktionsumgebung rechnen können. Die Ergebnisse sind in der folgenden Tabelle zusammengefasst:
| Option | Ping | TTFB |
|---|---|---|
| Ohne Load-Balancing | 110 ms zum Webserver | 230 ms |
| Netzwerk-Load-Balancing | 110 ms zum Netzwerk-Load-Balancer in der Region | 230 ms |
| HTTP(S)-Load-Balancing | 1 ms zum nächsten GFE | 123 ms |
Wenn eine fehlerfreie Anwendung Nutzer in einer bestimmten Region bereitstellt, behalten GFEs in dieser Region eine nichtflüchtige Verbindung zu allen bereitstellenden Back-Ends offen. Daher bemerken Nutzer in dieser Region, die sich in größerer Entfernung zum Back-End der Anwendung befinden, bei der ersten HTTP-Anfrage eine deutlich verminderte Latenz. Nutzer, die sich in der Nähe des Anwendungs-Back-Ends befinden, können keine Latenzverbesserung feststellen.
Für nachfolgende Anfragen, wie z. B. das Anklicken eines Seitenlinks, erhöht sich die Latenz nicht, da moderne Browser eine dauerhafte Verbindung zum Dienst herstellen. Dies unterscheidet sich von einem curl-Befehl, der über die Befehlszeile ausgegeben wird.
Zusätzliche Latenzeffekte des HTTP(S)-Load-Balancing
Die weiteren zu beobachtenden Auswirkungen mit dem HTTP(S)-Load-Balancing hängen von Trafficmustern ab.
Bei komplexen Inhalten erreicht das HTTP(S)-Load-Balancing im Vergleich zum Netzwerk-Load-Balancing eine geringere Latenz, weil weniger Umläufe bis zur abschließenden Antwort erforderlich sind. Wenn beispielsweise ein Nutzer in Deutschland die Latenz über dieselbe Verbindung durch wiederholtes Herunterladen einer 10 MB-Datei misst, beträgt die durchschnittliche Latenz für das Netzwerk-Load-Balancing 1911 ms im Vergleich zu 1.341 ms mit HTTP(S) Load-Balancing. Dies entspricht ungefähr 5 Roundtrips pro Anfrage. Nichtflüchtige Verbindungen zwischen GFEs und Bereitstellungs-Back-Ends verringern die Auswirkungen von TCP Slow Start.
Durch HTTP(S)-Load-Balancing wird die zusätzliche Latenz für einen TLS-Handshake (in der Regel ein bis zwei zusätzliche Umläufe) erheblich reduziert, da das HTTP(S)-Load-Balancing SSL-Offloading verwendet und nur die Latenz bis zum Edge-PoP relevant ist. Für Nutzer in Deutschland beträgt die minimale Latenz 201 ms mit HTTP(S)-Load-Balancing im Vergleich zu 525 ms mit HTTP(S) über das Netzwerk-Load-Balancing.
Das HTTP(S)-Load-Balancing ermöglicht ein automatisches Upgrade der Nutzersitzung auf HTTP/2, die die benötigte Anzahl von Paketen reduzieren kann. Hierfür werden Verbesserungen des binären Protokolls, der Header-Komprimierung und dem Multiplexing von Verbindungen vorgenommen. Durch die Umstellung auf HTTP(S)-Load-Balancing kann die beobachtete Latenz sogar noch höher als die beobachtete Latenz sein. HTTP/2 wird von aktuellen Browsern unterstützt, die SSL/TLS verwenden. Für Nutzer in Deutschland bedeutet die Verwendung von HTTP(2) anstelle von HTTPS eine erneute Verringerung der minimalen Latenz von 201 ms auf 145 ms.
HTTP(S)-Load-Balancing optimieren
Sie können die Latenz für Ihre Anwendung mit dem externen HTTP(S)-Load-Balancer so optimieren:
Wenn ein Teil des bereitgestellten Traffics cachefähig ist, können Sie Cloud CDN einbinden. Cloud CDN verringert die Latenz, da Inhalte direkt am Netzwerkrand von Google bereitgestellt werden. Cloud CDN nutzt auch die TCP- und HTTP-Optimierungen durch HTTP/2, die im Abschnitt Zusätzliche Latenzeffekte des HTTP(S)-Load-Balancing beschrieben werden.
Sie können jeden CDN-Partner mit Google Cloud verwenden. Durch die Nutzung eines der CDN Interconnect-Partner von Google profitieren Sie von reduzierten Kosten für ausgehenden Traffic.
Im Falle von statischen Inhalten können Sie die Webserver entlasten, indem Sie die Inhalte direkt aus Google Cloud Storage über den HTTP(S)-Load-Balancer bereitstellen. Diese Option ist mit Cloud CDN kombinierbar.
Stellen Sie Webserver in mehreren Regionen in der Nähe Ihrer Nutzer bereit. Dadurch wird die Latenz verringert, weil das HTTP(S)-, SSL-Proxy- und der TCP-Proxy-Load-Balancing Nutzer automatisch in die am nächsten liegende Region weiterleiten. Wenn Ihre Anwendung jedoch in Teilen zentralisiert ist, sollten Sie sie so gestalten, dass möglichst wenig Umläufe zwischen den Regionen erforderlich sind.
Untersuchen Sie alle Remote-Prozeduraufruf (RPCs), die zwischen VMs kommunizieren, um die Latenz innerhalb Ihrer Anwendungen zu reduzieren. Diese Art von Latenz tritt in der Regel auf, wenn Anwendungen über mehrere Ebenen oder Dienste kommunizieren. Tools wie Cloud Trace können Ihnen helfen, die durch Anfragen zur Anwendungsbereitstellung verursachte Latenz zu verringern.
Da das TCP-Proxy-Load-Balancing und das SSL-Proxy-Load-Balancing auf GFEs basieren, sind die Auswirkungen auf die Latenz dieselben wie beim HTTP(S)-Load-Balancing. Da HTTP(S)-Load-Balancing mehr Features als TCP-Proxy- und SSL-Proxy-Load-Balancing bietet, empfehlen wir die Verwendung von HTTP(S)-Load-Balancing für HTTP(S)-Traffic.
Tipp
Es wird empfohlen, die Anwendung möglichst nah bei den meisten Nutzern bereitzustellen. Weitere Informationen zu den verschiedenen Load-Balancing-Optionen in Google Cloud finden Sie in den folgenden Dokumenten: