Clerk: Eine versteckte Cloud-Datenbankmigration führt zu einem vollständigen Ausfall der Authentifizierung

Unternehmen und Produkt

Clerk ist eine Authentifizierungs- und Nutzerverwaltungsplattform, die für moderne Webanwendungen entwickelt wurde. Sie bietet APIs und SDKs für die Verwaltung von Nutzer-Sessions, Anmeldeabläufen und Identitätsmanagement.

Da die Authentifizierung den Einstiegspunkt der meisten Anwendungen bildet, wirkt sich jede Störung der Clerk-Dienste direkt auf den Zugriff durch die Nutzer aus. Das macht Clerk zu einer kritischen Abhängigkeit in Produktionsumgebungen.

Die Plattform stützt sich stark auf eine vom Anbieter verwaltete Cloud-Infrastruktur, einschließlich gehosteter PostgreSQL-Datenbanken, um Skalierbarkeit und Verfügbarkeit zu gewährleisten. Diese Abhängigkeit ist zwar betrieblich effizient, birgt jedoch Risiken, wenn bei vorgelagerten Anbietern Ausfälle auftreten.

Das geschah bei dem Ausfall

Der Incident begann mit einem plötzlichen Anstieg der Latenz und 5xx-Fehlern in den APIs von Clerk. Das interne Monitoring zeigte schnell erhöhte Lock-Konflikte in der Datenbank.

Die Datenbank selbst schien jedoch hinsichtlich der CPU-Auslastung in Ordnung zu sein, was ein irreführendes Signal darstellte:

• Die Abfragen schlugen nicht sofort fehl
• Aber ihre Ausführung dauerte deutlich länger

Dieser Anstieg der Latenz führte zu einem Cascading Failure:Dieser Anstieg der Latenz führte zu einem Cascading Failure:

• Langsame Abfragen verstärkten die Lock-Konflikte
• Lock-Konflikte verzögerten Transaktionen
• Verzögerte Transaktionen führten zu einer Überlastung der Rechenressourcen
• Die Auslastung führte dazu, dass eingehende Anfragen fehlschlugen

‍

Da die Rechenressourcen erschöpft waren, gab das System 429-Fehler (Too Many Requests) zurück, die direkt von einem internen Service weitergegeben wurden, anstatt in 500-Fehler umgewandelt zu werden.Ein Versuch, Read-Traffic auf Datenbankreplikate auszulagern, konnte das Problem nicht beheben, was darauf hindeutete, dass das Problem nicht im Abfragevolumen, sondern in der zugrundeliegenden Speicherlatenz lag.Schließlich aktivierte Clerk den Origin Outage Mode, einen Fallback-Mechanismus, der die Validierung von Sitzungen aufrechterhalten soll. Dadurch wurde zwar die Kernfunktionalität der Sitzungen wiederhergestellt, doch blieb das System beeinträchtigt, bis das Grundproblem behoben war.

Grundursache

‍

Die Ursache wurde auf eine fehlgeschlagene Live-Migration einer virtuellen Cloud SQL-Maschine zurückgeführt, die von Google Cloud durchgeführt wurde.

Live-Migrationen sind in der Regel so konzipiert, dass sie transparent und ohne Ausfallzeiten ablaufen. Nicht jedoch in diesem Fall:

• Die Migration führte zu erheblicher Festplattenlatenz
• Dies führte zu Leseverzögerungen, ohne dass die Schreibaktivität zunahm
• Die Latenz löste Lock-Konflikte in der Datenbank aus, was zu einem vollständigen Dienstausfall führte.

Entscheidende Faktoren:

• Diese Migrationen sind für Clerk weder sichtbar noch planbar
• Es erfolgt keine Vorankündigung
• Sie können während der Ausführung nicht sicher auf ein Replikat umgeschaltet werden.

Ein Replica-Failover ist während einer Live-Migration unsicher, was bedeutet, dass sich Teams während des laufenden Vorgangs nicht auf herkömmliche Failover-Strategien verlassen können. Dies erhöht das Abhängigkeitsrisiko gegenüber dem zugrunde liegenden Anbieter erheblich.

Dies macht Live-Migrationen zu einem risikoreichen, wenig transparenten Ausfallmodus für Systeme, die auf verwaltete Datenbanken angewiesen sind.

Zeitlicher Ablauf

• 15:57 UTC: Alarmierungen wegen erhöhter Latenz und 5xx-Fehlern; Incident ausgerufen
• 16:10 UTC: Origin Outage Mode aktiviert; Sitzungsvalidierung wiederhergestellt
• 16:23 UTC: Der Incident wird automatisch gelöst, sobald die Migration abgeschlossen istch dem Incident: Bestätigung der Grundursache durch Google Cloud
• Nach dem Incident: Bestätigung der Grundursache durch Google Cloud

‍

‍Zeit bis zur Erkennung (TTD): ca. 1 Minute
Zeit bis zur Behebung (TTR): ca. 26 Minuten

Wer war betroffen?

Bei allen Anwendungen, die während des Incidents für die Authentifizierung auf Clerk angewiesen waren, kam es zu Beeinträchtigungen oder Fehlern bei Anmelde- und Sitzungsanfragen.

Besonders schwerwiegend waren die Auswirkungen für:

