Load Balancing

Du hast einen Web-Server, der unter Last in die Knie geht. Du kaufst einen größeren – funktioniert eine Weile. Dann wächst die Last weiter. Du kaufst noch einen größeren – immer teurer. Irgendwann gibt's keinen größeren mehr. Das ist vertikale Skalierung, und sie hat eine harte Grenze.

Der Ausweg ist horizontale Skalierung: statt einem großen Server mehrere kleine. Aber wie verteilst du die Anfragen auf diese Server? Dafür gibt's den Load Balancer – ein zentraler Baustein moderner Architekturen. Er macht zwei Dinge auf einmal: Skalierung (mehr Last verkraften) und Hochverfügbarkeit (Ausfall einzelner Server abfangen). Diese Lektion erklärt wie.

1) Was ist ein Load Balancer?

Ein Load Balancer (deutsch: Lastverteiler) ist eine Komponente, die eingehende Anfragen auf mehrere Backend-Server verteilt. Aus Sicht des Clients ist er die einzige sichtbare Adresse – im Hintergrund sorgt er dafür, dass die Last auf vielen Servern verteilt wird.

Damit löst er zwei Probleme gleichzeitig:

Skalierung: mehr Server = mehr Kapazität. Bei wachsender Last fügst du einfach Server hinzu.
Hochverfügbarkeit: fällt ein Server aus, leitet der LB die Anfragen auf die anderen um. Endnutzer merken nichts.

Load Balancer sind essentiell für moderne Web-Anwendungen, Microservices, Mail-Server-Cluster und viele andere Setups. Ohne sie keine echte horizontale Skalierung, kein echtes Hochverfügbarkeit auf Service-Ebene.

2) Visualisierung: ohne und mit Load Balancer

Schauen wir uns das Bild an. Links ohne LB, rechts mit LB und mehreren Servern:

Mit und ohne Load Balancer

❌ Ohne Load Balancer – ein Server, ein SPoF

👤 User

→

🖥

Server 1

80% Last

Single Point of Failure · keine Skalierung · keine HA

✓ Mit Load Balancer – Skalierung und HA

👤 User

→

⚖

Load Balancer

→

🖥

Server 1

40%

🖥

Server 2

30%

💥

Server 3

DOWN

🖥

Server 4

35%

Server 3 ausgefallen → LB leitet nur an Server 1, 2, 4 weiter. Endnutzer merken nichts.

Der LB ist der zentrale Eintrittspunkt – der „Türsteher" der Architektur. Wichtig: er selbst muss redundant sein, sonst ist er der SPoF. Mehr dazu am Ende.

3) Layer-4 vs. Layer-7 Load Balancing

Load Balancer arbeiten auf verschiedenen Ebenen des OSI-Modells. Die zwei wichtigsten Klassen sind Layer-4 (Transport-Ebene, TCP/UDP) und Layer-7 (Anwendungs-Ebene, HTTP). Sie haben unterschiedliche Stärken:

Layer-4 vs. Layer-7 Load Balancer

Layer-4 LB

Transport-Ebene (TCP/UDP)

Entscheidet nur anhand von IP-Adresse und Port. Sehr schnell, einfach. Kennt den Inhalt der Pakete nicht.

✓ extrem performant, low-latency, jeder Protokoll-Typ

✗ keine inhaltsbasierten Entscheidungen, keine SSL-Termination ohne Tricks

Layer-7 LB

Anwendungs-Ebene (HTTP)

Entscheidet anhand von HTTP-Inhalt: URL, Header, Cookies, Hostname. Kann SSL terminieren, Inhalte modifizieren, Routing-Regeln umsetzen.

✓ flexibles Routing (/api → API-Server, /admin → Admin-Server), Sticky Sessions, SSL-Termination

✗ langsamer (Pakete analysieren kostet), nur für TCP-basierte Protokolle

