Skalierbarkeit und Verfügbarkeit

In dieser Lerneinheit verstehst du die grundlegenden Konzepte der horizontalen und vertikalen Skalierung von IT-Systemen. Du lernst die konkreten Unterschiede zwischen dem Hinzufügen weiterer Maschinen (Scale Out) und der Aufrüstung bestehender Hardware (Scale Up) kennen. Diese Kenntnisse helfen dir dabei, die richtige Skalierungsstrategie für unterschiedliche Systemanforderungen auszuwählen und Verfügbarkeit sowie Performance von Systemen zu optimieren.

Einführung

Stell dir vor, ein Onlineshop bewirbt einen großen Sonderverkauf – aber sobald der Ansturm startet, bricht die Website zusammen. Kunden verlassen frustriert die Seite, Bestellungen gehen verloren und das Unternehmen verliert Umsatz sowie Vertrauen.

Überlasteter Server vs. skalierbare Architektur — Bildrechte: Ausbildung-in-der-IT.de (KI-unterstützt)

Woran liegt das? Und wie gelingt es großen Anbietern wie Amazon oder Netflix, selbst zu Spitzenzeiten stabil und verfügbar zu bleiben?

Genau darum geht es im nächsten Block: Du lernst, mit welchen Strategien und Techniken du IT-Systeme gezielt skalierbar und hochverfügbar machst, um solche Ausfälle zuverlässig zu verhindern.

Lernziele

Nach dieser Lerneinheit kannst du:

1. Die Unterschiede zwischen horizontalem, vertikalem und diagonalem Skalieren erklären und bewerten können.

2. Redundanz- und Failover-Mechanismen in IT-Systemen beschreiben und deren Bedeutung für Hochverfügbarkeit erläutern.

3. Die Grundprinzipien verteilter Systeme und der Microservices-Architektur darstellen.

4. Konsistenzmodelle (insbesondere Eventual Consistency) und das CAP-Theorem anwenden und deren Auswirkungen auf Systemdesign erklären.

Überleitung

Viele Systeme geraten bei steigendem Nutzeraufkommen schnell an ihre Grenzen oder fallen bei Hardware-Ausfällen komplett aus. Ohne passende Skalierungs- und Redundanzstrategien drohen Performance-Probleme und Datenverluste. Wie schaffst du es, dass ein Onlineshop auch am Black Friday stabil bleibt oder ein Cloud-Dienst trotz Serverausfall weiterläuft?

Horizontales Skalieren (Scale Out/In)

Horizontales Skalieren (“Scale Out/In”) bezeichnet das Erhöhen der Kapazität eines Systems durch das Hinzufügen oder Entfernen mehrerer Maschinen. Anstatt eine einzelne Maschine zu verstärken, werden zusätzliche Instanzen hinzugefügt, die parallel arbeiten. Diese Methode eignet sich besonders für Anwendungen, die für parallele Verarbeitung optimiert sind.

Praxisbeispiel:
Viele Webshops setzen Load Balancer ein, die eingehende Anfragen gleichmäßig auf mehrere Server verteilen. Bei hoher Last werden weitere Server hinzugeschaltet.

Horizontales Skalieren (Scale Out/In)

Vorteile	Beschreibung	Nachteile	Beschreibung
Flexible Skalierung	Neue Maschinen lassen sich dynamisch je nach Last hinzufügen oder entfernen.	Komplexeres Load Balancing	Verteilte Systeme benötigen oft zusätzliche Load Balancer (z. B. AWS ELB) und deren Verwaltung.
Hohe Ausfallsicherheit	Fällt eine Instanz aus, übernehmen die übrigen Maschinen die Aufgaben.	Komplexe Datenkonsistenz	Zustandsverteilung ist aufwändiger. Hier spielen Konsistenzmodelle (z. B. eventual consistency) und das CAP-Theorem eine Rolle.
Kosteneffizienz	Meist günstiger und einfacher, Standard-Hardware oder Cloud-Instanzen zu ergänzen.	Netzwerklatenz	Kommunikation zwischen Instanzen kann Latenzen verursachen und die Performance beeinflussen.

Vertikales Skalieren (Scale Up/Down)

