Performance, Skalierbarkeit, Resilienz und Betreibbarkeit

Willkommen zu Kapitel 9: Performance, Skalierbarkeit, Resilienz und Betreibbarkeit. Ein Entwurf, der seine Ziele im Diagramm erfüllt, kann trotzdem an einem Freitag um halb eins zusammenbrechen, wenn jedes Büro der Stadt Mittagessen bestellt. Der Unterschied liegt selten in cleverem Code. Er besteht aus Architekturentscheidungen: wie Kapazität hinzukommt, wie Last verteilt wird, wie Arbeit wartet, wie Ausfälle eingedämmt werden und wie die Betreiber erkennen, was das System tut.

Dieses Kapitel richtet sich an Entwicklungsteams und Architekten, die die verteilten Stile aus Kapitel 6 kennen und ein System unter realer Last schnell und lauffähig halten müssen. Es baut auf Kapitel 2 auf, das Performance und Verfügbarkeit als testbare Qualitätsszenarien präzise gemacht hat. Hier lernen Sie, diese Szenarien in einem laufenden System zu erreichen und sie auch am geschäftigsten Tag des Jahres einzuhalten. Für Replikation, Partitionierung und Caching verweist es auf Kapitel 7, statt sie zu wiederholen. Und es führt zu Kapitel 10 über die Cloud-Plattformen, Kubernetes-Funktionen und Multi-Region-Designs, auf denen diese Systeme meist laufen.

Zwei durchgehende Beispiele begleiten das Kapitel. Eine Essenslieferplattform mit ausgeprägten Spitzen mittags und abends. Und ein Ticket-Vorverkauf, bei dem die Nachfrage innerhalb von Sekunden von fast nichts auf ein Vielfaches der Systemkapazität steigt. Abschnitt neun Punkt eins vergleicht Scale-up mit Scale-out, trennt mit dem Scale Cube Klonen, Aufteilung nach Funktion und Aufteilung nach Daten und erklärt, warum Autoscaling anhand der CPU oft die falsche Wahl ist. Abschnitt neun Punkt zwei behandelt, was vor den Instanzen sitzt: Load Balancer, ihre Algorithmen, Health Checks, Connection Draining und warum Sticky Sessions einem Session-Zustand außerhalb der Instanz weichen sollten. Abschnitt neun Punkt drei behandelt, was passiert, wenn Arbeit schneller eintrifft, als sie erledigt werden kann: begrenzte Queues, Backpressure, Load Shedding und Rate Limiting, die entscheiden, was angenommen wird, was wartet und was höflich abgelehnt wird. Abschnitt neun Punkt vier befasst sich mit Ausfällen zwischen Services: Timeouts und Deadlines, Wiederholungen mit Backoff und Jitter, Circuit Breaker, Bulkheads und Fallbacks.

Das ausgearbeitete Beispiel in Abschnitt neun Punkt vier zeigt, wie ein einziger fehlender Timeout eine langsame Abhängigkeit alles lahmlegen lässt, was sie aufruft. Der Zahlungsdienstleister antwortet normalerweise in null Komma drei Sekunden. Heute antwortet er nicht mehr. Der Bestellservice ruft ihn ohne Timeout auf, also warten nach und nach alle zweihundert Threads auf Zahlungsaufrufe. Jetzt scheitert der Bezahlvorgang. Aber auch Bestellverlauf und Sendungsverfolgung scheitern, obwohl sie Zahlungen nie berühren, weil keine freien Threads mehr übrig sind. Die Datenbank ist völlig gesund, aber kein Thread ist frei, um sie aufzurufen. Timeouts, Circuit Breaker und Bulkheads sind die Muster, die eine solche Kaskade stoppen.

Die zweite Hälfte wendet sich von den Mechanismen dem Betrieb zu. Abschnitt neun Punkt fünf zeigt, wie Sie Zuverlässigkeit aus Nutzersicht formulieren und wie ein Error Budget ein Verfügbarkeitsziel in eine Menge erlaubter Ausfälle verwandelt, die Teams für Änderungen ausgeben können. Abschnitt neun Punkt sechs behandelt die Logs, Metriken und Traces, mit denen Fachleute einem Produktionssystem neue Fragen stellen können, sowie Distributed Tracing mit OpenTelemetry. Abschnitt neun Punkt sieben schließt den Kreis zwischen Prognosen und Belegen, mit Last-, Stress-, Soak-, Spike- und Breakpoint-Tests und einem Kapazitätsplan für einen Ticket-Vorverkauf. Und Abschnitt neun Punkt acht befasst sich mit den Ausfällen, die trotzdem passieren: gezielte Experimente, um Schwachstellen vor der Kundschaft zu finden, klare Rollen bei Incidents und schuldfreie Reviews, die das System ändern statt der Menschen.

