Wie wir Deployments auf null 502-Fehler gebracht haben

Bei jedem Deployment des Mythex-Backends sind einige Anfragen mit 502 Bad Gateway fehlgeschlagen. Nicht viele, aber ein 502 während eines Deployments heißt, dass der Klick einer Person nichts bewirkt hat oder ein Build, den jemand verfolgte, für einen Moment stockte. Wir haben das auf zwei getrennte Probleme zurückgeführt: einen selbstheilenden Watchdog, der gegen unsere Deployments arbeitete, und eine Lücke zwischen dem Moment, in dem ein Server aufhört zu lauschen, und dem Moment, in dem der Load Balancer ihm keinen Verkehr mehr schickt. Über drei aufeinanderfolgende Produktions-Deployments nach den Korrekturen sank die Zahl von 10 auf 6 und dann auf 0.

Der Aufbau

Unsere API und unser Orchestrator laufen als Container auf einer kleinen Gruppe von Servern hinter einem AWS Application Load Balancer (ALB). Ein Deployment aktualisiert jeweils einen Server: Es leert die alten Container, startet neue und geht zum nächsten über. Auf jedem Server prüft ein Watchdog, ob die Container laufen, und startet alles neu, was nicht läuft. Er existiert, damit ein abgestürzter Prozess um drei Uhr nachts zurückkommt, ohne dass jemand aufwachen muss.

Beides ist für sich genommen vernünftig. Zusammen funktionierte es nicht.

Problem 1: Der Watchdog lief gegen das Deployment

Der Watchdog lief einmal pro Minute und „heilte“ schon bei einem fehlgeschlagenen Health-Check. Ein Deployment leert Dienste absichtlich bis zu 150 Sekunden lang, und in dieser Zeit soll ein Health-Check fehlschlagen. Deshalb feuerte der Watchdog bei jedem einzelnen Deployment.

Meist verlor er das Rennen ohne Folgen. Einmal gewann er: Er schrieb die Compose-Datei (die Beschreibung, welche Container laufen sollen) mitten in einem Deployment neu und hinterließ einen Server ganz ohne Gateway-Container, während der Deployment-Job Erfolg meldete.

Die Korrekturen:

• Eine Sperre. Das Deployment nimmt jetzt dieselbe Dateisperre wie das Bootstrap-Skript des Servers, sodass Watchdog und Deployment nie gleichzeitig laufen können.
• Vier Verwarnungen, nicht eine. Der Watchdog braucht vier aufeinanderfolgende fehlgeschlagene Prüfungen, bevor er handelt. Ein gerade geleerter Dienst sieht nicht mehr tot aus.
• Eine Definition. Die Compose-Datei hat jetzt genau eine Quelle, die auf die Server veröffentlicht wird, statt Kopien, die auseinanderlaufen können.
• Prüfen statt vertrauen. Der Deployment-Job gilt nicht mehr als erfolgreich, weil ein Befehl zurückkam. Er prüft die API, den Orchestrator, das Gateway und den Publish-Worker jedes Servers, bevor er erfolgreich sein kann.

Problem 2: Der Server ging früher als der Verkehr

Das zweite Problem war leiser. Wenn ein Deployment einen Server leert, beantwortet der Server seinen Health-Endpoint mit 503, damit der Load Balancer ihn aus der Rotation nimmt. Unser Server tat das 5 Sekunden lang und fuhr dann herunter.

Der ALB prüft die Gesundheit aber nur in Abständen und braucht mehrere fehlgeschlagene Prüfungen hintereinander, bevor er aufhört, an ein Ziel zu leiten. Ende zu Ende waren das etwa 60 Sekunden. In rund 55 Sekunden schickte der Load Balancer also echte Anfragen an einen Server, der bereits aufgehört hatte zu lauschen. Das waren unsere 502er.

Die Lösung war, die beiden Zeitabläufe in Einklang zu bringen:

• Die Zielgruppe prüft jetzt alle 5 Sekunden und markiert ein Ziel nach 2 Fehlschlägen als fehlerhaft. Etwa 10 Sekunden, bis es bemerkt wird.
• Der Leerungsvorgang bedient echten Verkehr noch 15 Sekunden, nachdem die Health-Checks zu fehlschlagen beginnen, sodass sich die Phasen immer überlappen.
• Diese Einstellungen stehen im Skript, das die Infrastruktur bereitstellt, nicht in einer Konsole, in die jemand einmal geklickt hat.

Die Zahlen so halten, dass sie zueinander passen

Zeitlimits wie diese hängen voneinander ab. Die Leerung muss länger dauern, als der Balancer braucht, um es zu bemerken. Leerung plus Herunterfahren muss beendet sein, bevor der Container zwangsbeendet wird. Es ist leicht, dass jemand in sechs Monaten eine Zahl ändert und den Fehler unbemerkt wieder einführt.

Deshalb haben wir diese Zusammenhänge als Tests festgehalten: Die Leerung muss länger sein als das Health-Check-Intervall mal der Fehlerschwelle. Die Zeit, bis ein Ziel wieder als gesund gilt, muss kurz bleiben. Die gesamte Leerung muss in die Stop-Frist des Containers passen. Ändert man eine Zahl ohne die anderen, schlägt die CI fehl. Wir haben auch die Tests selbst per Mutationstest geprüft: Jede Zahl haben wir auf einen falschen Wert gesetzt und kontrolliert, dass ein Test es bemerkt.

Ein Deployment zu messen ist leicht falsch

Unsere erste Messung ergab, dass ein sauberes Deployment zu etwa 3 % kaputt war. Das stimmte nicht. Wir haben jede Antwort ohne 200 gezählt, aber ein 503 von einem Health-Endpoint während einer Leerung ist kein Fehler. Es ist die Leerung, die ihre Arbeit tut: Sie sagt dem Balancer, diesen Server nicht zu wählen, während er weiterhin echte Anfragen bedient.

Was Nutzer spüren, ist ein 502: Die Anfrage hat nirgendwo ankommen können. Nur diese zu zählen gab das wirkliche Bild, nämlich 10, dann 6, dann 0 über drei Produktions-Deployments.

Was wir daraus mitnehmen

• Selbstheilung muss von geplanten Ausfällen wissen. Ein Watchdog, der ein Deployment nicht von einem Absturz unterscheiden kann, wird irgendwann gegen das Deployment arbeiten.
• Das Leeren ist ein Handschlag. Der Server muss weiter bedienen, bis der Load Balancer nachweislich keinen Verkehr mehr schickt, und diese Zeitsteuerung wird am Balancer festgelegt, nicht am Server.
• Invarianten als Tests festhalten. Betriebliche Zahlen driften. Tests, die sie zueinander in Beziehung setzen, tun das nicht.
• Entscheiden Sie, was Sie messen, bevor Sie messen. „Fehler“ war die falsche Kennzahl. „Anfragen, die nirgendwo ankamen“ war die richtige.

Wenn Sie eine App auf Mythex veröffentlichen, ist davon für Sie nichts sichtbar, und genau das ist der Sinn. Verwandt: wie Ihre veröffentlichte App online bleibt, während Sie sie neu veröffentlichen.