Load Balancing Adalah: Cara Kerja, Jenis & Algoritmanya

Setiap website yang tayang di internet dilayani oleh sebuah server: mesin yang menerima permintaan dari browser pengunjung, memprosesnya, lalu mengirim balik halaman yang diminta. Selama jumlah pengunjung masih wajar, satu mesin sudah memadai. Persoalan muncul ketika permintaan datang lebih cepat daripada kemampuan mesin itu memprosesnya. Antrian menumpuk, waktu muat memanjang, dan pada titik tertentu server berhenti menjawab sama sekali.

Jalan keluar pertama yang biasanya terpikir adalah menambah kapasitas mesin: RAM lebih besar, prosesor lebih banyak inti, penyimpanan lebih cepat. Cara ini bekerja sampai batas tertentu, tetapi menabrak dua langit-langit yang keras. Harga per satuan performa naik jauh lebih curam daripada performanya sendiri. Selain itu, sebesar apa pun mesin tersebut, ia tetap satu mesin — dan ketika ia mati, layanan Anda ikut mati.

Load balancing adalah jawaban atas kedua persoalan tersebut sekaligus. Alih-alih membesarkan satu mesin, beban dibagi ke beberapa mesin yang bekerja bersamaan.

Apa Itu Load Balancing?

Load balancing adalah teknik membagi beban kerja ke beberapa sumber daya yang setara. Tujuannya agar tidak ada satu sumber daya yang menanggung porsi berlebih sementara yang lain menganggur. Dalam konteks website, beban kerja yang dimaksud adalah permintaan pengunjung, dan sumber dayanya adalah sekumpulan server yang menjalankan aplikasi sama.

Perangkat atau perangkat lunak yang menjalankan pembagian tersebut disebut load balancer (penyeimbang beban). Ia berdiri di depan kumpulan server, menerima seluruh permintaan lebih dulu, lalu meneruskannya ke salah satu server di belakangnya. Sekumpulan server yang menerima limpahan ini biasa disebut backend atau upstream, istilah yang akan sering Anda temui di berkas konfigurasi.

Bayangkan sebuah kantor pelayanan dengan enam loket dan seorang petugas di pintu masuk. Pengunjung tidak memilih loket sendiri. Petugas itulah yang mengarahkan, berdasarkan dua hal: loket mana yang antriannya paling pendek, dan loket mana yang sedang tutup. Load balancer mengerjakan persis hal itu, hanya dalam hitungan milidetik dan untuk ribuan pengunjung sekaligus.

Dari sisi pengunjung, seluruh mekanisme ini tidak terlihat. Nama domain Anda menunjuk ke satu alamat IP milik load balancer, sering disebut virtual IP (alamat yang mewakili sekelompok server, bukan satu mesin fisik tertentu). Berapa pun jumlah server di belakangnya, browser hanya mengenal satu alamat.

Dua Arena yang Sering Tertukar

Sebelum masuk lebih dalam, ada satu hal yang perlu diluruskan. Di Indonesia, istilah load balancing dipakai untuk dua pekerjaan yang secara teknis berbeda, dan keduanya sama-sama sah.

Arena pertama adalah sisi server. Yang dibagi adalah permintaan yang masuk, dan tujuannya membuat satu website sanggup dilayani oleh banyak mesin. Ini yang dipakai penyedia hosting, aplikasi web, dan layanan cloud.

Arena kedua adalah sisi jaringan. Yang dibagi adalah trafik yang keluar, dan tujuannya memanfaatkan dua atau lebih jalur internet dari penyedia yang berbeda. Ini yang dikerjakan router di kantor atau warnet, umumnya dengan perangkat Mikrotik.

Prinsipnya sama: bagi beban supaya tidak menumpuk di satu titik. Namun yang dibagi, alat yang dipakai, dan hasil yang bisa Anda harapkan berbeda jauh. Bagian terbesar artikel ini membahas arena pertama, sedangkan arena kedua mendapat bagiannya sendiri di bawah.

Cara Kerja Load Balancing dari Sisi Pengunjung

Alur satu permintaan dari browser sampai kembali menjadi halaman berjalan seperti berikut.

Diagram cara kerja load balancing dari permintaan pengunjung sampai jawaban dikembalikan.

