Load Balancer 101

Beberapa waktu lalu, saya pergi ke Supermarket untuk berbelanja. Sayangnya, hari itu antrean di kasir sedang mengular panjang.

Lalu muncul seorang petugas yang mengarahkan sebagian pelanggan pindah ke kasir lain. Dalam hitungan menit, antrean yang tadinya mengular langsung terbagi ke beberapa kasir yang dibuka.

Nah, kejadian kecil itu mengingatkan saya tentang "Load Balancer" dalam Software Engineering.

Dikutip dari blog Cloudflare :  https://www.cloudflare.com/learning/performance/what-is-load-balancing/

Load balancing adalah praktek mendistribusikan beban kerja komputasi antara dua atau lebih komputer. Di Internet, penyeimbangan beban sering digunakan untuk membagi lalu lintas jaringan di antara beberapa server. Ini mengurangi ketegangan pada setiap server dan membuat server lebih efisien, mempercepat performance dan mengurangi latensi. Penyeimbangan beban sangat penting agar sebagian besar aplikasi Internet dapat berfungsi dengan baik.

Balik lagi ke supermarket tadi. Petugas yang mengarahkan antrean itu tidak memproses belanjaan siapa pun. Tugasnya cuma satu: melihat kasir mana yang memiliki load yang sedikit, lalu mengarahkan pelanggan berikutnya ke sana. Load balancer bekerja persis seperti itu.

Dalam Software Engineering, "pelanggan" itu adalah request (permintaan) dari pengguna, misalnya waktu kita buka e-commerce atau scroll medsos. "Kasir" adalah server, yaitu komputer yang menjawab request itu. Load balancer menjadi gerbang utama untuk semua server, jadi pengguna cuma tahu satu alamat saja, sementara di belakangnya ada banyak server yang siap digunakan.

Load balancer punya beberapa cara untuk membagi beban ke server. Tiga yang paling umum:

Tidak ada metode yang wajib dipakai atau paling benar, semua tergantung kebutuhan sistem aplikasi-nya.

Pernah lihat mesin kasir yang mendadak error, lalu petugas mengarahkan ke Kasir lain? Dalam Software Engineering, mekanisme ini bernama health check. Secara berkala, misalnya tiap 5 detik, load balancer mengirim request kecil ke setiap server, biasanya ke alamat khusus seperti /health. Kalau server membalas dengan status 200 OK, artinya ia sehat. Kalau balasannya error (misalnya 500) atau tidak ada jawaban sampai batas waktu (timeout), server ditandai unhealthy dan tidak dikirimi request lagi.

Biasanya server dianggap mati setelah gagal beberapa kali berturut-turut, supaya satu respons error tidak langsung dianggap mati. Health check tetap berjalan di server yang mati, dan begitu kembali merespons dengan status 200 OK, server tersebut dipakai lagi secara otomatis. Hasilnya, pengguna nggak sadar ada yang bermasalah. Tanpa load balancer, satu server yang mati bisa bikin seluruh aplikasi ikut tumbang. Istilah kerennya single point of failure.

Bayangkan event promo 12.12 di e-commerce atau war tiket konser. Jutaan orang membuka aplikasi di waktu yang sama. Kalau hanya ada satu server, antreannya pasti menumpuk, dan kemungkinan besar muncul pesan error. Dengan load balancer, kita bisa menambah server di belakangnya (scale out) dan beban otomatis terbagi. Begitu event tersebut selesai, jumlah server bisa dikurangi lagi supaya biaya tidak boros (scale in). Sama seperti supermarket yang membuka semua kasir saat weekend, lalu menutup sebagian saat sepi.

Namun, load balancer bukan solusi untuk segalanya. Kalau hanya ada satu, ia sendiri menjadi single point of failure yang baru: begitu Load Balancer mati, semua server di belakangnya ikut tidak bisa diakses. Karena itu, di sistem yang besar, load balancer dibuat berpasangan. Satu aktif melayani, satu lagi siaga dan langsung mengambil alih kalau yang aktif bermasalah. Sama seperti petugas antrean di supermarket yang punya rekan pengganti.