Skalierbarkeit: horizontal vs. vertikal

Die wichtigste wirtschaftliche Eigenschaft der Cloud ist nicht „billig" – das ist sie meistens gar nicht – sondern elastisch. Anders als bei eigener Hardware kannst du deine Kapazität in Minuten verzehnfachen und nach dem Ansturm wieder zurückfahren. Aber „mehr Kapazität" kann zweierlei bedeuten: einen größeren Server oder mehr Server. Die beiden Wege heißen vertikal (Scale-Up) und horizontal (Scale-Out) und unterscheiden sich grundlegend in Architektur, Grenzen und Kosten. Welcher Weg der richtige ist, hängt von der Anwendung ab – und Anwendungen, die nicht für die Cloud entworfen wurden, können oft nur einen davon nutzen.

Die Analogien dazu sind alltäglich. Vertikal skalieren ist wie ein Auto durch ein leistungsfähigeres Modell ersetzen: aus dem 1,4-Liter-Motor wird ein 3-Liter-V6. Mehr Power, gleicher Sitzplatz – und irgendwann ist Schluss, weil es keine größeren Motoren mehr gibt. Horizontal skalieren ist wie statt eines Autos einen ganzen Fuhrpark einsetzen: mehrere Fahrzeuge fahren parallel, jedes liefert einen Teil. Das skaliert beliebig hoch – aber Voraussetzung ist, dass die Ladung sich aufteilen lässt. Genau diese Frage – kann man die Last aufteilen? – entscheidet darüber, welche Skalierungsart möglich ist.

1) Vertikal vs. Horizontal – der visuelle Vergleich

Klick zwischen den beiden Skalierungsarten und vergleiche, wie sich die Infrastruktur ändert. Beachte: bei vertikal bleibt es ein Server, der wächst – bei horizontal kommen neue dazu, mit einem Load-Balancer davor, der die Last verteilt:

2) Elastizität – das definierende Cloud-Merkmal

„Skalierbarkeit" allein ist nicht das Cloud-Versprechen. Auch ein klassisches Rechenzentrum kann skalieren: man kauft halt einen größeren Server oder stellt mehr Racks auf. Das dauert nur Wochen und kostet Geld, das nie wieder zurückkommt. Elastizität ist der besondere Cloud-Trick: die Möglichkeit, automatisch und in beide Richtungen zu skalieren. Wenn Last steigt, kommen Instanzen hinzu (Scale-Out); wenn Last fällt, werden sie wieder gestoppt (Scale-In) – und du zahlst nur, solange sie liefen.

Diese Elastizität ist der wirtschaftliche Kern der Cloud-Argumentation. Wer für Black-Friday-Peaks 50 Server bereithält, die das restliche Jahr nichts tun, verschwendet 95 % der Hardware-Investition. In der Cloud werden diese 50 Server für 48 Stunden gemietet und danach wieder freigegeben – die Hardware steht jemand anderem zur Verfügung, der dann zahlt. Das funktioniert nur, weil Cloud-Anbieter die Last vieler Kunden mischen können (Multi-Tenancy).

3) Auto-Scaling in Aktion

Auto-Scaling ist die Automatisierung der Elastizität: Regeln definieren, wann Instanzen gestartet oder gestoppt werden. Typische Regel: „Wenn CPU-Auslastung > 70 % über 5 Minuten, starte eine neue Instanz. Wenn < 30 % über 10 Minuten, stoppe eine." Spiel mit der Last-Kurve und beobachte, wie die Instanzen mitwachsen:

4) Stateless vs. Stateful – die entscheidende Architekturfrage

Horizontale Skalierung funktioniert nur, wenn die Anwendung stateless ist – jede Anfrage kann von jeder Instanz beantwortet werden, ohne dass die Instanz „weiß", was vorher passiert ist. Stateful Anwendungen halten dagegen Zustand im Arbeitsspeicher (Benutzersitzung, Warenkorb, Cache) – wenn dieser Zustand verloren geht, ist der Benutzer wütend.

Die Lösung: State auslagern. Statt im VM-RAM wird der Zustand in einen externen, gemeinsam genutzten Dienst gelegt:

