Home
Strumenti
Documenti
Cerca
  • Prezzi
  1. Home
  2. Blog
  3. Ingegneria
  4. Stabilizzare Keycloak su larga scala: strumenti per la ricerca e il debugging
stabilizing-keycloak-at-scale

Stabilizzare Keycloak su larga scala: strumenti per la ricerca e il debugging

di Silvan Jegen

Puoi anche leggere questo articolo in Tedesco, Inglese, Francese, Indonesiano e Portoghese.

Silvan Jegen, Software Engineer a Smallpdf, parla dei problemi incontrati nell’autenticazione Keycloak e di ciò che ha fatto per risolverli.

Qui a Smallpdf abbiamo introdotto Keycloak per l’autenticazione nell’estate del 2021. Come sempre quando si implementa qualcosa di nuovo, non è stato un processo privo di difficoltà e ci è voluto più tempo del previsto. In questo articolo, Silvan Jegen, Software Engineer presso Smallpdf, approfondisce le difficoltà incontrate e le tecniche che ha utilizzato per la ricerca e il debugging.

Problemi legati alla stabilità

 

Il nostro setup iniziale prevedeva diverse istanze Keycloak, ciascuna con una cache Infinispan embeddata. Quando abbiamo messo queste istanze in produzione, abbiamo presto riscontrato problemi di stabilità, per cui i nodi hanno esaurito la memoria e si sono riavviati. Questi riavvii hanno provocato la perdita di alcune sessioni utente e ciò ha provocato il logout di questi utenti.

Abbiamo in seguito trascorso diversi mesi sperimentando diversi metodi per risolvere questi problemi di stabilità. Abbiamo provato diverse combinazioni di cache Infinispan embeddate ed esterne, con diverse opzioni di persistenza. Per un po’, abbiamo usato l’opzione di persistenza SIFS per una cache Infinispan esterna ma, dopo due settimane, questo setup ha provocato un downtime.

Alla fine abbiamo deciso di optare per un setup con diverse istanze Keycloak, tutte connesse a un cluster Infinispan esterno. Quando abbiamo fornito abbastanza nodi per essere in grado di sostenere il carico in produzione sia per quanto riguarda Keycloak che Infinispan, abbiamo ottenuto un sistema di produzione stabile.

Qual è stato il processo che ha condotto al nostro setup attuale?

Test di carico

La nostra esperienza con Keycloak e Infinispan con RocksDB ci ha dimostrato che il nostro carico di lavoro in produzione si discostava dalle condizioni del test di carico. La prima misura adottata per assicurarci che questi downtime non avessero più luogo è stata intraprendere più test di carico.

Il tool che abbiamo utilizzato per farlo è stato “k6”, che ci permette di generare richieste con un livello di controllo avanzato (grazie allo scripting in Javascript) e di personalizzare il modo in cui sono inviate (ad esempio la frequenza, la durata, etc.).

Siamo partiti da un sistema di autenticazione legacy, così abbiamo avuto bisogno di inviare le richieste di concessione di autorizzazione dirette alla nostra istanza Keycloak, che ha simulato la creazione di molte sessioni sul nostro cluster. Per farlo, abbiamo utilizzato il seguente script:

Se vuoi eseguire questo script con “k6” per un’ora, usando 16 connessioni TCP per inviare richieste in parallelo, puoi usare il seguente comando:

Nota bene: utilizzando questo script, creerai diverse sessioni di accesso per lo stesso account utente. Questo potrebbe essere ciò che vuoi testare oppure no.

Risolvere il problema

 

Usare “k6” per caricare le sessioni e controllare le metriche JVM e i log che raccogliamo nelle nostre soluzioni di osservabilità ci permette di verificare se il nostro setup sarà in grado di supportare il nostro carico di lavoro in produzione.

Ci siamo resi conto che caricare le sessioni direttamente in Infinispan con “k6”, invece di inviarle a Keycloak, non riflette accuratamente ciò che potrebbe succedere quando mettiamo Keycloak in produzione insieme a Infinispan. Quindi, per ottenere i migliori risultati, consigliamo di caricare le sessioni inviando le richieste a Keycloak e utilizzando lo script qui in alto e di non caricarle direttamente in Infinispan, anche se questa soluzione è più rapida.

