--- title: "Apa Itu Load Balancer dan Kapan Website Butuh?" description: "Load balancer membagi trafik ke beberapa server dan menyingkirkan yang bermasalah. Kenali round robin, health check, sticky session, dan L4 vs L7." url: "https://nivelva.com/insight/apa-itu-load-balancer" category: "Server \u0026 Infrastruktur" tags: ["load balancer","high availability","round robin","health check","server"] author: "Theresia Candiawan" published: "2026-11-05T17:11:00+07:00" updated: "2026-11-05T17:11:00+07:00" language: "id" publisher: "Nivelva (https://nivelva.com)" --- # Apa Itu Load Balancer dan Kapan Website Butuh? > **Jawaban singkat:** Load balancer adalah perantara yang membagi request ke beberapa server yang menjalankan aplikasi sama, dan berhenti mengirim ke server yang gagal health check. Website butuh saat satu server tidak lagi cukup menampung puncak trafik, atau saat downtime karena satu server mati sudah terlalu mahal. Promo besar sudah diumumkan, iklan sudah tayang, dan pengunjung berdatangan. Lalu halaman checkout mulai lambat, beberapa pengunjung melihat error, dan grafik CPU server menempel di batas atas. Atau skenario lain yang lebih sunyi: server satu-satunya perlu di-reboot untuk tambalan keamanan, dan selama beberapa menit website tidak bisa diakses sama sekali. Dua masalah ini berbeda, tapi jawabannya sering sama: lebih dari satu server, dengan load balancer di depannya. Load balancer adalah perantara yang menerima semua request dari pengunjung, lalu membaginya ke sekumpulan server yang menjalankan aplikasi yang sama. Ia juga terus memeriksa kesehatan setiap server dan berhenti mengirim request ke server yang sedang bermasalah. Bagi pengunjung, tetap hanya ada satu alamat website. ## Bagaimana load balancer memutuskan ke mana request dikirim Cara load balancer memilih server disebut algoritma penyeimbangan. Ada beberapa yang paling sering dipakai. **Round robin** adalah yang paling sederhana: request pertama ke server A, kedua ke server B, ketiga ke server C, lalu kembali ke A. Cocok bila semua server punya spesifikasi sama dan setiap request bebannya kurang lebih seragam. **Weighted round robin** memberi bobot berbeda. Server yang lebih kuat diberi bobot lebih besar sehingga menerima porsi request lebih banyak. **Least connections** mengirim request ke server yang sedang memegang koneksi aktif paling sedikit. Ini lebih adil ketika lama pemrosesan request sangat bervariasi, misalnya sebagian request membuat laporan berat sementara lainnya hanya membuka halaman ringan. **IP hash** memilih server berdasarkan alamat IP pengunjung, sehingga pengunjung yang sama cenderung selalu dikirim ke server yang sama. ## Health check: alasan utama ketersediaan meningkat Membagi beban hanya separuh manfaat load balancer. Separuh lainnya adalah health check. Load balancer mengirim pemeriksaan berkala ke setiap server, misalnya membuka alamat khusus seperti `/health` dan mengharapkan jawaban sukses. Kalau server gagal beberapa kali berturut-turut, ia dikeluarkan dari daftar tujuan sampai pulih. Inilah yang membuat perawatan tanpa downtime mungkin dilakukan. Kamu bisa mengeluarkan satu server, memperbaruinya, memasukkannya kembali, lalu mengulang untuk server berikutnya, sementara pengunjung terus dilayani server lain. Hal yang sama berlaku ketika satu server mati mendadak. Health check yang baik memeriksa hal yang benar-benar menentukan aplikasi bisa melayani, misalnya koneksi ke database, bukan sekadar apakah proses web server masih hidup. Tapi jangan juga terlalu berat, karena pemeriksaan ini dijalankan berulang kali. ## Sticky session dan aplikasi yang menyimpan state Masalah klasik muncul saat aplikasi menyimpan sesi login di memori atau disk server lokal. Pengunjung login di server A, request berikutnya dikirim ke server B, dan tiba-tiba ia dianggap belum login. Keranjang belanja pun bisa hilang. Ada dua cara mengatasinya. Pertama, **sticky session**: load balancer menandai pengunjung, biasanya lewat cookie, agar selalu dikirim ke server yang sama. Cara ini cepat diterapkan, tapi pembagian beban jadi kurang merata dan sesi tetap hilang bila server itu mati. Kedua, membuat aplikasi **stateless**: sesi disimpan di tempat bersama seperti Redis atau database, dan file unggahan disimpan di penyimpanan bersama atau object storage. Dengan begitu, server mana pun bisa melayani pengunjung mana pun. Cara ini butuh sedikit kerja di awal, tapi jauh lebih tahan banting dan memudahkan penambahan server. ## Layer 4 dan layer 7: dua tingkat kecerdasan Load balancer dibedakan berdasarkan lapisan jaringan tempat ia bekerja. | Aspek | Layer 4 (transport) | Layer 7 (aplikasi) | |:--|:--|:--| | Yang dibaca | Alamat IP dan port, protokol TCP atau UDP | Isi request HTTP: domain, path, header, cookie | | Keputusan routing | Berdasarkan koneksi | Berdasarkan isi request, misalnya `/api` ke server berbeda | | HTTPS | Biasanya diteruskan apa adanya ke server | Bisa membuka HTTPS di load balancer (TLS termination) | | Sticky session | Berdasarkan IP | Berdasarkan cookie | | Beban kerja load balancer | Lebih ringan | Lebih berat karena memeriksa isi request | | Cocok untuk | Lalu lintas non-HTTP, database, trafik sangat tinggi | Website dan API yang butuh routing pintar | Load balancer layer 7 pada dasarnya adalah reverse proxy yang punya kemampuan membagi beban dan health check. Karena itu perangkat lunak seperti Nginx, HAProxy, Traefik, atau Caddy bisa berperan sebagai keduanya. Konsep reverse proxy dijelaskan di apa itu reverse proxy. Selain perangkat lunak yang kamu jalankan sendiri, banyak penyedia cloud juga menawarkan load balancer terkelola. Satu catatan penting: load balancer sendiri bisa menjadi titik gagal tunggal. Kalau hanya ada satu load balancer dan ia mati, semua server di belakangnya ikut tak terjangkau. Pengaturan yang serius memakai dua load balancer dengan IP mengambang atau layanan terkelola yang sudah redundan. ## Sinyal bahwa website kamu butuh lebih dari satu server Load balancer tidak dibutuhkan semua website. Untuk website company profile atau toko kecil dengan trafik stabil, satu server yang cukup kuat, dipantau, dan punya backup yang teruji biasanya sudah memadai. Sebelum menambah server, cek dulu apakah optimasi sederhana seperti cache, CDN, atau menaikkan spesifikasi sudah dicoba. Cara menimbang spesifikasi ada di [memilih spesifikasi VPS](https://nivelva.com/insight/memilih-spesifikasi-vps). Sinyalnya mulai kuat ketika beberapa hal ini terjadi. Grafik pemakaian CPU atau RAM rutin mendekati batas pada jam ramai, padahal server sudah dinaikkan beberapa kali. Waktu respons memburuk tajam saat ada kampanye, dan kerugian dari halaman lambat terasa langsung di penjualan. Perawatan rutin seperti update atau reboot terpaksa dilakukan tengah malam karena downtime singkat sudah tidak bisa ditoleransi. Atau satu server pernah mati dan biaya gangguan itu jauh lebih besar dari biaya server tambahan. Data untuk membaca sinyal-sinyal ini datang dari pemantauan yang rapi: grafik sumber daya, waktu respons, dan tingkat error dari waktu ke waktu. Kalau belum punya, mulailah dari panduan observability server. Bila trafiknya naik turun tajam dan sulit diprediksi, model hosting yang menambah kapasitas otomatis juga layak dibandingkan, seperti dibahas di [apa itu autoscaling hosting](https://nivelva.com/insight/apa-itu-autoscaling-hosting). Jangan lupa bagian di belakang server aplikasi. Load balancer membagi beban ke server aplikasi, tapi kalau semuanya memakai satu database yang sudah kewalahan, masalahnya hanya berpindah tempat. ## Intinya Load balancer membagi request ke beberapa server, memeriksa kesehatannya, dan menyingkirkan yang bermasalah, sehingga website lebih tahan lonjakan trafik dan lebih jarang down. Ia layak dipasang ketika satu server sudah tidak cukup meski sudah dioptimalkan, atau ketika downtime dari satu server yang mati sudah terlalu mahal. Siapkan aplikasinya agar stateless, dan pastikan pemantauan sudah berjalan sebelum menambah server. --- Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/apa-itu-load-balancer Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com