Optimasi Kecepatan Respons Server Autentikasi

• Identifikasi masalah
  • Terjadi keterlambatan respons sesekali pada server autentikasi Airbridge.
  • Karena autentikasi/otorisasi dilakukan sebelum permintaan API, keterlambatan pada server autentikasi berdampak langsung pada stabilitas seluruh layanan.
  • Hasil pemantauan menunjukkan peringatan keterlambatan respons di atas 1 detik makin sering muncul → analisis penyebab dan pekerjaan optimasi pun dimulai.
• Analisis penyebab
  • (1) DB Query berlebihan: dalam proses pemeriksaan izin, DB Query terjadi secara berlebihan pada setiap permintaan, sehingga DB Connection Pool cepat habis → menimbulkan keterlambatan respons.
  • (2) Saturasi HikariCP Connection Pool: saat DB Query dijalankan secara berlebihan, pool HikariCP menjadi jenuh → terkonfirmasi adanya thread yang menunggu lebih dari 30 detik.
  • (3) Efisiensi cache rendah: TTL diatur singkat, yaitu 30 detik + logika caching yang tidak efisien → kemungkinan DB Query berulang menjadi tinggi.
• Strategi perbaikan
  • (1) Perbaikan struktur pemeriksaan izin dan caching
    • Menerapkan metode pengambilan massal DB (findAllBy~) → DB Query berkurang dari 134 kali menjadi 4 kali (-97%).
    • Menerapkan caching mutableMap berbasis memori aplikasi.
    • Menerapkan prinsip tanggung jawab tunggal (SRP) → pemisahan metode dan penetapan strategi cache untuk tiap logika turunan.
  • (2) Penerapan struktur cache 2-layer
    • Menerapkan struktur campuran Local Cache (Caffeine, L1) + Remote Cache (Redis, L2).
    • Strategi cache dirinci menjadi L1-Only, L2-Only, dan Hybrid untuk meningkatkan efisiensi operasional.
    • Analisis penggunaan memori cache → diperkirakan 500 ribu key Redis, kebutuhan memori sekitar 190MB, dengan buffer aman yang telah disiapkan.
  • (3) Invalidation cache berbasis Redis Pub/Sub
    • Lepas dari ketergantungan pada TTL, sinkronisasi cache dilakukan secara real-time saat informasi izin berubah.
    • Jika ada perubahan di satu server, Local Cache di semua server langsung diinvalidate secara sinkron melalui channel Redis.
  • (4) Tuning connection pool HikariCP
    • maximum-pool-size diperbesar dari 10 menjadi 30.
    • Opsi detail seperti Connection Timeout, Idle Timeout, dan Max Lifetime dioptimalkan → mengurangi kontensi DB I/O.
• Uji performa dan hasil: performa tetap stabil bahkan pada trafik skala besar.
• Dampak perbaikan di lingkungan produksi
  • Setelah deploy, peringatan keterlambatan respons menghilang dan waktu respons keseluruhan menjadi stabil.
  • Keandalan layanan dan stabilitas operasional meningkat secara signifikan.
• Optimasi tambahan: JVM Warm-Up
  • Ditemukan masalah keterlambatan respons permintaan awal akibat jeda kompilasi JIT sesaat setelah deploy.
  • Penerapan Warm-Up Runner:
    • Menjalankan dummy request terlebih dahulu saat aplikasi mulai.
    • Saat K8s Pod diganti, trafik diproses setelah JIT selesai → waktu respons awal dipangkas dari 1.07s menjadi 94ms.
• Kesimpulan dan dampak
  • Masalah keterlambatan respons terselesaikan + struktur untuk menghadapi lonjakan trafik berhasil disiapkan.
  • Stabilitas dan keandalan seluruh layanan Airbridge meningkat.
  • Pemanfaatan server autentikasi meningkat sehingga produktivitas pengembangan layanan domain ikut naik.

[anona]

Akhir-akhir ini, sepertinya perusahaan yang menggunakan layanan ini bertambah karena penghentian layanan deep link Google.
Semoga layanannya tetap stabil!

[daumkakao]

Eh... perusahaan kami juga baru-baru ini menandatangani kontrak di sini, dan kalian benar-benar bekerja keras untuk meningkatkan performa ya!!!