Belajar Authelia - Performance Tuning

#Pendahuluan

Episode 27 membuat Authelia aman: data bisa dipulihkan kapan pun. Sekarang kalian menambahkan pengguna — puluhan, ratusan, ribuan. Pertanyaan berikutnya muncul: apakah gerbang ini tetap cepat saat semua orang login bersamaan? Episode 28 menjawabnya: performance tuning.

Authelia ditulis dalam Go dan sangat ringan — pada idle ia memakai memori di bawah beberapa puluh megabyte. Artinya, bottleneck hampir tidak pernah ada di binary Authelia itu sendiri. Titik yang perlu diperhatikan justru di sekitarnya: koneksi ke Redis, pool koneksi database, dan reverse proxy di depan. Tuning yang baik adalah mengurangi kerja-kerja yang sebenarnya tidak perlu dilakukan.

#Ukur Dulu, Tuning Kemudian

Aturan pertama yang sudah kalian pelajari di episode-episode sebelumnya: jangan menyetel tanpa baseline. Sebelum mengubah apa pun, buat angka dasar dengan benchmark. Mulai dari endpoint kesehatan yang paling ringan — misalnya dengan hey -n 10000 -c 100 http://127.0.0.1:9091/api/health:

hey -n 10000 -c 100 http://127.0.0.1:9091/api/health

Lalu benchmark alur yang lebih realistis — endpoint verify dengan cookie sesi dan header Remote-User, seperti yang dilakukan reverse proxy setiap request:

hey -n 5000 -c 50 \
  -H "Cookie: authelia_session=<nilai-cookie>" \
  -H "Remote-User: arman" \
  "https://auth.example.com/api/verify?rm=0"

Catat angka requests per second dan latensi p50/p99. Ubah satu variabel, ukur lagi, bandingkan. Semua optimasi di episode ini adalah siklus itu — ukur, ubah, ukur lagi.

#Tuning Redis: Penyimpan Sesi

Redis adalah komponen yang paling sering bersinggungan dengan request. Setiap verify dan setiap akses sesi menyentuhnya, jadi koneksi dan kebijakan memorinya berpengaruh langsung.

Authelia mengelola pool koneksi Redis sendiri. Nilai maximum_active_connections dan minimum_idle_connections menentukan berapa banyak koneksi paralel yang dipertahankan:

session:
  redis:
    host: redis
    port: 6379
    database_index: 0
    maximum_active_connections: 16
    minimum_idle_connections: 4

Di sisi server Redis, perhatikan kebijakan memori. Sesi Authelia memakai TTL, jadi eviction volatile-lru — hanya membuang key yang punya TTL — adalah pilihan yang tepat; key non-sesi yang mungkin kalian simpan di instance yang sama tidak akan terusir:

maxmemory 1gb
maxmemory-policy volatile-lru
appendonly yes
appendfsync everysec

appendonly yes dengan fsync per detik memberi keseimbangan antara ketahanan sesi (episode 27) dan performa tulis. Jika sesi tidak perlu bertahan dari restart, RDB snapshot saja sudah cukup dan lebih cepat. Verifikasi kebijakan yang sedang aktif dengan redis-cli CONFIG GET maxmemory-policy.

#Tuning Database: Pool dan Maintenance

Authelia menulis ke database hanya saat ada perubahan — login pertama, registrasi MFA, token OIDC. Itu membuat database bukan jalur kritis per request, kecuali satu hal: koneksi yang boros. Setiap instance Authelia membuka pool koneksinya sendiri; dengan banyak replica, total koneksi bisa menumpuk.

Setel pool per instance seperlunya, lalu jaga totalnya jauh di bawah max_connections PostgreSQL:

storage:
  postgres:
    address: tcp://postgres:5432
    database: authelia
    username: authelia
    password: '<password>'
    maximum_active_connections: 12
    minimum_idle_connections: 2

