Load Balancing

Sobald eine Anwendung auf mehr als einer Instanz läuft, braucht es eine Komponente, die eingehende Anfragen verteilt: den Load Balancer. Er ist das Eingangstor zu allen Instanzen, verteilt die Last, erkennt ausgefallene Server und nimmt sie aus der Verteilung. Oft übernimmt er zusätzlich die TLS-Verschlüsselung, leitet Anfragen nach Pfaden an verschiedene Dienste weiter und schützt vor bestimmten Angriffen. Diese Lektion zeigt, wie ein Load Balancer arbeitet und worauf man beim Entwurf achten sollte.

1. Aufgaben eines Load Balancers

2. Verteilverfahren

Das einfachste Verfahren ist Round Robin: Die Anfragen werden der Reihe nach verteilt, eine an A, eine an B, eine an C. Das funktioniert gut, wenn alle Instanzen gleich stark sind und alle Anfragen ähnlich lange dauern. Least Connections schickt jede neue Anfrage an die Instanz mit den wenigsten offenen Verbindungen und passt sich damit automatisch an, wenn eine Instanz langsamer ist oder manche Anfragen länger dauern. Gewichtete Verfahren berücksichtigen unterschiedliche Kapazitäten, etwa wenn neue und alte Server gemischt betrieben werden. Probieren Sie die Verfahren aus:

Die Simulation zeigt zwei wichtige Lehren. Erstens: Gleichmäßige Verteilung ist nicht immer gerecht. Wenn eine Instanz langsamer ist, etwa weil sie gerade eine teure Aufgabe erledigt oder auf schwächerer Hardware läuft, überlastet Round Robin sie. Zweitens, und noch wichtiger: Ohne Health Checks schickt der Load Balancer weiter Anfragen an eine defekte Instanz, und ein Drittel aller Nutzer bekommt Fehler.

3. Health Checks

Ein Health Check ist eine regelmäßige Prüfung, ob eine Instanz gesund ist, typischerweise ein Aufruf eines speziellen Endpunkts wie /health alle paar Sekunden. Antwortet die Instanz mehrfach nicht oder mit Fehlern, nimmt der Load Balancer sie aus der Verteilung und nimmt sie wieder auf, sobald sie sich erholt hat. Man unterscheidet zwei Arten: Ein Liveness-Check prüft, ob der Prozess überhaupt läuft, ein Readiness-Check prüft, ob die Instanz bereit ist, Anfragen zu bearbeiten – etwa ob sie gestartet ist und ihre Datenbankverbindung hat.

Bei der Gestaltung von Health Checks lauern Fallen. Ein Check, der die Datenbank abfragt, erscheint gründlich, kann aber gefährlich sein: Ist die Datenbank kurz langsam, melden alle Instanzen gleichzeitig „ungesund“, der Load Balancer nimmt alle aus der Verteilung, und das ganze System ist aus – obwohl die Instanzen selbst in Ordnung waren. Ein Readiness-Check sollte deshalb prüfen, ob die Instanz selbst arbeitsfähig ist, und Abhängigkeiten nur vorsichtig einbeziehen.

4. Layer 4 und Layer 7

Load Balancer arbeiten auf verschiedenen Ebenen. Ein Layer-4-Load-Balancer verteilt TCP- oder UDP-Verbindungen, ohne deren Inhalt zu kennen. Er ist sehr schnell und eignet sich für einfache Verteilung und Protokolle jenseits von HTTP. Ein Layer-7-Load-Balancer versteht HTTP: Er kann nach Pfad, Host oder Header weiterleiten, Anfragen umschreiben, Cookies auswerten und einzelne Anfragen statt ganzer Verbindungen verteilen. Für Webanwendungen ist meist ein Layer-7-Load-Balancer die richtige Wahl, oft in Form eines Reverse Proxy wie Nginx oder Traefik oder eines verwalteten Dienstes des Cloudanbieters.

5. Sitzungsbindung und WebSockets