In der Praxis kombiniert: Layer-4 LB vor Layer-7 LB. Layer-4 verteilt erstmal grob auf mehrere Layer-7-LBs, Layer-7 macht das feine Routing. Beispiele: AWS NLB (Layer-4) → ALB (Layer-7); HAProxy kann beides.

4) Verteilungs-Algorithmen

Wie entscheidet der LB, welcher Server die nächste Anfrage bekommt? Es gibt mehrere klassische Algorithmen:

Load-Balancing-Algorithmen

Round Robin

Reihum

Anfrage 1 → Server 1, Anfrage 2 → Server 2, Anfrage 3 → Server 3, dann wieder Server 1. Einfachster Algorithmus, gleichmäßige Verteilung.

→ 1, 2, 3, 1, 2, 3, 1...

Weighted Round Robin

Gewichtet

Wie Round Robin, aber stärkere Server bekommen mehr Anfragen. Server-Gewicht 3:2:1 → von 6 Anfragen 3 an A, 2 an B, 1 an C.

→ A, A, A, B, B, C, A, A...

Least Connections

Wenigste offene Verbindungen

Anfrage geht an den Server mit den wenigsten aktiven Verbindungen. Gut bei langlaufenden Anfragen unterschiedlicher Dauer.

→ Server mit min(Conn) wählen

Least Response Time

Schnellste Antwort

Anfrage an den Server, der zuletzt am schnellsten geantwortet hat. Berücksichtigt aktuelle Auslastung implizit.

→ Server mit min(RT) wählen

IP Hash

Hash der Client-IP

Hash der Client-IP bestimmt den Server. Selbe IP geht immer zum gleichen Server. Hilfreich für Session-Persistenz ohne Cookies.

→ hash(client-IP) % N → Server

URL Hash

Hash der angefragten URL

Gleiche URL geht immer zum gleichen Server. Gut für Cache-Effizienz – jeder Server cacht „seinen" Content.

→ hash(URL) % N → Server

Random

Zufällig

Bei jeder Anfrage zufälligen Server wählen. Bei großen Server-Mengen statistisch gleichmäßig.

→ rand(N) → Server

Power of Two Choices

2 zufällige + Auswahl

Wähle 2 Server zufällig, nimm den mit weniger Last. Erstaunlich effektiv, kombiniert Einfachheit mit Last-Bewusstsein.

→ Best of (rand, rand)

Für die meisten Use Cases reicht Round Robin oder Least Connections. Bei heterogenen Servern Weighted Round Robin. Bei Sticky Sessions IP Hash oder Cookie-basierte Persistenz. Power of Two Choices ist ein Geheimtipp – fast so gut wie Least Connections, aber mit weniger Aufwand.

5) Sticky Sessions (Session-Persistenz)

Manche Anwendungen brauchen, dass ein User für seine ganze Session immer auf denselben Server kommt. Klassisches Beispiel: ein Warenkorb wird im Server-Memory gehalten. Wechselt der User auf einen anderen Server, ist der Warenkorb weg.

Lösungen dafür:

IP Hash: gleiche Client-IP → gleicher Server. Funktioniert solange die Client-IP stabil ist (kann bei NAT/Mobile-Netzen Probleme machen).
Cookie-basierte Sticky Sessions: der LB setzt ein Cookie mit der Server-ID. Bei Folge-Anfragen liest er es aus und routet entsprechend.
Application-Cookie: die App selbst setzt ein Cookie (z.B. JSESSIONID), der LB nutzt dieses zur Identifikation.

Wichtiger Vorbehalt: Sticky Sessions sind oft ein Anti-Pattern. Sie machen Server „stateful" und verhindern saubere horizontale Skalierung. Modernes Design: Session-Daten in Redis oder Memcached auslagern, damit jeder Server jeden Request bedienen kann. Dann braucht's keine Sticky Sessions mehr.

6) Health Checks

Die zweite Kernaufgabe des LB ist die Health-Überwachung. Bevor er Anfragen an einen Server schickt, muss er wissen, dass der Server überhaupt antworten kann. Dafür gibt's Health Checks:

Wie Health Checks funktionieren

Regelmäßiger Probe-Request

Alle X Sekunden (typisch 5-30s) schickt der LB einen Test-Request an jeden Backend-Server.

GET /health HTTP/1.1

Antwort-Auswertung

Erwartet wird HTTP 200 OK innerhalb eines Timeouts. Anderes Resultat (Timeout, 5xx, falscher Body) = ungesund.

200 OK / "OK" / {"status":"healthy"}

Threshold-Logik

N aufeinanderfolgende Fehler (z.B. 3) → Server als „down" markieren. M Erfolge (z.B. 2) → wieder „up". Verhindert flackernde Zustände.

3 fails → DOWN · 2 success → UP

Routing-Update

„Down"-Server bekommen keine neuen Anfragen. Bestehende Verbindungen werden meist noch beendet (Connection Draining).

Pool: [s1, s2, s4] (s3 entfernt)

Bei Erholung wieder einbinden

Sobald der Server wieder gesund ist, wird er langsam wieder in den Pool aufgenommen – oft mit niedrigerem initialen Gewicht („Slow Start"), um nicht sofort überlastet zu werden.

Slow start: gradient ramp-up

Wichtig ist, was der /health-Endpoint prüft. Nur Web-Server-Status reicht nicht – er sollte auch wesentliche Abhängigkeiten testen (DB-Verbindung, Cache, externe Services). Sonst meldet er „healthy", obwohl die App eigentlich kaputt ist. Best Practice: /health für LB (oberflächlich, schnell) und /health/deep für Monitoring (gründlich).

7) SSL-Termination

Eine wichtige Funktion von Layer-7 Load Balancern: SSL/TLS-Termination. Statt dass jeder Backend-Server selbst SSL macht, kümmert sich der LB darum:

Client → LB: verschlüsselte HTTPS-Verbindung
LB → Backend: meist unverschlüsseltes HTTP (im internen Netzwerk)

Vorteile:

Backend-Server haben keine SSL-Last (CPU-Aufwand für Verschlüsselung)
Zertifikate nur einmal verwalten (auf dem LB statt auf jedem Server)
SSL-Renewal (Let's Encrypt) zentral
Inhaltsbasierte Routing-Entscheidungen möglich (nach SSL-Decryption)

Wo höhere Sicherheit gefordert ist (z.B. PCI-DSS-konformes Setup), kann man auch SSL-Passthrough machen: LB leitet verschlüsselte Pakete unverändert weiter, Backend macht selbst SSL. Dann kann der LB aber keine HTTP-basierten Entscheidungen treffen.

8) Software Load Balancer mit nginx

Ein klassisches Beispiel: nginx als Load Balancer für mehrere Web-Server. Sehr verbreitet, einfach zu konfigurieren:

nginx.confNginx

1# Backend-Pool definieren
2upstream backend {
3    least_conn;        # Algorithmus: Least Connections
4    server 10.0.1.10:8080 weight=3;
5    server 10.0.1.11:8080 weight=2;
6    server 10.0.1.12:8080 weight=2;
7    server 10.0.1.13:8080 backup; # Standby-Server
8}
9
10server {
11    listen 443 ssl;
12    server_name app.example.com;
13
14    ssl_certificate /etc/ssl/cert.pem;
15    ssl_certificate_key /etc/ssl/key.pem;
16
17    location / {
18        proxy_pass http://backend;
19        proxy_set_header Host $host;
20        proxy_set_header X-Real-IP $remote_addr;
21    }
22}

Was hier passiert: nginx hört auf Port 443 (HTTPS), terminiert SSL, und leitet Anfragen via Least-Connections-Algorithmus an drei Backend-Server (mit unterschiedlichen Gewichten) weiter. Server 13 ist ein Backup, der nur einspringt wenn alle anderen down sind.

