Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03483.jsonl.gz/2211

In einem ausführlichen Blogbeitrag beschreibt Slack die Hintergründe, die den Collaboration-Dienst Ende Februar 2022 in die Knie
gezwungen haben. Es sei ein "kaskadenartiges Ausfallszenario" und ein "Lehrbeispiel für einen komplexen Systemausfall" gewesen, schreibt das Slack-Team.
Zunächst seien automatische Fehlermeldungen bemerkt worden, die gezeigt hätten, dass User Verbindungsprobleme haben. Startet der Nutzer eine Slack-Sitzung werden gemäss dem Unternehmen im Boot-Prozess Daten wie Channel-Listen, Benutzereinstellungen und die letzten Unterhaltungen von den Slack-Servern geholt und auf dem Client zwischengespeichert. Slack sei erst erreichbar, wenn der Client gebootet ist, führen die Autoren aus.
Unabhängig davon habe man dann auch Probleme durch einen deutlichen Anstieg der Last der Datenbanksysteme erkannt. "Aufgrund der überlasteten Datenbankebene dauerten die Client-Boot-Anfragen viel länger als gewöhnlich und schlugen oft fehl", heisst es weiter. Diese langsamen Anfragen hätten Ressourcen erschöpft und verhindert, "dass andere Anfragen von Benutzern, die Clients gebootet hatten, erfolgreich waren".
Drosseln, zu schnelles ent-drosseln
Aufgrund der Überlastung habe man beschlossen, die Boot-Requests der Clients zu drosseln. Dies habe zwar bedeutet, dass Benutzer ohne gebootete Clients sich wahrscheinlich nicht verbinden können. Aber für Nutzer mit gebooteten Clients habe man so einen relativ normalen Service wiederherstellen können.
Die Drosselung habe "bis zu einem gewissen Grad" funktioniert. "Die Anzahl der Fehler, die wir behoben haben, wurde reduziert, und Benutzer mit hochgefahrenen Clients begannen eine normalere Leistung zu sehen", führt Slack aus.
Man habe deshalb versucht, die Anzahl der erlaubten Boot-Vorgänge wieder zu erhöhen. "Bei unserem ersten Versuch wurde das Limit jedoch zu stark angehoben", wodurch die Datenbanklast "erneut über die Grenzen des Erträglichen hinaus" stieg, so der Blogeintrag.
Komplexe Interaktion von Elementen
Aber wie habe es passieren können, dass man von einer stabilen Situation in einen Zustand der Überlastung geriet, fragen die Blog-Autoren. "Die Antwort lag in den komplexen Interaktionen zwischen unserer Anwendung, den Vitess-Datenspeichern, dem Caching-System und unserem Service-Discovery-System."
Vitess ist eine Datenbanklösung für die Bereitstellung, Skalierung und Verwaltung grosser Cluster von Open-Source-Datenbankinstanzen.
Angefangen habe alles mit einem Upgrade des Service-Discovery-Systems Consul. Wie schon zuvor habe man jeweils 25% der Server aktualisiert. Dies habe zunächst geklappt, aber mit der gestiegenen Last durch die Clients, sei es zu bislang unbekannten Problemen gekommen.
Mit den Upgrades von Consul seien nach und nach die davon überwachten Cache-Knoten offline genommen worden, so der Blogbeitrag. Die Cache-Hit-Rate habe sich immer stärker verringert. Da die Abfragen im Cache nicht erfolgreich gewesen seien, wurden die eigentlichen Datenbanken verstärkt angefragt. Diese seien aufgrund einer spezifischen Anfrage und der Verteilung der angefragten Daten im System immer mehr unter Last geraten. Die Systeme hätten schliesslich einen Kipppunkt erreicht, ab dem sich der Fehler selbst weiter verstärkte.
Im Blogeintrag bietet Slack detailliertere Informationen über den Vorfall
. "Wir haben im Laufe unserer Karriere viel von den Geschichten anderer über das Versagen verteilter Systeme gelernt, und wir hoffen, dass Sie etwas von unserer Geschichte", schliessen die Autoren.