Langkah ketiga adalah yang paling menentukan, dan sering luput dari perhatian. Load balancer tidak asal membagi rata; ia lebih dulu memastikan server tujuannya masih hidup. Pemeriksaan ini disebut health check (pengecekan kesehatan berkala), dan tanpanya pembagian beban justru berbahaya — permintaan akan tetap dikirim ke server yang sudah mati.

Health check diatur lewat tiga angka. Pada HAProxy, inter menentukan jarak antar-pemeriksaan. Lalu fall menentukan berapa kali pemeriksaan harus gagal sebelum server dinyatakan mati, dan rise berapa kali harus berhasil sebelum server dikembalikan ke rotasi. Kombinasi yang lazim: pemeriksaan tiap 10 detik, tiga kegagalan berturut-turut untuk mengeluarkan, dua keberhasilan untuk memulihkan.

Angka rise sengaja lebih kecil dari fall karena kedua kesalahan tidak setara. Mengeluarkan server yang sebenarnya sehat hanya mengurangi kapasitas sesaat, sedangkan memasukkan kembali server yang belum benar-benar pulih langsung mengembalikan halaman error ke pengunjung.

Nginx versi gratis memakai pendekatan lebih sederhana: ia tidak mengirim pemeriksaan aktif, melainkan menilai dari permintaan asli yang gagal lewat max_fails dan fail_timeout. Pemeriksaan berkala secara aktif baru tersedia di Nginx Plus yang berbayar.

Algoritma Pembagian Beban dan Kapan Memakainya

Keputusan "server mana yang dipilih" ditentukan oleh algoritma. Ada dua kelompok besar: algoritma statis yang memutuskan berdasarkan aturan tetap, dan algoritma dinamis yang ikut memperhitungkan kondisi server saat itu.

1. Round robin: Server dipilih bergiliran satu per satu, kembali ke urutan awal setelah yang terakhir. Ini pilihan bawaan di hampir semua load balancer dan sudah memadai kalau seluruh server punya spesifikasi setara serta setiap permintaan berbobot mirip.
2. Weighted round robin: Sama seperti di atas, tetapi tiap server diberi bobot. Bobot bawaan adalah 1, dan server dengan bobot 5 akan menerima lima kali lebih banyak permintaan dibanding server berbobot 1. Pakai ini ketika spesifikasi server Anda timpang, misalnya satu mesin 8 vCPU digabungkan dengan dua mesin 2 vCPU.
3. Least connection: Permintaan dikirim ke server dengan koneksi aktif paling sedikit. Cocok untuk koneksi berumur panjang seperti basis data, gRPC, atau LDAP, karena pada beban seperti itu jumlah koneksi lebih mencerminkan kesibukan server dibanding jumlah permintaan.
4. Weighted least connection: Gabungan dari dua sebelumnya — jumlah koneksi dibandingkan setelah disesuaikan dengan kapasitas tiap server.
5. IP hash: Alamat IP pengunjung dihitung menjadi angka, dan angka itu menentukan servernya. Pengunjung yang sama selalu mendarat di server yang sama selama daftar server tidak berubah. Ini cara paling sederhana menjaga session tetap utuh.
6. Least response time: Server dengan waktu balas rata-rata tercepat yang dipilih. Paling akurat, tetapi menuntut load balancer terus mengukur latensi tiap server.
7. Resource-based: Keputusan diambil dari pemakaian CPU dan memori, yang dilaporkan agen kecil di tiap mesin.

Urutan pertimbangannya sederhana untuk kebanyakan website. Mulai dari round robin, tambahkan bobot kalau spesifikasi server tidak seragam, lalu pindah ke least connection kalau aplikasi Anda menahan koneksi lama. Algoritma yang lebih pintar seperti least response time baru terasa manfaatnya ketika jumlah server sudah belasan dan bebannya benar-benar timpang.

Diagram empat algoritma load balancing: Round Robin, Bobot, Koneksi Tersedikit, dan Waktu Balas Tercepat.

Perlu diperhatikan, least_time di Nginx hanya tersedia di versi berbayar. HAProxy menyediakan roundrobin, leastconn, source, dan uri sepenuhnya gratis.

Layer 4 dan Layer 7: Beda Kedalaman Membaca

Jenis load balancing juga dibedakan dari seberapa dalam ia membaca isi trafik yang lewat.

