Begriff
Scalability (Skalierbarkeit)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Stell dir vor, du hast einen kleinen Limonadenstand an der Ecke, der gut läuft. Wenn plötzlich ein ganzes Festival nebenan aufgebaut wird, hast du ein Problem: Du hast nur zwei Hände und einen Krug. Deine Kunden müssen ewig warten und gehen eventually genervt weg.
Skalierbarkeit (oder "Scalability") in der IT bedeutet, dass eine Software oder ein IT-System in der Lage ist, mit plötzlich wachsendem Erfolg und Nutzerzahlen umzugehen, ohne abzustürzen oder extrem langsam zu werden.
Anstatt nur einen großen Krug und dich selbst (das wäre Vertical Scaling oder Scale-Up – also einfach einen größeren Eimer und Muskeln kaufen), stellst du zehn Freunde ein, die eigene kleine Stände aufmachen (Horizontal Scaling oder Scale-Out). So bedienst du alle Kunden in gleicher Zeit, egal ob 10 oder 10.000 kommen.
Ein skalierbares System muss sich der echten Last dynamisch anpassen. Entwickler sprechen meist von zwei Hauptansätzen:
1. Vertical Scaling (Scale Up)
Man nimmt denselben Server und packt einfach "mehr Power" rein. Mehr CPU, mehr RAM, schnellere SSDs.
- Vorteil: Man muss am Code der Anwendung nichts verändern. Es ist weiterhin nur ein einziger Computer.
- Nachteil: Es gibt ein physikalisches (und finanzielles) Limit. Irgendwann gibt es keinen RAM mehr, den man noch dazukaufen kann. Außerdem ist es ein "Single Point of Failure" (wenn der Server neustartet, ist die App offline).
2. Horizontal Scaling (Scale Out)
Anstatt einen Supercomputer zu bauen, nimmt man viele kleine, günstige Server und teilt die Arbeit auf sie auf.
- Vorteil: Theoretisch endlos skalierbar. Fällt ein Server aus, übernehmen die anderen (Ausfallsicherheit).
- Nachteil: Die Software muss von Grund auf dafür gebaut sein. Server müssen Zustand (wie Sessions oder Datenbanken) teilen können, ohne sich zu blockieren.
Damit Horizontal Scaling funktioniert, setzt man fast immer einen Load Balancer vor die Serverflotte, der entscheidet: "Nutzer A geht zu Server 1, Nutzer B zu Server 2".
Die Architektur für "Infinite Scale" auf Enterprise-Ebene erfordert Cloud-Native-Denkmuster und die Entkopplung von Zustand ("State").
Stateless Architecture (Zustandslosigkeit)
Der Schlüssel zu horizontaler Skalierung ist die Zustandslosigkeit der Application-Server. Ein Server darf niemals Daten lokal speichern, die für den nächsten Request desselben Nutzers wichtig sind.
- Falsch: Nutzer legt Artikel in den Warenkorb, Server A merkt sich das in seinem RAM. Wenn der Nutzer beim nächsten Klick auf Server B landet, ist der Warenkorb leer.
- Richtig: Server A speichert den Warenkorb in einer zentralen In-Memory-Datenbank (wie Redis). Server B kann ihn dort später abrufen.
Auto-Scaling-Gruppen
Cloud-Provider wie AWS, Google Cloud oder Kubernetes beherrschen "Auto-Scaling". Sie messen permanent Metriken (z. B. CPU-Zulast aller Server oder Anzahl der Warteschlangen-Nachrichten). Übersteigt die CPU im Schnitt 70%, wird automatisch ein neuer Container oder eine VM hochgefahren (das dauert nur Sekunden) und dem Load Balancer hinzugefügt. Fällt die Last abends wieder ab, werden Server gelöscht, um Kosten zu sparen.
Wenn Code und Compute skalieren, wird meistens die Datenbank zum Flaschenhals ("Bottleneck"). Relationale Datenbanken (wie PostgreSQL oder MySQL) lassen sich traditionell nur sehr schwer horizontal skalieren.
Skalierung auf Daten-Ebene
- Read-Replicas: Da die meisten Applikationen 90% der Zeit Daten lesen und nur 10% schreiben, erstellt man Kopien der Datenbank. Ein Master-Server nimmt alle "Schreib"-Vorgänge entgegen, synchronisiert sich dann asynchron mit 5 "Read-Replica"-Servern. Alle "Lese"-Anfragen (z.B. Profil anzeigen) werden auf die Kopien verteilt.
- Sharding / Partitioning: Die horizontale Fragmentierung von Daten. Anstatt eine riesige Kundentabelle zu haben, teilt man sie logisch auf. Alle Kunden mit Nachnamen A-M liegen auf Server 1, Kunden von N-Z auf Server 2. Die Anwendungslogik muss dann intelligent genug sein, den richtigen Server anzufragen.
- NoSQL & NewSQL: Moderne Konzepte wie Cassandra (Dynamo-Architektur) oder Google Spanner sind "by design" horizontal skalierbar. Sie ordnen Daten in Hash-Ringen oder über globale Cluster an und garantieren Konsistenz durch hochkomplexe Algorithmen (Paxos/Raft) oder sogar Atomuhren (TrueTime API bei Spanner).
Quick-Check
Was ist der Unterschied zwischen Scale-Up und Scale-Out?
Scale-Up erhöht die Leistung eines einzelnen Geräts (RAM/CPU hinzufügen). Scale-Out fügt der Architektur weitere Geräte (Cluster/Nodes) hinzu.Warum ist "Statelessness" wichtig für die Cloud-Ressourcen?
Wenn Applikationen "stateless" (zustandslos) sind, kann jeder beliebige Server eine Nutzeranfrage verarbeiten, was reibungsloses Horizontal Scaling und automatisches Hoch-/Herunterfahren von Instanzen ohne Datenverlust ermöglicht.Warum wird eine MySQL-Datenbank häufig zum Flaschenhals, wenn eine Website wächst?
Weil Standard-SQL-Datenbanken stark auf ACID-Konsistenz auf einem Server optimiert sind. Horizontales Skalieren von Schreibvorgängen ist technisch extrem komplex und verursacht "Locks" oder Synchronisationsprobleme.