Skalierung im Cloud Hosting: Vertikal, horizontal, Load Balancer und Autoscaling
Wie Sie Cloud-Anwendungen skalieren: vertikale und horizontale Skalierung, Load Balancer, Autoscaling, Datenbank-Engpässe und die Kosten für Lastspitzen.
Skalierung bedeutet, die Kapazität einer Anwendung an die Last anzupassen. Es gibt zwei Grundrichtungen: vertikal (ein größerer Server mit mehr CPU und RAM) und horizontal (mehrere Server, auf die ein Load Balancer die Anfragen verteilt). Vertikale Skalierung ist einfach, stößt aber an Grenzen und braucht oft einen Neustart. Horizontale Skalierung ist flexibler und ausfallsicherer, verlangt aber, dass die Anwendung mit mehreren Instanzen umgehen kann. Autoscaling ergänzt beides: Instanzen werden nach Messwerten automatisch hinzugefügt oder entfernt. Für viele kleine Projekte genügt zunächst ein gut dimensionierter Server mit Caching.
Vertikale und horizontale Skalierung
| Merkmal | Vertikal (Scale-up) | Horizontal (Scale-out) |
|---|---|---|
| Prinzip | Größerer Server | Mehr Server |
| Umsetzung | Instanzgröße ändern | Load Balancer plus mehrere Instanzen |
| Ausfallsicherheit | Ein Server bleibt Einzelpunkt | Ausfall einer Instanz wird abgefangen |
| Anforderungen an die Anwendung | Gering | Zustandslose Anwendung, geteilter Speicher oder Datenbank |
| Grenzen | Größte verfügbare Instanz | Komplexität, Datenbank als Engpass |
| Kosten | Steigen oft überproportional | Steigen annähernd linear |
Load Balancer
Ein Load Balancer nimmt Anfragen entgegen und verteilt sie auf mehrere Server. Er prüft per Health Check, ob eine Instanz antwortet, und leitet bei Ausfall den Verkehr um. Typische Verfahren sind Round Robin (reihum), geringste Verbindungen oder gewichtete Verteilung. Relevante Funktionen:
- TLS-Terminierung: Der Load Balancer übernimmt die Verschlüsselung und das Zertifikat.
- Sitzungsbindung (Sticky Sessions): Ein Nutzer bleibt bei derselben Instanz. Besser ist, Sitzungsdaten zentral zu speichern.
- Health Checks: Definieren, wann eine Instanz als gesund gilt.
- Kosten: Load Balancer werden meist pro Stück und Monat plus Datenverkehr berechnet.
Zustandslose Anwendungen
Damit horizontale Skalierung funktioniert, sollten Anwendungsserver keine wichtigen Daten lokal halten. Sitzungen gehören in eine Datenbank oder einen Cache-Dienst, Uploads in Object Storage oder ein gemeinsames Dateisystem, Konfiguration in Umgebungsvariablen oder zentrale Verwaltung. Dann kann jede Instanz jederzeit ersetzt werden.
Autoscaling
Beim Autoscaling legen Sie Regeln fest, etwa „füge eine Instanz hinzu, wenn die durchschnittliche CPU-Auslastung zehn Minuten über 70 Prozent liegt, und entferne eine, wenn sie unter 30 Prozent fällt“. Wichtig sind:
- Minimum und Maximum der Instanzen, damit weder Ausfälle noch Kostenexplosionen drohen.
- Aufwärmzeit: Neue Instanzen brauchen Minuten, bis sie Last tragen. Reagieren Sie rechtzeitig.
- Abkühlzeit: Verhindert ständiges Hoch- und Herunterskalieren.
- Geeignete Messgrößen: CPU, Anfragen pro Sekunde, Warteschlangenlänge.
- Tests: Prüfen Sie das Verhalten mit einem Lasttest, bevor eine Lastspitze kommt.
Nicht alle Anbieter bieten Autoscaling als fertigen Dienst. Bei einfacheren Anbietern lässt es sich mit Skripten über die API realisieren.
Die Datenbank als Engpass
Anwendungsserver lassen sich leicht vervielfachen, die Datenbank dagegen nicht. Typische Maßnahmen:
- Abfragen und Indizes optimieren
- Caching häufiger Abfragen
- Lesereplikate für leseintensive Anwendungen
- Vertikale Skalierung der Datenbank
- Trennung nach Funktionen, bei sehr hoher Last Sharding (aufwendig)
Eine Managed-Datenbank erleichtert Replikation und Backups, kostet aber mehr. Prüfen Sie dazu die Kostenbausteine.
Rechenbeispiel zu Lastspitzen (illustrativ)
Ein Shop braucht normal zwei Server mit je 4 vCPU. An vier Tagen im Jahr (Aktionstage) steigt die Last auf das Dreifache. Beispielpreis 0,05 € je vCPU und Stunde (stundengenau abgerechnet).
- Normalbetrieb: 2 × 4 vCPU = 8 vCPU.
- Aktionstage: 6 Server, also 24 vCPU, für 4 Tage × 24 Stunden = 96 Stunden. Zusätzlich 16 vCPU × 96 Stunden × 0,05 € = 76,80 € für die Lastspitzen.
- Dauerhaft 24 vCPU über das Jahr: 24 × 8.760 Stunden × 0,05 € = 10.512 €.
- Nur Grundlast (8 vCPU): 8 × 8.760 × 0,05 = 3.504 €. Mit Spitzenzuschlag: 3.504 + 76,80 = 3.580,80 €.
Zeitweises Hochskalieren ist hier erheblich günstiger als dauerhaft vorgehaltene Kapazität. Die Grundlast könnten Sie zusätzlich per Reservierung vergünstigen. Voraussetzung ist, dass die Anwendung das Hochskalieren technisch erlaubt und Sie es testen.
Kubernetes und Container
Containerplattformen wie Kubernetes bieten horizontale Skalierung als Kernfunktion, bringen aber Komplexität mit. Für viele Teams ist ein einfacher Aufbau mit Load Balancer und Instanzgruppen ausreichend. Mehr im Guide zu Managed Kubernetes.
Typische Fehler
- Skalieren, bevor Engpässe analysiert wurden. Messen Sie zuerst: CPU, RAM, Datenbank, Netzwerk.
- Anwendungen mit lokalem Zustand horizontal skalieren.
- Autoscaling ohne Obergrenze und ohne Kostenwarnung.
- Health Checks, die zu streng oder zu lasch sind.
- Lasttests nur gegen eine Instanz, nicht gegen das Gesamtsystem.
- Einen einzelnen Load Balancer als Einzelpunkt zu übersehen; manche Anbieter bieten redundante Varianten.
Häufige Fragen
Wann brauche ich einen Load Balancer?
Wenn mehrere Server dieselbe Anwendung ausliefern sollen, für Ausfallsicherheit oder wenn Sie ohne Unterbrechung Updates einspielen wollen.
Ist Autoscaling für kleine Websites sinnvoll?
Meist nicht. Ein gut konfigurierter Server mit Caching reicht oft. Autoscaling lohnt sich bei deutlich schwankender Last.
Was kostet ein Load Balancer?
Das hängt vom Anbieter ab. Prüfen Sie die Preisliste und rechnen Sie den Load Balancer in die Gesamtkosten ein.
Quellen und weiterführende Informationen
- BSI — Hinweise zu Verfügbarkeit und Ausfallsicherheit
- Kubernetes-Dokumentation — offizielle Dokumentation zu Skalierung
