Belajar Caddy - Failover & Circuit Breaking

#Pendahuluan

Backend akan gagal. Server restart, proses hang, memory penuh — itu bagian dari kehidupan produksi. Pertanyaannya bukan apakah kegagalan terjadi, tapi bagaimana sistem kalian meresponsnya. Episode 16 membahas mekanisme failover dan circuit breaking di Caddy.

Kalian akan belajar dua jenis health check (pasif dan aktif), kebijakan retry yang aman, dan pola circuit breaker yang mencegah request membebani backend yang sedang sakit. Terakhir, kita lihat bagaimana menyusun high availability dengan banyak instance Caddy.

Tujuan akhir: ketika satu komponen mati, pengguna tidak merasakan apa-apa.

#Passive Health Checks

#Mendeteksi Kegagalan dari Request

Passive health check tidak mem-probe backend. Sebaliknya, Caddy menilai dari respons request yang sebenarnya:

app.example.com {
    reverse_proxy {
        to localhost:8080 localhost:8081 localhost:8082
        max_fails 2
        fail_duration 15s
    }
}

• max_fails 2 — dua kegagalan berturut-turut menandai backend tidak sehat.
• fail_duration 15s — jendela waktu di mana kegagalan dihitung.

Backend yang gagal dikeluarkan dari pool secara otomatis dan dicoba kembali setelah beberapa saat. Ini lapisan pertahanan pertama yang ringan.

#Pemulihan Otomatis

Backend yang dikeluarkan akan dimasukkan kembali setelah periode tertentu. Caddy menguji ulang backend tersebut dengan request nyata — jika berhasil, backend kembali ke pool. Tidak ada intervensi manual.

#Active Health Checks

#Probe Latar Belakang

Active health check mem-probe backend secara berkala, bahkan tanpa request dari pengguna:

app.example.com {
    reverse_proxy {
        to localhost:8080 localhost:8081
        health_uri /healthz
        health_interval 10s
        health_timeout 5s
        health_fails 3
        health_passes 2
        health_expected_status 200
    }
}

Opsi lengkap:

• health_uri /healthz — endpoint yang diprobed.
• health_interval 10s — interval probe.
• health_timeout 5s — batas waktu respons probe.
• health_fails 3 — tiga probe gagal berturut-turut = tidak sehat.
• health_passes 2 — dua probe sukses berturut-turut = sehat kembali.
• health_expected_status 200 — status code yang dianggap sukses.

health_expected_status 200 memastikan probe dianggap sukses hanya jika backend mengembalikan 200 — bukan sekadar koneksi terbuka.

#Custom Health Endpoint

Endpoint health yang baik harus merefleksikan kesehatan aplikasi, bukan hanya proses. Sebuah aplikasi bisa hidup tapi tidak bisa memproses request (misalnya database putus). Pastikan /healthz di aplikasi memeriksa dependency penting.

#Retry Policy

#Kapan Retry Aman

Caddy bisa mengulang request ke backend lain saat backend pertama gagal:

app.example.com {
    reverse_proxy {
        to localhost:8080 localhost:8081
        try_duration 10s
        try_interval 250ms
    }
}

try_duration 10s memberi Caddy waktu 10 detik untuk mencoba backend lain; try_interval 250ms mengatur jeda antar percobaan.

#Idempotent Methods Only

Retry otomatis sebaiknya dibatasi untuk request idempotent — yang aman diulang tanpa efek ganda:

• Aman: GET, HEAD, PUT, DELETE.
• Berbahaya: POST — bisa membuat duplikat transaksi.

Caddy secara default mengulang request yang dianggap idempotent atau yang sudah dikirim sebagian. Untuk POST yang sensitif, lebih baik biarkan gagal daripada membuat duplikat.

#Pola Circuit Breaker

#State Open, Closed, dan Half-Open

Circuit breaker melindungi backend yang sedang sakit dari banjir request:

• Closed: request mengalir normal.
• Open: setelah kegagalan melewati ambang, semua request ditolak langsung.
• Half-open: setelah waktu pemulihan, satu request uji diizinkan; jika sukses kembali ke closed.

Di Caddy, perilaku ini muncul dari kombinasi health check dan batas kegagalan:

app.example.com {
    reverse_proxy {
        to localhost:8080 localhost:8081
        max_fails 1
        fail_duration 10s
        try_duration 5s
    }
}

Satu kegagalan langsung menandai backend, request diarahkan ke backend lain, dan backend yang gagal punya waktu pulih — esensi circuit breaking tanpa plugin tambahan.

#Fallback Response

Ketika semua backend gagal, berikan respons yang jelas:

app.example.com {
    reverse_proxy {
        to localhost:8080 localhost:8081
    }
    handle_errors {
        @down {
            expression {http_error.status_code} >= 502
        }
        handle @down {
            respond "Layanan sedang dalam perawatan" 503
        }
    }
}

expression {http_error.status_code} >= 502 menangkap error gateway dan menampilkan halaman maintenance — pengguna mendapat pesan jelas, bukan layar putih.## High Availability Setup

#Banyak Instance Caddy

Satu instance Caddy adalah single point of failure. Untuk ketersediaan tinggi:

• Jalankan dua atau lebih instance Caddy di server berbeda.
• Letakkan load balancer eksternal (haproxy, cloud LB, atau DNS) di depan.
• Bagikan storage sertifikat agar semua instance memakai sertifikat yang sama.

Kombinasi dengan keepalived + VRRP untuk virtual IP, atau DNS-based failover, memastikan traffic tetap mengalir saat satu instance mati.

#Storage Bersama

Sertifikat ACME harus dibagi antar instance. Tanpa storage bersama, setiap instance meminta sertifikat sendiri dan renewal bisa bentrok. Opsi:

• Shared filesystem (NFS) — lokasi storage yang sama.
• Distributed storage (Redis, S3) lewat plugin.
• Satu instance mengelola issuance, sisanya membaca hasilnya.

#Penutup

Episode 16 membangun ketahanan layanan: passive health check dengan max_fails, active health check dengan health_uri dan ambang gagal/sukses, retry policy yang aman untuk method idempotent, pola circuit breaker, dan high availability dengan banyak instance serta storage bersama.

Inti yang harus dibawa pulang:

• Passive health check menilai dari request nyata, aktif mem-probe berkala.
• health_expected_status 200 memastikan probe menilai kesehatan aplikasi.
• Retry aman untuk method idempotent; hati-hati dengan POST.
• Circuit breaker mencegah backend sakit dibanjiri request.
• Siapkan fallback respons saat semua backend down.
• HA butuh banyak instance, load balancer, dan storage bersama.

Di episode 17 selanjutnya kita masuk ke basic authentication — directive basicauth, hashing password dengan caddy hash-password, melindungi seluruh situs atau path tertentu, beberapa user, dan use case seperti admin panel serta staging environment. Keamanan dasar menanti.