Hier verbesserst du die Leistung, indem du eine einzelne Maschine aufrüstest – etwa mit mehr CPU, RAM oder schnellerem Speicher. Das ist technisch oft einfacher, aber begrenzt und birgt das Risiko eines sogenannten Single Point of Failure. Das bedeutet: Gibt es nur eine zentrale Maschine und sie fällt aus, funktioniert das gesamte System nicht mehr – es gibt keinen Ersatz, der übernehmen kann. Für kurzfristige Leistungssteigerungen oder bei älteren Systemen kann diese Strategie dennoch sinnvoll sein.

Praxisbeispiel:
Du stattest einen zentralen Datenbankserver mit zusätzlichem Arbeitsspeicher aus, damit er mehr Anfragen parallel verarbeiten kann.

Vertikales Skalieren (Scale Up/Down)

Vorteile	Beschreibung	Nachteile	Beschreibung
Einfache Verwaltung	Kein Koordinationsaufwand zwischen mehreren Maschinen.	Physische/wirtschaftliche Grenzen	Hardware-Upgrades sind limitiert und leistungsfähige Hardware oft sehr teuer.
Geringe Latenz	Keine Netzwerkkommunikation zwischen Servern notwendig.	Downtime-Risiko	Upgrades erfordern meist Wartungsfenster; Live-Skalierung ist selten möglich.
		Single Point of Failure	Ein Ausfall führt zum Systemstillstand.

Diagonales Skalieren

Eine Mischform: Zuerst wird vertikal aufgerüstet, bis keine wirtschaftlichen oder technischen Reserven mehr bestehen. Danach erfolgt ein Wechsel auf horizontale Skalierung. So lassen sich Investitionen und Komplexität schrittweise steuern.

Entscheidungskriterien für Skalierungsstrategien

• Anwendungsarchitektur: Nicht alle Anwendungen lassen sich einfach horizontal skalieren (z. B. monolithische Alt-Systeme).
• Kosten und Nutzen: Kurzfristige Kostenersparnisse durch vertikale Skalierung – langfristige Flexibilität durch horizontale Ansätze.
• Wachstumsperspektive: Wer schnelles Wachstum erwartet, plant von Anfang an horizontal skalierbare Architekturen.

Redundanz und Failover-Mechanismen

Redundanz bedeutet, kritische Systemteile mehrfach vorzuhalten. So stellst du sicher, dass beim Ausfall einer Komponente das System weiterläuft und keine Daten verloren gehen.

Wichtige Redundanzarten

• Datenredundanz: Wichtige Daten werden auf mehreren Servern (Replikation) gespeichert. Bei Ausfall bleibt der Zugriff erhalten.
• Komponentenredundanz: Hardware wie Server, Switches oder Router sind doppelt vorhanden, um Ausfälle abzufangen.
• Service-Redundanz: Dienste laufen parallel auf mehreren Maschinen (Active-Active für Lastverteilung oder Active-Passive als Standby).

Failover und Cluster

Failover bezeichnet das automatische Umschalten auf Ersatzsysteme. In einem Failover-Cluster überwachen sich mehrere Server gegenseitig (Heartbeat). Fällt ein Server aus, übernimmt ein anderer nahtlos dessen Aufgaben. Zusätzliche Mechanismen wie Quorum, Witness und Fencing verhindern Datenverluste und Split-Brain-Szenarien.

Praxisbeispiel:
Banken und Onlineshops betreiben kritische Dienste fast immer in geografisch getrennten Rechenzentren mit automatischem Failover, um Hochverfügbarkeit sicherzustellen.

⏳ Lädt Dataview-Inhalt...

Überleitung

Digitale Dienste wie Suchmaschinen, Streaming-Plattformen oder Onlineshops müssen heute Millionen Nutzer gleichzeitig bedienen. Das gelingt nur, wenn du Aufgaben und Daten auf viele unabhängige Systeme verteilst. Wie lässt sich das erreichen, ohne dass Nutzer Verzögerungen oder Fehler bemerken? In dieser Konzeptvermittlung lernst du die Grundlagen verteilter Systeme und die Prinzipien der Microservices-Architektur kennen.

Was ist ein Distributed System?

