Load Balancing, Zustandslosigkeit und Sessions

Was ein Load Balancer tut

Ein Load Balancer sitzt zwischen Clients und einem Pool austauschbarer Instanzen und entscheidet für jede Verbindung oder Anfrage, welche Instanz sie erhält. Die Verteilung ist nur ein Teil der Aufgabe. Ein Load Balancer prüft auch, welche Instanzen gesund sind, und schickt den anderen keinen Traffic mehr; er gibt Clients eine stabile Adresse, während Instanzen mit Deployments und Autoscaling kommen und gehen; er terminiert oft TLS, sodass Zertifikate an einer Stelle verwaltet werden; und auf Layer 7 kann er jede Anfrage routen, wiederholen, mit Rate Limits belegen und protokollieren. Er ist daher die Komponente, die horizontale Skalierung für Clients unsichtbar macht.

Load Balancing gibt es auf mehreren Ebenen. Am Edge steht meist ein verwalteter Cloud-Load-Balancer oder ein Paar von Proxys wie HAProxy, NGINX oder Envoy. Zwischen Services wird das Balancing zunehmend clientseitig erledigt: Eine gRPC-Client-Bibliothek oder ein Sidecar-Proxy eines Service Mesh (Abschnitt 6.3) hält die Liste gesunder Instanzen aus der Service Discovery und wählt selbst eine aus, was einen Netzwerk-Hop und eine zentrale Komponente einspart. Unabhängig von der Form kehren dieselben Entscheidungen wieder: was der Balancer sehen kann, welchen Algorithmus er verwendet, wie er entscheidet, ob eine Instanz gesund ist, und wie Instanzen ausscheiden, ohne Arbeit zu verlieren.

Load Balancing auf Layer 4 und Layer 7

Die Layer-Nummern stammen aus dem OSI-Netzwerkmodell. Ein Layer-4-Load-Balancer arbeitet auf der Transportschicht: Er sieht IP-Adressen und TCP- oder UDP-Ports, wählt beim Öffnen einer Verbindung ein Backend und leitet die Pakete dieser Verbindung dann weiter, ohne hineinzusehen. Weil er so wenig tut, ist er extrem schnell und funktioniert mit jedem Protokoll, auch mit Datenbanken, Message Brokern und verschlüsseltem Traffic, den er nicht lesen kann. Googles Maglev und die Network Load Balancer der großen Clouds sind Layer-4-Designs, die Millionen Pakete pro Sekunde verarbeiten.