• Sessions in Redis oder Memcached – ein zentraler In-Memory-Speicher. Jede Webserver-Instanz greift gleichberechtigt zu. Siehe Redis-Anwendungsfälle.
• Datei-Uploads in Object Storage – nicht ins lokale Filesystem der VM, sondern in S3, Azure Blob oder Google Cloud Storage. Beim VM-Neustart sind die Daten weg, im Object Storage bleiben sie.
• Sticky Sessions als Krücke – der Load-Balancer leitet einen Benutzer immer auf dieselbe Instanz. Funktioniert, verliert aber Vorteile beim Skalieren.

Diese Architektur-Umstellung ist oft der größte Aufwand bei einer Cloud-Migration: aus „klassischer Monolith mit Sitzungen im Server-RAM" wird „stateless Microservice mit Sessions in Redis und Dateien in S3". Erst dann skaliert die Anwendung horizontal.

5) Grenzen der Skalierung – das Amdahl'sche Gesetz

Auch horizontale Skalierung hat Grenzen, und sie folgen einer Formel, die jeder Informatiker mal gesehen haben sollte: dem Amdahl'schen Gesetz. Es besagt: Wenn ein Teil deiner Anwendung nicht parallelisierbar ist (z. B. ein zentraler Datenbank-Zugriff), dann begrenzt dieser Anteil den Gesamt-Speedup – egal, wie viele Server du hinzufügst.

Konkret: Sind 10 % deines Codes seriell (z. B. Schreibzugriffe auf eine zentrale Datenbank), dann erreichst du selbst mit unendlich vielen Servern maximal das 10-fache der Ein-Server-Performance. Sind 1 % seriell, sind es 100×. Diese Mathematik ist der Grund, warum in echten Cloud-Architekturen so viel Aufwand betrieben wird, um auch die Datenbank zu skalieren – durch Read-Replicas, Sharding, oder durch den Wechsel zu NoSQL-Datenbanken wie MongoDB oder DynamoDB, die horizontal skalieren.

6) Skalierungs-Trigger – wann genau wird hochgefahren?

Auto-Scaling braucht klare Auslöser. Die wichtigsten sind:

Eine wichtige Konfigurationsentscheidung: Cooldown-Zeit. Nach einer Skalierungsaktion wird für X Minuten gewartet, bevor die nächste passiert. Sonst kann das System „oszillieren" – Last hoch → Skalierung up → Last verteilt sich → Last niedrig → Skalierung down → Last konzentriert sich wieder → Skalierung up. Typische Cooldowns: 5–15 Minuten.

7) Welche Cloud-Services skalieren wie?

In der Praxis übernimmt der Cloud-Anbieter die Skalierung oft automatisch – wenn du den richtigen Service wählst. Die Trennlinie zwischen „du verwaltest Skalierung" und „der Anbieter macht es" ist eine der wichtigsten Cloud-Entscheidungen:

Die obersten Zeilen erfordern Konfiguration, die unteren sind „magisch": je weiter unten in der Tabelle, desto weniger musst du dich um Skalierung kümmern, desto teurer ist meist auch die Abrechnung pro Einheit. Das ist eine zentrale Architekturentscheidung – mehr dazu in der nächsten Lektion Shared Responsibility Model.

Zusammenfassung

Skalierbarkeit hat zwei Richtungen: vertikal (Scale-Up) = größerer Server, einfach umzusetzen, aber Hardware-Obergrenze und Downtime; horizontal (Scale-Out) = mehr Server hinter einem Load-Balancer, beliebig skalierbar, aber nur für stateless Anwendungen. Elastizität = automatische Skalierung in beide Richtungen, das definierende Cloud-Merkmal. Auto-Scaling startet/stoppt Instanzen anhand definierter Trigger (CPU, Memory, Request-Rate, Queue-Tiefe, Zeitplan) mit Cooldown-Zeit gegen Oszillation. State muss aus VMs ausgelagert werden (Redis, Object Storage), damit horizontale Skalierung funktioniert. Amdahl'sches Gesetz: serieller Anteil begrenzt den maximalen Speedup. Managed Services (Lambda, S3, RDS) skalieren oft automatisch – je weniger du verwaltest, desto teurer pro Einheit, aber deutlich einfacher.

Verwandte Lektionen: Cloud-Preismodelle · Load Balancing · Shared Responsibility Model · und mehrWeitere relevante LektionenCloud-GrundbegriffeCloud-ModelleClusteringRedis als CacheSchwellenwerte und AlertingContainer vs. VMIHK-Aufgaben Cloud