Praktischer Leitfaden für Load Balancing mit nginx

Praktischer Leitfaden für Load Balancing mit nginx

Viele Entwickler nutzen nginx nur als "Reverse‑Proxy + statische Dateiserver", doch in Wahrheit ist nginx ein sehr leistungsfähiger Software‑Load‑Balancer. Wer selbst Server betreibt, kann mit einer guten nginx‑Konfiguration die Stabilität und Performance bei hohem Traffic deutlich verbessern.

In diesem Beitrag richten wir uns an Anfänger bis Fortgeschrittene und behandeln:

Was Load Balancing ist
Wie man nginx für Load Balancing konfiguriert
Die verschiedenen Algorithmen (Round Robin, least_conn, ip_hash usw.)
Health‑Checks
Häufig genutzte Optionen

1. Was ist Load Balancing?

Load Balancing bedeutet im Wesentlichen:

"Anfragen gleichmäßig auf mehrere Server verteilen, damit kein einzelner Server überlastet wird."

Warum ist es nötig?

Traffic‑Spitzen – verhindert, dass ein Server bei hohem Anfragenaufkommen ausfällt.
Skalierbarkeit (Scale‑Out) – statt die Spezifikationen eines Servers zu erhöhen, kann man mehrere Server horizontal hinzufügen.
Fehlertoleranz (High Availability) – wenn ein Server ausfällt, wird der Traffic automatisch auf die verbleibenden Server umgeleitet.

Wo steht nginx?

Typische Architektur:

Client → nginx (Load Balancer / Reverse‑Proxy) → mehrere Applikationsserver

nginx empfängt die Anfragen und leitet sie an einen der hinterlegten Applikationsserver weiter.

2. Grundlegende Struktur von nginx‑Load Balancing

In der nginx‑Konfiguration gibt es zwei zentrale Elemente:

upstream‑Block – definiert die Backend‑Server‑Pool.
server / location‑Block – legt fest, welcher upstream für eingehende Anfragen verwendet wird.

Ein einfaches Beispiel:

http {
    upstream app_backend {
        server 10.0.0.101:3000;
        server 10.0.0.102:3000;
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://app_backend;

            # Standard‑Proxy‑Header
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
}

Was bedeutet diese Konfiguration?

upstream app_backend – zwei Applikationsserver bilden einen Pool.
proxy_pass http://app_backend; – die Anfrage wird an einen Server aus dem Pool weitergeleitet.
Ohne explizite Angabe ist der Standard‑Algorithmus Round Robin.

3. Arten von Load‑Balancing‑Algorithmen

nginx bietet mehrere Strategien. Die Wahl hängt von der jeweiligen Situation ab.

3.1 Standard: Round Robin

Wenn nichts angegeben wird, ist Round Robin die Standardeinstellung.

upstream app_backend {
    server 10.0.0.101:3000;
    server 10.0.0.102:3000;
}

1. Anfrage → Server 1
2. Anfrage → Server 2
3. Anfrage → wieder Server 1 …

Vorteil: Einfach und in den meisten Fällen ausreichend. Nachteil: Berücksichtigt nicht die aktuelle Last.

3.2 least_conn

upstream app_backend {
    least_conn;
    server 10.0.0.101:3000;
    server 10.0.0.102:3000;
}

Der Server mit den wenigsten aktiven Verbindungen erhält die neue Anfrage. Besonders sinnvoll, wenn einzelne Anfragen stark variieren.

Empfohlene Szenarien: * Einige Anfragen sind lang, andere kurz. * Server haben ähnliche Spezifikationen, aber unterschiedliche Lastmuster.

3.3 ip_hash

upstream app_backend {
    ip_hash;
    server 10.0.0.101:3000;
    server 10.0.0.102:3000;
}

Die IP des Clients wird gehasht, sodass immer derselbe Server bedient wird. Nützlich für Sticky‑Sessions, wenn Sessions im Server‑Speicher gehalten werden.

Vorteile: * Sessions bleiben konsistent.

Nachteile: * Beim Hinzufügen/Entfernen von Servern kann die Zuordnung stark verschoben werden. * Bei Proxies wie Cloudflare kann die echte Client‑IP nicht erfasst werden.

3.4 Gewichtete Verteilung

Wenn Server unterschiedliche Leistungsstufen haben, kann man Gewichte setzen.

upstream app_backend {
    server 10.0.0.101:3000 weight=3;
    server 10.0.0.102:3000 weight=1;
}

Server 1 erhält 3 / 4 der Anfragen, Server 2 1 / 4.

4. Health‑Checks und Ausfall‑Handling

Um wirklich intelligent zu sein, muss der Load Balancer tote Server automatisch entfernen.

nginx‑Open‑Source unterstützt passive Health‑Checks.

4.1 max_fails / fail_timeout

upstream app_backend {
    server 10.0.0.101:3000 max_fails=3 fail_timeout=30s;
    server 10.0.0.102:3000 max_fails=3 fail_timeout=30s;
}

max_fails=3 – nach drei aufeinanderfolgenden Fehlern gilt der Server als nicht verfügbar.
fail_timeout=30s – für 30 s wird kein Traffic mehr an diesen Server gesendet.

Fehler sind typischerweise 502/503/504 oder Verbindungsabbrüche.

4.2 proxy_next_upstream

location / {
    proxy_pass http://app_backend;
    proxy_next_upstream error timeout http_502 http_503 http_504;
}

Bei den angegebenen Fehlern wird die Anfrage an den nächsten Server weitergeleitet. Übermäßiges Retry kann die Latenz erhöhen, daher nur bei Bedarf aktivieren.

5. Praxisbeispiel: Load Balancing einer einfachen Web‑Service

Angenommen, zwei Node.js‑Server laufen auf Port 3000:

10.0.0.101:3000
10.0.0.102:3000

5.1 nginx‑Konfiguration

http {
    upstream app_backend {
        least_conn;

        server 10.0.0.101:3000 max_fails=3 fail_timeout=30s;
        server 10.0.0.102:3000 max_fails=3 fail_timeout=30s;
    }

    server {
        listen 80;
        server_name myservice.com;

        location / {
            proxy_pass http://app_backend;

            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;

            proxy_read_timeout 60s;
            proxy_connect_timeout 5s;
            proxy_send_timeout 10s;
        }
    }
}

Nach einem Reload:

Alle Anfragen an myservice.com werden an den Node.js‑Server mit der geringsten aktiven Verbindung weitergeleitet.
Ein Server, der mehrere Fehler hintereinander produziert, wird für 30 s automatisch aus dem Pool entfernt.

6. HTTPS (SSL) Terminierung + Load Balancing

In Produktionsumgebungen wird fast immer HTTPS verwendet. Der typische Ansatz ist, nginx als SSL‑Termination‑Point zu nutzen.

http {
    upstream app_backend {
        least_conn;
        server 10.0.0.101:3000;
        server 10.0.0.102:3000;
    }

    server {
        listen 443 ssl;
        server_name myservice.com;

        ssl_certificate     /etc/letsencrypt/live/myservice.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/myservice.com/privkey.pem;

        location / {
            proxy_pass http://app_backend;

            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }

    # HTTP → HTTPS Redirect
    server {
        listen 80;
        server_name myservice.com;
        return 301 https://$host$request_uri;
    }
}

Client ↔ nginx: HTTPS
nginx ↔ Backend: HTTP (innerhalb des Netzwerks)

7. Sticky Sessions: Sind sie wirklich nötig?

Früher wurden Sessions häufig im Server‑Speicher gehalten, sodass der gleiche Client immer denselben Server erreichen musste. Mit ip_hash lässt sich das einfach realisieren, aber heute bevorzugt man:

Externe Session‑Stores wie Redis
JWT‑basierte, stateless‑Architekturen

Wenn möglich, sollte die Anwendung stateless bleiben. Der Load Balancer kann dann ausschließlich die Last verteilen, was Skalierbarkeit und Wartbarkeit verbessert.

8. Häufige Tuning‑Punkte

8.1 Keepalive

upstream app_backend {
    least_conn;
    server 10.0.0.101:3000;
    server 10.0.0.102:3000;

    keepalive 32;
}

server {
    location / {
        proxy_pass http://app_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

keepalive 32; – bis zu 32 Keep‑Alive‑Verbindungen pro Worker.
Reduziert TCP‑Handshake‑Overhead und Latenz.

8.2 Buffer & Timeouts

location / {
    proxy_pass http://app_backend;

    proxy_buffering on;
    proxy_buffers 16 16k;
    proxy_busy_buffers_size 64k;

    proxy_read_timeout 60s;
    proxy_send_timeout 60s;
}

Zu kurze Timeouts führen zu 504‑Fehlern.
Buffer‑Größen sollten an die erwartete Antwortgröße angepasst werden.

9. Schritt‑für‑Schritt‑Strategie zur Einführung von nginx‑Load Balancing

Wenn ein Service bereits läuft und auf einem einzigen Server gehostet wird, empfiehlt sich ein schrittweiser Ausbau:

Reverse‑Proxy einführen – Client → nginx → bestehender Server.
Server replizieren – neue Instanz starten, Daten synchronisieren, in upstream aufnehmen.
Health‑Checks & Monitoring – max_fails, fail_timeout, proxy_next_upstream konfigurieren; Logs und Metriken (z. B. Prometheus + Grafana) integrieren.
Algorithmus & Tuning – je nach Traffic‑Muster least_conn oder weight wählen; Keepalive, Buffer, Timeouts anpassen.

Fazit

nginx bietet weit mehr als nur einen Reverse‑Proxy. Mit den richtigen Konfigurationen kann er als robuster Load Balancer dienen:

upstream definiert den Server‑Pool.
Algorithmus (Round Robin, least_conn, ip_hash, weight) wird je nach Bedarf gewählt.
Health‑Checks und Retry‑Policies sorgen für Ausfallsicherheit.
HTTPS‑Termination kombiniert Sicherheit und Performance.

Wenn du dich mit diesen Konzepten vertraut gemacht hast, kannst du bei steigender Last deine Infrastruktur mit nginx auf die nächste Stufe heben.