Ein Layer-7-Load-Balancer ist ein Reverse Proxy, der das Anwendungsprotokoll versteht, fast immer HTTP. Er terminiert die Verbindung des Clients (und meist TLS), liest jede Anfrage und öffnet eigene Verbindungen zu den Backends oder nutzt sie wieder. So kann er nach Pfad, Host, Header oder Cookie routen (/orders/* zum Bestell-Pool, /menus/* zum Speisekarten-Pool), jede Anfrage statt jeder Verbindung verteilen, eine fehlgeschlagene Anfrage auf einer anderen Instanz wiederholen, Rate Limits durchsetzen, Tracing-Header hinzufügen und jede Anfrage mit Status und Latenz protokollieren. Der Preis sind mehr Verarbeitung pro Anfrage, eine Komponente, die die TLS-Schlüssel halten muss, und eine weitere Stelle, an der Timeouts und Wiederholungen konsistent mit dem übrigen System konfiguriert werden müssen (Abschnitt 9.4).

Ein Unterschied erwischt viele Teams kalt. HTTP/2 und gRPC multiplexen viele Anfragen über eine langlebige Verbindung. Ein Layer-4-Balancer wählt ein Backend einmal pro Verbindung, daher schickt ein Client, der eine Verbindung öffnet, alle seine Anfragen an eine Instanz, egal wie viele Instanzen es gibt: Neue Instanzen, die das Autoscaling hinzufügt, erhalten nichts, bis die Clients sich neu verbinden. Das Balancing von gRPC-Traffic braucht daher einen Layer-7-Proxy oder clientseitiges Balancing pro Anfrage.

Load-Balancing-Algorithmen

Der Algorithmus entscheidet, welche gesunde Instanz die nächste Verbindung oder Anfrage erhält. Die einfachen ignorieren, wie ausgelastet Instanzen sind; die besseren nutzen ein Maß für die Last; hashbasierte schicken zusammengehörige Anfragen bewusst an dieselbe Stelle. Die Tabelle fasst die üblichen Optionen zusammen.

Die Power of Two Random Choices

Wenn Least Connections so gut funktioniert, warum nicht immer die global am wenigsten belastete Instanz wählen? Weil es in einem großen System keine einzige, aktuelle Sicht auf die Last gibt. Dutzende Load Balancer oder Tausende clientseitige Balancer sehen jeweils nur ihre eigenen Anfragen oder einen Lastbericht, der einige Sekunden alt ist. Wenn alle die Instanz wählen, die am wenigsten belastet aussah, wählen alle dieselbe, die prompt überlastet wird, und dann ziehen alle zur nächsten weiter: eine Herde, die der Last durch den Pool hinterherjagt.

Michael Mitzenmachers Doktorarbeit (1996), veröffentlicht als The Power of Two Choices in Randomized Load Balancing (IEEE Transactions on Parallel and Distributed Systems, 2001) und aufbauend auf früheren Arbeiten von Azar, Broder, Karlin und Upfal, analysierte eine verblüffend einfache Alternative: zwei Instanzen zufällig wählen und die Anfrage an die weniger belastete der beiden senden. Im klassischen Bälle-in-Körbe-Modell ergibt die zufällige Verteilung von n Anfragen auf n Server einen am stärksten belasteten Server mit etwa log n ÷ log log n Anfragen; mit zwei Zufallsauswahlen sinkt das auf etwa log log n ÷ log 2, eine exponentielle Verbesserung, während eine dritte Auswahl nur noch wenig bringt. Der Zufall verhindert den Herdentrieb, und der Vergleich vermeidet die schlechtesten Instanzen.

Die Power of Two Random Choices ist heute in weit verbreiteten Proxys der Standard oder eine Standardoption: Der Least-Request-Balancer von Envoy vergleicht standardmäßig zwei zufällig gewählte Hosts, und NGINX bietet random two least_conn. Sie ist eine gute Voreinstellung für clientseitiges Balancing in jedem System mit vielen Balancern.

Hashing und Affinität

Manchmal geht es gerade darum, zusammengehörige Anfragen an dieselbe Instanz zu schicken: an einen Cache-Knoten, der die Speisekarte eines Restaurants bereits hält, oder an die Instanz, die eine WebSocket-Session hält. Das Hashen eines Schlüssels (Restaurantkennung, Nutzerkennung, Quell-IP) auf eine Instanz erreicht das. Einfaches hash mod N ordnet die meisten Schlüssel neu zu, sobald sich N ändert, und leert damit jeden Cache im ungünstigsten Moment, während eines Scale-out. Konsistentes Hashing (eingeführt in Abschnitt 7.4) verschiebt nur etwa 1 ÷ N der Schlüssel, wenn eine Instanz hinzukommt oder wegfällt. Seine Schwäche sind Hot Keys: Das beliebteste Restaurant zur Mittagszeit landet auf einer Instanz. Varianten wie Consistent Hashing with Bounded Loads begrenzen den Anteil jeder Instanz und geben den Überschuss an die nächste Instanz auf dem Ring weiter.

Health Checks: Liveness und Readiness

Ein Load Balancer muss wissen, welche Instanzen Traffic annehmen können. Ein aktiver Health Check prüft jede Instanz regelmäßig, zum Beispiel mit GET /healthz alle fünf Sekunden, markiert sie nach einigen aufeinanderfolgenden Fehlschlägen als ausgefallen und nach einigen Erfolgen wieder als verfügbar. Passive Prüfungen, oft Outlier Detection genannt, beobachten den echten Traffic und werfen eine Instanz hinaus, die etwa fünf aufeinanderfolgende Serverfehler liefert. Beide ergänzen sich: Aktive Prüfungen finden Instanzen, die keinen Traffic erhalten, passive Prüfungen reagieren auf Fehler, die eine triviale Prüfung nicht auslöst.

Kubernetes hat eine wichtige Unterscheidung explizit gemacht. Eine Liveness Probe fragt, ob der Prozess unrettbar hängt (Deadlock, Speichermangel in einer Schleife); schlägt sie fehl, wird die Instanz neu gestartet. Eine Readiness Probe fragt, ob die Instanz gerade jetzt Traffic erhalten sollte; schlägt sie fehl, wird die Instanz aus dem Load Balancer genommen, läuft aber weiter, etwa während sie beim Start ihre Caches aufwärmt oder während sie Last abwirft. Eine dritte, die Startup Probe, hält die anderen beiden zurück, während eine langsame Anwendung startet.

Der klassische Fehler besteht darin, in diesen Probes gemeinsame Abhängigkeiten zu prüfen. Ruft die Liveness Probe jeder Instanz die Datenbank auf, lässt ein kurzer Datenbankausfall jede Probe scheitern, der Orchestrator startet alle Instanzen gleichzeitig neu, und der Neustart-Sturm (kalte Caches, Tausende neuer Verbindungen) verlängert den Ausfall noch lange, nachdem die Datenbank wieder da ist. Readiness-Prüfungen, die eine gemeinsame Abhängigkeit einschließen, können ebenso die ganze Flotte als nicht bereit markieren und Teilfehler in einen Totalausfall verwandeln. Halten Sie Liveness lokal und minimal, lassen Sie Readiness die eigene Fähigkeit der Instanz zum Bedienen widerspiegeln, und behandeln Sie Ausfälle von Abhängigkeiten mit den Mustern aus Abschnitt 9.4. Load Balancer schützen sich gegen den Extremfall, indem sie offen ausfallen (Fail Open): Ein AWS Application Load Balancer routet zu allen Zielen, wenn alle ihre Health Checks nicht bestehen, und Envoy ignoriert den Gesundheitsstatus, wenn der Anteil gesunder Hosts unter eine Panikschwelle fällt (standardmäßig 50 %), mit der Begründung, dass Traffic an zweifelhafte Instanzen besser ist als Traffic ins Nichts.

Connection Draining und kontrolliertes Herunterfahren

Instanzen verlassen den Pool ständig: Jedes Deployment ersetzt sie, das Autoscaling entfernt sie, und die Plattform verschiebt sie bei Wartungsarbeiten. Wird eine Instanz einfach beendet, scheitert jede Anfrage, die sie gerade bearbeitet, und Clients sehen Fehler bei einem eigentlich routinemäßigen Release. Connection Draining (bei AWS Deregistration Delay genannt) nimmt die Instanz aus der Rotation des Balancers, sodass sie keine neuen Anfragen erhält, wartet, bis die bereits laufenden Anfragen abgeschlossen sind, und lässt sie erst dann stoppen.

Die Instanz muss mitwirken. Wenn sie ihr Shutdown-Signal erhält, sollte sie ihre Readiness-Prüfung nicht mehr bestehen, laufende Anfragen weiter bedienen, Clients auf Keep-alive-Verbindungen mitteilen, sich anderswohin zu wenden (ein Connection: close-Header bei HTTP/1.1, ein GOAWAY-Frame bei HTTP/2), Hintergrundarbeit abschließen oder zurückgeben und sich vor dem Ende der Grace Period beenden. In Kubernetes geschehen das Entfernen eines Pods aus dem Load Balancer und das Senden von SIGTERM gleichzeitig, daher kann kurz nach dem Signal noch eine Anfrage eintreffen; eine kurze Pre-Stop-Verzögerung von einigen Sekunden deckt diese Race Condition ab. Die Standard-Grace-Period beträgt 30 Sekunden, danach wird der Prozess beendet. Lang laufende Anfragen (große Uploads, Streaming-Antworten, WebSockets) brauchen entweder eine längere Grace Period oder ein Protokoll, über das sich Clients ohne Arbeitsverlust anderswo neu verbinden.

Sticky Sessions und ihre Probleme

Ältere Webanwendungen hielten die Session jedes Nutzers (wer angemeldet ist, was im Warenkorb liegt) im Arbeitsspeicher des Servers, der sie erstellt hatte. Hinter einem Load Balancer funktioniert das nur, wenn alle Anfragen eines Nutzers zu diesem Server zurückgehen; deshalb bieten Balancer Sticky Sessions (Session-Affinität), meist über ein Cookie, das die Instanz benennt. Stickiness ist ein schneller Weg, eine zustandsbehaftete Anwendung hinter einen Balancer zu stellen, und sie hat eine berechtigte Verwendung als Performance-Hinweis, etwa um einen Nutzer auf einer Instanz zu halten, deren lokaler Cache seine Daten bereits enthält.

Als Mechanismus für Korrektheit macht sie Ärger. Die Last wird ungleichmäßig, weil einige intensive Nutzer oder ein großes Büro hinter einer IP-Adresse an einer Instanz festhängen, egal wie belastet sie ist. Fällt eine Instanz aus, verlieren ihre Nutzer ihre Sessions: Warenkörbe verschwinden, und Menschen werden abgemeldet. Herunterskalieren und jedes Deployment bewirken dasselbe, sofern Sessions nicht per Draining beendet werden, was so lange dauern kann wie die längste Session. Neue Instanzen, die das Autoscaling hinzufügt, erhalten nur neue Nutzer und entlasten die überlasteten Instanzen daher nur langsam. Und das System ist nicht mehr zustandslos im Sinne von Abschnitt 9.1, sodass jedes dieser Probleme beim Failover zwischen Zonen oder Regionen wieder auftaucht.

Den Session-Zustand auslagern

Die Abhilfe besteht darin, den Session-Zustand aus der Instanz herauszulösen, damit jede Instanz jede Anfrage bedienen kann. Es gibt drei Hauptoptionen, oft kombiniert. Ein clientseitiges Token trägt den Zustand mit jeder Anfrage: ein signiertes (und bei Bedarf verschlüsseltes) Cookie oder ein Token wie ein JWT mit der Identität des Nutzers und ein paar Daten. Server brauchen überhaupt keinen Speicher, aber Tokens müssen klein bleiben, lassen sich vor ihrem Ablauf nicht leicht widerrufen und müssen gegen Manipulation und Diebstahl geschützt werden (Abschnitt 8.3). Ein gemeinsamer Session-Speicher, typischerweise Redis oder Memcached, hält Sessions in einem schnellen externen Speicher, adressiert über eine Session-Kennung im Cookie; er bewältigt größeren Zustand und sofortiges Abmelden, auf Kosten eines Netzwerkaufrufs pro Anfrage und einer Abhängigkeit, die selbst hochverfügbar sein muss. Eine Datenbank eignet sich für Zustand, der alles überstehen muss, etwa einen Warenkorb, den der Nutzer morgen wiederzufinden erwartet; das sind eigentlich Geschäftsdaten und keine Session-Daten.

Eine praktische Aufteilung für die Essenslieferplattform: die Identität in einem kurzlebigen signierten Token, der Warenkorb in der Datenbank des Bestellservice (Nutzer wechseln vom Smartphone zum Laptop) und flüchtiger UI-Zustand im Client. Keine Instanz behält etwas, das eine spätere Anfrage braucht, daher kann der Load Balancer Least-Request-Balancing ohne Affinität verwenden, und Instanzen lassen sich nach Belieben hinzufügen, entfernen und ersetzen.

Globales Load Balancing: DNS und Anycast

Sobald ein System in mehreren Regionen läuft, muss etwas jeden Nutzer in eine geeignete schicken: die nächstgelegene gesunde Region oder die Region, die seine Daten hält. Globales Load Balancing erfolgt meist auf eine von zwei Arten, oft kombiniert.

DNS-basiertes Global Server Load Balancing nutzt einen autoritativen Nameserver, der denselben Namen mit unterschiedlichen Adressen beantwortet, abhängig davon, woher die Anfrage kommt, vom Gesundheitszustand jeder Region und von konfigurierten Gewichten: Ein Nutzer in Lissabon erhält die Adresse der EU-Region, ein Nutzer in Ohio die der US-Region. Es braucht kein besonderes Netzwerk, ist aber grob und reagiert langsam. Antworten werden von Resolvern mindestens für die Time to Live des Eintrags (oft 30 bis 300 Sekunden) und manchmal länger zwischengespeichert, daher kommen nach dem Ausfall einer Region einige Nutzer noch minutenlang dort an. Der Nameserver sieht den Standort des Resolvers statt den des Nutzers, wobei die Erweiterung EDNS Client Subnet (RFC 7871) es Resolvern erlaubt, einen Teil der Client-Adresse weiterzugeben.

Bei Anycast wird dieselbe IP-Adresse über das Routing-Protokoll des Internets (BGP) von vielen Standorten aus angekündigt, und die Pakete jedes Nutzers werden an den Standort zugestellt, der routingtechnisch am nächsten liegt. Failover bedeutet, die Ankündigung eines ausgefallenen Standorts zurückzuziehen, was schnell wirkt, ohne auf DNS-Caches zu warten. Anycast wird seit Langem für DNS-Root- und Resolver-Dienste genutzt; CDNs und die globalen Load Balancer der großen Cloud-Anbieter nutzen es, um Nutzer zu einem nahen Edge-Standort zu bringen, an dem Layer-7-Proxys die Verbindung terminieren und Anfragen über das Netzwerk des Anbieters an eine gesunde Region weiterleiten. Multi-Region-Design, Datenplatzierung und Failover sind Thema von Abschnitt 10.6.