• Harga
Masuk
  1. Rumah
  2. Blog
  3. Rekayasa
  4. Menstabilisasi Keycloak di Scale: Alat Debug & Investigasi
stabilizing-keycloak-at-scale

Menstabilisasi Keycloak di Scale: Alat Debug & Investigasi

oleh Silvan Jegen

Kamu juga dapat membaca artikel ini di Jerman, Inggris dan Italia.

Staf Teknisi Perangkat Lunak Smallpdf, Silvan Jegen melihat tantangan yang ditemui dengan autentikasi Keycloak dan solusi untuk menyelesaikannya.

Di Smallpdf, kami memperkenalkan Keycloak untuk autentikasi mulai dari musim panas tahun 2021. Layaknya implementasi baru lainnya, benar-benar bukanlah proses yang mulus dan malah memakan waktu lebih lama dari yang diharapkan. Dalam artikel ini, Staf Teknisi Perangkat Lunak Smallpdf, Silvan Jegen, menggali lebih dalam mengenai isu yang ditemukan dan teknik yang digunakan untuk investigasi dan debug.

Isu Stabilitas

 

Pengaturan awal kami terdiri dari beberapa instance Keycloak, masing-masing dengan cache Infinispan tersemat. Ketika kami memasukkan instance ini ke dalam produksi, kami langsung mengalami masalah stabilitas, di mana node kehabisan memori dan di-restart. Restart ini juga mengakibatkan sesi pengguna hilang, dan membuat pengguna dikeluarkan.

Beberapa bulan percobaan tentang cara mengatasi masalah stabilitas ini. Kami mencoba berbagai kombinasi cache Infinispan tersemat dan eksternal dengan pilihan persistensi yang berbeda. Untuk sementara, kami menggunakan pilihan persistensi SIFS untuk cache Infinispan eksternal, namun setelah sekitar dua minggu, pengaturan ini mengakibatkan kerusakan.

Akhirnya, kami menggunakan pengaturan dengan beberapa instance Keycloak, semuanya terhubung ke cluster Infinispan eksternal. Ketika kami menyediakan node yang cukup untuk mempertahankan beban produksi baik di sisi Keycloak maupun sisi Infinispan, kami kembali muncul dengan sistem produksi yang stabil.

Seperti apa proses menemukan pengaturan kami saat ini?

Pengujian Beban Pengalaman kami menggunakan Keycloak+Infinispan dengan RocksDB menunjukkan bahwa beban kerja produksi kami tidak sedekat kondisi pengujian beban seperti yang kami duga. Langkah pertama yang kami ambil untuk memastikan bahwa pemadaman ini tidak akan terjadi lagi adalah dengan memanfaatkan pengujian beban lebih lanjut.

Alat yang kami gunakan untuk ini adalah "k6," yang memungkinkan kami untuk menghasilkan permintaan dengan kontrol yang halus (berkat skrip JavaScript) dan menyesuaikan cara pengirimannya (contohnya frekuensi, durasi, dll.).

Kami harus beralih dari sistem autentikasi lama, maka kami perlu mengirim permintaan hibah langsung ke instans Keycloak kami, yang akan meniru pembuatan banyak sesi di kluster kami. Untuk melakukannya, kami menggunakan skrip berikut:

Untuk menjalankan skrip ini dengan "k6" selama satu jam menggunakan 16 koneksi TCP untuk mengirim permintaan secara paralel, Anda dapat menggunakan baris perintah berikut:

Catatan: ketika menggunakan skrip ini, kamu membuat beberapa sesi pemberian langsung untuk akun pengguna yang sama. Ini bisa jadi atau bukan yang sebenarnya ingin kamu tes.

Menyelesaikan Masalah

Menggunakan "k6" untuk memuat sesi dan memeriksa metrik dan log JVM yang kami kumpulkan dalam observasi kami memungkinkan kami untuk memverifikasi apakah pengaturan yang kami atur untuk mendukung beban produksi kami dapat diandalkan.

Memuat sesi di Infinispan dengan "k6" secara langsung alih-alih mengirimnya ke Keycloak ternyata tidak cukup akurat mencerminkan apa yang akan terjadi ketika kami menempatkan Keycloak bersama dengan Infinispan dalam produksi. Oleh karena itu, demi hasil terbaik, kami sarankan untuk memuat sesi dengan mengirim permintaan ke Keycloak menggunakan skrip di atas daripada memuatnya langsung di Infinispan—meskipun ini akan lebih cepat.

Sesi yang Hilang

 

