Alles anzeigenEin Ausfall von Slack im Februar resultierte aus einem kaskadierenden Fehler, den das Team aufgrund der Komplexität nur schwer beheben konnte.
In seinem Engineering-Blog beschreibt ein Technikteam des Messengerdienstes Slack Ursachen und Fehlerbehebung eines Ausfalls im vergangenen Februar. Dabei hält das Team schon zu Beginn eine wohl eher unbequeme Erkenntnis fest: “Dieser Vorfall war ein Paradebeispiel für ein komplexes Systemversagen: Es gab eine Reihe von Faktoren, die dazu beitrugen, und ein Teil des Vorfalls bestand aus einem kaskadenartigen Fehlerszenario.”
Der Ausfall des Systems machte sich dem Beitrag zufolge dadurch bemerkbar, dass Nutzer Probleme damit hatten, sich am Morgen (US-Zeitzonen) mit dem Messenger zu verbinden. Unabhängig davon erhielt das Team automatische Fehlermeldungen des Alarmsystems.
Die Probleme zeigten sich laut dem Blogpost an der Technik durch einen deutlichen Anstieg der Last der Datenbanksystemen. Das Team schreibt: “Was anfangs nicht klar war, war die Frage, warum die Datenbank so stark belastet wurde (..) und wie wir zu einem normalen Betriebszustand gelangen konnten.” Lösen konnte das Slack demnach nur durch eine größere interne Kooperation unter Beteiligung mehrerer Teams.
Die zunächst naheliegende Lösung, zur Lastvermeidung die Anzahl neuer Clients zu reduzieren, die sich mit neu mit dem System verbanden, und anschließend diese Zahl wieder langsam zu erhöhen, hatte aber nicht den erhofften Erfolg. Das Team war offenbar schlicht zu ungeduldig und erzeugte zu schnell wieder zu viel Last, ohne den zugrunde liegenden Fehler zu beheben.
Zur Ursachensuche schreibt das Team: “Wie kam es dazu, dass wir von einem stabilen Auslieferungszustand in einen Zustand der Überlastung gerieten? Die Antwort lag in den komplexen Interaktionen zwischen unserer Anwendung, den Vitess-Datenspeichern, dem Caching-System und unserem Service Discovery System.” Bei Vitess handelt es sich um ein Datenbank-Cluster-System für MySQL, das gestartet wurde, um die Skalierungsprobleme von Youtube zu lösen.
Ausgangspunkt war den Angaben zufolge ein Upgrade von Consul, das für Service Discovery genutzt wird. Wie schon mehrfach zuvor sollten dabei nur 25 Prozent der Server aktualisiert werden. Das hatte zwar zuvor geklappt, zusammen mit einer gestiegenen Last durch die Clients führte es aber letztlich am Tag des Ausfalls von Slack zu bisher unbekannten Problemen.
Mit den Upgrades von Consul wurden nach und nach die davon überwachten Cache-Knoten offline genommen. Die Automatisierung von Slack startete dann zwar ersatzweise neue Knoten mit Memcached, letztlich führte der Updateprozess aber dazu, dass sich die Cache Hit Rate immer stärker verringerte.
Da die Abfragen im Cache nicht erfolgreich waren, wurden die eigentlichen Datenbanken verstärkt angefragt, die aufgrund einer spezifischen Anfrage und der Verteilung der angefragten Daten im System immer mehr unter Last gerieten. Dazu schreibt das Team: “Die Datenbank war überfordert, da die Leselast im Verhältnis zum Prozentsatz der Cache Misses superlinear anstieg.” Die Systeme erreichten laut Slack schließlich einen Kipppunkt, ab dem sich der Fehler selbst weiter verstärkte.
Das Team reduzierte zum Beheben der Probleme zunächst die Anzahl sich verbindender Clients, verbesserte die ineffiziente Datenbankabfrage, um nur noch jene Daten zu lesen, die tatsächlich im Cache fehlten, und die Datenbank-Replicas wurden als Systeme zum Lesezugriff bereitgestellt. Letztlich konnte der Cache so wieder aufgefüllt werden, bis alle Clients ihre Daten wieder daraus erhalten konnten.
Der Beitrag Slack erklärt “Paradebeispiel für komplexes Systemversagen” erschien zuerst auf Linux-Magazin.
Quelle: https://www.linux-magazin.de/n…komplexes-systemversagen/