Sessioni perse

 

Una volta che i nostri cluster Keycloak e Infinispan si sono stabilizzati, pensavamo che il numero dei errori di aggiornamento del token, che avevamo osservato in precedenza diminuissero. Gli errori sono di fatto diminuiti, ma erano comunque più del previsto e ogni giorno migliaia di utenti venivano ancora disconnessi, perché quando provavamo ad aggiornare il loro token di accesso, veniva loro notificato un errore.

Ottenere maggiori informazioni

Al fine di effettuare il debugging per questo problema, abbiamo inizialmente consultato il log degli eventi offerto da Keycloak. Tuttavia, il livello di default del log era troppo alto per ottenere le informazioni che ci interessavano. Dunque, per ottenere log più dettagliati, abbiamo impostato il livello su “DEBUG”. Bisogna essere consapevoli del fatto che ciò può generare molti dati, il che creerà quasi sicuramente problemi se stai salvando i log degli eventi nel database relazionale di Keycloak e hai un traffico notevole.

I log ottenuti in questo modo non contenevano ancora i dettagli sugli errori richiesti di cui avevamo bisogno per identificare la fonte di questi Refresh Token Errors. Alla fine abbiamo eseguito il patching del codice della nostra istanza Keycloak per ottenere maggiori dettagli rispetto agli errori generici forniti e le ID delle sessioni. Queste ultime ci hanno permesso di associare i Refresh Token Errors più facilmente con i corrispondenti eventi “Login”.

Queste informazioni aggiuntive ci hanno poi indirizzato nella giusta direzione: la stragrande maggioranza dei nostri Refresh Token Errors erano dovuti ad errori “session_not_found”. Ciò indicava che Keycloak non stava trovando le sessioni dei nostri utenti dopo che era passato un po’ di tempo, anche se il tempo trascorso prima della perdita della sessione sembrava variare ampiamente.

Creare un setup controllato

Lo step successivo è stato riprodurre il problema in un ambiente controllato. Abbiamo scoperto che il modo migliore di farlo è stato creare un setup Keycloak+Infinispan locale al quale potevamo inviare richieste utilizzando Postman. Usando questo setup locale, abbiamo potuto aumentare il livello del log fino a “TRACE” senza essere sommersi di eventi, visto che non dovevamo preoccuparci del traffico di produzione.

Il livello di debug “TRACE” ci ha permesso di vedere che le nuove sessioni erano inizialmente ripristinate con successo da Infinispan dopo la creazione. Dopo un po’ di tempo, tuttavia, Keycloak provava a ripristinare la sessione da Infinispan e la sessione scompariva senza un motivo comprensibile.

È venuto fuori che eliminare e ripristinare una sessione da disco due volte di fila, aveva come conseguenza il fatto che la sessione non veniva trovata quando si inoltrava la successiva richiesta di aggiornamento del token. Il fatto che la sessione sparisse era alla base dei Refresh Token Errors che avevamo osservato nel nostro ambiente di produzione.

In conclusione, che cosa abbiamo imparato?

 

Il debugging di Keycloak è complesso, specialmente se gira su un cluster Infinispan esternalizzato. Avere a disposizione le metriche JVM e i log potrebbe non essere abbastanza.

In questo caso, avere un setup locale che riproduca il problema che stai avendo è la soluzione migliore, anche se richiede di eseguire il patching di Keycloak per ottenere i dati che ti serviranno per il debugging in un secondo momento.

Non dimenticare di fare dei test di carico adeguati per i cambiamenti che stai operando all’interno del setup di Keycloak. In base alla nostra esperienza, ti risparmierai con ogni probabilità diversi problemi in produzione!

Ringrazio in modo speciale Sam Smith e Zhandos Zhylkaider per le loro osservazioni e i loro contributi per questo articolo.

Ti è piaciuto questo post? Dai un’occhiata alle ulteriori informazioni, agli approfondimenti e ai consigli forniti dagli ingegneri di Smallpdf presto disponibili all’interno del blog!

Articolo tradotto e adattato in italiano da Giuliana

silvan-jegen
Silvan Jegen
Ingegnere del software @Smallpdf