Timeouts, Wiederholungen, Circuit Breaker, Bulkheads und Graceful Degradation

Ausfälle sind normal; ihre Ausbreitung ist es nicht

In einem verteilten System ist immer irgendeine Abhängigkeit langsam oder fällt aus: Ein Zahlungsanbieter hat eine schlechte Minute, eine Datenbank macht ein Failover, eine Netzwerkverbindung verliert Pakete, ein Deployment geht schief. Abschnitt 6.1 hat gezeigt, warum sich solche Teilausfälle nicht verhindern lassen und warum ein Aufrufer oft nicht einmal erkennen kann, was passiert ist. Die architektonische Frage lautet daher nicht, wie man Ausfälle vermeidet, sondern wie man verhindert, dass ein lokaler Ausfall zu einem globalen wird. Ein kaskadierender Ausfall ist die typische Art, wie Systeme sterben: Eine langsame Abhängigkeit macht ihre Aufrufer langsam, deren Ressourcen füllen sich mit wartenden Anfragen, sie werden ihrerseits für ihre eigenen Aufrufer langsam, und binnen Sekunden hat ein Problem in einer unbedeutenden Komponente die ganze Plattform lahmgelegt.

Michael Nygard hat die Muster, die solche Ketten unterbrechen, in Release It! (2007; zweite Auflage 2018) katalogisiert und sich dabei auf Ausfälle gestützt, die er untersucht hatte. Seine zentrale Beobachtung ist, dass Integrationspunkte, also jede Stelle, an der ein System ein anderes aufruft, die Hauptquelle von Instabilität sind und dass jeder einzelne gezielten Schutz braucht. Die Muster in diesem Abschnitt (Timeouts, Deadlines, Wiederholungen mit Backoff, Circuit Breaker, Bulkheads, Fallbacks, Idempotenz und Hedging) sind der Standardwerkzeugkasten. Sie sind Taktiken im Sinne von Abschnitt 2.5: Jede ist eine einzelne Entscheidung, die auf Verfügbarkeit zielt, und jede hat ihren Preis.

Timeouts: das erste und wichtigste Muster

Ein Timeout begrenzt, wie lange ein Aufrufer wartet. Ohne Timeout hält ein Aufruf an eine Abhängigkeit, die nie antwortet, einen Thread, eine Verbindung und Speicher so lange, wie das Betriebssystem die Verbindung offen hält, und das können viele Minuten sein. Viele Client-Bibliotheken haben standardmäßig keinen Timeout (die weit verbreitete Python-Bibliothek requests wartet unbegrenzt, wenn man nichts anderes angibt); das Fehlen eines Timeouts ist also eine Entwurfsentscheidung durch Unterlassen. Das ausgearbeitete Beispiel unten zeigt die Folgen.

Meist kommt es auf zwei Timeouts an. Der Connect-Timeout begrenzt den Verbindungsaufbau und kann kurz sein, innerhalb eines Rechenzentrums wenige hundert Millisekunden, weil ein gesunder Server Verbindungen fast sofort annimmt. Der Request-Timeout begrenzt den gesamten Austausch und sollte aus Messungen abgeleitet werden: knapp über der hohen Perzentil-Latenz der Abhängigkeit (p99 oder p99.9) unter normaler Last, sodass er krankhafte Wartezeiten abschneidet, ohne gewöhnliche langsame Anfragen scheitern zu lassen. Er muss außerdem in das eigene Budget des Aufrufers passen. Gibt das Gateway nach 2 Sekunden auf, wartet der Bestellservice aber 10 Sekunden auf die Preisgestaltung, arbeitet der Bestellservice 8 Sekunden lang an einer Anfrage, auf die niemand wartet. Timeouts sollten daher entlang einer Aufrufkette kleiner werden, und das ist die Idee hinter Deadlines.

Deadlines und ihre Weitergabe

