Skip to content
NeuralSkills
Bereitstellung

Load-Balancer-Einrichtung

Load-Balancing-Strategien konfigurieren, die Traffic effizient verteilen — von Round-Robin ueber Sticky Sessions bis hin zu Health-aware Routing.

Fortgeschritten Kostenlos Veroeffentlicht: 15. April 2026
Kompatible Tools claude-codechatgptgeminicopilotcursorwindsurfuniversal

Das Problem

Ihr einzelner Server ist ein Single Point of Failure. Bei Traffic-Spitzen knickt er ein. Beim Deployment geht er offline. Load Balancer loesen das, aber die falsche Algorithmus-Wahl — oder fehlerhafte Health-Checks — erzeugt schlimmere Probleme als gar kein Load Balancer: ungleichmaessige Traffic-Verteilung, Requests an tote Server und verlorene Session-Daten zwischen Anfragen.

Der Prompt

Du bist ein Load-Balancing-Architekt. Entwirf eine Load-Balancing-Strategie fuer meine Anwendung.

ANWENDUNGSKONTEXT:
- Architektur: [z.B. 3 Node.js-Server, Kubernetes-Pods, Serverless-Funktionen]
- Traffic-Volumen: [z.B. 1000 Req/Min, 50k gleichzeitige Nutzer, sprunghaft/gleichmaessig]
- Session-Handling: [z.B. Stateless JWT, serverseitige Sessions, WebSocket-Verbindungen]
- Health-Check-Endpunkt: [z.B. /health, /api/status, noch keiner]
- Plattform: [z.B. AWS ALB/NLB, Nginx, HAProxy, Cloudflare, Traefik]

Entwirf die Load-Balancing-Strategie:
1. **Algorithmus-Auswahl**: Vergleiche Round-Robin, Least-Connections, Weighted, IP-Hash fuer meinen Fall. Empfehle mit Begruendung.
2. **Health-Check-Konfiguration**: Definiere Health-Check-Endpunkt, Intervall, Schwellenwerte und was "gesund" bedeutet.
3. **Session-Persistenz**: Wie Session-Affinitaet behandelt wird ohne horizontale Skalierung zu brechen.
4. **SSL-Terminierung**: Wo SSL terminiert wird (Load Balancer vs. Backend) mit Performance-Implikationen.
5. **Failover-Verhalten**: Was passiert wenn ein Backend ausfaellt — Drain, Retry, Circuit Break.
6. **Konfiguration**: Liefere die exakte Konfiguration fuer meine Plattform.

Beispielausgabe

Strategie: Least-Connections (empfohlen fuer Ihre API mit variabler Request-Dauer)
Health Check: GET /health alle 10s, gesund nach 2 Erfolgen, ungesund nach 3 Fehlschlaegen
  /health liefert: { status: "ok", db: "connected", uptime: 3600 }
Session: Stateless JWT — keine Sticky Sessions noetig, vereinfacht Skalierung
SSL: Am ALB terminieren (lagert TLS-Overhead von App-Servern aus, zentralisiert Zertifikatsverwaltung)
Failover: Connection Draining 30s vor Entfernung ungesunder Targets, Retry bei 502/503 (max 2 Retries)

Wann einsetzen

Verwenden Sie diesen Skill beim Hinzufuegen eines zweiten Servers, bei der Vorbereitung auf Traffic-Wachstum oder der Einrichtung von Hochverfuegbarkeit. Unverzichtbar beim erstmaligen Deployment hinter Cloud-Load-Balancern oder beim Debugging ungleichmaessiger Traffic-Verteilung ueber Backend-Server.

Profi-Tipps

  • Health Checks sollten echte Abhaengigkeiten testen — ein /health das 200 zurueckgibt ohne die Datenbankverbindung zu pruefen, leitet Traffic freudig an einen Server weiter, der keine echten Anfragen bedienen kann.
  • Connection Draining verhindert abgebrochene Requests — beim Entfernen eines Servers aus dem Pool sollten aktive Verbindungen abfliessen (30-60 Sekunden) statt sofort abgeschnitten zu werden.
  • WebSocket-Verbindungen brauchen andere Regeln — Standard-HTTP-Load-Balancing bricht persistente Verbindungen. Verwenden Sie verbindungsbasiertes Balancing oder einen separaten Listener fuer WebSocket-Traffic.
  • Ueberwachen Sie Per-Backend-Metriken — wenn ein Server konsistent hoehere Latenz oder Error-Raten hat, funktioniert der Load Balancer korrekt, aber etwas stimmt mit dieser spezifischen Instanz nicht.