Layer 4 bekerja di lapisan transport. Ia hanya melihat alamat IP dan nomor port, lalu meneruskan paket tanpa membuka isinya. Karena tidak perlu memahami muatan, cara ini sangat cepat dan hemat sumber daya, serta bisa dipakai untuk protokol apa pun — bukan hanya web.

Layer 7 bekerja di lapisan aplikasi. Ia membaca isi permintaan HTTP: alamat host, path URL, header, sampai cookie. Kemampuan membaca ini membuka pengarahan yang jauh lebih cerdas. Permintaan ke /api bisa dikirim ke kelompok server tersendiri, permintaan gambar ke server lain, dan pengunjung dengan cookie tertentu selalu diarahkan ke server yang sama.

Diagram perbandingan Layer 4 dan Layer 7 untuk load balancing dengan ikon amplop tertutup dan terbuka.

Konsekuensinya bisa ditebak: Layer 7 menuntut lebih banyak pemrosesan dan menambah sedikit penundaan, sedangkan Layer 4 lebih cepat tetapi buta terhadap isi. Untuk website biasa, Layer 7 hampir selalu lebih masuk akal. Layer 4 dipakai ketika yang dibagi bukan HTTP, atau ketika volume trafiknya sangat besar sehingga setiap milidetik berarti.

Perangkat Keras, Perangkat Lunak, atau Layanan Cloud

Ada tiga jalur untuk menghadirkan load balancer, dengan konsekuensi biaya dan kendali yang berbeda.

1. Perangkat keras khusus: Kotak fisik buatan vendor seperti F5 atau Citrix yang dipasang di rak data center. Performanya tinggi dan dukungannya jelas, tetapi harganya di kelas puluhan sampai ratusan juta rupiah.
2. Perangkat lunak di server sendiri: Nginx dan HAProxy adalah dua nama yang paling banyak dipakai, keduanya open source. Anda memasangnya di server biasa dan mendapat kendali penuh atas konfigurasi. Jalur ini paling umum untuk website skala kecil sampai menengah.
3. Layanan terkelola: AWS Elastic Load Balancing, Google Cloud Load Balancing, dan Cloudflare Load Balancing dijual sebagai layanan. Anda tidak mengurus mesin maupun pembaruan keamanan, tetapi membayar per jam pemakaian ditambah volume trafik, dengan konfigurasi terbatas pada apa yang disediakan penyedia.

Kalau Anda sudah menjalankan Nginx sebagai reverse proxy, menjadikannya load balancer hanya soal menambahkan blok upstream berisi daftar server. Tidak ada perangkat lunak baru yang perlu dipasang.

Load Balancing Lewat DNS dan Batas Kemampuannya

Bentuk paling sederhana dari pembagian beban tidak membutuhkan perangkat tambahan sama sekali. Anda cukup mendaftarkan beberapa alamat IP untuk satu nama domain di pengaturan DNS. Server DNS akan memberikan alamat yang berbeda-beda secara bergiliran kepada penanya yang berbeda. Cara ini disebut DNS round robin.

Kemudahannya nyata, tetapi ada tiga batas yang sama nyatanya.

Pertama, DNS tidak tahu apa pun soal kesehatan server. Ia terus membagikan alamat IP server yang sudah mati, karena tugasnya memang hanya menerjemahkan nama menjadi alamat.

Kedua, jawaban DNS disimpan sementara oleh resolver dan browser sesuai nilai TTL (Time To Live, masa berlaku sebuah jawaban DNS). Rotasi pun menjadi tidak merata — satu resolver besar milik penyedia internet bisa mengirim ribuan pengunjung ke alamat yang sama selama masa simpan belum habis.

Ketiga, penggantian server tertunda selama TTL. Dengan TTL 3600 detik, sebagian pengunjung masih diarahkan ke server yang mati sampai satu jam ke depan. Menurunkan TTL ke 60 detik mempercepat perpindahan, tetapi menaikkan jumlah query DNS secara signifikan.

Karena itu DNS round robin lebih tepat sebagai pelengkap untuk membagi trafik antar-lokasi data center, bukan pengganti load balancer sungguhan.

Membagi Dua Jalur Internet di Router