Eine Deadline ist ein absoluter Zeitpunkt, bis zu dem die gesamte Anfrage abgeschlossen sein muss. Deadline-Weitergabe gibt die verbleibende Zeit an jeden nachgelagerten Aufruf weiter, sodass jeder Service weiß, wie viel Budget noch übrig ist, statt einen eigenen festen Timeout anzuwenden. gRPC hat das eingebaut: Ein Client setzt eine Deadline, die verbleibende Zeit reist mit dem Aufruf mit, und ein Server kann prüfen, ob die Deadline überschritten ist, und die Arbeit einstellen. Über HTTP geben Teams einen Header mit den verbleibenden Millisekunden oder der absoluten Deadline weiter, idealerweise über dieselbe Middleware, die auch den Tracing-Kontext weitergibt (Abschnitt 9.6).

Die Weitergabe bringt zwei Vorteile. Ein Service kann schnell fehlschlagen, wenn die verbleibende Zeit offensichtlich zu kurz für die Arbeit ist, statt eine Datenbankabfrage zu starten, die nicht rechtzeitig fertig werden kann. Und wenn der Benutzer aufgibt, stoppt auch die Arbeit darunter, statt weiter Kapazität zu verbrauchen, und das genau während der Überlast, die die Verzögerung verursacht hat. Das ist Load Shedding toter Anfragen, einer der wirksamsten Schutzmechanismen, die ein System unter Stress haben kann.

Wiederholungen mit exponentiellem Backoff und Jitter

Viele Fehler sind vorübergehend: ein verlorenes Paket, ein Verbindungsabbruch während eines Failovers, ein kurzes 503 von einer überlasteten Instanz. Eine Wiederholung (Retry) verwandelt sie in Erfolge, die der Benutzer nie bemerkt. Doch Wiederholungen sind auch Last, und schlecht entworfene Wiederholungen gehören zu den häufigsten Ursachen von Ausfällen. Vier Regeln machen sie sicher. Wiederholen Sie nur vorübergehende Fehler (Timeouts, Verbindungsfehler, 502, 503, 504 und 429 nach der angegebenen Wartezeit), niemals Fehler, die erneut auftreten werden, etwa 400 oder 404. Wiederholen Sie nur idempotente Operationen oder solche mit einem Idempotenzschlüssel, denn eine Anfrage mit Timeout kann trotzdem erfolgreich gewesen sein. Wiederholen Sie nur wenige Male, typischerweise zwei- oder dreimal. Und warten Sie zwischen den Versuchen, mit exponentiellem Backoff: einer Wartezeit, die sich mit jedem Versuch verdoppelt, bis zu einer Obergrenze.

Backoff allein reicht nicht. Scheitern tausend Clients im selben Moment, wie es bei einem kurzen Aussetzer einer Abhängigkeit geschieht, wiederholen sie alle nach 100 ms, dann alle nach 200 ms und treffen in synchronisierten Wellen ein, die die Abhängigkeit unten halten können. Marc Brookers Artikel Exponential Backoff And Jitter (AWS Architecture Blog, 2015) hat das simuliert und gezeigt, dass Zufall, Jitter, sowohl die Gesamtarbeit als auch die Zeit bis zum Abschluss stark verringert. Sein empfohlenes Full Jitter wartet eine zufällige Zeit zwischen null und der exponentiellen Schranke: sleep = random(0, min(cap, base × 2attempt)). Jitter gehört zu allem, was viele Clients gleichzeitig tun: Wiederholungen, Neuverbindungen, Ablaufzeiten von Cache-Einträgen und geplante Jobs.

import random, time

class TransientError(Exception):
    """Timeouts, connection resets, 502, 503 and 504 responses."""

def call_with_retries(fn, attempts=3, base=0.1, cap=2.0):
    for attempt in range(attempts):
        try:
            return fn()
        except TransientError:
            if attempt == attempts - 1:
                raise                      # give up: let the caller decide
            ceiling = min(cap, base * 2 ** attempt)
            time.sleep(random.uniform(0, ceiling))   # full jitter

Retry-Stürme und Retry-Budgets