Manche Anwendungen verlangen, dass ein Nutzer immer bei derselben Instanz landet – etwa weil die Sitzung im Arbeitsspeicher liegt. Das nennt man Sitzungsbindung oder Sticky Sessions. Sie funktioniert, hat aber Nachteile: Die Last verteilt sich ungleichmäßig, und fällt die Instanz aus, verlieren alle ihre Nutzer die Sitzung. Besser ist fast immer, die Anwendung zustandslos zu machen, wie in der vorigen Lektion beschrieben. Eine Ausnahme sind lang laufende Verbindungen wie WebSockets für Echtzeitfunktionen: Hier bleibt eine Verbindung naturgemäß an einer Instanz. Der Entwurf muss dann berücksichtigen, dass Nachrichten an Nutzer auf anderen Instanzen weitergeleitet werden müssen, etwa über einen gemeinsamen Nachrichtenkanal. Das Modul Moderne Anwendungsmuster vertieft das.

6. Der Load Balancer als Ausfallpunkt

Ein Load Balancer verteilt Last und fängt Ausfälle ab – aber er selbst darf nicht zum einzelnen Ausfallpunkt werden. Verwaltete Load Balancer der Cloudanbieter sind intern redundant. Wer selbst einen Reverse Proxy betreibt, sollte mindestens zwei Instanzen einplanen, etwa mit einer gemeinsamen, wandernden IP-Adresse oder über DNS mit mehreren Einträgen. Für kleinere Systeme ist es oft am einfachsten, den Load Balancer des Hosting-Anbieters oder das vorgeschaltete CDN zu nutzen, das diese Aufgabe übernimmt.

Schließlich sollte der Load Balancer Zeitlimits setzen. Eine Anfrage, die nach dreißig Sekunden noch keine Antwort hat, sollte abgebrochen werden, damit sie keine Ressourcen blockiert. Gleichzeitig muss das Zeitlimit zu den Anforderungen passen: Ein Upload großer Dateien oder eine KI-Anfrage dauert länger als eine normale Seitenanfrage. Solche langen Vorgänge sollten, wie das nächste und übernächste Kapitel zeigen, ohnehin eher asynchron gestaltet werden.

7. Rollouts über den Load Balancer

Ein Load Balancer ist auch das wichtigste Werkzeug für sichere Aktualisierungen. Bei einem Rolling Update werden die Instanzen nacheinander ersetzt: Eine Instanz wird aus der Verteilung genommen, laufende Anfragen werden noch zu Ende bearbeitet, dann wird die neue Version gestartet und nach erfolgreichem Health Check wieder aufgenommen. So gibt es keine Ausfallzeit. Bei einem Blue-Green-Deployment läuft die neue Version komplett parallel zur alten, und der Load Balancer schaltet auf einen Schlag um – mit der Möglichkeit, ebenso schnell zurückzuschalten. Bei einem Canary-Release erhält die neue Version zunächst nur einen kleinen Teil der Anfragen, etwa fünf Prozent. Zeigen die Messwerte keine Probleme, wird der Anteil schrittweise erhöht.

Damit das funktioniert, müssen alte und neue Version eine Zeit lang gleichzeitig laufen können. Datenbankänderungen müssen deshalb abwärtskompatibel sein, und Schnittstellen dürfen sich nicht plötzlich ändern. Wichtig ist auch das sogenannte Connection Draining: Bevor eine Instanz beendet wird, bekommt sie keine neuen Anfragen mehr, darf aber die laufenden noch abschließen. Wer diese Details beachtet, kann mehrmals täglich neue Versionen ausrollen, ohne dass Nutzer davon etwas bemerken. Das Modul zu Zuverlässigkeit und Betrieb greift diese Verfahren noch einmal im Zusammenhang mit Containern und Deployment auf.

Für die meisten Webanwendungen genügt am Anfang ein verwalteter Load Balancer oder ein einfacher Reverse Proxy mit zwei Anwendungsinstanzen. Wichtig ist nicht die ausgefeilteste Technik, sondern dass Health Checks, Zeitlimits und ein geordnetes Ausrollen neuer Versionen von Beginn an sauber eingerichtet sind.

Stand: September 2026. Kursmaterial der Klarwerk Akademie. Zahlen zu Latenzen und Kosten sind Größenordnungen zur Orientierung, keine Messwerte.