Infrastrukturskalierung: Horizontal vs. Vertikal, Lastausgleich und automatische Skalierung

Netflix bedient 260 Millionen Abonnenten in 190 Ländern durch dynamische Skalierung Tausender Instanzen basierend auf der Echtzeitnachfrage. Während die meisten Unternehmen nicht im Netflix-Maßstab arbeiten, sind die Skalierungsprinzipien dieselben: Passen Sie die Infrastrukturkapazität automatisch an die Verkehrsnachfrage an, ohne manuelles Eingreifen und ohne für ungenutzte Ressourcen zu bezahlen. Die Auswahl, die Sie zwischen horizontaler und vertikaler Skalierung, L4- und L7-Load-Balancern sowie reaktiver und prädiktiver automatischer Skalierung treffen, bestimmt, ob Ihre Plattform elegant wächst oder an eine Wand stößt.

Wichtige Erkenntnisse

• Beginnen Sie der Einfachheit halber vertikal (größere Maschinen) und wechseln Sie dann zu horizontal (mehr Maschinen), wenn Sie eine hohe Verfügbarkeit benötigen oder die Grenzen einzelner Maschinen überschreiten
• L7-Load-Balancer bieten inhaltsbasiertes Routing, das für moderne Anwendungen unerlässlich ist, während L4-Balancer Rohdurchsatz für eine einfache TCP-Verteilung bieten – Richtlinien zur automatischen Skalierung sollten metrikbasierte Trigger (CPU, Speicher) mit prädiktiver Skalierung für bekannte Verkehrsmuster kombinieren – Die Datenbankskalierung folgt anderen Regeln als die Anwendungsskalierung – Lesereplikate für leseintensive Lasten, Partitionierung für schreibintensive Lasten

---

Horizontale vs. vertikale Skalierung

Die grundlegende Skalierungsentscheidung besteht darin, bestehende Maschinen zu vergrößern (vertikal) oder weitere Maschinen hinzuzufügen (horizontal). Jeder Ansatz hat unterschiedliche Kompromisse.

Wann vertikal skaliert werden sollte

Die vertikale Skalierung ist aus mehreren Gründen die richtige erste Wahl. Es sind keine Anwendungsänderungen, keine Load-Balancer-Konfiguration und keine verteilte Statusverwaltung erforderlich. Insbesondere bei Datenbanken vermeidet die vertikale Skalierung die Komplexität von Sharding, Replikationsverzögerung und verteilten Transaktionen.

Vertikal skalieren, wenn:

• Ihre Anwendung ist noch nicht zustandslos (Sitzungen im Speicher gespeichert, Dateisystemschreibvorgänge)
• Sie betreiben eine einzelne Datenbank und haben die Verbindungs- oder CPU-Grenzwerte nicht erreicht
• Die nächste Instanzgröße ist günstiger als die Entwicklungszeit für die horizontale Umstellung
• Sie müssen sofort und ohne architektonische Änderungen skalieren

Beenden Sie die vertikale Skalierung, wenn:

• Sie benötigen eine hohe Verfügbarkeit (einzelne Instanz = Single Point of Failure)
• Die größte verfügbare Instanz reicht nicht aus
• Sie zahlen für Spitzenkapazität, die 90 % der Zeit ungenutzt bleibt
• Sie benötigen eine geografische Verteilung für die Latenz

Wann horizontal skaliert werden sollte

Für die horizontale Skalierung muss Ihre Anwendung zustandslos sein – jede Anfrage kann von jeder Instanz bearbeitet werden. Das bedeutet:

– Sitzungen werden in Redis oder in der Datenbank gespeichert, nicht im Arbeitsspeicher – Datei-Uploads werden im Objektspeicher (S3) gespeichert, nicht auf der lokalen Festplatte – Keine instanzspezifische Konfiguration oder lokales Caching ohne Replikation

• Sanfte Handhabung der Instanzbeendigung (Zustandsprüfungen, Verbindungsabbau)

Horizontal skalieren, wenn:

