Behebung des Problems mit der Service-Instabilität von Kagi.com
- Untersuchung läuft – Nach einem Deployment trat ein Problem auf, und das Team arbeitet an der Behebung. (12. Januar, 16:45 UTC)
- Monitoring – Eine Konfigurationsänderung, die als Ursache des Problems vermutet wird, wurde zurückgenommen, und es wird fortlaufend überwacht, ob der Service in den Normalzustand zurückkehrt. (12. Januar, 18:30 UTC)
- Update – Um die Stabilität vollständig wiederherzustellen, wird der Traffic vorübergehend gestoppt und die Nutzer werden auf diese Seite umgeleitet. Weitere Details werden bereitgestellt, sobald sich die Lage entwickelt, während der Service kontrolliert wieder hochgefahren wird. (12. Januar, 20:26 UTC)
- Monitoring – Der Traffic wurde wiederhergestellt, und es wird weiterhin überwacht, ob der Service vollständig in den Normalzustand zurückkehrt. (12. Januar, 21:14 UTC)
- Behoben – Alle Services laufen wieder normal. Es wird den Nutzern dafür gedankt, dass sie auf die Behebung gewartet haben.
Postmortem
- Zac, der technische Leiter von Kagi, hat ein ausführliches Postmortem zum Ausfall der vergangenen Woche veröffentlicht.
- Als Reaktion auf den Vorfall arbeiteten Staff Engineer Seth und DevOps Engineer Luan gemeinsam an der Behebung.
- Es gab Akteure, die den Service missbrauchten und Engpässe in der Infrastruktur ausnutzten; es wurden sofortige Gegenmaßnahmen ergriffen, und in mehreren Bereichen von Code und Kommunikation laufen Verbesserungen.
Ablauf des Vorfalls
- Am 12. Januar gegen 17:30 Uhr wurde durch internes Monitoring und Problemmeldungen von Nutzern erkannt, dass ein Infrastrukturproblem aufgetreten war.
- Die Art des Problems führte bei Nutzern in verschiedenen Regionen zu langsamen Ladezeiten oder Timeouts von Seiten.
- Die Behebung nahm erhebliche Zeit in Anspruch; hier werden Hintergrund, Verlauf und die weiteren Pläne erläutert.
Technischer Ablauf der Fehlerbehebung
- Zunächst trat das Problem zufällig gleichzeitig mit einem Upgrade zusätzlicher RAM-Ressourcen für eine VM auf.
- Das Monitoring meldete hohe Latenzen sowie Probleme mit dem Database-Connection-Pool der Anwendung.
- Der Connection-Pool war ausgelastet, was bedeutete, dass die Gesamtzahl der Verbindungen das konfigurierte Maximum überschritt.
- Während der interne Zustand der Datenbank und die Query-Performance bewertet wurden, wurden einige Instanzen ersetzt, um zu testen, ob sich die Überlastung dadurch verringern lässt.
- Da es hilfreich zu sein schien, einige Instanzen auszutauschen, wurde der Nutzer-Traffic vorübergehend pausiert, um alle Connection-Pools auf einmal vollständig zurückzusetzen.
- Bei der Untersuchung des Datenbankzustands wurde klar, dass eine hohe Contention auf Zeilen in der Nutzertabelle die eigentliche Ursache war.
- Diese Contention erhöhte die Write-Latenz stark, erzeugte Backpressure auf den Connection-Pool der Anwendung und führte schließlich dazu, dass alle verfügbaren Verbindungen erschöpft waren.
- Kagi hatte bislang die günstigste Single-Core-Datenbank verwendet, die auf GCP verfügbar war, was das Risiko mit sich brachte, dass die Datenbank leicht lahmgelegt werden konnte.
- Es wurden böswillige Akteure identifiziert: darunter Konten, die innerhalb von 24 Stunden erstellt worden waren, sowie ein einzelnes Nutzerkonto, das in kurzer Zeit mehr als 60.000 Suchanfragen ausgeführt hatte.
- Für dieses Konto wurde die Suchfunktion entfernt, und es wurde ein Hotfix veröffentlicht, der den konkreten Schreibvorgang deaktivierte, der das Problem verursacht hatte.
- Bis Mitternacht war das Problem vollständig behoben, und es wird weiterhin genau überwacht, ob die Akteure zurückkehren.
Weitere Maßnahmen
- Aus diesem Vorfall wurde viel gelernt, und es laufen bereits unmittelbare Pläne, das System weiter zu härten und die Kommunikationsprozesse bei Störungen zu verbessern.
- Zunächst wird eingeräumt, dass die Updates auf der Statusseite nicht schnell genug waren.
- Es soll auf eine Statusseiten-Plattform gewechselt werden, über die sich automatisiertes internes Monitoring leichter für Nutzer sichtbar machen lässt, damit der Zustand der Plattform in Echtzeit nachvollziehbar ist.
- Die problemverursachenden Queries werden direkt entschärft, und es laufen Lasttests, um festzustellen, ob es weitere ähnliche Schwachstellen gibt.
- Zusätzliche Monitoring-Lösungen werden eingerichtet, damit in der Infrastruktur schneller an die richtige Stelle gezeigt wird und keine Zeit mehr damit verloren geht, wie in diesem Fall falschen Signalen nachzugehen.
- Die Systeme zur Erkennung solcher Formen des Missbrauchs werden verstärkt; da dies nicht nur Performance-Auswirkungen hat, sondern auch direkte Kosten verursacht, müssen automatisierte Limits eingerichtet und durchgesetzt werden.
- Neue Limits sind zum Zeitpunkt dieses Beitrags bereits in Kraft, und ihre Auswirkungen werden beobachtet und bei Bedarf weiter angepasst.
- Wer glaubt, dass der Zugriff auf Kagi fälschlich blockiert wurde, soll sich an support@kagi.com wenden.
Meinung von GN⁺
- Kagi hatte mit Write-Latenzproblemen durch Zeilen-Contention in der Nutzertabelle zu kämpfen, was Backpressure auf den Connection-Pool der Anwendung auslöste und zum Ausfall des Services führte.
- Diese Probleme waren eine Folge des Risikos, das daraus entstand, dass Kagi die günstigste Single-Core-Datenbank auf GCP verwendete.
- Das Kagi-Team zeigt mit Maßnahmen wie der Härtung des Systems, verbesserter Kommunikation mit den Nutzern und der Einführung automatisierter Limits zur Verhinderung von Missbrauch den Willen, Stabilität und Transparenz des Services zu erhöhen. Diese Bemühungen spiegeln KAGIs Absicht wider, den Nutzern einen verlässlicheren Service zu bieten.
1 Kommentare
Hacker-News-Meinungen
Anfangs stellte sich heraus, dass es reiner Zufall war, dass das Infrastruktur-Upgrade, bei dem einer VM RAM hinzugefügt wurde, und die Störung exakt zur gleichen Zeit auftraten. Aber solche „Zufälle“ passieren wirklich häufig und bringen einen während der Fehlersuche dazu, ihre bloße Existenz infrage zu stellen.
Wenn man in diesem Zustand in Panik gerät, schiebt man am Ende einen Hotfix nach, der etwas anderes kaputtmacht, und ab dann wird es deutlich schmerzhafter.
Murphys Gesetz ist grausam zu Systemadministratoren und Entwicklern.
Einer meiner Lieblingssätze lautet: „Wenn du nicht weißt, warum/wie du es behoben hast, hast du es vielleicht gar nicht wirklich behoben.“
„Zum Glück“ hatte es nichts mit meiner Abfrage zu tun, aber wenn zwei solche Zufälle zusammenkommen, ist das wirklich beängstigend.
Nachdem ich so etwas oft genug erlebt habe, habe ich mir angewöhnt, mehr Annahmen zu hinterfragen und Dinge, die noch nicht verifiziert sind, nicht als gesicherte Daten zu markieren.
Voreingenommenheit und vorschnelle Schlüsse habe ich damit nicht vollständig beseitigt, aber es hat geholfen; offen zu bleiben ist ziemlich schwierig.
Eine wichtige Fähigkeit für Engineers ist es, Änderungen im Incident Response kritisch zu durchdenken, zu debuggen und „isoliert zu testen“. Das ist viel schwieriger, als es aussieht, und liegt normalerweise eher im Bereich von Senior-Kompetenz.
Ich war einer der Nutzer, die dieses Problem auf Discord gemeldet haben. Ich mag Kagi, aber es war ziemlich enttäuschend, dass die Statusseite anzeigte, alles sei normal.
Es wirkte beunruhigend, als hätte die Statusseite selbst bei einer Störung mit Auswirkungen auf echte Nutzer keine Priorität, und ich hoffe, dass sie künftig korrekt aktualisiert wird.
Dienste, auf die ich mich früher stark verlassen habe, zum Beispiel GitHub, haben ihre Statusseite sofort aktualisiert. Dadurch konnte ich beruhigt sein, weil ich wusste, dass das Problem nicht auf meinem Gerät lag, sondern ein vom Dienst erkanntes Problem war.
Diesmal musste ich vor dem Schneefall an diesem Tag ein geöffnetes Lebensmittelgeschäft in der Nähe finden, und am Ende musste ich zu Google wechseln, was etwas enttäuschend war.
Trotzdem war Kagi in 99,9 % der Zeit, in der ich es genutzt habe, besser als Google, daher werde ich es weiter verwenden, und ich hoffe, dass sie den Code der Statusseite wie im Postmortem beschrieben auf einen anderen Dienst/eine andere Plattform umziehen.
Am Ende wird schon das Einstellen von irgendetwas auf die Statusseite zu einer eigenen Diskussion, und diese Diskussion frisst Zeit und Aufmerksamkeit der Engineers, wodurch sich die Behebung der Störung entsprechend verzögert.
Man muss eine Balance zwischen Kommunikation und tatsächlicher Wiederherstellung finden, und die richtige Antwort ist nicht immer klar.
Wenn genug Leute da sind, kann ein Technical Incident Manager die Kommunikation übernehmen und man kann zusätzlich Engineers auf die Kommunikationsseite setzen, aber das ist nicht immer möglich. Manche Systeme sind speziell, schlecht dokumentiert und unzureichend instrumentiert.
Persönlich bevorzuge ich es, sobald Anzeichen für ein Problem sichtbar sind, eine große, vage Meldung „Wir untersuchen ein mögliches Problem“ zu veröffentlichen und später Details nachzutragen oder sie zurückzuziehen. Aber die Unternehmen, in denen ich gearbeitet habe, mochten diese Idee nicht.
Damals hat mich Kagi richtig gepackt, und ich habe einige Suchanfragen hin und her ausprobiert. Doch da LLMs, Perplexity und Google immer häufiger direkt auf der Suchseite antworten, bleiben nicht mehr viele Anfragen für Kagi übrig.
Wenn Kagi irgendwie mit Perplexity zusammenkäme, fände ich das ziemlich interessant.
Oft wird es sogar bis zum Ende gar nicht angezeigt.
Diese Störung kommt mir so bekannt vor, dass es fast erstaunlich ist.
Ich habe persönlich öfter genau diese Art von Störung behandelt, als ich zugeben möchte, und bin wie das Kagi-Team in das Rabbit Hole des Zustands des Datenbank-Connection-Pools geraten, habe dieselben Gegenmaßnahmen versucht, etwa neue Instanzen dazuzustellen oder zu glauben, dass ein „Reset“ des Traffics das Problem löst – alles vergeblich.
Bei solchen Störungen hilft es auch nicht, dass die üblichen Sättigungsmetriken der Datenbank wie CPU-Auslastung, IOPS usw. sich kaum bewegen. Die Query-Latenz sieht hoch aus, aber man denkt: „CPU und IOPS haben ja noch Luft …“, und übersieht, wie so oft, dass Lock Contention dahintersteckt.
Meiner Erfahrung nach stammen 98 % der Auffälligkeiten im DB-Connection-Pool aus Problemen in der Datenbank selbst. Ich weiß nicht, welche relationale Datenbank Kagi verwendet, aber ich würde dringend empfehlen, die globale I/O-Wartezeit (Sekunden/Sekunde), die globale Lock-Acquisition-Zeit (Sekunden/Sekunde) und die Ausführungszeit pro normalisierter Query (Sekunden/Sekunde) der DB zu grafen.
Nimmt man noch ein Diagramm zur CPU-Auslastung dazu, ergibt das ein Dashboard, mit dem sich die meisten größeren Performance-Probleme schnell identifizieren lassen.
Abgesehen davon überrascht es mich etwas, dass Suchanfragen Schreibvorgänge in einer relationalen Datenbank auslösen. Ich hätte gedacht, dass die relationale Datenbank nur für Dinge wie Benutzereinstellungen und Login-Verwaltung genutzt wird.
Wenn Kagi Nutzungsaggregation, zum Beispiel das Erhöhen von Zählern, in der relationalen Datenbank macht, ist das ein sehr typischer Failure Mode, der bei wachsender Größe explodiert.
Durch Suchen kann es indirekte Schreibvorgänge geben, etwa wenn man Suchergebnisse blockiert, und Verlauf oder Analytics gibt es natürlich auch.
Trotzdem ist nicht klar, was bei jeder einzelnen Suche Write-Lock-Contention verursachen könnte.
Das passiert irgendwann jedem Startup. Ich habe es selbst erlebt, und es ist wirklich schmerzhaft.
Manchmal fehlen Zeit oder Ressourcen, um die Fähigkeiten aufzubauen, die solche Probleme verhindern, und manchmal rechnet man nicht einmal damit, dass ein bestimmtes Problem tatsächlich auftreten kann, bis es einen kalt erwischt.
Transparenz ist wichtig, Lernen ebenso, aber manchmal ist auch eine Entschädigung wichtig. Kagi sollte in Erwägung ziehen, für die Zeit, in der der Dienst nicht nutzbar war, Such-Credits bereitzustellen.
Zumal sie selbst eingeräumt haben, dass die Echtzeit-Reaktion unzureichend war.
Ein Ausfall eines kostenpflichtigen Dienstes ist nicht dasselbe wie ein Ausfall eines Dienstes, bei dem „der Nutzer das Produkt ist“.
Das zeigt einiges darüber, wie weit die Observability der internen Systeme geht.
Es ist leicht zu sagen, man hätte es früher bemerken müssen, aber mit passenden Datadog-Dashboards und Splunk-Queries wäre es viel schneller offensichtlich geworden.
Ich hoffe, sie nutzen das als Lernchance und investieren in besseres Monitoring.
Das Ganze war zu 100 % eine Lernerfahrung, aber ich kann zur Observability etwas mehr Kontext geben.
Kagi ist ein kleines Team, und es gibt faktisch 3 Personen, die auf solche Ereignisse reagieren können, verteilt auf 3 Zeitzonen. Für mich und den Kernentwickler ist das die erste Phase unserer Web-Karriere; wir sind keine Silicon-Valley-Veteranen, die all das schon einmal durchgemacht haben.
Dass wir viel zu lernen haben, ist selbstverständlich, aber da wir Kagi von null aufgebaut haben, bin ich stolz auf den Weg, den wir bisher zurückgelegt haben, und auf die Richtung, in die wir gehen.
Observability nehmen wir seit etwa den letzten 6 Monaten ernster. Inzwischen haben wir viele Dashboards sowie Alerts, die direkt in die Chat-Kanäle des Unternehmens gehen und die zuständigen Leute pingen.
Als Hauptverantwortlicher für die DB ist GCP Query Insights eine große Hilfe. Auch während des Ausfalls schlug das Monitoring an, und Query Insights zeigte die „schuldige“ Query, aber selbst mit allem Monitoring der Welt kann einem die Erfahrung fehlen, die eigentliche Ursache oder die effizienteste Gegenmaßnahme zu interpretieren.
Anders gesagt: Uns fehlt noch die Weisheit, uns nicht selbst von dem, was unsere Systeme anzeigen, gaslighten zu lassen, wenn wir nicht vorsichtig sind. Rückblickend kann ich sagen, dass GCP Query Insights zu 100 % richtig lag und es kein Bug im Applikationsbereich war.
Dank des Wachstums können wir das Team nun deutlich erweitern; wir hatten auch früher schon SRE-Beratung und wollen uns künftig weiter durch Vollzeit- oder Teilzeit-Unterstützung verbessern.
Heißt das, ein einzelner Nutzer hat einen Scraper laufen lassen und den Dienst 7 Stunden lang lahmgelegt? Ich weiß, von außen ist es leicht zu sagen „das hättet ihr erwarten müssen“, aber es ist schon seltsam, dass beim Testen niemand gefragt hat: „Was passiert, wenn extrem viele Suchanfragen auftreten?“
https://news.ycombinator.com/item?id=39019936
Kurz gesagt: Wir sind ein sehr kleines, junges Team mit wenigen Schlüsselpersonen, und alle tragen mehrere Hüte gleichzeitig. Ein dediziertes SRE-Team haben wir noch nicht.
Zu „Was passiert, wenn extrem viele Suchanfragen auftreten?“: Wenn man sich https://kagi.com/stats ansieht, sieht man, dass bereits „viele Suchanfragen“ stattfinden und wir uns 400.000 pro Tag nähern. Im Alltag läuft das System mit ausreichend Reservekapazität, und es gibt auch einige automatische Skalierungsmaßnahmen.
Das Problem lag in den Details, dass einige Nutzer einen pathologischen Fall ausgenutzt haben. Wegen unserer mangelnden Erfahrung wussten wir nicht, welchen natürlichen oder pathologischen Traffic wir im Voraus hätten vorhersagen und simulieren können.
20.000 gleichzeitige Suchnutzer als Last zu simulieren klingt nach einem Experiment, das man früh machen könnte, und etwas Ähnliches haben wir auch gemacht. Aber mit Blick auf diesen Ausfall hätte selbst das dieses Problem wohl nicht gefunden.
Bisher gab es etwa 10 Leute, die Security-Scanner gegen den produktiven Dienst laufen ließen, und der dabei entstehende Traffic war höher als bei diesem Ausfall.
Diese Art von Entwicklung gegen den Bau von Features auszubalancieren, ist sehr schwierig, und wir hätten eindeutig mehr tun müssen. Wie ich an anderer Stelle gesagt habe, wollen wir das Team in naher Zukunft erweitern, damit wir bei solchen Anstrengungen nicht zu dünn aufgestellt sind.
Im Nachhinein lässt sich viel sagen, aber ich hoffe, ich konnte transparenter vermitteln, wie wir an diesen Punkt gekommen sind.
Besonders dann nicht, wenn jemand zum ersten Mal auf diese Weise darauf eingeschlagen hat.
Zum Vergleich: Die Systeme, mit denen ich arbeite, sind nicht auf FAANG-Niveau, aber gemessen an der Request-Rate definitiv größer als Kagi. Kagi wird schnell lernen, und wenn in der Zwischenzeit weitere solche Probleme auftreten, finde ich das bis zu einem gewissen Grad sogar in Ordnung. Es ist auch ein Zeichen dafür, dass sie sich in die richtige Richtung bewegen.
Als zahlender Kagi-Nutzer habe ich nach der Downtime gemerkt, wie sehr ich die Zuverlässigkeit von Google für selbstverständlich gehalten habe.
Google war für mich in den letzten 20 Jahren, bis auf vielleicht ein einziges Mal, nie down. Den Zugriff auf eine Suchmaschine zu verlieren, ist ziemlich einschneidend.
Ich mag Kagi wirklich sehr und zahle dafür, aber im zweiten Nutzungsmonat Downtime zu erleben, hat einen ziemlich schlechten Beigeschmack. Ich schätze Postmortems, aber ich hoffe, sie nicht lesen zu müssen.
Trotzdem hoffe ich, dass Kagi durch diese Erfahrung zu einem robusteren und zuverlässigeren Dienst wird.
Eine Suchmaschine ist kein Dienst mit Lock-in-Effekt wie ein E-Mail-Anbieter oder ISP.
Ich hatte mich eindeutig darauf verlassen, dass Kagi schnell ist und überall gut funktioniert.
Das erinnert mich an die Zeit, als wir bei einem Kunden einen Proof of Concept für ein neues Networking-Tool laufen ließen. Etwa 2 Minuten nach dem Start ging das gesamte Netzwerk des Kunden down.
Wir befanden uns in einem isolierten Sandbox-Bereich, daher gab es keine Möglichkeit, dass unser Produkt den kompletten Netzwerkausfall verursacht hatte, aber in meinem Kopf dachte ich: „Das kann doch nicht sein, oder … oder?!?!”
„Wir konnten später Kontakt zu dem gesperrten Konto aufnehmen; es behauptete, das Konto zum automatisierten Scraping unserer Ergebnisse genutzt zu haben, was laut unseren Nutzungsbedingungen nicht erlaubt ist.“
Für alle möglichen eingehenden RPC-/API-/HTTP-Requests, insbesondere öffentliche Requests, müssen QPS-Limits gelten.
Wir hatten eine Suchfunktion mit Autocomplete, und um Nutzer zu unterstützen, die schnell tippen, hatten wir das Rate Limiting für diesen Endpoint absichtlich entfernt.
Eines Tages gegen 6 Uhr morgens kam jemand in Tennessee zur Arbeit und legte seine Geldbörse auf die Tastatur; die Geldbörse hielt eine Taste gedrückt und begann, bei jedem Tastendruck die API zu treffen.
Natürlich wurde die DB nach etwa 15 Minuten sehr instabil, und die DB-Latenz wurde so groß, dass ein Webserver abstürzte. Es folgten Kaskadenausfälle, und der gesamte Produktionscluster ging offline.
Es versteht sich von selbst, dass an diesem Tag das Rate Limiting wieder hinzugefügt wurde.