Ein Distributed System ist ein Zusammenschluss unabhängiger Computer, die nach außen als ein einziges System erscheinen. Ziel ist es, Aufgaben auf viele Maschinen zu verteilen, um Ausfallsicherheit, Skalierbarkeit und Flexibilität zu erreichen.

Typische Merkmale:

• Unabhängigkeit: Jeder Knoten arbeitet eigenständig.
• Transparenz: Nutzer merken nichts von der Verteilung im Hintergrund.
• Skalierbarkeit: Neue Knoten können bei Bedarf einfach ergänzt werden.
• Fehlertoleranz: Fällt ein Teil aus, übernehmen andere die Aufgaben.
• Nebenläufigkeit: Viele Aufgaben laufen gleichzeitig und unabhängig ab.
• Heterogenität: Unterschiedliche Hardware und Betriebssysteme sind möglich.

Beispiel:
Ein Content-Delivery-Netzwerk (CDN) stellt weltweit Mediendateien bereit. Nutzer erhalten Daten immer vom nächstgelegenen Server, auch wenn einzelne Server ausfallen.

Microservices-Architektur

Die Microservices-Architektur teilt eine Anwendung in kleine, spezialisierte Dienste auf. Jeder Microservice übernimmt eine bestimmte Aufgabe (z. B. Bestellabwicklung, Zahlung, Produktkatalog) und kann unabhängig entwickelt, betrieben und skaliert werden.

Wichtige Merkmale:

• Modularität: Jeder Dienst lässt sich einzeln entwickeln und austauschen.
• Technologieunabhängigkeit: Verschiedene Dienste können mit unterschiedlichen Tools oder Programmiersprachen umgesetzt werden.
• Resilienz: Der Ausfall eines Dienstes gefährdet nicht die gesamte Anwendung.
• Unabhängige Skalierung: Dienste können je nach Bedarf getrennt skaliert werden.
• Agilität: Änderungen an einem Dienst sind möglich, ohne die Gesamtanwendung zu gefährden.
• Dezentrale Datenhaltung: Jeder Microservice verwaltet seine eigenen Daten.

Beispiel:
Ein Onlineshop besteht aus eigenständigen Diensten für Produktverwaltung, Bestellung, Zahlung und Versand. Fällt die Zahlungsabwicklung aus, können andere Teile weiterarbeiten.

Verbindung: Microservices als Sonderfall verteilter Systeme

Microservices sind eine spezielle Form verteilter Systeme mit Fokus auf Geschäftsanwendungen. Sie setzen auf die Trennung in Geschäftsbereiche, Teamautonomie und Automatisierung. Im Unterschied zu klassischen verteilten Systemen steht bei Microservices die Organisation nach Geschäftslogik und die Flexibilität für Entwicklung und Betrieb im Vordergrund.

Eventual Consistency (Schlussendlich konsistent)

In vielen verteilten Systemen ist es nicht praktikabel, überall sofort identische Daten zu garantieren. Eventual Consistency bedeutet: Nach kurzer Zeit sind alle Datenkopien auf dem gleichen Stand, solange keine neuen Änderungen eintreffen.

Eigenschaften:

• Asynchrone Aktualisierung: Änderungen werden zeitverzögert übertragen.
• Anwendungsbezug: Geeignet für Social Media oder verteilte Cloud-Datenbanken, wo Updates nicht sofort sichtbar sein müssen.
• Hohe Skalierbarkeit: Viele Nutzer können gleichzeitig arbeiten.

Herausforderung: Tritt an mehreren Stellen zeitgleich eine Änderung auf, sind Mechanismen zur Konfliktlösung nötig. Nutzende müssen akzeptieren, dass neue Daten nicht immer überall sofort erscheinen.

CAP-Theorem: Grundprinzip verteilter Systeme

Das CAP-Theorem sagt: Ein verteiltes System kann immer nur zwei von drei Eigenschaften gleichzeitig sicherstellen:

1. Konsistenz (Consistency): Alle Nutzer sehen immer die gleichen aktuellen Daten.
2. Verfügbarkeit (Availability): Das System reagiert stets mit einer Antwort – auch wenn nicht immer alle aktuellen Daten sichtbar sind.
3. Partitionstoleranz (Partition Tolerance): Das System bleibt auch dann funktionsfähig, wenn Teile der Infrastruktur zeitweise nicht miteinander kommunizieren können.