Sekarang arena kedua. Di sini yang dibagi adalah trafik yang keluar dari jaringan Anda menuju internet, lewat dua atau lebih koneksi dari penyedia berbeda. Pada Mikrotik, metode yang paling banyak dipakai adalah PCC (Per Connection Classifier, penggolong per koneksi), selain ECMP yang membagi berdasarkan tabel rute.

Kata kuncinya ada pada nama metodenya: per koneksi. PCC menandai setiap koneksi baru, menetapkan satu jalur untuknya, lalu mengunci seluruh paket koneksi itu ke jalur yang sama. Penguncian ini bukan keterbatasan yang tidak disengaja, melainkan keharusan. Kalau paket dari satu sesi berpindah-pindah jalur, alamat IP publik Anda ikut berubah di tengah jalan. Banyak situs akan memutus sesi login karena menganggapnya mencurigakan.

Ilustrasi load balancing dengan router terhubung ke dua ISP melalui dua jalur terpisah.

Dari sifat itu muncul konsekuensi yang perlu Anda pahami sejak awal: dua koneksi 50 Mbps tidak membuat satu unduhan berjalan di 100 Mbps. Total kapasitas jaringan Anda memang menjadi 100 Mbps. Namun angka itu hanya tercapai saat banyak koneksi berjalan bersamaan, misalnya dua puluh karyawan membuka situs yang berbeda-beda. Satu unduhan berkas besar tetap memakai satu jalur, sehingga puncaknya tetap 50 Mbps. Menggabungkan bandwidth untuk satu koneksi tunggal menuntut teknik bonding yang jauh lebih rumit.

Perlu dibedakan juga dengan failover. Load balancing memakai kedua jalur bersamaan, sedangkan failover menyimpan jalur kedua sebagai cadangan yang menganggur sampai jalur utama putus. Keduanya biasa dipasang berdampingan, tetapi yang satu menambah kapasitas dan yang lain menjaga ketersediaan.

Fungsi dan Manfaat yang Anda Dapatkan

Manfaat load balancing menjadi lebih mudah dijelaskan sekarang, karena masing-masing berakar pada mekanisme yang sudah dibahas di atas.

1. Ketersediaan yang tidak bergantung pada satu mesin: Health check mengeluarkan server bermasalah dari rotasi dalam hitungan detik. Pengunjung tidak melihat halaman error, mereka hanya dilayani mesin lain.
2. Penambahan kapasitas secara mendatar: Menambah server keempat ke kelompok berisi tiga server jauh lebih murah. Anda tidak perlu mengganti satu server besar dengan yang lebih besar lagi.
3. Perawatan tanpa menghentikan layanan: Anda bisa mengeluarkan satu server dari rotasi, memperbaruinya, lalu memasukkannya kembali tanpa jeda yang terlihat pengunjung.
4. Penyerapan lonjakan trafik: Lonjakan mendadak, baik dari kampanye promosi maupun serangan DDoS berskala kecil, terbagi ke beberapa mesin dan tidak langsung menjatuhkan satu titik.

Kelemahan dan Hal yang Perlu Anda Pertimbangkan

Bagian ini yang sering terlewat ketika load balancing dibicarakan sebagai solusi tanpa cela.

Load balancer justru menjadi titik kegagalan tunggal yang baru. Ini konsekuensi paling penting dan paling sering diabaikan. Anda sudah menyiapkan lima server backend supaya tidak bergantung pada satu mesin, tetapi seluruh trafik tetap melewati satu load balancer. Ketika perangkat itu mati, kelima server sehat tersebut sama sekali tidak berguna. Penanganannya adalah memasang dua load balancer dalam susunan aktif-pasif dengan satu alamat IP mengambang di antaranya. Di Linux, keepalived mengerjakannya lewat protokol VRRP: node pasif mengambil alih alamat IP itu begitu node aktif berhenti merespons.

Session menjadi urusan yang harus dirancang. Kalau data login disimpan di berkas lokal server pertama, pengunjung yang permintaan berikutnya mendarat di server kedua akan mendapati dirinya keluar dari akun. Ada dua jalan keluar: menempelkan pengunjung ke satu server dengan IP hash atau sticky session, atau memindahkan penyimpanan session ke tempat terpusat seperti Redis. Cara kedua lebih sehat karena pembagian beban tetap merata, tetapi menambah satu komponen untuk dirawat. Perlu dicatat, sticky session pada Nginx hanya tersedia di versi berbayar.