Dieses Diagramm aus Abschnitt neun Punkt fünf bringt drei Begriffe auf eine Skala, anhand der Verfügbarkeit des Bezahlvorgangs über rollierende achtundzwanzig Tage. Das Service Level Objective, kurz SLO, ist das interne Ziel: hier neunundneunzig Komma neun Prozent. Das Service Level Agreement, kurz SLA, ist ein Vertrag mit Partnern, lockerer angesetzt, bei neunundneunzig Komma fünf Prozent. Der Service Level Indicator, kurz SLI, ist die Messung. Diesen Monat liegt er bei neunundneunzig Komma neun vier Prozent, in der Zone, in der der Service innerhalb seines Budgets liegt. Unterhalb des SLO ist das Ziel verfehlt, und eine schriftliche Error-Budget-Policy legt fest, was dann geschieht. Erst unterhalb des SLA sind Gutschriften fällig. Die Lücke zwischen SLO und SLA ist die Warnzone. Das Error Budget ist einfach eins minus SLO. Über dreißig Tage erlaubt ein Ziel von neunundneunzig Komma neun Prozent dreiundvierzig Komma zwei Minuten Totalausfall, oder dass eine von tausend Anfragen scheitert.

Die Abschnitte bilden eine Kette und führen zu einem Gedanken. Jede Ressource ist endlich, also hat jedes System eine Belastungsgrenze. Die Aufgabe der Architektur ist es, im Voraus zu entscheiden, was passiert, wenn sie erreicht ist. Ein gut entworfenes System wird unter übermäßiger Last kontrolliert langsamer und wirft die unwichtigste Arbeit zuerst ab. Es lehnt klar ab, statt stillschweigend in einen Timeout zu laufen. Es isoliert den ausfallenden Teil. Und es erholt sich von selbst, wenn der Druck nachlässt. Ein schlecht entworfenes System reiht ohne Grenze ein, wiederholt Anfragen, bis es zusammenbricht, und reißt seine Nachbarn mit. Diese Mechanismen lassen sich beim Entwurf günstig einbauen und nur teuer nachrüsten. Ob ein Service zustandslos ist, ob eine Queue begrenzt ist und ob eine Anfrage eine Deadline mitführt, wird lange vor dem ersten Incident entschieden.

Am Ende des Kapitels können Sie entscheiden, wie Sie skalieren, und eine Flotte mit Littles Gesetz und Kapazitätsreserve für eine bekannte Spitze dimensionieren. Sie können Timeouts, Deadlines, Wiederholungen mit Backoff und Jitter, Circuit Breaker, Bulkheads und Fallbacks kombinieren, um Ausfälle einzudämmen. Sie können Service Level Indicators und Objectives aus Nutzersicht definieren, Error Budgets berechnen und Alerts dafür entwerfen, wie schnell sie verbraucht werden. Und Sie können Kapazitäts- und Performancetests planen, Chaos-Experimente sicher durchführen und schuldfreie Post-Incident-Reviews leiten.

Weil die Abschnitte eine Kette bilden, lesen Sie sie am besten der Reihe nach. Jeder steht aber auch für sich, sodass Sie direkt zu dem Abschnitt gehen können, den Sie brauchen. Planen Sie etwa dreieinhalb Stunden ein, um das ganze Kapitel zu lesen. Am Ende jedes Abschnitts gibt es Fragen zur Selbstkontrolle. Beantworten Sie sie im Kopf, bevor Sie sich die Antworten ansehen. Wenn Sie so weit sind, gibt es einen optionalen Kapiteltest, der etwa fünfundvierzig Minuten dauert. Er umfasst zwanzig Multiple-Choice-Fragen und zwei schriftliche Antworten. Die Bestehensgrenze liegt bei achtzig Prozent.

So ist das Kapitel aufgebaut. Beginnen Sie mit Abschnitt neun Punkt eins über Scale-up, Scale-out und den Scale Cube. Bis gleich.