Skalierung
Eine gemessene Kapazitätsgrenze verlangt eine gezielte Änderung an der Engpassressource.
- RessourceRessource: Kapazität wird an einem Engpass ergänzt.
- RichtungRichtung: Vertikale und horizontale Änderung unterscheiden sich.
- WirkungWirkung: End-to-end-Verhalten bestätigt den Zugewinn.
Einordnung
Warum das wichtig ist
Kapazität durch begründete Ressourcenänderungen anpassen.
Kapazität durch begründete Ressourcenänderungen anpassen.
Skalierung: Entscheidung prüfen
Das Shop-Beispiel nutzt die bestehende gemeinsame Datenbank und sieben Module. Jede ergänzte Dienst- oder Betriebsform ist eine hypothetische Erweiterung. Zum Kampagnenstart ergänzt das Betriebsteam Shop-Webinstanzen, nachdem ein Test CPU als Engpass zeigt. Die Bestellmodule bleiben innerhalb derselben Anwendung und nutzen weiterhin die gemeinsame Datenbank. Ein zweiter Test zeigt, dass deren Schreibkapazität früher erreicht wird als die Webkapazität. Das Team skaliert deshalb den Datenbankpfad gesondert und misst Antwortzeit, Queue-Länge und Kosten. Die angenommenen Lastwerte bleiben ausdrücklich Testannahmen.
So liest du das Bild
- Ressource Ressource
- Richtung Richtung
- Wirkung Wirkung
| Begriff | Bedeutung | Prüffrage |
|---|---|---|
| Ressource | Kapazität wird an einem Engpass ergänzt. | Welche Ressource wird nach der Webkapazität separat betrachtet? |
| Richtung | Vertikale und horizontale Änderung unterscheiden sich. | Welche Daten stützen eine Skalierungsänderung? |
| Wirkung | End-to-end-Verhalten bestätigt den Zugewinn. | Warum behebt eine zusätzliche Webinstanz den Datenbankengpass nicht zwingend? |
Nutzen & Grenzen
Hilft, wenn
- Kapazität durch begründete Ressourcenänderungen anpassen.
- Engpass messen, Kapazität zielgerichtet ändern und Wirkung erneut testen.
Grenzen
- Mehr Ressourcen können einen anderen Engpass oder höhere Kosten erzeugen.
- Horizontale und vertikale Skalierung ändern Kosten, Fehlerdomäne und Engpass jeweils anders.
In der Praxis
- Miss CPU, Datenbank-Schreibkapazität, Queue-Länge und Antwortzeit, bevor du Instanzen ergänzt; ordne jede Änderung einem beobachteten Engpass zu.
- Erhöhe zuerst nur die Webkapazität und wiederhole denselben Lasttest; prüfe, ob sich der Engpass zur gemeinsamen Datenbank verlagert und welche Module darunter leiden.
- Teste anschließend eine gezielte Datenbankmaßnahme getrennt und vergleiche Durchsatz, Latenz und Betriebskosten, während die sieben Module im modularen Monolithen bleiben.
Ausführliche Erklärung lesen
Skalierung verändert verfügbare Kapazität durch größere Ressourcen (vertikal) oder zusätzliche Instanzen (horizontal). Die Entscheidung betrifft Rechenleistung, Speicher, Parallelität und Datenhaltung und richtet sich nach dem tatsächlichen Engpass.
Zusätzliche Instanzen helfen nur, wenn Arbeit geteilt werden kann und gemeinsam genutzte Abhängigkeiten mithalten. Zustand, Startzeit, Koordination, Kosten und Rücknahme bestimmen, ob die Änderung den gewünschten Nutzen bringt.
Das Shop-Beispiel nutzt die bestehende gemeinsame Datenbank und sieben Module. Jede ergänzte Dienst- oder Betriebsform ist eine hypothetische Erweiterung. Zum Kampagnenstart ergänzt das Betriebsteam Shop-Webinstanzen, nachdem ein Test CPU als Engpass zeigt. Die Bestellmodule bleiben innerhalb derselben Anwendung und nutzen weiterhin die gemeinsame Datenbank. Ein zweiter Test zeigt, dass deren Schreibkapazität früher erreicht wird als die Webkapazität. Das Team skaliert deshalb den Datenbankpfad gesondert und misst Antwortzeit, Queue-Länge und Kosten. Die angenommenen Lastwerte bleiben ausdrücklich Testannahmen. backpressure und skalierbarkeit helfen, diese Entscheidung mit benachbarten Fragen zu vergleichen.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Welche Ressource wird nach der Webkapazität separat betrachtet?
Lösung mit Begründung ansehen
Die Datenbank als eigenständig gemessener Engpass.
AnwendenAuf eine neue Lage übertragen
Welche Daten stützen eine Skalierungsänderung?
Lösung mit Begründung ansehen
Engpassmessung sowie Kosten- und Wirkungsvergleich nach der Änderung.
BewertenEine Alternative abwägen
Warum behebt eine zusätzliche Webinstanz den Datenbankengpass nicht zwingend?
Lösung mit Begründung ansehen
Mehr Webkapazität kann die Datenbank stärker belasten, ohne ihren Durchsatz zu erhöhen.
Zehnmal mehr Bestellungen
Vergleiche Kapazität, Verteilung und Engpässe im gemeinsamen Lernbeispiel.
Skalierung am Shop ausprobierenVertiefen
Hier findest du Varianten und Verweise auf eigenständige Begriffe.
Vertikale Skalierung
Vertikale Skalierung gibt einer Instanz mehr CPU, Arbeitsspeicher oder I/O-Leistung und passt damit den Engpass innerhalb derselben Anwendung an. Sie ist oft einfach zu betreiben, bleibt aber durch Instanzgrenzen und einen einzelnen Ausfallbereich begrenzt.
Horizontale Skalierung
Horizontale Skalierung startet weitere Instanzen derselben Anwendung und verteilt Anfragen auf sie. Das setzt zustandsarme oder extern gespeicherte Sitzungen voraus; gemeinsame Datenbank- und Schreibengpässe wachsen dadurch nicht automatisch mit.
Automatische Skalierung
Autoscaling passt die Zahl oder Größe von Instanzen anhand gemessener Signale und definierter Richtlinien an. Es eignet sich für vorhersehbare Lastschwankungen, reagiert aber nur innerhalb von Startzeit, Obergrenzen, Aufwärmphase und verfügbarem Ressourcenbudget.
Weiterführende Bausteine
Quellen
- Auto Scaling concepts (öffnet in neuem Tab)AWS-Dokumentation zu Kapazitätsänderungen und Richtlinien.
- Scalability Quality Attribute (öffnet in neuem Tab)Trennt Qualitätsziel von konkreten Skalierungsmechaniken.
- Google SRE: Handling Overload (öffnet in neuem Tab)Behandelt Kapazität, Last und Überlastreaktionen.