• Hohe Verfügbarkeit ist Voraussetzung (Ihr Unternehmen kann keine Ausfallzeiten von Minuten tolerieren)
• Der Datenverkehr ist variabel und die automatische Skalierung kann Kosten sparen, indem sie in ruhigen Zeiten herunterskaliert – Sie müssen eine Bereitstellung ohne Ausfallzeiten durchführen (rollende Bereitstellungen über Instanzen hinweg).
• Die Leistungsanforderungen übersteigen die Kapazität einer einzelnen Maschine

---

Tiefer Einblick in die Lastverteilung

Ein Load Balancer verteilt den eingehenden Datenverkehr auf mehrere Backend-Server. Der Typ des Load Balancers bestimmt, welche Routing-Entscheidungen möglich sind.

L4 (Transportschicht) Lastausgleich

L4-Load-Balancer arbeiten auf TCP/UDP-Ebene. Sie leiten Verbindungen basierend auf IP-Adresse und Port weiter, ohne den Paketinhalt zu überprüfen. Sie sind schnell, einfach und verarbeiten jedes TCP-basierte Protokoll.

Am besten geeignet für: Raw-TCP-Verteilung, Datenbankverbindungs-Proxying (PgBouncer), Nicht-HTTP-Protokolle, extrem hohe Durchsatzanforderungen

Einschränkungen: Es können keine Routing-Entscheidungen basierend auf URL-Pfad, Headern oder Cookies getroffen werden. SSL kann nicht beendet werden (muss auf Backends durchgeführt werden).

L7 (Anwendungsschicht) Lastenausgleich

L7-Load-Balancer arbeiten auf HTTP-Ebene. Sie prüfen Anforderungsheader, URLs, Cookies und sogar Anforderungstexte, um Routing-Entscheidungen zu treffen. Sie kümmern sich um die SSL-Terminierung und -Komprimierung und können Anfragen und Antworten ändern.

Am besten geeignet für: Webanwendungen, API-Gateways, inhaltsbasiertes Routing, SSL-Terminierung, A/B-Tests, Canary-Bereitstellungen

Lastausgleichsalgorithmen

Gesundheitschecks und würdevolle Degradierung

Gesundheitsprüfungen bestimmen, ob ein Backend-Server Datenverkehr empfangen soll. Konfigurieren Sie sie sorgfältig:

• Flache Integritätsprüfung – eine einfache TCP-Verbindungsprüfung oder HTTP 200 auf einem dedizierten Endpunkt. Erfasst Serverabstürze, jedoch keine Fehler auf Anwendungsebene.
• Tiefe Gesundheitsprüfung – überprüft die Datenbankkonnektivität, die Redis-Verfügbarkeit und die Erreichbarkeit externer Dienste. Erkennt mehr Probleme, riskiert jedoch falsch-negative Ergebnisse, wenn eine nicht kritische Abhängigkeit ausgefallen ist.
• Schonfrist – neue Instanzen benötigen Zeit zum Aufwärmen (JIT-Kompilierung, Cache-Auffüllung). Legen Sie eine Startfrist fest, bevor der Load Balancer den vollständigen Datenverkehr sendet.
• Draining – Wenn Sie eine Instanz entfernen, wird das Senden neuer Anfragen gestoppt, aber die Fertigstellung bestehender Anfragen wird ermöglicht (Verbindungsdrainage). Normalerweise 30–60 Sekunden.

---

Richtlinien zur automatischen Skalierung

Die automatische Skalierung passt die Anzahl der Instanzen je nach Bedarf an und passt die Kapazität ohne manuelle Eingriffe an den Datenverkehr an.

Metrikbasierte Skalierung

Der gebräuchlichste Ansatz löst Skalierungsaktionen aus, wenn eine Metrik einen Schwellenwert überschreitet.

Prädiktive Skalierung

Wenn Ihr Datenverkehr vorhersehbaren Mustern folgt (Tagesspitzen, wöchentliche Zyklen, saisonale Ereignisse), stellt die vorausschauende Skalierung Kapazität bereit, bevor der Datenverkehr eintrifft. AWS Auto Scaling unterstützt eine prädiktive Skalierung, die aus historischen Mustern lernt und proaktiv skaliert.

Kombinieren Sie prädiktive und reaktive: Verwenden Sie prädiktive Skalierung für bekannte Muster (morgendlicher Verkehrsanstieg, Black Friday-Vorabbereitstellung) und reaktive Skalierung für unerwartete Spitzen.

