HTTP(S)-Load-Balancing – Best Practices für die Leistung

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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-Front-End 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:

Caching mit Cloud CDN aktivieren

Aktivieren Sie Cloud CDN und Caching als Teil Ihrer standardmäßigen globalen HTTP(S)-Load-Balancer-Konfiguration. 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 Back-End konfiguriert wird. Weitere Informationen finden Sie unter Cloud CDN-Fehlerbehebung.

Auswahl des Weiterleitungsregelprotokolls

  • Für den globalen externen HTTP(S)-Load-Balancer und den globalen externen HTTP(S)-Load-Balancer (klassisch) empfehlen wir HTTP/3, ein Internetprotokoll, das auf IETF QUIC aufbaut. 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 muss HTTP/3 in Ihrem globalen externen HTTP(S)-Load-Balancing zuvor nicht deaktiviert 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 HTTP(S)-Load-Balancer werden HTTP/1.1, HTTPS und HTTP/2 unterstützt. Sowohl HTTPS als auch HTTP/2 erfordern einen gewissen Overhead, um TLS einzurichten.

Auswahl des Back-End-Dienstprotokolls

Die Wahl des Back-End-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 Back-End-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 Back-End-Latenzen führen, da Back-End-Verbindungen häufiger hergestellt werden.

Das Back-End-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 Back-End-Typen empfiehlt Google Cloud, sichere Protokolloptionen wie HTTPS und HTTP/2 zu verwenden, um die Kommunikation mit dem Back-End-Dienst zu verschlüsseln. Informationen finden Sie unter Verschlüsselung vom Load-Balancer zu Back-Ends.

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 Back-End 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 Back-End-Dienst für jede neue Verbindung auswählen, je nachdem, welches Back-End am reaktionsschnellsten ist. Dies ist mithilfe des Balancing-Modus RATE möglich. In diesem Fall wird der Back-End-Dienst mit der geringsten durchschnittlichen Latenz gegenüber den letzten Anfragen oder bei HTTP/2 und HTTP/3 der Back-End-Dienst 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 Back-End 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 Back-End-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 Back-End Anfragen von derselben Ressource verarbeitet, z. B. mit demselben Nutzerkonto oder aus demselben Dokument.

Die Sitzungsaffinität wird für die gesamte Back-End-Dienstressource und nicht pro Back-End angegeben. Eine URL-Zuordnung kann jedoch auf mehrere Back-End-Dienste verweisen. Daher müssen Sie nicht nur einen Sitzungsaffinitätstyp für den Load-Balancer verwenden. Je nach Anwendung können Sie verschiedene Back-End-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 Back-End-Dienst verwenden, um stattdessen im Cache gespeicherte Antworten bereitzustellen.

Weitere Informationen finden Sie unter Sitzungsaffinität.