Microservices
Ein Architekturmuster, bei dem eine Anwendung aus vielen kleinen, unabhängigen Services besteht, die jeweils eine spezifische Aufgabe erfüllen.
Das Verteilen von eingehenden Anfragen auf mehrere Server oder Instanzen, um Überlastung zu vermeiden, Ausfallsicherheit zu erhöhen und die Performance zu optimieren.
Ein einzelner Server kann nur eine begrenzte Anzahl von Anfragen gleichzeitig verarbeiten. Wenn mehr Nutzer kommen, wird er langsamer oder bricht zusammen. Die Lösung: mehrere Server betreiben und die Last gleichmäßig verteilen.
Der Load Balancer sitzt vor den Servern und entscheidet, welcher Server die nächste Anfrage bekommt. Fällt ein Server aus, bemerkt der Load Balancer das über Health Checks und schickt keinen Traffic mehr dorthin.
Gängige Algorithmen:
| Algorithmus | Funktionsweise | Geeignet für |
|---|---|---|
| Round Robin | Reihum, gleichmäßig | Gleich starke Server |
| Least Connections | Server mit wenigsten aktiven Verbindungen | Unterschiedliche Request-Dauer |
| IP Hash | Gleicher Nutzer → gleicher Server | Zustandsbehaftete Apps |
| Weighted | Stärkere Server bekommen mehr Traffic | Heterogene Server |
upstream llm_backends {
least_conn; # Algorithmus: wenigste aktive Verbindungen
server gpu-server-1:8080 weight=3;
server gpu-server-2:8080 weight=3;
server gpu-server-3:8080 weight=1; # Schwächerer Server
}
server {
location /api/generate {
proxy_pass http://llm_backends;
proxy_connect_timeout 10s;
proxy_read_timeout 120s; # LLM-Antworten können lang dauern
}
}
upstream llm_backends {
server gpu-server-1:8080;
server gpu-server-2:8080;
# Aktiver Health Check (NGINX Plus)
health_check interval=5s fails=3 passes=2;
} Load Balancing ist wie ein Kassierer-Koordinator im Supermarkt: Er schaut, welche Kasse am wenigsten Warteschlange hat, und schickt den nächsten Kunden dorthin. Kein Kassierer wird überlastet, alle arbeiten gleichmäßig.
Verteilt Traffic auf mehrere Server-Instanzen
Erhöht Verfügbarkeit: Fällt ein Server aus, übernehmen die anderen
Verschiedene Algorithmen: Round Robin, Least Connections, IP Hash
LLM-Inference-Skalierung
Anfragen auf mehrere GPU-Instanzen verteilen, um hohe Last zu bewältigen
Zero-Downtime-Deployments
Neue Version deployen, während der Load Balancer Traffic noch auf die alte Version schickt
Geo-Routing
Nutzer automatisch zum nächstgelegenen Rechenzentrum leiten
Layer 4 (Transport): Verteilt Traffic basierend auf IP und Port – schnell, aber ohne Kenntnis des Inhalts. Layer 7 (Application): Versteht HTTP – kann nach URL-Pfad, Headers oder Cookie routen. Für KI-APIs ist Layer 7 sinnvoll, um z. B. /chat auf andere Server zu routen als /embeddings.
Der Load Balancer sendet regelmäßig Anfragen an alle Server (z. B. GET /health). Antwortet ein Server nicht oder mit einem Fehler, wird er aus der Rotation genommen und bekommt keinen Traffic mehr.
Eine Konfiguration, bei der alle Anfragen eines Nutzers immer zum selben Server gehen (z. B. über ein Cookie). Nötig bei zustandsbehafteten Anwendungen, aber ein Hindernis für echte Skalierung.