Skalierungsstrategien: vertikal, horizontal und der Scale Cube

Was Skalieren praktisch bedeutet

Abschnitt 2.4 hat Skalierbarkeit als die Fähigkeit definiert, durch zusätzliche Ressourcen mehr Last zu bewältigen, und mit dem Amdahlschen Gesetz und dem Universal Scalability Law gezeigt, warum mehr Ressourcen nicht immer mehr Kapazität bringen. In diesem Abschnitt geht es um die praktischen Entscheidungen: welche Ressourcen hinzukommen, wo, wann und wie automatisch. Der Ausgangspunkt ist immer dieselbe Frage: Was ist der Lastparameter, und welche Ressource geht zuerst aus? Die Bestell-API einer Essenslieferplattform ist zur Mittagszeit durch die Anfragen pro Sekunde begrenzt, ihr Dispositionsservice durch die Zahl aktiver Kuriere, deren Positionen alle paar Sekunden abgeglichen werden müssen, ihre Datenbank durch Schreibtransaktionen pro Sekunde und durch Verbindungen. Jede braucht eine andere Antwort.

Ein System zu skalieren heißt eigentlich, seinen aktuellen Engpass zu skalieren und dann den nächsten zu finden. Die Webschicht eines Systems zu verdoppeln, dessen Datenbank zu 95 % ausgelastet ist, bringt nichts außer einer höheren Rechnung und einer Datenbank, die jetzt noch stärker belastet wird. Deshalb beginnt jede Skalierungsentscheidung mit Messung: Auslastung und Sättigung jeder Ressource (die USE-Methode von Brendan Gregg, behandelt in Observability) und ein Lasttest, der zeigt, wo die Latenz zu steigen beginnt (Kapazitätsplanung und Performancetests).

Vertikale Skalierung: ein größerer Rechner

Vertikale Skalierung (Scale-up) bedeutet, dem vorhandenen Rechner mehr CPU-Kerne, mehr Arbeitsspeicher, schnellere Festplatten oder ein schnelleres Netzwerk zu geben. Ihr großer Vorzug: An der Software ändert sich nichts. Eine einzelne relationale Datenbank auf einem größeren Server behält ihre Transaktionen, ihre Joins und ihre einfache Konsistenz; eine Anwendung behält ihre In-Memory-Caches und ihre lokalen Dateien. In der Cloud ist eine Größenänderung ein API-Aufruf mit anschließendem Neustart. Die größten virtuellen Maschinen in der Cloud bieten heute Hunderte virtueller CPUs und Terabytes an Arbeitsspeicher, weit mehr, als die meisten Geschäftssysteme je brauchen werden, und einige sehr stark besuchte Websites haben öffentlich beschrieben, wie sie enormen Traffic mit wenigen leistungsstarken Datenbankservern bedienen.

Die Grenzen sind allerdings real. Es gibt einen größten Rechner, und der Preis pro Kapazitätseinheit steigt im oberen Bereich steil an. Ein Rechner ist eine Fehlerdomäne: Fällt er aus oder wird er für eine Größenänderung oder ein Patch neu gestartet, steht alles darauf still; Scale-up allein tut also nichts für die Verfügbarkeit. Software kann einen größeren Rechner oft nicht voll nutzen: Ein Single-Thread-Prozess, eine globale Sperre oder eine Hot Row in der Datenbank begrenzt den Geschwindigkeitsgewinn genau so, wie das Amdahlsche Gesetz es vorhersagt. Und Kapazität kommt in großen, langsamen Stufen, sodass Sie rund um die Uhr für die Spitze bezahlen. Trotzdem ist vertikale Skalierung weit häufiger der richtige erste Schritt, als die Mode vermuten lässt, besonders bei Datenbanken, wo Scale-out viel Entwurfsaufwand kostet.

Horizontale Skalierung: mehr Rechner

Horizontale Skalierung (Scale-out) bedeutet, mehr Instanzen zu betreiben und die Arbeit auf sie zu verteilen, meist mit einem Load Balancer davor. Sie reicht viel weiter, in kleinen und günstigen Schritten, und dieselbe Redundanz, die Kapazität schafft, toleriert auch Ausfälle: Bei acht Instanzen kostet der Verlust einer Instanz ein Achtel der Kapazität statt der gesamten. Cloud-Plattformen machen das Hinzufügen einer Instanz zu einer Sache von Sekunden oder Minuten; darauf beruht das Autoscaling.