Biayanya berlipat, bukan bertambah sedikit. Load balancing menuntut minimal dua server backend ditambah lapisan load balancer itu sendiri, dan menjadi empat mesin kalau Anda menerapkan pasangan aktif-pasif. Untuk website yang trafiknya masih tertangani satu server, biaya sebesar ini belum sepadan.

Konsistensi data antar server jadi pekerjaan tambahan. Berkas yang diunggah ke server pertama tidak otomatis ada di server kedua, sehingga Anda perlu penyimpanan bersama, sinkronisasi, atau layanan penyimpanan objek. Basis data pun umumnya dipisahkan ke server tersendiri agar semua backend membaca sumber yang sama.

Ada satu lompatan tambahan di jalur permintaan. Penundaan yang ditambahkan load balancer memang kecil, umumnya di bawah satu milidetik untuk Layer 4 dan beberapa milidetik untuk Layer 7. Meski begitu, ia tetap ada pada setiap permintaan.

Kapan Website Anda Mulai Membutuhkannya

Berikut ambang praktis yang bisa Anda pakai sebagai patokan. Pertimbangkan load balancer ketika pemakaian CPU server bertahan di atas 70 persen pada jam sibuk selama beberapa hari berturut-turut. Ambang kedua adalah waktu balas yang melewati 500 milidetik padahal aplikasi sudah dioptimasi dan cache sudah dipasang. Alasan ketiga bersifat non-teknis: kalau layanan Anda tidak boleh mati bahkan lima belas menit untuk pembaruan sistem, Anda membutuhkannya sekarang, berapa pun trafiknya.

Sebaliknya, kalau pemakaian CPU rata-rata masih di bawah 40 persen dan lonjakan hanya sesekali, menaikkan spesifikasi satu server hampir selalu lebih murah dan lebih sederhana. Optimasi query basis data dan pemasangan cache yang benar sering memberi perbaikan lebih besar daripada menambah mesin.

Untuk yang baru menyiapkan dua server backend, VPS Indonesia adalah cara paling hemat memulai. Anda bisa mengambil dua unit kecil lebih dulu, lalu menaikkan spesifikasinya seiring trafik bertambah.

Pertanyaan yang Sering Muncul

Apa bedanya load balancing dengan failover? Load balancing memakai semua server atau jalur secara bersamaan untuk menambah kapasitas. Failover menyiapkan cadangan yang menganggur dan baru aktif ketika yang utama gagal. Keduanya sering dipasang berdampingan.

Apakah load balancer harus perangkat khusus? Tidak. Nginx dan HAProxy adalah perangkat lunak open source yang berjalan di server biasa dan sudah lebih dari cukup untuk mayoritas website.

Algoritma mana yang paling bagus? Tidak ada yang unggul di semua keadaan. Round robin memadai untuk server seragam, least connection lebih tepat untuk koneksi berumur panjang, dan IP hash dipakai ketika pengunjung harus menempel di satu server.

Berapa jumlah server minimal untuk memulai? Dua server backend ditambah satu load balancer. Kalau load balancer juga ingin dibuat tahan gangguan, siapkan empat mesin.

Kesimpulan

Load balancing adalah cara membagi beban ke beberapa sumber daya setara supaya tidak ada satu titik yang menanggung semuanya sendirian. Di sisi server, ia membagi permintaan pengunjung ke sekumpulan mesin lewat algoritma seperti round robin dan least connection. Health check menjaga agar permintaan tidak nyasar ke server yang sudah mati. Di sisi jaringan, ia membagi trafik keluar ke beberapa jalur internet — menambah kapasitas total, tetapi tidak melipatgandakan kecepatan satu unduhan.

Teknik ini pantas diterapkan ketika satu server sudah kewalahan atau ketika layanan Anda tidak boleh mati sama sekali. Sebelum sampai di titik itu, menaikkan spesifikasi satu mesin dan membenahi cache biasanya memberi hasil lebih besar dengan kerumitan jauh lebih kecil. Kalau Anda memutuskan menerapkannya, jangan lupa menggandakan load balancer itu sendiri — kalau tidak, Anda hanya memindahkan titik kegagalan tunggal ke tempat baru.

Semoga artikel ini membantu.