• Anwendungen mit hohem Authentifizierungsanfragenvolumen
• Systeme ohne Ausweichmechanismen für die Authentifizierung
• Workloads, die auf eine Echtzeit-Sitzungsvalidierung angewiesen sind

Wie reagierte Clerk?

Clerk reagierte schnell, indem folgende Maßnahmen ergriffen wurden:

• Erkennung des Problems mithilfe von Monitoring- und Alarmierungssystemen
• Versuche zur Abhilfe durch Read-Replica-Routing
• Aktivierung des Origin Outage Mode zur Aufrechterhaltung der Sitzungsfunktionalität
• Eskalation des Problems an Google Cloud

Nach dem Incident leitete Clerk mehrere langfristige Abhilfemaßnahmen ein:

• Einführung von Database Pinning, um zukünftige Live-Migrationen zu vermeiden
• Ersatz zukünftiger Live-Migrationen durch kontrollierte Replica Promotion
• Bewertung alternativer Datenbankstrategien, einschließlich selbst gehosteter Optionen

Darüber hinaus verlagerte Clerk einen erheblichen Teil seiner technischen Ressourcen auf Initiativen zur Verbesserung der Zuverlässigkeit und räumte der Systemstabilität Vorrang vor der Entwicklung neuer Funktionen ein.

Wie kommunizierte Clerk?

Clerk kommunizierte transparent durch ein detailliertes, öffentlich zugängliches Postmortem.

Die Kommunikation umfasste:

• Eine klare Timeline der Ereignisse
• Übernahme der Verantwortung
• Eine technische Erklärung der Ursachen
• Konkrete Abhilfemaßnahmen

Bemerkenswert ist, dass Clerk sich dafür entschied, seinen vorgelagerten Anbieter namentlich zu nennen, und damit Verantwortlichkeit und Klarheit gegenüber einer abstrakten Darstellung in den Vordergrund stellte.

Wichtige Erkenntnisse für andere Teams

• Risiken durch undurchsichtige Infrastruktur. Managed Services können versteckte Vorgänge (wie Live-Migrationen) mit sich bringen, die außerhalb Ihrer Kontrolle liegen, aber dennoch die Verfügbarkeit beeinträchtigen können.
• Latenz ist genauso gefährlich wie Ausfallzeiten. Systeme können „intakt“ erscheinen, während eine verschlechterte Latenz unbemerkt Kaskadenausfälle verursacht.
• Kaskadenausfallmuster. Datenbank-Latenz → Lock-Konflikte → Überlastung der Rechenressourcen → Anforderungsfehler ist eine kritische Kette, die überwacht und gemindert werden muss.
• Failover-Einschränkungen in verwalteten Systemen.❗ Ein Replica-Failover kann während bestimmter Provider-Vorgänge (wie Live-Migrationen) unsicher sein, wodurch ein wichtiger Wiederherstellungsmechanismus bei Incidents wegfällt.
• Resilienzmechanismen müssen unter Last skalierbar sein. Fallback-Modi müssen auch dann funktionieren, wenn Rechenressourcen begrenzt sind.
• Risiken durch Abhängigkeit von einem einzigen Anbieter vermeiden. Kritische Infrastrukturen sollten nach Möglichkeit Strategien für Failover, Redundanz oder Anbieterunabhängigkeit beinhalten.

Zusammenfassung

Clerk erlebte einen SEV-1-Ausfall, der durch eine fehlgeschlagene Live-Migration von Google Cloud SQL verursacht wurde. Die daraus resultierende Festplattenlatenz löste Lock-Konflikte und eine Auslastung der Rechenressourcen aus, was zu weitreichenden Authentifizierungsfehlern führte. Der Incident verdeutlicht die Risiken undurchsichtiger Cloud-Abläufe und die Grenzen des Failovers bei vom Anbieter kontrollierten Ereignissen.

So kann ilert helfen

Incidents wie der Ausfall bei Clerk verdeutlichen, wie schnell sich Ausfälle auf Infrastrukturebene ausbreiten können, während sie gleichzeitig schwer zu diagnostizieren sind. ilert kann zwar Ausfälle bei vorgelagerten Anbietern nicht verhindern, reduziert jedoch die Erkennungszeit, den Untersuchungsaufwand und die Komplexität der Koordinierung von Reaktionen erheblich.

‍

•  Erweiterte Alarmierung: Korrelieren Sie Latenzspitzen, Fehlerraten und Sättigungssignale, um Frühindikatoren für Kettenausfälle aufzudecken und Teams dabei zu helfen, systemische Probleme schneller zu identifizieren.
• Bereitschaftsmanagement: Leiten Sie SEV-1-Incidents automatisch an die richtigen Engineers (Backend-, Infrastruktur- und Datenbankspezialisten) weiter und gewährleisten Sie so eine umgehende und strukturierte Reaktion.
• ChatOps-Koordination: Zentralisieren Sie Untersuchungsschritte, Abhilfemaßnahmen und Hypothesen in Echtzeit und vermeiden Sie so eine fragmentierte Kommunikation bei Incidents unter hohem zeitlichen Druck.
• ‍Statusseiten: Kommunizieren Sie Ausfälle der Authentifizierung und Leistungseinbußen klar an Endnutzer, um Unsicherheiten und Supportaufwand während eines Incidents zu reduzieren.