Da Partitionstoleranz für verteilte Systeme unverzichtbar ist, musst du meist zwischen Konsistenz und Verfügbarkeit abwägen. Entweder bekommen alle Nutzer immer die gleichen Daten (aber manchmal keine Antwort), oder sie bekommen immer eine Antwort (auch wenn sie kurzzeitig veraltete Daten enthält).

Beispiel:
Relationale Datenbanken setzen auf Konsistenz und Partitionstoleranz, Key-Value-Stores wie Dynamo priorisieren Verfügbarkeit und Partitionstoleranz und nehmen dafür vorübergehend inkonsistente Daten in Kauf.

⏳ Lädt Dataview-Inhalt...

Zusammenfassung und Ausblick

Zusammenfassung:

In dieser Zusammenfassung findest du die wichtigsten Konzepte und Zusammenhänge der Themen Skalierung, Redundanz, verteilte Systeme und Microservices – fachlich präzise und kompakt, damit du gezielt prüfen kannst, was du jetzt erklären und anwenden solltest.

Skalierungsstrategien in Systemarchitekturen

• Horizontales Skalieren erhöht die Systemkapazität durch mehrere parallele Instanzen (z. B. zusätzliche Server). Das verbessert Ausfallsicherheit und Flexibilität. Voraussetzung sind Anwendungen, die für parallele Verarbeitung ausgelegt sind.
• Vertikales Skalieren verstärkt eine einzelne Maschine (mehr CPU/RAM), ist technisch oft einfacher, aber durch Kosten und einen Single Point of Failure begrenzt.
• Diagonales Skalieren kombiniert beide Ansätze: Zunächst wird aufgerüstet, danach bei Bedarf auf mehrere Instanzen verteilt.
• Bei der Wahl der Strategie entscheidest du je nach Systemarchitektur, Kosten-Nutzen-Verhältnis und Wachstumsperspektive.

Redundanz & Failover

• Redundanz bedeutet, kritische Komponenten und Daten mehrfach vorzuhalten. Ziel ist, auch bei Ausfällen handlungsfähig zu bleiben.
• Es gibt Daten-, Komponenten- und Service-Redundanz.
• Failover-Mechanismen schalten bei Störungen automatisch auf Ersatzsysteme um, oft in sogenannten Clustern (Serververbünden) organisiert. Techniken wie Heartbeat, Quorum und Fencing stellen sicher, dass kein Datenverlust oder Systemstillstand eintritt.

Verteilte Systeme & Microservices

• Ein Distributed System ist ein Zusammenschluss unabhängiger Rechner, die nach außen wie ein einziges System wirken. Ziele: Skalierbarkeit, Ausfallsicherheit, Flexibilität.
• Merkmale: Unabhängigkeit der Knoten, Transparenz für Nutzer, Skalierbarkeit, Fehlertoleranz, Nebenläufigkeit, Heterogenität.
• Die Microservices-Architektur teilt Anwendungen in kleine, spezialisierte Dienste, die jeweils eigene Aufgaben erfüllen, unabhängig deployt und betrieben werden können und oft eigene Daten verwalten. Sie ermöglichen flexible Skalierung, schnelle Änderungen und hohe Ausfallsicherheit.

Konsistenzmodelle und Systemkompromisse

• Eventual Consistency garantiert, dass Daten nach einer gewissen Zeit überall übereinstimmen, solange keine neuen Änderungen erfolgen. Das erhöht die Skalierbarkeit und Ausfallsicherheit, kann aber zu kurzfristig unterschiedlichen Datenständen führen.
• Das CAP-Theorem legt fest: In einem verteilten System können nie gleichzeitig Konsistenz, Verfügbarkeit und Partitionstoleranz garantiert werden. Da Partitionstoleranz unverzichtbar ist, musst du bei Design und Auswahl von Technologien zwischen Konsistenz und Verfügbarkeit abwägen.

Ausblick:

In der nächsten Lerneinheit lernst du, wie Load Balancer funktionieren, welche verschiedenen Load-Balancing-Methoden es gibt und wie sie gezielt zur Skalierung und Ausfallsicherheit in verteilten Architekturen eingesetzt werden.

---