Wiederholungen multiplizieren sich über Schichten. Angenommen, ein Tippen in der mobilen App läuft durch das API-Gateway, den Bestellservice und den Zahlungsclient, und jede der drei Schichten unternimmt bis zu drei Versuche. Ist der Zahlungsanbieter ausgefallen, erzeugt eine Benutzeraktion 3 × 3 × 3 = 27 Aufrufe an ihn, und ein Ausfall, der eine gleichmäßige Fehlerrate hätte bedeuten sollen, wird zu einem Retry-Sturm mit der 27-fachen normalen Last, der den Anbieter auch dann noch unten hält, wenn die ursprüngliche Ursache behoben ist. Benutzer, die erneut tippen, fügen eine vierte Schicht hinzu.

Drei Abwehrmaßnahmen wirken zusammen. Erstens: Wiederholen Sie nur auf einer Schicht, meist der, die der fehlschlagenden Abhängigkeit am nächsten ist, und lassen Sie die anderen Schichten den Fehler nach oben weiterreichen; Googles SRE-Buch empfiehlt, dass ein überlasteter Server das ausdrücklich meldet, damit Aufrufer weiter oben nicht wiederholen. Zweitens: Nutzen Sie ein Retry-Budget: Das SRE-Buch beschreibt, Wiederholungen nur zuzulassen, solange sie unter 10 % der Anfragen eines Clients liegen, was die zusätzliche Last durch Wiederholungen auf etwa das 1,1-Fache des Normalen begrenzt statt auf bis zum Dreifachen. AWS-SDKs implementieren ein ähnliches Kontingent an Retry-Tokens, und die Retry-Policy von gRPC enthält Throttling zum selben Zweck. Drittens: Kombinieren Sie Wiederholungen mit einem Circuit Breaker, damit eine Abhängigkeit, von der bekannt ist, dass sie ausgefallen ist, gar nicht erst erneut aufgerufen wird.

Circuit Breaker

Ein Circuit Breaker, von Nygard nach dem elektrischen Schutzschalter benannt, umhüllt Aufrufe an eine Abhängigkeit und beobachtet deren Ergebnisse. Solange die Abhängigkeit gesund ist, ist der Breaker geschlossen und Aufrufe gehen durch, während Fehler und Timeouts gezählt werden. Überschreiten die Fehler eine Schwelle, zum Beispiel die Hälfte der letzten 20 Aufrufe, öffnet der Breaker: Für einen festgelegten Zeitraum scheitert jeder Aufruf sofort, ohne das Netzwerk zu berühren, was die Threads des Aufrufers schützt und der Abhängigkeit Raum zur Erholung gibt. Läuft der Zeitraum ab, wird der Breaker halboffen und lässt einige Testaufrufe durch. Gelingen sie, schließt er; scheitert einer, öffnet er erneut für einen weiteren Zeitraum. Martin Fowlers Beschreibung von 2014 machte das Muster weithin bekannt, und Netflix’ Bibliothek Hystrix (heute im Wartungsmodus) machte es bei Microservices populär; Resilience4j für Java und Polly für .NET sind heute die gängigen Bibliotheken, und Service Meshes bieten verwandte Schutzmechanismen wie Nebenläufigkeitslimits und Outlier Detection (in Envoy heißen sie Circuit Breaking, obwohl sie anders funktionieren).

Die Einstellungen verdienen Überlegung. Was zählt als Fehler? Timeouts und 5xx-Antworten sollten zählen; 4xx-Antworten meist nicht, weil sie die Anfrage des Aufrufers widerspiegeln, nicht die Gesundheit der Abhängigkeit. Auch langsame Erfolge können zählen, sodass eine Abhängigkeit, die in 5 Sekunden antwortet, als fehlerhaft behandelt wird. Das Fenster muss groß genug sein, um nicht bei ein paar unglücklichen Aufrufen auszulösen (Bibliotheken verlangen eine Mindestzahl an Aufrufen), und der offene Zeitraum lang genug für die Erholung, aber kurz genug, um einen Ausfall nicht zu verlängern. Breaker sollten pro Abhängigkeit, manchmal pro Endpoint, eingerichtet werden, damit ein fehlerhafter Reporting-Endpoint nicht das Bestellen abschneidet. Wiederholungen sollten einen offenen Breaker als endgültige Antwort behandeln, nicht als etwas, das man wiederholt. Und jeder Zustandswechsel sollte geloggt und grafisch dargestellt werden, denn ein offener Breaker ist ein Symptom, das jemand sehen muss.

