Tail-Latenz-Verstärkung: wenn eine Anfrage auf die langsamste von hundert wartet

Worum es geht

Eine Anfrage, die parallel an N Backends verteilt wird (Shards, Microservices, Werkzeugaufrufe), ist abgeschlossen, wenn die Antwort des langsamsten der N eintrifft. Antwortet jedes Backend unabhängig mit Wahrscheinlichkeit p langsam, ist die gesamte Anfrage mit Wahrscheinlichkeit 1 − (1 − p)^N langsam. Bei p = 1 % und N = 100 sind das 1 − 0,99^100, etwa 63 % (Arithmetik). Dean und Barrosos «The Tail at Scale» hält fest, dass vorübergehende Episoden hoher Latenz, die in mittelgrossen Systemen unbedeutend sind, in grossem Massstab die Gesamtleistung eines Dienstes dominieren können, und plädiert dafür, Latenz-Tail-tolerante Systeme so zu bauen, wie fehlertolerante Systeme aus unzuverlässigen Teilen gebaut werden. Das SRE-Buch beschreibt denselben Effekt von der Überwachungsseite her: Das 99. Perzentil eines Backends kann leicht zur Median-Antwortzeit des Frontends werden.

Warum es wichtig ist

Den Median jedes einzelnen Backends zu verbessern, bewirkt für die verteilte Anfrage nichts. Jede Zusammensetzung paralleler Aufrufe ist davon betroffen: eine Seite, die ein Dutzend Services abfragt, eine Suche über Shards, ein Agent, der vor der Antwort mehrere Werkzeuge aufruft. Sequenzielle Ketten addieren ihre Latenzen, statt das Maximum zu nehmen, doch eine lange Kette von p99-Werten ist nicht besser.

So wird es angewendet

• Das p99 des Blatts und den p50 der Wurzel im selben Diagramm messen; folgt der Median der Wurzel dem Tail des Blatts, ist Verstärkung die Ursache, nicht der eigene Code der Wurzel.
• N verringern: grössere Partitionen, weniger Services pro Anfrage, zwischengespeicherte Ergebnisse für die Blätter, die sich selten ändern.
• Hedging: Nach einer Verzögerung, die etwa der p95-Latenz des Blatts entspricht, dieselbe Anfrage an eine zweite Replik senden und die erste Antwort verwenden. Hedging nach dem p95 dupliziert höchstens 5 % der Anfragen (Arithmetik). Das Papier beschreibt auch Tied Requests, bei denen die zweite Kopie abgebrochen wird, sobald die erste mit der Ausführung beginnt.
• Eine Deadline an der Wurzel setzen und ein ausreichend gutes Ergebnis aus den Blättern zurückgeben, die rechtzeitig geantwortet haben, als Teilergebnis markiert, statt auf das letzte zu warten.
• Blatt-Tails an der Quelle beseitigen: Garbage-Collection-Pausen, Hintergrund-Kompaktierung, kalte Caches, laute Nachbarn; geplante Hintergrundarbeit über die Repliken hinweg staffeln.
• Jedem Blattaufruf ein eigenes Timeout geben und der Wurzel ein Gesamtbudget, damit ein hängendes Blatt die Anfrage nicht aufhalten kann.

Stolpersteine

Hedging einer nicht idempotenten Operation verdoppelt ihren Nebeneffekt. Jede Anfrage zu hedgen verdoppelt die Last und verschlechtert den Tail unter Sättigung; nur nach einer perzentilbasierten Verzögerung hedgen und die Hedging-Rate begrenzen. Wiederholungen auf jeder Ebene einer Verteilung vervielfachen die Last auf einem bereits langsamen Backend. Die Formel setzt unabhängige Blätter voraus; eine gemeinsame Datenbank oder ein gemeinsamer Host korreliert ihre Langsamkeit, was den Tail schlimmer macht als die Formel, nicht besser.

Hedging sicher einsetzen

Eine aus Live-Perzentilen abgeleitete Hedging-Verzögerung wirkt auf sich selbst zurück: Hedges erzeugen zusätzliche Last, die das Perzentil anhebt, was die Verzögerung verschiebt, und unter Sättigung ist jedes Hedge Arbeit, für die das Blatt keine Kapazität hatte. Eine feste, offline aus dem Perzentil einer ruhigen Phase gewählte Verzögerung verwenden, die verlierende Kopie abbrechen, sobald eine Antwort eintrifft (die Tied Requests aus dem Papier), und Hedges auf einen expliziten Anteil des Verkehrs begrenzen, mit einem Budget, das das Hedging stoppt, wenn Fehler oder Wartezeit in der Queue steigen; die Hedging-Policy von gRPC (hedgingDelay, maxAttempts, Retry-Drosselung) und die Per-Try-Timeout-Hedging-Policy von Envoy setzen genau diese Kontrollen um. Nur idempotente Aufrufe hedgen, nie auf mehr als einer Ebene einer Verteilung, und Hedging vollständig abschalten, wenn die Wartezeit in der Queue des Blatts steigt, weil dann die zweite Kopie in derselben Queue wartet wie die erste.