Auto-Scaling
Wenn viele Nutzer gleichzeitig auf einen Dienst zugreifen, steigt die benötigte Rechenleistung. Auto-Scaling bezeichnet den Mechanismus, der diese Rechenressourcen automatisch an die aktuelle Last anpasst, ohne dass ein Mensch eingreifen muss.
Ressourcen folgen der Last
Cloud-Dienste laufen auf Servern, die jeweils eine begrenzte Kapazität haben. Steigt die Zahl der Anfragen über diese Kapazität hinaus, verlangsamt sich der Dienst oder fällt ganz aus. Auto-Scaling löst dieses Problem, indem es die Zahl der aktiven Server-Instanzen an den tatsächlichen Bedarf koppelt.
Beispiel: Ein KI-basierter Übersetzungsdienst verarbeitet werktags zwischen 9 und 18 Uhr rund 5.000 Anfragen pro Minute. Nachts sinkt die Last auf unter 200 Anfragen. Ohne Auto-Scaling müsste der Betreiber dauerhaft Server für die Spitzenlast bereithalten. Mit Auto-Scaling startet das System morgens zusätzliche Instanzen und fährt sie nachts wieder herunter.
Das Grundprinzip besteht aus drei Komponenten: einer Metrik, die den aktuellen Zustand misst, einem Schwellenwert, der den Zielkorridor definiert, und einer Steuerungslogik, die Instanzen hinzufügt oder entfernt.
Beispiel: Ein Chatbot-Dienst definiert als Metrik die durchschnittliche Antwortzeit. Der Schwellenwert liegt bei 500 Millisekunden. Sobald die gemessene Antwortzeit diesen Wert überschreitet, startet die Steuerungslogik eine weitere Instanz. Fällt die Antwortzeit unter 200 Millisekunden, wird eine Instanz entfernt.
Horizontales und vertikales Skalieren
Auto-Scaling unterscheidet zwei grundsätzliche Strategien. Beim horizontalen Skalieren (Scale-Out/Scale-In) verändert sich die Anzahl der laufenden Instanzen. Beim vertikalen Skalieren (Scale-Up/Scale-Down) verändert sich die Leistungsfähigkeit einzelner Instanzen, etwa durch Zuweisung zusätzlicher CPU-Kerne oder Arbeitsspeicher.
Beispiel: Ein Bilderkennungsdienst nutzt horizontales Skalieren. Bei steigender Anfragezahl startet das System zusätzliche Container mit identischer Konfiguration. Jeder Container verarbeitet unabhängig voneinander Anfragen. Dieses Muster eignet sich für zustandslose Dienste, bei denen jede Anfrage unabhängig von vorherigen Anfragen bearbeitet wird.
Beispiel: Ein Datenbank-Server lässt sich oft nicht horizontal skalieren, weil alle Anfragen denselben Datenbestand betreffen. Vertikales Skalieren weist dem Server dann mehr Arbeitsspeicher zu, damit er größere Datenmengen im Cache halten kann.
In der Praxis kombinieren viele Systeme beide Strategien. Die Anwendungsschicht skaliert horizontal, während die Datenschicht vertikal skaliert oder über Read-Replicas verteilt wird.
Fachliche Einordnung: Horizontales Skalieren setzt voraus, dass die Anwendung zustandslos arbeitet oder ihren Zustand externalisiert (etwa in Redis oder einer gemeinsamen Datenbank). Das ist eine architektonische Entscheidung, die vor dem Einsatz von Auto-Scaling getroffen werden muss. Containerisierung erleichtert horizontales Skalieren erheblich, weil jede Instanz aus einem identischen Container-Image entsteht.
Metriken und Schwellenwerte
Die Qualität eines Auto-Scaling-Systems hängt von der Wahl der richtigen Metriken ab. Eine falsch gewählte Metrik führt dazu, dass das System zu spät, zu früh oder gar nicht reagiert.
Häufig verwendete Metriken:
- CPU-Auslastung: Anteil genutzter Prozessorzeit an der verfügbaren Gesamtleistung
- Arbeitsspeicher-Belegung: Anteil des genutzten RAM
- Anfragen pro Sekunde (Requests per Second): Durchsatz auf Netzwerkebene
- Antwortzeit (Latency): Zeit zwischen Anfrage und Antwort
- Queue-Länge: Zahl der wartenden Aufträge in einer Warteschlange
Beispiel: Ein Dienst für Fine-Tuning von Sprachmodellen nutzt die Queue-Länge als Metrik. Jeder Trainingsauftrag dauert mehrere Stunden. Die CPU-Auslastung liegt während des Trainings immer bei nahezu 100 Prozent und ist deshalb kein nützlicher Indikator. Die Zahl der wartenden Aufträge hingegen zeigt präzise, ob zusätzliche Kapazität nötig ist.
Beispiel: Eine Echtzeit-Suchmaschine für Produktkataloge verwendet die Antwortzeit als primäre Metrik. Wenn die durchschnittliche Antwortzeit von 80 auf 300 Millisekunden steigt, signalisiert das eine Überlast, bevor die CPU-Auslastung sichtbar reagiert.
Auto-Scaling bei KI-Workloads
KI-Systeme stellen besondere Anforderungen an Auto-Scaling. Inferenz auf GPUs ist rechenintensiv, die Startzeiten von GPU-Instanzen liegen typischerweise bei 30 bis 120 Sekunden, und die Kosten pro Instanz sind deutlich höher als bei CPU-basierten Diensten.
Beispiel: Ein Sprachmodell-Dienst, der auf GPU-Instanzen läuft, benötigt nach dem Start einer neuen Instanz zunächst 45 Sekunden, um das Modell in den GPU-Speicher zu laden. Während dieser Aufwachphase kann die Instanz keine Anfragen bearbeiten. Das Auto-Scaling muss diese Verzögerung berücksichtigen und früher skalieren als bei CPU-Diensten, die in wenigen Sekunden bereit sind.
Predictive Scaling (vorausschauendes Skalieren) analysiert historische Lastmuster und startet Instanzen bereits vor dem erwarteten Lastanstieg. Reaktives Skalieren wartet hingegen auf das Eintreten eines Schwellenwertüberschritts.
Beispiel: Ein Unternehmen betreibt einen KI-Dienst für Bewerbungsanalyse. Die Zugriffsmuster zeigen regelmäßig Spitzen am Montagmorgen. Das Predictive Scaling startet die zusätzlichen GPU-Instanzen bereits am Montag um 7:30 Uhr, obwohl die Last erst um 9 Uhr ansteigt. Ohne diese Vorlaufzeit würden die ersten Anfragen auf zu wenige Instanzen treffen.
Cooldown-Perioden und Flapping
Ein häufiges Problem bei Auto-Scaling ist das sogenannte Flapping: Das System skaliert hoch, die Last sinkt durch die zusätzliche Kapazität, das System skaliert herunter, die Last steigt wieder, und der Zyklus wiederholt sich in kurzen Abständen. Jeder Skalierungsvorgang verursacht Kosten und kann den Dienst kurzzeitig destabilisieren.
Cooldown-Perioden verhindern dieses Verhalten. Nach einem Skalierungsvorgang wird für eine definierte Zeitspanne kein weiterer Vorgang ausgelöst, damit sich die Metriken stabilisieren können.
Beispiel: Ein Empfehlungssystem skaliert von 4 auf 8 Instanzen. Die Cooldown-Periode beträgt 300 Sekunden. Während dieser Zeit ignoriert das System alle Schwellenwertüberschreitungen nach unten, damit die neuen Instanzen ihren Betrieb aufnehmen und die Metriken ein stabiles Niveau erreichen können.
Beispiel: Ein Transformer-basierter Zusammenfassungsdienst erlebt nach einem Social-Media-Post kurzzeitig das Zehnfache der normalen Last. Ohne Cooldown würde das System innerhalb von Minuten mehrfach hoch- und herunterskalieren. Mit einer Cooldown-Periode von 600 Sekunden skaliert es einmal hoch und bleibt auf dem erhöhten Niveau, bis sich die Lage stabilisiert hat.
Kosten und Budgetgrenzen
Auto-Scaling optimiert nicht automatisch Kosten. Es optimiert Verfügbarkeit. Ohne explizite Obergrenzen kann ein Lastanstieg beliebig viele Instanzen starten und die Kosten sprunghaft erhöhen.
Alle gängigen Cloud-Plattformen bieten deshalb konfigurierbare Grenzen: eine minimale Instanzanzahl (damit der Dienst auch bei geringer Last verfügbar bleibt), eine maximale Instanzanzahl (damit die Kosten nicht unkontrolliert steigen) und Budget-Alarme, die bei Überschreitung eines Schwellenwerts warnen.
Beispiel: Ein Startup betreibt einen KI-Dienst zur Textgenerierung. Das monatliche Budget für GPU-Instanzen liegt bei 12.000 Euro. Das Auto-Scaling ist auf maximal 20 GPU-Instanzen begrenzt. Bei einer DDoS-Attacke oder einem viralen Traffic-Spike verhindert diese Obergrenze, dass die Kosten das Budget sprengen. Der Dienst wird in diesem Fall langsamer, bleibt aber kostentechnisch kontrollierbar.
Grenzen und häufige Fehlannahmen
Auto-Scaling löst keine architektonischen Probleme. Wenn eine Anwendung schlecht optimiert ist oder einen Engpass in der Datenbank hat, verschiebt Auto-Scaling den Engpass lediglich auf eine andere Ebene. Mehr Instanzen der Anwendungsschicht erhöhen dann die Last auf die Datenbank, die nicht mitskaliert.
Beispiel: Ein Dienst für semantische Suche nutzt ein einziges Datenbankcluster für alle Anfragen. Das Auto-Scaling startet bei hoher Last zusätzliche Such-Instanzen. Aber alle diese Instanzen greifen auf dieselbe Datenbank zu. Ab 12 Instanzen wird die Datenbank zum Flaschenhals, und zusätzliche Such-Instanzen verschlechtern die Gesamtleistung sogar, weil die Datenbank mit Verbindungen überlastet wird.
Weitere Grenzen:
- Kaltstartzeiten: GPU-Instanzen und Modell-Ladezeiten verhindern sofortige Reaktion auf Lastspitzen
- Zustandsbehaftete Dienste: Systeme mit persistentem Zustand (etwa laufende Trainingsaufträge) lassen sich nicht ohne Datenverlust herunterskalieren
- Lizenzkosten: Software mit nutzungsbasierter Lizenzierung kann durch Auto-Scaling unvorhergesehene Lizenzkosten erzeugen
- Netzwerk-Overhead: Jede neue Instanz erhöht den internen Netzwerkverkehr für Health-Checks, Service-Discovery und Lastenverteilung
Fachliche Einordnung: Auto-Scaling ist ein operatives Werkzeug, kein Ersatz für Kapazitätsplanung. Produktionssysteme kombinieren Auto-Scaling mit vorausschauender Kapazitätsplanung, Lastverteilungsstrategien und regulärer Architekturüberprüfung. Die alleinige Abhängigkeit von reaktivem Auto-Scaling kann bei plötzlichen, extremen Lastspitzen zu Ausfällen führen, weil die Skalierung nicht schnell genug nachkommt.