Der Preis ist, dass die Software dafür entworfen sein muss. Jede Instanz muss jede Anfrage bearbeiten können; Instanzen dürfen also nichts behalten, wovon eine spätere Anfrage abhängt (der nächste Abschnitt). Die Arbeit muss teilbar sein: Ein Job, der eine globale Sperre braucht, läuft auf zehn Rechnern nicht schneller. Die Daten müssen von jeder Instanz aus erreichbar sein, was den Druck auf die gemeinsame Datenschicht verlagert. Und das System wird verteilt, mit den Teilausfällen, Timeouts und Wiederholungen, die Abschnitt 6.1 beschreibt. Die meisten realen Systeme kombinieren beides: Zustandslose Anwendungsschichten skalieren horizontal, während Datenbanken so lange vertikal skalieren, wie es vernünftig möglich ist, und dann mit Replikaten und Partitionen horizontal.

Der Scale Cube: drei verschiedene Arten des Scale-out

Martin Abbott und Michael Fisher, die die Technologie bei eBay und PayPal leiteten, beschreiben Scale-out mit dem Scale Cube in The Art of Scalability (erste Auflage 2009, zweite Auflage 2015). Er unterscheidet drei unabhängige Arten, ein System aufzuteilen, jede als eine Achse eines Würfels gezeichnet, dessen Ursprung eine einzelne Instanz ist, die alles erledigt.

Die X-Achse ist horizontale Vervielfältigung, also Klonen: Betreiben Sie N identische Kopien der ganzen Anwendung oder des Service und verteilen Sie die Anfragen auf sie. Sie ist die einfachste und günstigste Achse und eignet sich gut für zustandslose Anfrageverarbeitung und Lesetraffic. Für die Datenmenge oder das Schreibvolumen bringt sie nichts, weil jeder Klon weiterhin mit denselben Daten arbeitet, und ebenso wenig für die Größe der Codebasis oder die Zahl der Teams, die daran arbeiten.

Die Y-Achse teilt das System nach Funktion auf: verschiedene Services für Speisekarten, Bestellungen, Disposition und Zahlungen, die jeweils nur den Code und die Daten für ihre Fähigkeit ausführen. Jeder Service kann dann getrennt skalieren, ausfallen und deployt werden, und jeder ist kleiner und leichter zu verstehen. Das ist die Achse hinter Microservices (Abschnitt 6.3), mit all ihren Kosten. Die Z-Achse teilt nach Daten auf: Jede Kopie führt denselben Code aus, ist aber nur für einen Ausschnitt der Kunden, Mandanten, Regionen oder Datensätze zuständig, gewählt über einen Schlüssel wie Stadt oder Kundenkennung. Datenbank-Sharding ist die Z-Achse, angewandt auf die Speicherung (Abschnitt 7.4); eine zellbasierte Architektur wendet sie auf ganze Stacks an, sodass ein Fehler oder ein fehlerhaftes Deployment in einer Zelle nur die Kunden dieser Zelle trifft.

Die Achsen lassen sich kombinieren. Der Bestellservice der Plattform (eine Aufteilung auf der Y-Achse) läuft als viele Klone (X) in jeder regionalen Zelle (Z). Der praktische Rat von Abbott und Fisher lautet, die günstigste Achse zu wählen, die das tatsächliche Problem löst: X für das Anfragevolumen, Y, wenn Teile des Systems wirklich unterschiedliche Anforderungen an Skalierung, Ausfallverhalten oder Teams haben, und Z, wenn ein Datenbestand oder ein Blast Radius zu groß geworden ist. Wer Z wählt, weil es beeindruckend klingt, holt sich Routing, Rebalancing und partitionsübergreifende Abfragen lange bevor sie nötig sind.

Zustandslosigkeit: die Voraussetzung für das Klonen

Skalierung auf der X-Achse funktioniert nur, wenn jeder Klon jede Anfrage bedienen kann. Ein zustandsloser Service behält zwischen Anfragen nichts in seinem eigenen Arbeitsspeicher oder auf seiner eigenen Festplatte; alles, was eine spätere Anfrage braucht, liegt in einem gemeinsamen Speicher oder reist mit der Anfrage mit. Der Zustand, der sich typischerweise in einer Instanz versteckt, ist leicht aufzuzählen, sobald man hinsieht: im Arbeitsspeicher gehaltene Nutzer-Sessions, hochgeladene Dateien auf der lokalen Festplatte, In-Memory-Caches, die als maßgebliche Quelle behandelt werden, geplante Jobs, die auf genau einem Rechner laufen müssen, prozessinterne Sperren, die eine gemeinsame Ressource schützen, und Zähler für Rate Limits.