Setelah kluster Keycloak dan Infinispan kami stabil, kami memperkirakan jumlah Kesalahan Token Refresh akan turun dibandingkan pengamatan kami sebelumnya. Jumlah error-nya sebenarnya turun, tetapi masih lebih tinggi dari perkiraan kami, yang berarti bahwa ribuan pengguna masih "ditendang" setiap harinya, saat mereka mencoba me-refresh token akses mereka, yang muncul malah error.

Mendapatkan Lebih Banyak Info

Untuk men-debug masalah ini, pertama-tama kami mengecek log peristiwa yang disertakan dengan Keycloak. Namun, tingkat log default yang ditetapkan terlalu tinggi untuk mendapatkan informasi yang kami inginkan. Maka itu, untuk mendapatkan log yang lebih rinci, kami mengatur levelnya ke "DEBUG." Akan membantu untuk mengingat bahwa ini dapat membuat banyak data yang kemungkinan besar akan menyebabkan masalah bila kamu menyimpan log peristiwa di Keycloak DB terkait dan memiliki lalu lintas yang substansial.

Log yang diperoleh dengan cara ini masih tidak berisi detail kesalahan yang kami perlukan untuk mengidentifikasi sumber Kesalahan Token Refresh ini. Kami akhirnya menambal kode instance Keycloak untuk menambahkan lebih banyak detail dibanding yang kesalahan generik berikan, beserta semua ID sesi-nya. Sesi ID memungkinkan kami untuk menyocokkan Kesalahan Refresh Token dengan lebih mudah dengan peristiwa "Login-nya.

Info tambahan ini kemudian akan mengarahkan kami ke arah yang benar: sebagian besar Kesalahan Refresh Token kami disebabkan oleh kesalahan "sesi tidak ditemukan". Ini menunjukkan bahwa Keycloak tidak menemukan sesi pengguna kami setelah beberapa waktu berlalu, meskipun jangka waktu hingga sesi hilang tampaknya sangat bervariasi.

Membuat Pengaturan yang Terkontrol

Langkah selanjutnya adalah mereproduksi masalah dalam lingkungan yang terkendali. Kami menemukan bahwa cara terbaik untuk melakukan ini adalah dengan membuat pengaturan Keycloak+Infinispan lokal yang dapat kami kirimi permintaan menggunakan Postman. Dengan menggunakan pengaturan lokal ini, kami dapat meningkatkan level log menjadi "TRACE" tanpa tenggelam dalam peristiwa, karena tidak ada lalu lintas produksi yang perlu dipedulikan.

Tingkat debug "TRACE" memungkinkan kami untuk melihat bahwa sesi baru pada awalnya berhasil diambil dari Infinispan setelah pembuatan. Namun, setelah beberapa waktu berlalu, Keycloak akan mencoba untuk mengambil sesi di sisi Infinispan dan sesi tersebut akan hilang tanpa alasan yang jelas.

Ternyata mengusir dan mengingat kembali sesi dari disk dua kali berturut-turut mengakibatkan sesi tidak ditemukan pada saat permintaan token refresh berikutnya. Alasannya masih belum diketahui. Sesi menghilang adalah sumber Kesalahan Token Refresh yang kami amati di lingkungan produksi kami.

Jadi Apa yang Kita Pelajari?

 

Men-debug Keycloak sangatlah rumit, terutama bila kamu menjalankannya dengan kluster Infinispan eksternal. Dengan metrik JVM dan log yang sudah ada mungkin tidaklah cukup.

Dalam hal ini, bergantung pada pengaturan lokal untuk mereproduksi masalah yang kamu alami merupakan cara terbaik untuk dicoba — bahkan jika itu mengharuskan kamu untuk menambal Keycloak demi mendapatkan data yang kamu butuhkan untuk men-debug masalah setelahnya.

Jangan lupa untuk melakukan beberapa pengujian beban yang tepat untuk perubahan yang kamu buat pada pengaturan Keycloak kamu. Berdasarkan pengalaman kami, ini mungkin dapat membantu kamu menyelesaikan beberapa masalah dalam produksi!

Terima kasih khususnya kepada Sam Smith dan Zhandos Zhylkaidar atas wawasan dan kontribusi mereka untuk artikel ini.

Menikmati artikel ini? Nantikan info lebih lanjut, wawasan, dan tips dari para teknisi di Smallpdf yang akan segera hadir di blog.

Artikel diterjemahkan ke Bahasa Indonesia oleh Marcelina

silvan-jegen
Silvan Jegen
Staf Teknisi Perangkat Lunak @Smallpdf