Best Practices für die Skalierung

1. Schnelles Skalieren, langsames Skalieren – Instanzen aggressiv hinzufügen (1–2 Minuten Abklingzeit), aber nach und nach entfernen (10–15 Minuten Abklingzeit), um ein Flattern zu vermeiden
2. Verwenden Sie mehrere Metriken – skalieren Sie anhand der CPU ODER des Arbeitsspeichers ODER der Anzahl der Anfragen, indem Sie die erste Metrik verwenden, die auslöst
3. Mindest- und Höchstgrenzen festlegen – Verhindern Sie eine Skalierung auf Null (keine Verfügbarkeit) oder eine Skalierung auf unbestimmte Zeit (Kostenexplosion)
4. Testen Sie die Skalierung während Lasttests – stellen Sie sicher, dass die automatische Skalierung korrekt ausgelöst wird und neue Instanzen den Datenverkehr innerhalb des erwarteten Zeitrahmens bereitstellen
5. Skalierungsereignisse überwachen – Warnung bei häufiger Skalierung, um Konfigurationsprobleme oder zugrunde liegende Leistungsprobleme zu erkennen

---

Strategien zur Datenbankskalierung

Datenbanken lassen sich horizontal nicht auf die gleiche Weise skalieren wie Anwendungsserver. Schreibvorgänge erfordern einen Konsens und eine starke Konsistenz schränkt die Verteilungsmöglichkeiten ein.

Replikate lesen

Lesereplikate kopieren Daten aus der Primärdatenbank und bedienen Leseabfragen. Sie skalieren den Lesedurchsatz linear, tragen jedoch nicht zum Schreibdurchsatz bei.

Überlegungen zur Implementierung:

• Replikationsverzögerung – Replikate sind schließlich konsistent. Bei Abfragen unmittelbar nach einem Schreibvorgang wird die Änderung möglicherweise nicht angezeigt. Verwenden Sie den Primärserver für Lese-nach-Schreibvorgänge.
• Verbindungsrouting – Ihre Anwendung benötigt Logik, um Lesevorgänge an Replikate und Schreibvorgänge an den Primärserver weiterzuleiten. ORMs und Verbindungs-Proxys (ProxySQL, PgBouncer) können dies automatisieren.
• Failover – wenn die primäre Instanz ausfällt, kann ein Replikat heraufgestuft werden. Automatisiertes Failover (AWS RDS Multi-AZ, AWS Aurora) reduziert die Ausfallzeit auf Sekunden.

Tabellenpartitionierung

Bei schreibintensiven Workloads für große Tabellen unterteilt die Partitionierung eine Tabelle in kleinere physische Blöcke und behält dabei eine einzige logische Schnittstelle bei. Ausführliche Partitionierungsstrategien finden Sie in unserem Leitfaden zur Datenbankoptimierung.

Verbindungspooling

Datenbankverbindungen sind teuer in der Erstellung und in der Anzahl begrenzt. Verbindungspooler wie PgBouncer bündeln Verbindungen von vielen Anwendungsinstanzen in einer kleineren Anzahl von Datenbankverbindungen.

Ohne Pooling: 20 Anwendungsinstanzen x jeweils 20 Verbindungen = 400 Datenbankverbindungen (überschreitet wahrscheinlich die PostgreSQL-Grenzwerte)

Mit PgBouncer: 20 Anwendungsinstanzen stellen eine Verbindung zu PgBouncer her, das 50–100 Verbindungen zu PostgreSQL unterhält und Anfragen effizient multiplext.

---

Microservices-Zerlegung

Wenn ein Monolith zu groß wird, als dass ein einzelnes Team ihn effizient entwickeln und bereitstellen könnte, ermöglicht die Zerlegung von Microservices die unabhängige Skalierung verschiedener Komponenten.

Wann man sich zersetzen sollte

Beginnen Sie nicht mit Microservices. Beginnen Sie mit einem gut strukturierten Monolithen und zerlegen Sie ihn, wenn:

