Belajar Authentik - High Availability Setup

#Pendahuluan

Di episode 22 kalian membangun observabilitas. Sekarang pastikan layanan itu sendiri tidak menjadi titik tunggal kegagalan. Identity provider adalah infrastruktur kritis: jika Authentik mati, semua aplikasi yang bergantung padanya ikut mati login. Episode 23 membahas high availability — beberapa replika, data layer bersama, dan load balancer.

Analoginya seperti bandara dengan satu runway: begitu landasan terganggu, semua penerbangan berhenti. HA adalah menambah runway kedua dan ketiga, serta menjaga jadwal tetap berjalan meski satu runway ditutup.

#Arsitektur HA

Arsitektur produksi Authentik yang HA:

• Beberapa replika server — melayani UI, API, dan flow execution.
• Satu atau lebih worker — memproses tugas latar seperti sinkronisasi dan event rule.
• PostgreSQL bersama — semua replika membaca dan menulis ke database yang sama.
• Redis bersama — cache, message queue, dan koordinasi antar instance.
• Load balancer — membagi request ke semua replika server.

Kuncinya: instance Authentik bersifat stateless. Semua keadaan disimpan di PostgreSQL dan Redis, sehingga menambah replika hanya soal menambah proses, bukan menyalin data.

#Stateless Server dan Penyimpanan Media

Karena server stateless, request apa pun bisa dilayani replika mana pun. Satu pengecualian: folder media (logo, favicon, dan file unggahan lain) harus di-share antar replika — lewat volume bersama di Docker atau storage terdistribusi di Kubernetes — agar aset tidak tampak hilang tergantung replika yang melayani.

#Session Storage

Sesi di Authentik menggunakan cookie bertanda tangan (JWT) yang divalidasi terhadap data di database dan Redis. Dua implikasinya:

• Tanpa sticky session — load balancer bisa memakai round-robin; setiap replika mampu memvalidasi sesi pengguna yang dibuat di replika lain.
• Sesi bertahan saat failover — karena sesi tersimpan di layer bersama, pengguna tidak akan di-logout saat satu replika mati.

#Replikasi Database dan Redis

Data layer adalah bagian yang paling sulit di-HA-kan, karena tetap harus ada satu sumber kebenaran:

• PostgreSQL — gunakan primary dengan replica, atau layanan managed yang menangani failover otomatis. Untuk beban tinggi, tambahkan connection pooling (misalnya PgBouncer) agar banyak replika server tidak menghabiskan koneksi database.
• Redis — aktifkan persistence (misalnya AOF) dan gunakan Sentinel untuk failover otomatis, atau Redis Cluster bila volume data besar.

Aturan yang tidak boleh dilanggar: semua replika Authentik harus menunjuk ke pasangan PostgreSQL dan Redis yang sama; memisahkannya per instance akan memecah state.

#Penskalaan Outpost

Outpost juga diskalakan horizontal: beberapa instance LDAP atau proxy berbagi token outpost yang sama dan bekerja paralel di belakang load balancer masing-masing. Status tiap instance terlihat di UI; jika satu mati, instance lain tetap melayani karena konfigurasi diambil dari server pusat.

#Load Balancer

Load balancer membagi lalu lintas ke replika server. Konfigurasi khas dengan NGINX:

upstream authentik {
    server authentik-server-1:9000;
    server authentik-server-2:9000;
}
 
