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 | Umfang |
|---|---|---|---|
| Externer Application Load Balancer | Unterstützt HTTP(S)-Traffic und erweiterte Features wie URL-Zuordnung und SSL-Offloading Verwenden Sie einen externen Proxy-Network Load Balancer 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 |
| Externer Passthrough-Network Load Balancer | 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 Cloud Service Mesh 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 eines externen Network Load Balancers.
- 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
- Externer Passthrough-Network Load Balancer
- Externer Application Load Balancer oder externer Proxy-Network Load Balancer
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.
Externer Passthrough-Network Load Balancer
Auch bei Verwendung eines Network 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 externen Passthrough-Network Load Balancer. Anschließend wird er ohne Änderungen an die Ziel-VM im Backend weitergeleitet. Der externe Passthrough-Network 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 externen Passthrough-Network 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
Bei externen Application Load Balancern stellen die GFEs den Traffic sicher. Diese GFEs befinden sich am Rand des globalen Google-Netzwerks. Das GFE beendet die TCP-Sitzung und stellt eine Verbindung zu einem Backend 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 |
|---|---|---|
| Ping des externen Application Load Balancers |
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 Ergebnisse für den externen Application Load Balancer unterscheiden sich erheblich. Beim Anpingen des externen Application Load Balancers liegt die Umlauflatenzzeit nur etwas über 1 ms. Dieses Ergebnis stellt die Latenz zum nächstgelegenen GFE dar, der sich in derselben Stadt wie der Nutzer befindet. 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 Backend-VMs. Deshalb muss nur für die erste Anfrage eines bestimmten GFE bei einem bestimmten Backend ein dreifacher Handshake erfolgen.
Jeder Standort hat mehrere GFEs. Das Latenzdiagramm zeigt mehrere schwankende Lastspitzen, wenn der Traffic das erste GFE-Backend-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 |
| Externer Passthrough-Network Load Balancer | 110 ms zum externen Passthrough-Network Load Balancer in der Region | 230 ms |
| Externer Application Load Balancer | 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 Backend 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 externen Application Load Balancers
Die weiteren zu beobachtenden Auswirkungen mit dem externen Application Load Balancer hängen von Trafficmustern ab.
Der externe Application Load Balancer hat für komplexe Assets eine geringere Latenz als der externe Passthrough-Network Load Balancer, da weniger Umläufe bis zur abschließenden Antwort erforderlich sind. Wenn beispielsweise ein Nutzer in Deutschland die Latenz für dieselbe Verbindung durch wiederholtes Herunterladen einer 10 MB-Datei misst, beträgt die durchschnittliche Latenz für das Network Load Balancers 1911 ms. Beim Application Load Balancer beträgt die durchschnittliche Latenz 1341 ms, also pro Anfrage rund fünf Umläufe weniger. Nichtflüchtige Verbindungen zwischen GFEs und Bereitstellungs-Back-Ends verringern die Auswirkungen von TCP Slow Start.
Der externe Application Load Balancer reduziert die zusätzliche Latenz für einen TLS-Handshake erheblich (in der Regel ein bis zwei zusätzliche Umläufe). Dies liegt daran, dass der externe Application Load Balancer SSL-Offloading verwendet und nur die Latenz bis zum Edge-PoP relevant ist. Für den Nutzer in Deutschland ergibt sich eine minimale Latenz von 201 ms mit dem externen Application Load Balancer, verglichen mit 525 ms über HTTP(S) und den externen Passthrough-Network Load Balancer.
Der externe Application Load Balancer ermöglicht ein automatisches Upgrade der Nutzersitzung auf HTTP/2. HTTP/2 kann die Anzahl der erforderlichen Pakete reduzieren, indem es Verbesserungen im Binärprotokoll, in der Header-Komprimierung und beim Multiplexing von Verbindungen vornimmt. Durch diese Verbesserungen kann die beobachtete Latenz sogar noch stärker reduziert werden als durch den Wechsel zum externen Application Load Balancer. 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.
Externe Application Load Balancer optimieren
Sie können die Latenz für Ihre Anwendung mit dem externen Application 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 externen Application Load Balancers erwähnt werden.
Sie können jeden CDN-Partner mit Google Cloud verwenden. Wenn Sie einen der CDN Interconnect-Partner von Google verwenden, profitieren Sie von reduzierten Kosten für die Datenübertragung.
Im Falle von statischen Inhalten können Sie die Webserver entlasten, indem Sie die Inhalte direkt aus Cloud Storage über den Application 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 der Load-Balancer die Nutzer automatisch in die am nächsten liegende Region weiterleitet. 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 externe Proxy-Network Load Balancer auf GFEs basieren, sind die Auswirkungen auf die Latenz dieselben wie beim externen Application Load Balancer. Da der externe Application Load Balancer mehr Features als der externe Proxy-Network Load Balancer hat, empfehlen wir die Verwendung externer Application Load Balancer für HTTP(S)-Traffic.
Nächste Schritte
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:
- Externer Passthrough-Network Load Balancer
- Externer Application Load Balancer
- Externer Proxy-Network Load Balancer