Wird ein Dienst langsam, hängen die Server, die ihn aufrufen, beim Warten auf Antworten fest, und selbst unbeteiligte Funktionen bleiben stehen.
Warum Ein Dienst wie DB oder Authentifizierung wird langsam → Folge Threads und Verbindungen der aufrufenden Server hängen beim Warten auf Antworten fest, Retries fehlgeschlagener Anfragen erhöhen die Last → Auf dem Bildschirm Selbst scheinbar unbeteiligte Funktionen werden langsam oder bleiben stehen
Timeout für jeden Aufruf, Circuit-Breaker, Isolation pro Funktion (Bulkhead), Retries mit wachsendem Abstand und begrenzter Anzahl, Antworten auf Health-Checks von aufwendiger Arbeit entkoppeln.
Aufgaben Infrastrukturteam
Health-Checks des Load-Balancers mit Spielraum bei Fehleranzahl und Intervall konfigurieren, damit kurz langsame Server nicht sofort herausfallen, Zahl der gleichzeitig entfernten Server begrenzen.
Im Graphen
Plateau am Limit · Antwortzeit und Fehlerrate pro Dienst, belegte Threads und Verbindungen
Wo nachsehen
Antwortzeit, Fehlerrate und Retries pro Dienst mit gleicher Zeitachse auf einem Bildschirm darstellen und den Dienst finden, der zuerst langsam wurde. Hinter einem Load-Balancer: Antwortzeit der Ziele (bei AWS ALB TargetResponseTime), 5xx-Anzahl der Ziele (HTTPCode_Target_5XX_Count), Zahl der als fehlerhaft entfernten Ziele (UnHealthyHostCount)
Spricht dafür
Latenz eines Dienstes steigt zuerst, danach erreichen belegte Threads und Verbindungen der Aufrufer ihr Limit, Fehler greifen auf andere Dienste über, und Retries sowie entfernte Ziele nehmen gleichzeitig zu
Spricht dagegen
Mehrere Dienste im selben Moment langsam: zuerst Störungen gemeinsamer Ressourcen (DB, Netzwerk, Host) prüfen
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Auch Health-Checks (Prüfungen, ob ein Server noch lebt) verstärken die Kaskade. Antwortet ein ausgelasteter Server zu spät auf die Prüfung, nimmt der Load-Balancer einen eigentlich funktionierenden Server aus dem Betrieb. Dessen Traffic landet bei den übrigen Servern, und der nächste Server wird ebenfalls langsam.
Site Reliability Engineering, Chapter 22: Addressing Cascading FailuresGoogle Fällt ein überlasteter Server beim Health-Check durch und wird entfernt, konzentriert sich die Last auf die übrigen Server, und Retries erhöhen sie weiter. Empfohlen: begrenzte Retries, exponentielles Backoff mit Zufallsanteil, Deadlines
Circuit Breaker PatternMicrosoft Azure Bis zum Timeout blockierte Anfragen belegen Threads und DB-Verbindungen und lassen auch unbeteiligte Funktionen scheitern. Häufen sich Fehler innerhalb einer festen Zeit, werden Aufrufe sofort abgewiesen
Timeouts, retries, and backoff with jitterAWS Amazon Builders' Library. Bei einer Aufrufkette über 5 Ebenen mit je 3 Retries pro Ebene steigt die DB-Last auf das 243-Fache. Retries nur an einer Stelle durchführen und per Token-Bucket begrenzen
CloudWatch metrics for your Application Load BalancerAWS TargetResponseTime (Zeit vom Verlassen des Load-Balancers bis zum Antwortbeginn des Ziels), HTTPCode_Target_5XX_Count (vom Ziel erzeugte 5xx-Antworten), UnHealthyHostCount (Zahl fehlerhafter Ziele)
Verwandte Ursachen
Gleiche Schicht: L13 Serverarchitektur und Betrieb