Rumus kasar: max_connections PostgreSQL dikurangi koneksi untuk maintenance, dibagi jumlah instance Authelia. Untuk skala menengah, pool 8-12 per instance sudah berlebih. PgBouncer di depan PostgreSQL memecahkan masalah many instances, one database dengan membagi koneksi dari pool kecil.

Jangan lupa maintenance rutin. Nyalakan autovacuum (default aktif) agar tabel yang sering ditulis tidak membengkak, dan pantau long-running query lewat monitoring dari episode 26. Cek kesehatan koneksi secara berkala dengan psql -U authelia -h postgres -d authelia -c "SELECT 1". Skema Authelia memiliki indeksnya sendiri — jangan membuat indeks tambahan tanpa data beban yang menunjukkan butuh.

#Tuning Reverse Proxy

Karena semua trafik melewati proxy, di sinilah keuntungan terbesar bisa didapat dengan sedikit usaha:

• Connection keep-alive. Setiap request yang membuka koneksi TCP baru ke Authelia membayar biaya handshake. Dengan keepalive, koneksi dipakai ulang:

upstream authelia {
    server authelia-1:9091;
    server authelia-2:9091;
    keepalive 32;
}
 
server {
    listen 443 ssl;
    server_name auth.example.com;
 
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
 
    location / {
        proxy_pass http://authelia;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

• Cache aset statis. Halaman login Authelia memuat CSS dan JavaScript yang jarang berubah. Proxy bisa menyajikan dari cache tanpa menyentuh Authelia sama sekali — potongan kerja paling mudah yang bisa dihilangkan.
• TLS session resumption. ssl_session_cache membuat handshake TLS singkat untuk koneksi berulang — menurunkan latensi pengguna lama secara nyata.

#Horizontal Scaling dan Capacity Planning

Authelia sudah dirancang untuk digandakan secara horizontal — persis yang dibangun di episode 24 dan 25. Saat beban naik, menambah instance lebih mudah daripada menggeser-geser konfigurasi. Tapi perhatikan dua batas yang tidak ikut bertambah:

1. Koneksi ke Redis. Setiap instance membuka pool; pastikan total koneksi di bawah kapasitas Redis.
2. Koneksi ke database. Sama ceritanya — inilah alasan PgBouncer muncul.

Untuk capacity planning, mulai dari angka nyata bukan tebakan: ukur jumlah sesi aktif puncak (metrik Redis atau log), hitung RPS autentikasi dari metrik authelia_authn_total di episode 26, lalu kalikan dengan aturan praktis: satu instance Authelia modern dengan mudah menangani ratusan RPS verifikasi. Untuk ribuan pengguna dengan puncak bersamaan, dua sampai empat instance hampir selalu cukup. Beri ruang 2-3 kali dari kebutuhan puncak, dan gunakan HPA (episode 25) agar scaling otomatis saat lonjakan.

#Penutup

Episode 28 ini melatih kalian menyetel performa dengan data: membuat baseline dengan benchmark hey pada endpoint health dan verify, menyetel pool koneksi Redis dan kebijakan eviction volatile-lru, menjaga pool database tetap kecil dengan PgBouncer sebagai payung, mengoptimalkan reverse proxy lewat keep-alive, cache aset statis, dan TLS session resumption, serta melakukan capacity planning yang berbasis angka.

Poin kunci:

• Ukur dulu; benchmark health dan verify sebelum mengubah apa pun.
• Redis harus punya maxmemory-policy volatile-lru agar sesi TTL dieviction dengan benar.
• Pool koneksi database adalah sumber masalah paling umum di banyak instance.
• Keep-alive dan cache aset statis adalah optimasi proxy dengan rasio hasil terbaik.
• Batas scaling bukan CPU Authelia, melainkan koneksi ke Redis dan database.

Bahkan dengan konfigurasi terbaik, akan datang hari di mana sesuatu rusak. Di episode 29 kita bedah Troubleshooting & Debugging: 503 dari proxy, redirect loop, masalah sesi, TOTP gagal, hingga cara membaca log dan memvalidasi konfigurasi. Sampai jumpa di episode 29!