Keycloak im großen Maßstab stabilisieren: Werkzeuge zur Fehlersuche und Untersuchung

Bei Smallpdf haben wir im Sommer 2021 Keycloak zur Authentifizierung eingeführt. Wie bei vielen neuen Implementierungen verlief der Prozess nicht reibungslos und dauerte viel länger als erwartet. In diesem Artikel beschäftigt sich Silvan Jegen, Software Engineer bei Smallpdf, mit den aufgetretenen Problemen und den Methoden, mit denen wir sie untersucht und behoben haben.

Probleme mit der Stabilität

Unser anfängliches Setup umfasste mehrere Keycloak-Instanzen, jede mit einem eingebetteten Infinispan-Cache. Als wir diese Instanzen in Betrieb nahmen, stießen wir schnell auf Stabilitätsprobleme, bei denen die Nodes keinen Speicher mehr hatten und neu gestartet werden mussten. Diese Neustarts führten auch dazu, dass die Benutzersitzungen verloren gingen und die Benutzer abgemeldet wurden.

Es folgten mehrere Monate des Experimentierens, wie wir diese Stabilitätsprobleme lösen konnten. Wir haben verschiedene Kombinationen von eingebetteten und externen Infinispan-Caches mit unterschiedlichen Persistenzoptionen ausprobiert. Eine Zeit lang nutzten wir die SIFS-Persistenzoption für einen externen Infinispan-Cache, aber nach etwa zwei Wochen führte diese Konfiguration zu einem Ausfall.

Schließlich entschieden wir uns für ein Setup mit mehreren Keycloak-Instanzen, die alle mit einem externen Infinispan-Cluster verbunden sind. Als wir genügend Nodes bereitstellten, um die Produktionslast sowohl auf der Keycloak- als auch auf der Infinispan-Seite aufrechtzuerhalten, konnten wir diese Erfahrung mit einem stabilen Produktionssystem beenden.

Wie sah der Prozess aus, um unser aktuelles Setup zu finden?

Lasttests

Unsere Erfahrungen mit Keycloak+Infinispan mit RocksDB haben uns gezeigt, dass unsere Produktionsarbeitslast nicht so nah an den Lasttestbedingungen lag, wie wir dachten. Die erste Maßnahme, die wir ergriffen haben, um sicherzustellen, dass sich diese Ausfälle nicht wiederholen, war der verstärkte Einsatz von Lasttests.

Das Tool, auf das wir dabei zurückgriffen, war „k6“, mit dem wir (dank JavaScript-Skripting) Anfragen mit feiner Steuerung generieren und die Art und Weise, wie sie gesendet werden (d.h. Häufigkeit, Dauer usw.), anpassen können.

Wir mussten von einem alten Authentifizierungssystem zu Keycloak wechseln und mussten daher direkte Grant-Anfragen an unsere Keycloak-Instanz senden, was die Erstellung vieler Sitzungen in unserem Cluster imitieren würde. Dazu haben wir das folgende Skript verwendet:

Um dieses Skript mit „k6“ eine Stunde lang mit 16 TCP-Verbindungen laufen zu lassen, um Anfragen parallel zu senden, kannst du folgende Befehlszeile verwenden:

Hinweis: Wenn du dieses Skript verwendest, erstellst du mehrere Direct Grant-Sitzungen für dasselbe Benutzerkonto. Das kann sein, muss aber nicht das sein, was du eigentlich testen willst.

Die Lösung für das Problem

Indem wir „k6“ zum Laden von Sitzungen verwenden und die JVM-Metriken und Protokolle prüfen, die wir in unserer Observability-Lösung sammeln, können wir überprüfen, ob wir erwarten können, dass unser Setup unsere Produktionslast unterstützen kann.

Es hat sich herausgestellt, dass das direkte Laden von Sessions in Infinispan mit „k6“, anstatt sie an Keycloak zu senden, nicht genau das widerspiegelt, was passieren würde, wenn wir Keycloak zusammen mit Infinispan in der Produktion einsetzen. Um die besten Ergebnisse zu erzielen, empfehlen wir daher, die Sitzungen mit dem obigen Skript an Keycloak zu senden, anstatt sie direkt in Infinispan zu laden - auch wenn das schneller geht.

Verlorene Sitzungen

