Load Balancer Bukan Sekadar Pembagi Trafik: Kap…

Ketika sebuah website mulai menerima lebih banyak pengunjung, menambah kapasitas server bukan satu-satunya pilihan. Ada titik ketika satu server saja terlalu berisiko: jika kewalahan atau mengalami gangguan, seluruh layanan ikut terdampak. Di sinilah load balancer mulai relevan.

Sederhananya, load balancer adalah komponen yang menerima permintaan dari pengguna lalu meneruskannya ke satu atau beberapa server di belakangnya. Dari sisi pengguna, alamat yang diakses tetap sama. Di sisi infrastruktur, permintaan bisa dibagi ke beberapa mesin yang bekerja sebagai satu layanan.

Namun, load balancer bukan tombol ajaib untuk membuat website lebih cepat. Ia membantu mengatur lalu lintas dan meningkatkan ketersediaan, tetapi tetap bergantung pada kesehatan aplikasi, database, jaringan, serta konfigurasi server di belakangnya.

Bagaimana load balancer bekerja?

Bayangkan sebuah restoran dengan satu pintu masuk dan beberapa kasir. Pengunjung tidak perlu memilih kasir sendiri. Petugas di pintu mengarahkan mereka ke kasir yang tersedia agar antrean lebih seimbang. Load balancer bekerja dengan prinsip serupa.

Dalam layanan seperti AWS Elastic Load Balancing, load balancer menjadi titik kontak bagi klien dan meneruskan permintaan ke target yang terdaftar. Target tersebut dapat berupa instance, alamat IP, atau layanan lain, tergantung jenis load balancer yang digunakan. Sistem juga dapat memantau kesehatan target dan menghindari server yang tidak sehat. Dokumentasi AWS menjelaskan pola ini secara resmi.

Distribusi trafik dapat memakai beberapa pendekatan, misalnya:

Round robin: permintaan dibagi bergiliran ke setiap server.
Least connections: permintaan diarahkan ke server dengan koneksi aktif paling sedikit.
Weighted routing: server yang lebih kuat diberi bobot lebih besar.
Routing berdasarkan lokasi atau aturan: pengguna atau jenis permintaan tertentu diarahkan ke kelompok server tertentu.

Algoritma yang tersedia berbeda-beda menurut penyedia dan jenis load balancer. Karena itu, jangan memilih hanya berdasarkan nama fiturnya. Perhatikan bagaimana algoritma tersebut cocok dengan pola trafik dan karakter aplikasi Anda.

Health check lebih penting daripada sekadar membagi trafik

Fitur yang sering dianggap sepele justru menjadi bagian penting: health check. Load balancer secara berkala menguji apakah sebuah server masih layak menerima permintaan. Pemeriksaannya bisa berupa koneksi ke port tertentu atau permintaan HTTP ke endpoint khusus.

Misalnya, Anda membuat endpoint /health yang hanya mengembalikan status aplikasi. Jika endpoint itu gagal merespons sesuai aturan, server dapat dikeluarkan sementara dari daftar tujuan. Google Cloud juga menggunakan health check untuk menentukan backend mana yang siap menerima koneksi. Konsep health check Google Cloud menjelaskan bahwa status sehat atau tidak sehat ditentukan berdasarkan ambang batas dan hasil pemeriksaan yang dikonfigurasi.

Kesalahan umum adalah membuat health check terlalu sederhana atau terlalu berat. Endpoint yang hanya memeriksa apakah proses web hidup mungkin tidak mengetahui bahwa koneksi database sedang gagal. Sebaliknya, endpoint yang menjalankan query kompleks setiap beberapa detik dapat membebani sistem.

Pendekatan yang lebih masuk akal adalah memisahkan pemeriksaan:

Liveness check: apakah proses aplikasi masih berjalan?
Readiness check: apakah aplikasi siap menerima trafik, termasuk ketergantungan penting seperti database atau layanan internal?

Gunakan pemeriksaan yang sesuai dengan tujuan. Tidak semua gangguan database harus membuat seluruh server dikeluarkan dari rotasi, terutama jika aplikasi masih bisa melayani halaman atau fungsi tertentu.

Kapan website mulai membutuhkan load balancer?

Load balancer masuk akal ketika ada alasan operasional yang jelas, bukan sekadar karena infrastrukturnya ingin terlihat lebih “enterprise”. Beberapa tanda yang patut diperhatikan adalah:

