Belajar Keycloak - Performance Tuning & Monitoring

#Pendahuluan

Di episode 27 kalian membangun cluster yang tahan gagal. Episode 28 ini membuatnya cepat dan terukur: performance tuning agar Keycloak melayani banyak login tanpa membengkak, dan monitoring agar kalian tahu kapan harus bertindak sebelum pengguna mengeluh. Tuning tanpa metrik adalah menebak; metrik tanpa tuning adalah menonton.

#Optimasi JVM & Sumber Daya

Keycloak berjalan di atas JVM, dan memori adalah pengaturan pertama yang harus diperhatikan:

• Heap size — atur lewat variabel KC_HEAP. Heap yang terlalu kecil memicu GC terus-menerus; terlalu besar menyia-nyiakan RAM dan memperlama GC.
• Garbage collection — pilih GC yang sesuai profil beban; untuk layanan dengan lonjakan login, GC yang lebih sering tapi pendek biasanya lebih baik daripada pause panjang.
• Thread pool — jumlah worker menentukan berapa request yang bisa diproses bersamaan; sesuaikan dengan core CPU.
• Database pool — pool koneksi harus cukup untuk menyerap lonjakan, tapi tidak melebihi kapasitas database.

KC_HEAP=2g \
KC_DB_POOL_MIN_SIZE=5 \
KC_DB_POOL_MAX_SIZE=50 \
kc.sh start

KC_HEAP=2g menetapkan batas memori; KC_DB_POOL_MIN_SIZE dan KC_DB_POOL_MAX_SIZE mengatur jumlah koneksi database. Untuk instance kecil mulai dari 2 GB heap; untuk beban enterprise dengan ribuan login bersamaan, naikkan bertahap sambil mengamati metrik. Setiap penambahan node cluster (episode 27) juga berarti menambah permintaan ke database — sesuaikan pool di kedua sisi.

Sebagai aturan praktis: ubah satu variabel pada satu waktu, lalu amati dampaknya terhadap response time dan GC. Mengubah heap, pool, dan cache sekaligus membuat kalian tidak tahu perubahan mana yang sebenarnya berpengaruh.

#Caching

Sebagian besar kecepatan Keycloak berasal dari cache Infinispan. Cache yang relevan:

Ukuran cache harus cukup untuk menampung populasi user aktif, tapi jangan boros memori. Cache invalidation dikelola Keycloak secara otomatis saat data berubah; dalam cluster, perubahan di satu node disebarkan lewat JGroups sehingga cache tetap konsisten. Untuk beban sangat besar, session store bisa dipindahkan ke database agar memori tidak penuh — trade-off antara kecepatan dan skala yang harus kalian putuskan berdasarkan pengukuran, bukan perasaan.

#Monitoring

Tanpa pengamatan, tuning tidak ada arahnya. Aktifkan metrik Keycloak:

KC_METRICS_ENABLED=true kc.sh start --optimized

Dengan KC_METRICS_ENABLED=true, Keycloak memaparkan metrik Prometheus di endpoint /metrics. Prometheus lalu menariknya secara berkala:

scrape_configs:
  - job_name: keycloak
    metrics_path: /metrics
    static_configs:
      - targets: ["sso.example.com:8080"]

Data metrik kemudian divisualkan dengan dashboard Grafana — banyak dashboard Keycloak community yang siap pakai. Untuk detail internal JVM, gunakan JMX (misalnya lewat JConsole atau ekspor ke Prometheus dengan JMX exporter). Log terpusat memakai ELK atau Loki membantu korelasi antar node; APM (Application Performance Monitoring) memberi jejak permintaan dari load balancer sampai database.

Setelah metrik masuk, susun alerting: alarm login rate yang turun, error rate yang naik, dan cache hit ratio yang turun adalah tiga pemicu yang paling sering menyelamatkan tim dari insiden. Grafana bisa dihubungkan ke Alertmanager atau notifikasi lain, sehingga respons tidak bergantung pada siapa yang kebetulan membuka dashboard.

#Key Metrics

Inilah metrik yang sebaiknya selalu kalian pantau:

Selain metrik Prometheus, manfaatkan endpoint health yang sudah dipakai di episode 27: /health/live untuk kelayakan proses, /health/ready untuk kesiapan melayani, dan /health/started untuk status startup. Alarm kesehatan inilah yang memberi tahu load balancer dan tim on-call kalian.

#Capacity Planning

Monitoring menjawab "apa yang terjadi sekarang"; capacity planning menjawab "apa yang terjadi bulan depan":

• User load estimation — proyeksikan jumlah user aktif dan login per jam dari tren pertumbuhan.
• Resource sizing — terjemahkan perkiraan beban menjadi jumlah node, heap, dan ukuran database.
• Scalability testing — buktikan dengan beban nyata bahwa tambahan node benar-benar menambah kapasitas.
• Growth projections — rencanakan headroom: jangan tunggu metrik menyentuh batas untuk menambah sumber daya.

Proses yang disarankan untuk capacity planning:

1. Catat baseline beban saat ini dari metrik yang sudah dipasang.
2. Proyeksikan pertumbuhan pengguna dari roadmap bisnis, bukan asumsi.
3. Ukur dampak setiap skenario lewat load testing di lingkungan staging.
4. Susun rencana penambahan sumber daya jauh sebelum batas tercapai.
5. Tinjau ulang proyeksi setiap kuartal agar tetap relevan.

#Penutup

Episode 28 melengkapi cluster kalian dengan kecepatan dan penglihatan: tuning JVM lewat KC_HEAP, pool database, dan cache; metrik Prometheus lewat KC_METRICS_ENABLED=true; visualisasi Grafana; pengamatan JMX dan log terpusat; metrik-metrik kunci; serta capacity planning berbasis tren.

Inti yang harus dibawa pulang:

• Tuning butuh metrik — ukur dulu, ubah satu variabel, ukur lagi.
• Cache adalah sumber kecepatan utama — pantau hit ratio dan ukuran cache realms, users, sessions.
• Health endpoints adalah komunikasi pertama — live, ready, started memberi sinyal ke load balancer dan alerting.
• Kapasitas direncanakan, bukan direaksikan — headroom harus ada sebelum metrik menyentuh batas.

Di episode 29 berikutnya, kalian melindungi semua kerja keras ini: backup, disaster recovery & upgrades — dari backup database dan konfigurasi, RTO dan RPO, sampai upgrade versi yang aman.