Für jeden gibt es ein Standardmittel: Sessions wandern in einen gemeinsamen Speicher oder in ein signiertes Token (Abschnitt 9.2); Dateien wandern in einen Object Storage; Caches werden zu einer Performanceoptimierung, die jederzeit verloren gehen darf, oder wandern in einen gemeinsamen Cache (Abschnitt 7.6); geplante Jobs nutzen einen Scheduler mit Leader Election oder eine Queue; Sperren wandern in die Datenbank oder einen Koordinationsdienst; Rate-Limit-Zähler wandern in einen gemeinsamen Speicher. Die Regel der Twelve-Factor App, dass Prozesse zustandslos sind und nichts teilen (Abschnitt 10.3), ist genau dieser Gedanke. Zustandslosigkeit lässt sich günstig von Anfang an einplanen und nur teuer nachrüsten, weil Zustand an vielen kleinen Stellen in den Code sickert.

Autoscaling: reaktiv, zeitgesteuert und prädiktiv

Autoscaling schließt einen Regelkreis: Last messen, mit einem Zielwert vergleichen, die Zahl der Instanzen ändern. Reaktives Autoscaling tut das fortlaufend anhand einer Metrik. Die übliche Form ist Target Tracking: die durchschnittliche CPU bei 60 % halten oder die laufenden Anfragen pro Instanz bei 30. Der Kubernetes Horizontal Pod Autoscaler berechnet desired = ceil(current replicas × current metric ÷ target): Aus sechs Pods mit durchschnittlich 45 laufenden Anfragen bei einem Zielwert von 30 werden ceil(6 × 45 ÷ 30) = 9. Standardmäßig wertet er alle 15 Sekunden neu aus und ignoriert Abweichungen von weniger als 10 % vom Zielwert.

Zeitgesteuertes Autoscaling ändert die Kapazität zu bekannten Zeiten: das Minimum an jedem Werktag um 11:15 Uhr vor der Mittagsspitze auf 18 Instanzen anheben und um 14:00 Uhr wieder senken. Das ist grob und bei vorhersehbaren Mustern sehr wirksam, und es ist der einzige Weg, Kapazität vor einer sprunghaften Änderung bereitzuhaben, etwa vor einem Ticket-Vorverkauf um Punkt 10:00 Uhr. Prädiktives Autoscaling, das die großen Cloud-Anbieter anbieten, prognostiziert die Last aus der Historie (Tages- und Wochenzyklen) und skaliert ihr voraus, mit reaktiver Skalierung als Sicherheitsnetz für Überraschungen.

Die entscheidende Eigenschaft jedes reaktiven Verfahrens ist die Verzögerung. Metriken werden über Dutzende Sekunden gesammelt und gemittelt; der Autoscaler handelt bei seiner nächsten Auswertung; eine neue virtuelle Maschine braucht eine Minute oder länger zum Booten, ein Container-Image muss geladen werden, ein JVM- oder Python-Service muss starten, seine Caches und Connection Pools aufwärmen und seine Readiness-Prüfung bestehen, bevor der Load Balancer ihm Traffic schickt. In einem Cluster müssen womöglich erst die Knoten selbst von einem zweiten, langsameren Autoscaler hinzugefügt werden. Vom Moment, in dem die Last steigt, bis zu dem Moment, in dem neue Kapazität nützt, vergehen üblicherweise zwei bis zehn Minuten. Reaktives Autoscaling bewältigt daher allmähliche Änderungen; plötzliche Änderungen müssen durch Kapazitätsreserve, durch Queues (Abschnitt 9.3) oder durch im Voraus eingeplante Kapazität aufgefangen werden.

Anhand welcher Metrik skalieren und warum die CPU oft falsch ist

Die CPU-Auslastung ist auf den meisten Plattformen das Standardsignal, weil sie immer verfügbar ist. Das richtige Signal ist sie nur, wenn der Service CPU-gebunden ist: Bildskalierung, Verschlüsselung, aufwendige Serialisierung. Die meisten Geschäftsservices sind es nicht. Eine Bestell-API verbringt den größten Teil jeder Anfrage mit Warten auf die Datenbank, den Zahlungsdienstleister und andere Services; ihre CPU liegt womöglich bei 25 %, während jeder Worker-Thread mit Warten beschäftigt ist und neue Anfragen sich stauen. Skalierung anhand der CPU tut dann nichts, bis es viel zu spät ist. Auch der umgekehrte Fehler kommt vor: Ein Garbage-Collection-Sturm oder ein JIT-Warm-up treibt die CPU hoch, ohne dass die Last steigt, und der Autoscaler fügt Instanzen hinzu, die nicht gebraucht werden.