Sobald unsere Keycloak- und Infinispan-Cluster stabil waren, erwarteten wir, dass die Anzahl der Refresh Token Error, die wir zuvor beobachtet hatten, zurückgehen würde. Die Fehler gingen tatsächlich zurück, aber sie waren immer noch höher als erwartet. Das bedeutet, dass immer noch täglich Tausende von Nutzern abgemeldet wurden, weil sie beim Versuch, ihr Zugriffstoken zu aktualisieren, eine Fehlermeldung erhielten.

Mehr Informationen erhalten

Um dieses Problem zu beheben, haben wir zunächst das Ereignisprotokoll von Keycloak herangezogen. Die standardmäßig eingestellte Protokollstufe war jedoch zu hoch, um die Informationen zu erhalten, die uns interessierten. Um detailliertere Protokolle zu erhalten, haben wir die Stufe auf „DEBUG“ gesetzt. Du solltest dir darüber im Klaren sein, dass dies eine Menge Daten erzeugen kann, was wahrscheinlich zu Problemen führen wird, wenn du die Ereignisprotokolle in der relationalen Keycloak-DB speicherst und einen hohen Datenverkehr hast.

Die auf diese Weise erhaltenen Logs enthielten immer noch nicht die erforderlichen Fehlerdetails, die wir benötigten, um die Quelle dieser Refresh Token Errors zu identifizieren. Am Ende haben wir den Code unserer Keycloak-Instanz gepatcht, um mehr Details als die generischen Fehler sowie die Sitzungs-IDs hinzuzufügen. Dadurch konnten wir die Refresh Token Errors leichter mit den entsprechenden „Login“-Ereignissen in Verbindung bringen.

Diese zusätzlichen Informationen wiesen uns dann in die richtige Richtung: Die große Mehrheit unserer Refresh Token-Fehler war auf „session_not_found“-Fehler zurückzuführen. Dies deutete darauf hin, dass Keycloak die Sitzungen unserer Nutzer nach einiger Zeit nicht mehr fand, obwohl die Zeit bis zum Verlust der Sitzung sehr unterschiedlich zu sein schien.

Ein kontrolliertes Setup erstellen

Der nächste Schritt bestand darin, das Problem in einer kontrollierten Umgebung zu reproduzieren. Wir fanden heraus, dass dies am besten mit einem lokalen Keycloak+Infinispan-System möglich war, an das wir mit Postman Anfragen senden konnten. Mit dieser lokalen Einrichtung konnten wir den Log-Level auf „TRACE“ erhöhen, ohne in Ereignissen zu ertrinken, da es keinen Produktionsverkehr gab, um den wir uns kümmern mussten.

Auf der Debug-Ebene „TRACE“ konnten wir sehen, dass neue Sitzungen nach der Erstellung zunächst erfolgreich von Infinispan abgerufen wurden. Nach einiger Zeit versuchte Keycloak jedoch, eine Sitzung auf der Infinispan-Seite abzurufen, und die Sitzung war ohne erkennbaren Grund verschwunden.

Es stellte sich heraus, dass das zweimalige Auslagern und Zurückholen einer Sitzung von der Festplatte dazu führte, dass die Sitzung bei der nächsten Anforderung eines Aktualisierungs-Tokens nicht mehr gefunden wurde. Der Grund dafür ist noch unbekannt. Das Verschwinden der Sitzung war die Ursache für die Refresh-Token-Fehler, die wir in unserer Produktionsumgebung beobachteten.

Was haben wir also gelernt?

Die Fehlersuche bei Keycloak ist komplex, vor allem, wenn du es mit einem ausgelagerten Infinispan-Cluster betreibst. Es kann sein, dass es nicht ausreicht, die JVM-Metriken und die Logs zur Hand zu haben.

In diesem Fall ist es am besten, ein lokales Setup zu verwenden, um das Problem zu reproduzieren - auch wenn du dafür Keycloak patchen musst, um die Daten zu erhalten, die du für die Fehlersuche brauchst.

Vergiss auch nicht, die Änderungen, die du an deinem Keycloak-Setup vornimmst, einem ordentlichen Belastungstest zu unterziehen. Unserer Erfahrung nach wird dir das in der Produktion wahrscheinlich einige Probleme ersparen!

Unser besonderer Dank gilt Sam Smith und Zhandos Zhylkaidar für ihre Einblicke und Beiträge zu diesem Artikel.

Hat dir dieser Beitrag gefallen? Halte Ausschau nach weiteren Informationen, Einblicken und Tipps von den Smallpdf-Ingenieuren, die du bald in unserem Blog findest.

Übersetzt und ins Deutsche adaptiert von Anna