9) Layer-7-Routing am Beispiel

Die volle Power von Layer-7 zeigt sich beim Routing nach URL-Pfad oder Host. Eine moderne Microservice-Architektur könnte so aussehen:

nginx-routing.confNginx

1upstream api_servers   { server 10.0.1.10; server 10.0.1.11; }
2upstream static_servers { server 10.0.1.20; }
3upstream admin_servers { server 10.0.1.30; }
4
5server {
6    listen 443 ssl;
7
8    # /api/* → API-Server
9    location /api/ {
10        proxy_pass http://api_servers;
11    }
12
13    # /admin/* → Admin-Server (mit IP-Whitelist)
14    location /admin/ {
15        allow 192.168.1.0/24;
16        deny all;
17        proxy_pass http://admin_servers;
18    }
19
20    # Alles andere → Static-Server
21    location / {
22        proxy_pass http://static_servers;
23    }
24}

Hier wird je nach URL-Pfad an unterschiedliche Server-Pools weitergeleitet – API-Anfragen, statische Inhalte und der Admin-Bereich werden getrennt skaliert. Admin-Bereich zusätzlich mit IP-Whitelist abgesichert. Das ist klassische Microservice-Architektur.

10) Hardware vs. Software vs. Cloud-LB

Es gibt verschiedene Arten, einen Load Balancer zu betreiben:

Load Balancer Optionen im Markt

nginx / OpenResty

Open Source, sehr verbreitet, vielseitig (Web, LB, Reverse Proxy)

HAProxy

Hochperformant, Layer 4+7, beliebt im Enterprise-Bereich

Traefik

Cloud-Native, dynamische Konfiguration, gut für Container

Envoy

Modern, Layer 7, Basis für Service Meshes wie Istio

AWS ALB / NLB

Managed Service, integriert in AWS, Auto-Scaling

Azure App Gateway

Microsofts Cloud-LB, WAF-Integration

Google Cloud LB

Global Load Balancing, Anycast-IPs

F5 BIG-IP

Klassischer Hardware-LB, hochperformant, sehr teuer

Citrix ADC

Früher NetScaler, Hardware + Software, Enterprise

Trend der letzten Jahre: weg von Hardware-LB (teuer, unflexibel) hin zu Software-LB (in Container/VM) und Cloud-managed LB. Hardware-LB bleibt im Enterprise mit Spezial-Anforderungen (Layer-7-Performance, SSL-Beschleunigung) relevant.

11) Global Server Load Balancing (GSLB)

Für globale Anwendungen reicht ein einzelner LB nicht. Du willst, dass User in Europa zum europäischen Cluster geleitet werden, US-User zum US-Cluster. Das macht Global Server Load Balancing (GSLB), oft via DNS:

Geo-DNS: DNS-Server antwortet je nach Client-Geo mit unterschiedlichen IP-Adressen. User aus Berlin → europäische IP, User aus New York → US-IP.
Anycast: gleiche IP-Adresse wird an mehreren Standorten beworben (BGP). Router leiten Traffic zum nächstgelegenen Standort. CDNs wie Cloudflare, AWS CloudFront nutzen das.
Health-aware GSLB: DNS schickt nicht nur nach Geo, sondern auch nach Health. Wenn die EU-Region down ist, antwortet er mit US-IPs.

Anbieter: AWS Route 53, Cloudflare, NS1, F5 BIG-IP DNS, Akamai GTM. Für Hochverfügbarkeit auf Cross-Region-Ebene ist GSLB unverzichtbar.

12) Der LB selbst muss redundant sein

Ein häufiger Anfänger-Fehler: einen einzigen Load Balancer aufbauen, der dann selbst SPoF wird. Wenn der LB stirbt, ist alles down – trotz aller redundanten Backend-Server. Lösungen:

Active-Passive HA: zwei LBs, einer aktiv, einer Standby. Bei Ausfall übernimmt Standby via Failover (z.B. VRRP, Keepalived). Mehr in L7.
Active-Active: beide LBs leiten Traffic, Load wird zwischen ihnen geteilt (DNS Round Robin oder Anycast davor).
Cloud-managed LB: AWS ALB, Azure App Gateway etc. sind intern bereits redundant – das übernimmt der Anbieter.

Tools für LB-Redundanz: Keepalived mit VRRP (Virtual Router Redundancy Protocol) – zwei LBs teilen sich eine Virtual IP, die im Failover-Fall umschwenkt. Sehr verbreitet bei On-Premise-Setups.

13) Verfügbarkeits-Mathematik mit LB

Schauen wir uns an wie ein LB die Verfügbarkeit erhöht. Annahmen: jeder Backend-Server hat 99% Verfügbarkeit. Ohne LB heißt das: 99% Gesamt-Verfügbarkeit. Mit LB und N Servern:

1 Server: 99,00% (entspricht 87,6 h Downtime/Jahr)
2 Server: 99,99% (52,5 Min/Jahr – Berechnung: 1 - 0,01² = 0,9999)
3 Server: 99,9999% (32 Sek/Jahr)
4 Server: 99,999999% (0,3 Sek/Jahr)

Diese Mathematik gilt nur unter unabhängigen Ausfällen – also wenn die Server nicht alle gleichzeitig ausfallen wegen einer gemeinsamen Ursache. Mehr dazu in L3. Vorausgesetzt der LB selbst ist redundant – sonst ist er der SPoF.

14) Häufige Probleme und Anti-Patterns

Beim Aufbau von Load-Balancing-Setups gibt's klassische Fehler:

LB als SPoF: kein Standby-LB
Unzureichende Health Checks: nur „Server lebt" gecheckt, nicht „App funktioniert"
Health-Check zu aggressiv: bei kurzem Hänger werden Server fälschlich rausgenommen → Cascade
Health-Check zu lasch: kaputte Server bekommen weiter Traffic
Sticky Sessions ohne Session-Store: keine echte Skalierung möglich
X-Forwarded-For nicht gesetzt: Backend sieht nur LB-IP, nicht echte Client-IP (Logging-Problem)
SSL-Termination ohne Backend-Verschlüsselung: in unsicheren Netzen Risiko
Keine Connection-Draining: bei Server-Removal werden laufende Verbindungen hart abgebrochen
Server-Pool nicht groß genug: Ausfall eines Servers überlastet die anderen → Cascade
Falscher Algorithmus: Round Robin bei heterogenen Servern → schwache Server überlastet

Zusammenfassung

Load Balancer verteilt Anfragen auf mehrere Backend-Server – löst Skalierungs- und HA-Probleme gleichzeitig. Layer-4 (TCP/UDP, schnell, IP+Port) vs. Layer-7 (HTTP, flexibel, URL+Header+SSL). Algorithmen: Round Robin, Weighted RR, Least Connections, Least Response Time, IP Hash, URL Hash, Random, Power of Two Choices. Sticky Sessions via IP-Hash oder Cookies – aber Anti-Pattern, besser Session-Store (Redis). Health Checks: regelmäßige Probe-Requests mit Threshold-Logik, gestaffeltes Auf-/Abnehmen. SSL-Termination: LB macht SSL, Backend HTTP – CPU-Entlastung, zentrales Zertifikats-Management. Tools: nginx, HAProxy, Traefik, Envoy (Software), AWS ALB/NLB, Azure App Gateway (Cloud), F5 BIG-IP (Hardware). GSLB für globale Setups via Geo-DNS oder Anycast. LB selbst muss redundant sein (Active-Passive mit Keepalived/VRRP oder Active-Active). Verfügbarkeits-Mathematik: 2 Server à 99% = 99,99% (wenn unabhängig). Anti-Patterns: LB als SPoF, schlechte Health Checks, Sticky Sessions ohne Session-Store, fehlendes Connection Draining.