Besser ist ein Signal, das direkt an die Ressource gekoppelt ist, die ausgeht. Bei Request-Response-Services ist das meist die Nebenläufigkeit: die Zahl der laufenden Anfragen pro Instanz, verglichen mit der Zahl ihrer Worker-Threads oder Verbindungen. Littles Gesetz stellt den Zusammenhang exakt her (laufende Anfragen = Ankunftsrate × Antwortzeit), und das Signal reagiert sowohl auf mehr Traffic als auch auf langsamere Antworten. Bei Queue-Workern ist es der Rückstand pro Worker oder das Alter der ältesten Nachricht, was ausdrückt, wie lange der Abbau der Queue dauern wird. Die Latenz ist als Skalierungssignal verlockend, aber gefährlich: Sie steigt aus Gründen, die mehr Instanzen nicht beheben können, etwa bei einer langsamen Datenbank, und wer einen Service horizontal skaliert, dessen Abhängigkeit schon kämpft, schickt dieser Abhängigkeit noch mehr Last. Nutzen Sie die Latenz für Alerts und skalieren Sie anhand eines Maßes für Arbeit.

Cooldowns, Stabilisierung und Flapping

Ein Autoscaler, der auf jedes Schwanken reagiert, gerät ins Flapping: Er fügt Instanzen hinzu, wenn ein Lastschub kommt, entfernt sie eine Minute später, wenn der Schub vorbei ist, und fügt sie dann wieder hinzu, zahlt jedes Mal die Startkosten und stört Caches und Connection Pools. Er kann sich auch selbst im Kreis jagen: Neue Instanzen sind kalt und langsam, daher steigen Latenz oder CPU pro Anfrage nach dem Scale-out kurzzeitig an, was wie mehr Last aussieht.

Die üblichen Gegenmaßnahmen sind asymmetrisch. Skalieren Sie schnell hoch, weil zu wenig Kapazität den Nutzern schadet; skalieren Sie langsam herunter, weil zu viel Kapazität nur Geld kostet. Ein Cooldown oder Stabilisierungsfenster lässt den Autoscaler nach einer Aktion warten oder vor dem Herunterskalieren die höchste Empfehlung eines zurückliegenden Zeitfensters nehmen: Der Kubernetes-Autoscaler nutzt standardmäßig ein Fenster von fünf Minuten (300 Sekunden) für das Herunterskalieren und keines für das Hochskalieren. Ein Toleranzband ignoriert kleine Abweichungen. Mindest- und Höchstzahlen für Instanzen begrenzen den Regelkreis: Das Minimum hält genug Kapazität vor, um den Verlust einer Zone und die ersten Minuten eines Ansturms zu überstehen, und das Maximum schützt die Datenbank, nachgelagerte Services und das Budget vor einem Autoscaler, der ein Problem fälschlich als Last deutet. Auch das Herunterskalieren muss kontrolliert ablaufen: Eine zum Entfernen ausgewählte Instanz darf keine neuen Anfragen mehr erhalten und muss die laufenden abschließen (Connection Draining, Abschnitt 9.2).

Die Datenschicht skalieren

Zustandslose Anwendungsschichten lassen sich leicht skalieren; genau deshalb macht man sie zustandslos. Der Druck landet dann auf den Datenbanken, Caches und Brokern, die sie gemeinsam nutzen; deshalb ist die Datenschicht meist die eigentliche Grenze eines Systems. Die Werkzeuge wurden in Kapitel 7 behandelt und sind hier in der Reihenfolge zusammengefasst, in der Fachleute meist zu ihnen greifen. Erstens: die Arbeit verringern, mit Indizes, besseren Abfragen, weniger Roundtrips pro Anfrage. Zweitens: Lesezugriffe mit Caching (Abschnitt 7.6) und Lesereplikaten auffangen und Replikationsverzögerung hinnehmen, wo der Anwendungsfall es erlaubt. Drittens: Verbindungen schützen. Jede Anwendungsinstanz hält einen Pool, die Gesamtzahl wächst also mit der Flotte, und ein Connection Pooler wie PgBouncer lässt Tausende Client-Verbindungen sich einige Hundert Datenbankverbindungen teilen (der Standardwert von max_connections in PostgreSQL ist nur 100). Viertens: den Primary vertikal skalieren, was oft günstiger ist als jeder Umbau. Erst dann Schreibzugriffe entlang der Z-Achse nach einem Schlüssel wie Stadt oder Kunde partitionieren (Abschnitt 7.4) oder auf eine Distributed-SQL-Datenbank wechseln.

Zwei Warnungen gelten. Erstens kann Autoscaling der Anwendungsschicht der Datenschicht schaden: Jede neue Instanz öffnet Verbindungen und wärmt ihren Cache aus der Datenbank auf, sodass ein großes Scale-out-Ereignis die Datenbank selbst überlasten kann. Zweitens sind manche Grenzen logisch, nicht physisch: Eine einzige Hot Row (der Bestandszähler für die letzten 500 Tickets eines Konzerts oder eine globale Sequenznummer) serialisiert Schreibzugriffe, egal wie groß der Server ist. Solche Grenzen beseitigt man durch Design, etwa indem man den Bestand auf mehrere Zähler aufteilt oder Plätze in Blöcken reserviert, nicht durch Hardware.