Cloud Load Balancing bietet Verfahren zur Verteilung des Nutzertraffics auf mehrere Instanzen einer Anwendung. Dazu wird die Last auf die Anwendungsinstanzen verteilt und die optimale Anwendungsleistung für die Endnutzer bereitgestellt. Auf dieser Seite werden einige Best Practices beschrieben, damit der Load-Balancer für Ihre Anwendung optimiert ist. Um eine optimale Leistung zu gewährleisten, empfehlen wir das Benchmarking der Traffic-Muster Ihrer Anwendung.
Back-Ends in der Nähe von Clients platzieren
Je näher Ihre Nutzer oder Clientanwendungen an Ihren Arbeitslasten (Load-Balancer-Back-Ends) liegen, desto geringer ist die Netzwerklatenz zwischen ihnen. Erstellen Sie daher die Load-Balancer-Back-Ends in der Region, die der Region am nächsten ist, in der Sie erwarten, dass der Traffic Ihrer Nutzer am Google-Frontend ankommt. In vielen Fällen ist eine Ausführung Ihrer Back-Ends in mehreren Regionen erforderlich, um die Latenz zu Clients in verschiedenen Teilen der Welt zu minimieren.
Weitere Informationen finden Sie unter folgenden Links:
- Traffic-Verteilung für externe Application Load Balancer
- Best Practices für die Auswahl der Region in Compute Engine
Caching mit Cloud CDN aktivieren
Aktivieren Sie Cloud CDN und das Caching im Rahmen Ihrer standardmäßigen Konfiguration des globalen externen Application Load Balancers. Weitere Informationen finden Sie unter Cloud CDN.
Wenn Sie Cloud CDN aktivieren, kann es einige Minuten dauern, bis Antworten im Cache gespeichert werden. Cloud CDN speichert nur Antworten mit cache-fähigen Inhalten. Wenn Antworten für eine URL nicht im Cache gespeichert werden, prüfen Sie, welche Antwortheader für diese URL zurückgegeben werden und wie die Cache-Fähigkeit für Ihr Backend konfiguriert wird. Weitere Informationen finden Sie unter Cloud CDN-Fehlerbehebung.
Auswahl des Weiterleitungsregelprotokolls
Für den globalen externen Application Load Balancer und den klassischen Application Load Balancer empfehlen wir HTTP/3, ein Internetprotokoll, das auf IETF QUIC basiert. HTTP/3 ist standardmäßig in allen großen Browsern, Android Cron und iOS aktiviert. Damit HTTP/3 für Ihre Anwendungen verwendet werden kann, dürfen Sie in Ihrem Netzwerk keinen UDP-Traffic blockieren oder die Rate einschränken. Außerdem darf HTTP/3 nicht für Ihre globalen externen Application Load Balancer deaktiviert worden sein. Clients, die HTTP/3 noch nicht unterstützen, z. B. ältere Browser oder Netzwerkbibliotheken, sind davon nicht betroffen. Weitere Informationen finden Sie unter HTTP/3 QUIC.
Für den regionalen externen Application Load Balancer unterstützen wir HTTP/1.1, HTTPS und HTTP/2. Sowohl HTTPS als auch HTTP/2 erfordern einen gewissen Overhead, um TLS einzurichten.
Auswahl des Backend-Dienstprotokolls
Die Wahl des Backend-Protokolls (HTTP, HTTPS oder HTTP/2) wirkt sich auf die Anwendungslatenz und die für Ihre Anwendung verfügbare Netzwerkbandbreite aus. Wenn Sie beispielsweise HTTP/2 zwischen dem Load-Balancer und der Backend-Instanz verwenden, können wesentlich mehr TCP-Verbindungen zur Instanz erforderlich sein als HTTP(S). Verbindungs-Pooling, eine Optimierung, die die Anzahl dieser Verbindungen bei HTTP(S) reduziert, ist bei HTTP/2 derzeit nicht möglich. Dies kann zu hohen Backend-Latenzen führen, da Backend-Verbindungen häufiger hergestellt werden.
Das Backend-Dienstprotokoll wirkt sich auch auf die Verschlüsselung des Traffics bei der Übertragung aus. Mit externen HTTP(S)-Load-Balancern wird der gesamte Traffic an Back-Ends in Google Cloud-VPC-Netzwerken automatisch verschlüsselt. Dieser Vorgang wird als automatische Verschlüsselung auf Netzwerkebene bezeichnet. Die automatische Verschlüsselung auf Netzwerkebene ist jedoch nur für die Kommunikation mit Instanzgruppen und zonalen NEG-Back-Ends verfügbar. Für alle anderen Backend-Typen empfiehlt Google Cloud, sichere Protokolloptionen wie HTTPS und HTTP/2 zu verwenden, um die Kommunikation mit dem Backend-Dienst zu verschlüsseln. Informationen finden Sie unter Verschlüsselung vom Load-Balancer zu Back-Ends.
Empfohlene Verbindungsdauer
Die Netzwerkbedingungen können sich ändern und die Gruppe der Back-Ends kann sich je nach Last ändern. Bei Anwendungen, die viel Traffic zu einem einzelnen Dienst generieren, ist eine lang andauernde Verbindung nicht immer eine optimale Einrichtung. Anstatt eine einzelne Verbindung zum Backend unbegrenzt zu verwenden, empfehlen wir, eine maximale Verbindungsdauer (z. B. zwischen 10 und 20 Minuten) und/oder eine maximale Anzahl von Anfragen auszuwählen (z. B. zwischen 1.000 und 2.000 Anfragen. Anschließend wird eine neue Verbindung für neue Anfragen verwendet. Die alte Verbindung wird geschlossen, wenn alle aktiven Anfragen verwendet werden, die sie verwenden.
Dadurch kann die Clientanwendung von Änderungen an der Gruppe der Back-Ends profitieren, darunter die Proxys des Load-Balancers und jede Netzwerkoptimierung, die für die Bereitstellung der Clients erforderlich ist.
Auswahlkriterien für den Balancing-Modus
Für eine bessere Leistung sollten Sie den Backend-Gruppe für jede neue Anfrage auswählen, je nachdem, welches Backend am reaktionsschnellsten ist. Dies ist mithilfe des Balancing-Modus RATE möglich. In diesem Fall wird der Backend-Gruppe mit der geringsten durchschnittlichen Latenz gegenüber den letzten Anfragen oder bei HTTP/2 und HTTP/3 der Backend-Gruppe mit den wenigsten ausstehenden Anfragen ausgewählt.
Der Balancing-Modus UTILIZATION gilt nur für Instanzgruppen-Back-Ends und verteilt den Traffic anhand der Auslastung von VM-Instanzen in einer Instanzgruppe.
Sitzungsaffinität konfigurieren
In einigen Fällen kann es sinnvoll sein, dasselbe Backend für Anfragen zu verwenden, die von denselben Endnutzern stammen oder sich auf denselben Endnutzer beziehen, zumindest für einen kurzen Zeitraum. Dies kann mithilfe der Sitzungsaffinität konfiguriert werden, eine Einstellung, die für den Backend-Dienst konfiguriert ist. Die Sitzungsaffinität steuert die Verteilung neuer Verbindungen von Clients zu den Back-Ends des Load-Balancers. Mit der Sitzungsaffinität können Sie dafür sorgen, dass dasselbe Backend Anfragen von derselben Ressource verarbeitet, z. B. mit demselben Nutzerkonto oder aus demselben Dokument.
Die Sitzungsaffinität wird für die gesamte Backend-Dienstressource und nicht pro Backend angegeben. Eine URL-Zuordnung kann jedoch auf mehrere Backend-Dienste verweisen. Daher müssen Sie nicht nur einen Sitzungsaffinitätstyp für den Load-Balancer verwenden. Je nach Anwendung können Sie verschiedene Backend-Dienste mit unterschiedlichen Einstellungen für die Sitzungsaffinität verwenden. Wenn beispielsweise ein Teil Ihrer Anwendung vielen Nutzern statischen Inhalt bereitstellt, ist es unwahrscheinlich, dass Sie von der Sitzungsaffinität profitieren. Stattdessen würden Sie einen mit Cloud CDN aktivierten Backend-Dienst verwenden, um stattdessen im Cache gespeicherte Antworten bereitzustellen.
Weitere Informationen finden Sie unter Sitzungsaffinität.