import time

class CircuitOpen(Exception):
    pass

class CircuitBreaker:
    def __init__(self, failure_threshold=5, reset_after=30.0):
        self.failure_threshold = failure_threshold  # failures in a row that trip it
        self.reset_after = reset_after              # seconds to stay open
        self.failures, self.state, self.opened_at = 0, "closed", 0.0

    def call(self, fn, *args, **kwargs):
        if self.state == "open":
            if time.monotonic() - self.opened_at < self.reset_after:
                raise CircuitOpen("failing fast")   # no remote call at all
            self.state = "half-open"                # let a trial call through
        try:
            result = fn(*args, **kwargs)
        except Exception:
            self.failures += 1
            if self.state == "half-open" or self.failures >= self.failure_threshold:
                self.state, self.opened_at = "open", time.monotonic()
            raise
        self.failures, self.state = 0, "closed"    # success closes the circuit
        return result

payments = CircuitBreaker()
# payments.call(provider.authorise, order_id, amount, timeout=2.0)

Bulkheads

Der Rumpf eines Schiffs ist durch Schotten (Bulkheads) in wasserdichte Abteilungen geteilt, sodass ein Leck eine Abteilung flutet, statt das Schiff zu versenken. In Software partitioniert ein Bulkhead Ressourcen, sodass ein fehlerhafter oder überlasteter Teil nicht alles verbrauchen kann. Die häufigste Form gibt jeder Abhängigkeit einen eigenen begrenzten Thread-Pool, Connection-Pool oder Semaphor: Zahlungen dürfen höchstens 40 gleichzeitige Aufrufe pro Instanz nutzen, Restaurantabfragen 40, Kurierzuweisung 40. Werden Zahlungen langsam, füllt sich ihr Pool, und weitere Zahlungsaufrufe werden sofort abgelehnt, aber Restaurant- und Kurieraufrufe laufen weiter. Ein Timeout begrenzt, wie lange jeder Aufruf Ressourcen halten kann; ein Bulkhead begrenzt, wie viele gleichzeitig gehalten werden können, und schützt daher selbst dann, wenn Timeouts zu lang gesetzt sind.

Bulkheads wirken auch im größeren Maßstab. Getrennte Deployments desselben Service für verschiedene Aufrufer (ein Pool von Bestellservice-Instanzen für die Kunden-App, ein anderer für die Restaurantpartner-API) verhindern, dass eine fehlerhafte Partnerintegration die Kunden aushungert. Zellbasierte Architekturen, die Z-Achse des Scale Cube, machen jede Zelle zu einem Bulkhead für einen Teil der Kunden, und Shuffle Sharding, von Fachleuten bei AWS beschrieben, weist jedem Kunden eine zufällige kleine Kombination von Instanzen zu, sodass der giftige Verkehr eines Kunden nur sehr wenige andere trifft. Der Preis jedes Bulkheads ist Auslastung: Für eine Abteilung reservierte Kapazität kann nicht an eine andere verliehen werden, daher müssen Pools anhand des gemessenen Bedarfs dimensioniert werden.

Fallbacks und Graceful Degradation

Scheitert ein Aufruf oder ist ein Breaker offen, muss der Aufrufer trotzdem antworten. Ein Fallback legt fest, was er zurückgibt. Die Optionen, von der besten zur schlechtesten für den Benutzer, sind: ein zwischengespeicherter oder veralteter Wert (die zuletzt bekannte Speisekarte, mit Preisen, die im Bezahlvorgang bestätigt werden); ein sinnvoller Standardwert (eine geschätzte Lieferzeit von 30 bis 45 Minuten statt einer Live-Schätzung); eine eingeschränkte Funktion (beliebte Gerichte statt personalisierter Empfehlungen); die Arbeit aufschieben (eine Bewertung annehmen und veröffentlichen, wenn sich der Bewertungsservice erholt hat); und ein klarer, schneller Fehler, der dem Benutzer sagt, was zu tun ist. Diese pro Feature gemeinsam mit dem Product Owner zu entwerfen, ist das, was Graceful Degradation in der Praxis bedeutet: Die Kernabläufe (stöbern, bestellen, bezahlen, verfolgen) funktionieren weiter, während nicht wesentliche Features zurücktreten. Dasselbe Denken leitet Load Shedding (Abschnitt 9.3): Wissen Sie im Voraus, welche Features Sie zuerst abschalten.

