Postmortem zum Kagi-Vorfall der vergangenen Woche

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 [e-mail] 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.

[GN⁺]

Hacker-News-Kommentare

• Meinungen zu dem Vorfall, der zeitgleich mit einem Infrastruktur-Upgrade auftrat

  • Es hieß, dass es reiner Zufall gewesen sei, dass der Vorfall genau während eines Infrastruktur-Upgrades durch zusätzliche RAM-Ressourcen für die VM auftrat.
  • Solche "Zufälle" kämen häufig vor und ließen einen bei der Fehlersuche an der eigenen Existenz zweifeln.
  • Es wird davor gewarnt, dass man in Panik während der Problemlösung einen Hotfix einspielen könne, der etwas anderes kaputtmacht, und dass dies für Systemadministratoren und Entwickler zu einer grausamen Form von Murphys Gesetz werden könne.

• Erfahrungen eines Nutzers mit der Kagi-Statusseite

  • Ein Nutzer sagte, die Kagi-Statusseite habe ihn verunsichert, weil dort angezeigt wurde, dass alles normal funktioniere.
  • Im Vergleich dazu hätten Dienste, auf die er sich früher verlassen habe, ihre Statusseiten sofort aktualisiert, sodass er erkennen konnte, dass das Problem nicht bei seinem Gerät lag.
  • Er sagte, dass er Kagi weiterhin nutzen wolle, hoffe aber, dass der Code der Statusseite wie in der Postmortem erwähnt auf einen anderen Dienst bzw. eine andere Plattform verlagert werde.

• Kommentar, der persönliche Erfahrungen teilt

  • Jemand teilte, dass er persönlich mehrmals dieselbe Art von Dienstausfall erlebt habe und versucht habe, Probleme mit dem Gesundheitszustand des Datenbank-Connection-Pools zu beheben.
  • Es wird darauf hingewiesen, dass sich typische Sättigungsmetriken der Datenbank (CPU %, IOPS usw.) während solcher Ausfälle kaum verändern und stattdessen Lock-Contention die Ursache sein könne.
  • Als Empfehlung für das von Kagi verwendete RDBMS wurde vorgeschlagen, globale I/O-Wartezeiten, Zeiten für den Lock-Erwerb und Query-Ausführungszeiten grafisch darzustellen.

• Kommentar zu den Erfahrungen von Startups

  • Es wurde gesagt, dass jedes Startup irgendwann mit solchen Problemen konfrontiert werde.
  • Möglicherweise habe man nicht genug Zeit oder Ressourcen, um Fähigkeiten aufzubauen, die das Problem verhindern könnten, oder man habe nicht damit gerechnet, dass genau dieses Problem auftritt.
  • Transparenz und Lernen seien wichtig, aber manchmal seien auch Entschädigungen wichtig; daher wurde vorgeschlagen, dass Kagi Search-Credits für die Zeit in Betracht ziehen sollte, in der der Dienst nicht verfügbar war.

• Kommentar zur Observability interner Systeme

  • Es wurde angemerkt, dass das Problem früher hätte erkannt werden müssen und dass die richtigen Datadog-Dashboards und Splunk-Queries das Problem deutlich schneller hätten klar machen sollen.
  • Es wurde geraten, in besseres Monitoring zu investieren und dies als Lernerfahrung zu nutzen.

• Meinung eines zahlenden Nutzers zur Zuverlässigkeit von Kagi

  • Ein zahlender Nutzer, der den Ausfall von Kagi erlebt hatte, sagte, ihm sei klar geworden, dass er die Zuverlässigkeit von Google für selbstverständlich gehalten habe.
  • Er erwähnte, dass der Verlust des Zugangs zu einer Suchmaschine ein großes Hindernis sein könne, und teilte mit, dass er Kagi liebe, es aber unangenehm gewesen sei, den Ausfall zu erleben.
  • Er hoffe, dass diese Erfahrung Kagi zu einem stärkeren und zuverlässigeren Dienst mache.

• Kommentar zu dem Scraper, der den Dienstausfall verursacht hat

  • Angesichts der Tatsache, dass ein von einem Nutzer ausgeführter Scraper den Dienst für sieben Stunden lahmgelegt habe, wurde die Frage aufgeworfen, ob beim Testen nicht gefragt wurde: "Was passiert, wenn sehr viele Suchanfragen eingehen?"

• Kommentar zu Nutzungserfahrungen mit Kagi und zum Postmortem

  • Nach einigen Wochen Nutzung von Kagi teilte jemand mit, dass er letzte Woche nicht gewusst habe, was er tun solle, als es nicht sofort lud.
  • Er erwähnte, dass er den Vorfall bereits vergessen gehabt habe, noch bevor das Postmortem erschien, und dankte dem Team dafür, dass Suchvorgänge etwas seien, über das man nicht nachdenken müsse.

• Kommentar zur auf GCP verwendeten Single-Core-Datenbank

  • Es wurde positiv darauf reagiert, dass Kagi auf GCP die günstigste verfügbare Single-Core-Datenbank verwendet hatte.
  • Es wurde vorgeschlagen, etwas wie PolyScale in Betracht zu ziehen, um einen plötzlichen Anstieg der Leselast zu bewältigen und die Performance weiter zu steigern.

• Kommentar zu automatisiertem Scraping

  • Es wurde erwähnt, dass ein Nutzer, der nach der Sperrung seines Kontos Kontakt aufgenommen hatte, behauptet habe, das Konto zum automatisierten Scrapen der Ergebnisse verwendet zu haben.
  • Es wurde empfohlen, QPS-Limits (Queries per Second) für alle eingehenden RPC-/API-/HTTP-Anfragen festzulegen, insbesondere für öffentliche.