Anda menjalankan lebih dari satu server aplikasi. Jika beberapa server harus menerima trafik dari satu alamat publik, load balancer menyederhanakan pengaturan akses.
Downtime satu server tidak boleh mematikan layanan. Dengan health check dan beberapa backend, trafik dapat dialihkan ketika salah satu server bermasalah.
Deployment perlu dilakukan bertahap. Sebagian trafik dapat diarahkan ke versi baru sebelum semua pengguna dipindahkan.
Beban trafik berubah-ubah. Load balancer dapat menjadi pintu masuk untuk sistem autoscaling, meskipun autoscaling sendiri tetap harus dikonfigurasi terpisah.
Aplikasi memiliki beberapa wilayah layanan. Pada arsitektur multi-region, pengaturan dapat mengarahkan pengguna ke pool atau backend yang lebih sesuai.

Untuk blog pribadi atau aplikasi internal dengan satu server dan trafik kecil, reverse proxy sederhana atau konfigurasi langsung pada web server sering kali sudah cukup. Menambahkan load balancer terkelola terlalu dini dapat menciptakan biaya tetap, aturan jaringan baru, serta lebih banyak titik yang harus dipantau.

Hal yang sering terlupakan saat memasang load balancer

1. Sesi pengguna

Jika aplikasi menyimpan sesi pengguna hanya di memori lokal server, pengguna bisa mengalami logout atau kehilangan konteks ketika permintaan berikutnya masuk ke server berbeda. Solusinya bisa berupa penyimpanan sesi terpusat seperti Redis atau database, atau memakai sticky session bila memang sesuai.

Sticky session mengikat pengguna ke server tertentu. Ini praktis, tetapi dapat mengurangi pemerataan trafik dan membuat server tertentu lebih terbebani. Karena itu, penyimpanan sesi terpusat biasanya lebih fleksibel untuk aplikasi yang ingin berkembang.

2. Terminasi TLS

Load balancer dapat menangani koneksi HTTPS dari pengguna lalu meneruskan trafik ke backend. Pola ini disebut terminasi TLS. Manfaatnya, pengelolaan sertifikat menjadi lebih terpusat. Namun, jalur dari load balancer ke server tetap perlu dipertimbangkan. Untuk data sensitif, enkripsi internal mungkin tetap diperlukan.

3. Timeout dan ukuran permintaan

Pengaturan timeout yang terlalu pendek dapat memutus proses yang sebenarnya masih berjalan, sedangkan timeout terlalu panjang bisa membuat koneksi menumpuk. Perhatikan juga batas ukuran unggahan, koneksi WebSocket, streaming, dan request yang berjalan lama. Nilai default belum tentu cocok dengan perilaku aplikasi Anda.

4. Log harus menyimpan konteks

Jika semua permintaan melewati load balancer, log aplikasi sebaiknya menyimpan informasi seperti alamat klien yang diteruskan, ID permintaan, waktu respons, serta backend yang menangani permintaan. Tanpa itu, investigasi gangguan bisa terasa seperti mencari jarum di tumpukan jerami.

Yang bisa dilakukan sekarang

Sebelum membeli atau mengaktifkan layanan load balancer, buatlah peta sederhana:

Berapa banyak server aplikasi yang benar-benar diperlukan?
Apakah aplikasi menyimpan sesi atau file secara lokal?
Endpoint apa yang akan dipakai untuk health check?
Berapa lama request normal, dan request mana yang memang boleh berjalan lama?
Bagaimana trafik dialihkan jika semua backend dianggap tidak sehat?
Apakah biaya dan monitoring sudah dihitung, bukan hanya biaya server?

Uji juga skenario kegagalan secara sengaja. Matikan satu backend, lihat apakah trafik berpindah, lalu pulihkan server tersebut dan pastikan ia tidak langsung menerima beban penuh sebelum benar-benar siap.

Intinya: load balancer paling berguna ketika website membutuhkan ketersediaan, pembagian beban, atau jalur menuju arsitektur yang lebih besar. Tetapi fondasinya tetap sama: aplikasi harus stateless sejauh mungkin, health check harus masuk akal, log harus lengkap, dan setiap aturan routing perlu diuji sebelum terjadi insiden nyata.

Sumber & bacaan lebih lanjut

– Rio Yotto @rioyotto