Sicherheitsentscheidungen sind die Ausnahme: Ist der Autorisierungsservice nicht erreichbar, ist der sichere Fallback, zu verweigern (Fail-closed), nicht zu erlauben. Fachleute sind sich bei Fallbacks auch allgemein uneins. Nygard und die Fachleute bei Netflix befürworten sie breit. Fachleute bei Amazon haben im Builders’-Library-Artikel Avoiding fallback in distributed systems argumentiert, dass Fallback-Pfade selten durchlaufen werden, schwer zu testen sind und selbst Ausfälle auslösen können, indem sie eine große Flotte im ungünstigsten Moment in einen ungetesteten Modus schalten; sie ziehen es vor, den primären Pfad zuverlässiger zu machen und schnell fehlzuschlagen. Beide Positionen sind sich über die praktische Regel einig: Ein Fallback muss einfacher sein als das, was er ersetzt, darf nicht von der ausgefallenen Komponente abhängen und muss regelmäßig durchlaufen werden, zum Beispiel an Game Days (Abschnitt 9.8), sonst sollte es ihn nicht geben.

Idempotenz: was Wiederholungen und Hedging sicher macht

Idempotenz ist die Eigenschaft, dass etwas zweimal zu tun dieselbe Wirkung hat wie es einmal zu tun. Jedes Muster in diesem Abschnitt, das Arbeit wiederholt, hängt davon ab: Wiederholungen nach einem Timeout, Hedged Requests, erneute Zustellung von Nachrichten nach dem Absturz eines Consumers und Replays aus einer Dead Letter Queue. Abschnitt 6.5 hat gezeigt, wie ein Idempotenzschlüssel POST /orders sicher wiederholbar macht, und Abschnitt 6.4, wie idempotente Consumer Nachrichten deduplizieren. Die architektonische Regel ist einfach: Prüfen Sie vor dem Hinzufügen einer Wiederholung, ob die Operation idempotent ist, und wenn nicht, fügen Sie zuerst einen Schlüssel oder eine Duplikatprüfung hinzu. Eine Retry-Policy für einen nicht idempotenten Zahlungsaufruf ist kein Resilienzmuster, sondern ein Generator für Doppelabbuchungen.

Hedged Requests

Wiederholungen behandeln Fehler; Hedged Requests behandeln Langsamkeit. Abschnitt 2.4 hat sie nach Dean und Barrosos The Tail at Scale (2013) eingeführt: Senden Sie eine Anfrage an ein Replikat, und wenn es nicht innerhalb, sagen wir, der Latenz des 95. Perzentils geantwortet hat, senden Sie eine Kopie an ein zweites Replikat, verwenden Sie die Antwort, die zuerst kommt, und brechen Sie die andere ab. Weil nur die langsamsten paar Prozent der Anfragen dupliziert werden, ist die zusätzliche Last gering, während der Tail drastisch schrumpft, wie der in Abschnitt 2.4 zitierte Benchmark gezeigt hat.

Hedging hat Voraussetzungen. Die Operation muss idempotent sein, normalerweise ein Lesezugriff. Es muss unabhängige Replikate geben, damit die zweite Kopie wahrscheinlich nicht aus demselben Grund langsam ist. Die zusätzlichen Anfragen müssen budgetiert und unter Überlast abgeschaltet werden, denn wenn jedes Replikat langsam ist, verdoppelt Hedging die Last auf einem System, das ohnehin kämpft, genau wie eine unbudgetierte Wiederholung. Sorgfältig eingesetzt auf leselastigen Fan-out-Pfaden wie Suche und Speisekartenabfragen, ist es eines der wirksamsten verfügbaren Werkzeuge gegen Tail-Latenz.