– Unterschiedliche Komponenten haben sehr unterschiedliche Skalierungsanforderungen (für die Suche sind 20 Instanzen erforderlich, für den Checkout sind 5 Instanzen erforderlich). – Verschiedene Teams müssen unabhängig voneinander bereitstellen, ohne Release-Zeitpläne zu koordinieren – Eine bestimmte Komponente benötigt einen anderen Technologie-Stack (maschinelles Lernen in Python, API in Node.js) – Die Bereitstellungszeit des Monolithen überschreitet aufgrund der Codebasisgröße 30 Minuten

Was zuerst extrahiert werden soll

---

Häufig gestellte Fragen

Woher weiß ich, wann ich skalieren muss?

Überwachen Sie vier wichtige Kennzahlen: CPU-Auslastung (konstant über 70 %), Speichernutzung (über 80 %), Antwortzeit P95 (über Ihrem SLO) und Fehlerrate (über 0,1 %). Wenn eine Metrik dauerhaft ihren Schwellenwert überschreitet, müssen Sie skalieren. Proaktive Überwachung mit Alarmierung erkennt diese Trends, bevor Benutzer sie bemerken. Sehen Sie sich unseren Überwachungsleitfaden an.

Ist automatische Skalierung oder Vorabbereitstellung kostengünstiger?

Die automatische Skalierung ist bei unvorhersehbarem Datenverkehr kostengünstiger, da Sie nur dann für die Kapazität zahlen, wenn Sie sie benötigen. Die Vorabbereitstellung ist bei vorhersehbaren Spitzen (Black Friday, tägliche Stoßzeiten) besser, da die automatische Skalierung 3–10 Minuten dauert, um Kapazität hinzuzufügen. Der kostengünstigste Ansatz kombiniert beides: Vorabbereitstellung für erwartete Spitzen, automatische Skalierung für unerwartete Spitzen und Nutzung reservierter Instanzen für Ihre Basiskapazität. Sehen Sie sich unseren Leitfaden zur Cloud-Kostenoptimierung an.

Sollte ich Container (Docker/Kubernetes) oder herkömmliche VMs verwenden?

Container starten schneller (Sekunden statt Minuten), nutzen Ressourcen effizienter (höhere Dichte pro Host) und bieten konsistente Umgebungen über Entwicklung und Produktion hinweg. Kubernetes fügt Orchestrierung (automatische Skalierung, Selbstheilung, rollierende Bereitstellungen) hinzu, bringt jedoch eine erhebliche betriebliche Komplexität mit sich. Beginnen Sie mit verwalteten Containerdiensten (AWS ECS, Google Cloud Run), bevor Sie Kubernetes in Betracht ziehen.

Wie gehe ich mit einem Datenbank-Failover ohne Datenverlust um?

Verwenden Sie die synchrone Replikation für ein Failover ohne Datenverlust – der Primärserver bestätigt einen Schreibvorgang erst, wenn das Replikat ihn bestätigt. Dadurch erhöht sich die Schreiblatenz (normalerweise 1–5 ms innerhalb derselben Region), garantiert aber keinen Datenverlust während des Failovers. AWS RDS Multi-AZ und Aurora bieten verwaltete synchrone Replikation mit automatischem Failover.

---

Was kommt als nächstes?

Bewerten Sie Ihre aktuelle Infrastruktur anhand Ihrer Wachstumsprognosen. Wenn Sie einen einzelnen Server betreiben, stellen Sie sicher, dass Ihre Anwendung zustandslos und für die horizontale Skalierung bereit ist. Wenn Sie bereits mehrere Instanzen ausführen, optimieren Sie Ihre Load-Balancer-Konfiguration und implementieren Sie Richtlinien zur automatischen Skalierung.

Die vollständige Performance-Engineering-Perspektive finden Sie in unserem Säulenleitfaden zur Skalierung Ihrer Geschäftsplattform. Um die Kosten bei der Skalierung zu optimieren, lesen Sie unseren Leitfaden zur Cloud-Kostenoptimierung.

ECOSIRE entwirft und implementiert eine skalierbare Infrastruktur für Geschäftsplattformen auf AWS und Multi-Cloud-Umgebungen. Kontaktieren Sie unser DevOps-Team für eine Bewertung der Infrastrukturskalierung.

---

Veröffentlicht von ECOSIRE – Unterstützung von Unternehmen bei der Skalierung mit KI-gestützten Lösungen in Odoo ERP, Shopify eCommerce und OpenClaw AI.