Mitos "Load Balancer Saja Cukup"

Banyak dari kita mungkin merasa sudah aman ketika berhasil menerapkan load balancer di depan beberapa server backend. Rasanya seperti sudah punya asuransi; kalau satu server mati, yang lain masih bisa menopang. Tapi, pernahkah kamu bertanya-tanya: Bagaimana jika si pengatur lalu lintas itu sendiri yang pingsan?

Inilah jebakan Single Point of Failure (SPOF) yang sering terlupakan. Sebagus apapun backend yang kita bangun, jika pintu gerbang utamanya hanya satu dan ia tumbang, maka seluruh sistem kita akan ikut 'gelap'. Dalam artikel kali ini, saya ingin mengajak teman-teman untuk melihat lebih jauh melampaui konsep distribusi beban biasa. Kita akan membedah bagaimana membangun arsitektur High Availability yang sebenarnya—sebuah sistem yang tidak hanya tangguh di level aplikasi, tapi juga memiliki mekanisme pertahanan diri saat infrastrukturnya mengalami kegagalan

Redundansi di Level Aplikasi

Pada tahap awal pengembangan, kita sering kali memulai dengan satu server tunggal. Namun, seiring bertambahnya trafik, kita mulai mengenal konsep redundansi. Mari kita perhatikan ilustrasi pertama di bawah ini:

Di sini, kita menempatkan HAProxy sebagai garda terdepan. Tugasnya sederhana namun krusial: menerima permintaan dari user dan membaginya ke App Backend 1 dan App Backend 2. Jika Backend 1 sedang sibuk atau mengalami crash, HAProxy secara cerdas akan mengalihkan trafik ke Backend 2. Inilah bentuk awal dari ketahanan sistem.

Mengapa Database dan Storage Harus Terpisah?

Satu hal yang menarik dari diagram di atas adalah pemisahan antara server aplikasi dengan PostgreSQL dan Rustfs (Object Storage). Mungkin ada yang bertanya, "Kenapa tidak dijadikan satu saja di dalam server aplikasi agar lebih hemat?" Ada dua alasan utama mengapa pemisahan ini wajib dilakukan dalam arsitektur High Availability:

• Data Consistency (Konsistensi Data): Jika setiap backend memiliki database lokal sendiri, maka data antara Backend 1 dan Backend 2 tidak akan pernah sinkron. Dengan memisahkan database ke server tersendiri, semua node aplikasi akan melihat dan menulis ke satu sumber kebenaran (single source of truth) yang sama.

• Stateless Application: Agar kita bisa menambah atau menghapus server aplikasi sesuka hati (scaling), server aplikasi tersebut tidak boleh menyimpan data permanen secara lokal. Semua file gambar atau dokumen harus dilempar ke Rustfs, dan semua data relasional disimpan di PostgreSQL. Dengan begini, server aplikasi menjadi stateless—artinya, ia bisa diganti kapan saja tanpa takut kehilangan data user.

Arsitektur ini sudah cukup bagus, tapi masih menyimpan satu titik lemah yang fatal: Bagaimana jika HAProxy yang ada di tengah itu mati? Seluruh sistem akan lumpuh seketika. Masalah inilah yang akan kita pecahkan di bagian selanjutnya.

High Availability yang Sebenarnya

Jika pada diagram pertama kita merasa sudah aman dengan dua backend, sekarang mari kita hadapi kenyataan pahit: Bagaimana jika server HAProxy dengan IP 192.168.87.6 mati?

Meskipun kamu punya 100 backend yang sehat di belakangnya, user tetap tidak akan bisa mengakses aplikasi karena pintu masuknya terkunci. Di sinilah kita masuk ke level High Availability yang sebenarnya dengan memperkenalkan konsep Load Balancer Redundancy.

Mengenal Mekanisme Failover & Health Check

Pada diagram kedua, kita tidak lagi hanya mengandalkan satu HAProxy. Kita menambahkan satu lagi "penjaga" dengan IP 192.168.87.7. Perhatikan tanda panah dua arah bertuliskan "Health Check" di antara keduanya. Inilah rahasianya:

1. Saling Mengawasi (Heartbeat): Kedua node HAProxy ini saling mengirimkan sinyal "detak jantung" secara terus-menerus. Selama node utama (192.168.87.6) memberikan respon, node cadangan (192.168.87.7) akan tetap dalam posisi standby.

2. Deteksi Kegagalan: Begitu node utama berhenti merespon (mungkin karena hardware failure atau kernel panic), node cadangan akan langsung mendeteksinya dalam hitungan milidetik.

3. Pengambilalihan (Failover): Node cadangan akan segera mengambil alih tugas node utama. Di sinilah biasanya kita menggunakan teknologi seperti Keepalived atau VRRP.

Keajaiban Floating IP (Virtual IP)

Mungkin kamu bingung: "Kalau IP-nya ada dua (192.168.87.6 dan 192.168.87.7), lalu user tembak ke IP yang mana?"

Dalam arsitektur HA yang matang, kita menggunakan Floating IP atau Virtual IP (VIP). User tidak menembak langsung ke IP asli server, melainkan ke satu IP bayangan. IP bayangan ini secara dinamis akan "menempel" pada server HAProxy yang sedang aktif. Jika server A mati, IP bayangan itu akan "berpindah" secara otomatis ke server B tanpa user sadari.

Menghilangkan Single Point of Failure

Dengan konfigurasi ini, kita telah berhasil mengeliminasi titik lemah di setiap lapisan:

• Layer Traffic: Jika satu LB mati, ada LB cadangan.

• Layer Application: Jika satu backend mati, ada node lain yang siap sedia.

• Layer Data: Database dan Storage dipisahkan agar tetap persistent dan bisa diakses secara kolektif.

Inilah yang kita sebut sebagai infrastruktur yang memiliki daya tahan tinggi atau Resilient Infrastructure.

Kesimpulan

Setelah membedah diagram-diagram di atas, satu hal yang harus kita sadari adalah: High Availability (HA) bukanlah sebuah barang yang bisa kita beli jadi, lalu selesai. HA adalah sebuah perjalanan untuk terus mengidentifikasi dan mengeliminasi setiap kemungkinan titik kegagalan atau Single Point of Failure (SPOF).

Membangun infrastruktur seperti ini memang membutuhkan usaha ekstra—kita harus mengonfigurasi dua HAProxy, mengatur protokol VRRP, hingga memastikan aplikasi kita bersifat stateless agar bisa berkomunikasi dengan PostgreSQL dan Rustfs secara lancar. Namun, imbalannya sebanding: sebuah sistem yang memiliki daya tahan tinggi (resilience) dan kepercayaan dari pengguna.

Ringkasnya, prinsip utama dalam membangun arsitektur HA adalah:

• Redundansi: Selalu miliki cadangan di setiap lapisan.

• Failover otomatis: Jangan biarkan proses perpindahan bergantung pada campur tangan manusia.

• Separation of Concerns: Pisahkan logika aplikasi dari penyimpanan data agar sistem lebih fleksibel.

Infrastruktur yang kuat bukan berarti infrastruktur yang tidak pernah mengalami kendala. Justru sebaliknya, infrastruktur yang hebat adalah yang sudah siap menghadapi kerusakan di bagian mana pun, namun tetap mampu melayani pengguna seolah-olah tidak terjadi apa-apa.

Next Part 2 kita implementasikan.