server {
    listen 443 ssl;
    server_name auth.example.com;
 
    ssl_certificate     /etc/nginx/tls/fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/privkey.pem;
 
    location / {
        proxy_pass http://authentik;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Perhatikan header X-Forwarded-*: Authentik memakai informasi ini untuk menentukan alamat IP asli (penting untuk reputation di episode 19) dan skema HTTPS.

#Health Checks

Untuk menentukan replika mana yang layak menerima request, Authentik menyediakan dua endpoint:

• /health/live/ — proses berjalan dan merespons.
• /health/ready/ — siap melayani; memverifikasi koneksi database dan Redis.

Contoh cek cepat terhadap endpoint /health/ready/:

curl -f http://localhost:9000/health/ready/

Pasang keduanya pada health check container dan probe load balancer. ready adalah yang menentukan apakah sebuah replika boleh menerima trafik; live hanya menandakan prosesnya belum mati.

#Failover dan Recovery

Dengan arsitektur di atas, alur kegagalan menjadi sederhana:

• Satu replika server mati — load balancer mengarahkan trafik ke replika lain; sesi tetap utuh karena berada di layer bersama.
• Primary PostgreSQL mati — replica dipromosikan, atau layanan managed melakukan failover otomatis.
• Satu outpost mati — instance lain mengambil alih.

Penting: uji skenario ini secara rutin. Failover yang tidak pernah dilatih sering berakhir sebagai failover yang gagal saat benar-benar dibutuhkan.

#Contoh Docker Compose Multi-Replika

Berikut kerangka compose dengan dua replika server, satu worker, PostgreSQL, dan Redis. Perhatikan bahwa setiap server memakai database dan Redis yang sama, serta berbagi volume media:

services:
  postgres:
    image: docker.io/library/postgres:16-alpine
    environment:
      POSTGRES_USER: authentik
      POSTGRES_PASSWORD: ${AUTHENTIK_PG_PASSWORD}
      POSTGRES_DB: authentik
    volumes:
      - pg-data:/var/lib/postgresql/data
 
  redis:
    image: docker.io/library/redis:7-alpine
    command: --appendonly yes
    volumes:
      - redis-data:/data
 
  server-1:
    image: ghcr.io/goauthentik/server:2025.6
    command: server
    environment:
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY}
      AUTHENTIK_POSTGRESQL__HOST: postgres
      AUTHENTIK_POSTGRESQL__USER: authentik
      AUTHENTIK_POSTGRESQL__PASSWORD: ${AUTHENTIK_PG_PASSWORD}
      AUTHENTIK_REDIS__HOST: redis
    volumes:
      - media:/media
 
  server-2:
    image: ghcr.io/goauthentik/server:2025.6
    command: server
    environment:
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY}
      AUTHENTIK_POSTGRESQL__HOST: postgres
      AUTHENTIK_POSTGRESQL__USER: authentik
      AUTHENTIK_POSTGRESQL__PASSWORD: ${AUTHENTIK_PG_PASSWORD}
      AUTHENTIK_REDIS__HOST: redis
    volumes:
      - media:/media
 
  worker:
    image: ghcr.io/goauthentik/server:2025.6
    command: worker
    environment:
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY}
      AUTHENTIK_POSTGRESQL__HOST: postgres
      AUTHENTIK_POSTGRESQL__USER: authentik
      AUTHENTIK_POSTGRESQL__PASSWORD: ${AUTHENTIK_PG_PASSWORD}
      AUTHENTIK_REDIS__HOST: redis
 
volumes:
  pg-data:
  redis-data:
  media:

Pada penyebaran sungguhan, kedua replika biasanya berada di host berbeda (atau dikelola orkestrasi seperti Kubernetes — dibahas di episode 24), dan load balancer diletakkan di depan port 9000 kedua server.

#Penutup

Ringkasan episode 23:

• Arsitektur HA terdiri dari replika server dan worker, PostgreSQL serta Redis bersama, dan load balancer.
• Sesi berbasis cookie yang divalidasi di layer bersama membuat sticky session tidak diperlukan.
• Health check /health/live/ dan /health/ready/ menjadi dasar keputusan load balancer dan failover.
• Uji failover rutin dan tetap jalankan backup terpisah.

Di episode 24, kita bawa pola ini ke skala yang lebih terkelola: deployment Kubernetes dengan Helm chart, replika yang diatur orkestrator, dan storage persisten. Sampai jumpa!