Mengenal Load Balancing: Cara Satu Website Berjalan di Banyak Server

Hampir setiap proyek yang sukses akhirnya sampai di titik ketika satu server saja sudah tidak cukup. Trafik membesar, permintaan menumpuk, dan mesin yang tadinya menjawab seketika mulai melambat. Solusinya jelas: tambah server. Tapi langkah itu langsung memunculkan pertanyaan yang biasanya tidak terpikir sampai benar-benar kejadian — saat sepuluh ribu orang mengetik alamatmu, server yang mana sebenarnya yang menjawab masing-masing dari mereka?

Di situlah tugas load balancer. Dia berdiri di depan deretan server-mu, menerima setiap permintaan yang masuk, lalu menentukan ke mana permintaan itu dikirim. Kalau dilakukan dengan benar, pengunjungmu tidak pernah sadar bahwa di belakang sana ada lebih dari satu mesin — yang mereka rasakan cuma situs yang cepat dan andal. Yuk kita bedah cara kerjanya, kenapa ini penting, dan kompromi-kompromi yang bakal kamu temui di sepanjang jalan.

Load balancing itu sebenarnya apa

Load balancing adalah praktik membagi pekerjaan yang masuk ke beberapa server sekaligus, supaya tidak ada satu pun yang kewalahan sendirian. Perangkat lunak (atau perangkat keras) yang melakukan pembagian itu disebut load balancer.

Bayangkan sebuah bank yang ramai dengan satu kasir saja dan antrean mengular sampai ke pintu. Menyiksa. Sekarang bayangkan bank yang sama dengan lima kasir, ditambah satu orang di pintu masuk yang mengarahkan tiap nasabah ke kasir mana pun yang sedang kosong. Antrean bergerak lima kali lebih cepat, dan kalau satu kasir izin istirahat, empat yang lain tetap melayani. Orang di pintu itulah load balancer-mu. Para kasir itulah server-mu.

Dalam istilah web, load balancer adalah wajah publik situsmu — satu alamat yang dihubungi oleh dunia luar. Di belakangnya berdiri beberapa server backend yang identik (sering disebut “pool” atau “farm”), masing-masing menjalankan salinan aplikasimu. Seluruh tugas load balancer adalah menjawab pertanyaan “siapa yang menangani yang satu ini?” ribuan kali per detik.

                         ┌────────────────┐
       permintaan ─────► │  LOAD BALANCER │
                         └───────┬────────┘
              ┌──────────────────┼──────────────────┐
              ▼                  ▼                  ▼
        ┌───────────┐      ┌───────────┐      ┌───────────┐
        │ Server A  │      │ Server B  │      │ Server C  │
        │ (salinan  │      │ (salinan  │      │ (salinan  │
        │  aplikasi)│      │  aplikasi)│      │  aplikasi)│
        └───────────┘      └───────────┘      └───────────┘

Pengunjung terhubung ke satu alamat. Load balancer diam-diam menyebar permintaan itu ke backend mana pun yang paling pas saat ini. Jawabannya kembali lewat jalur yang sama. Bagi browser, seolah-olah dia hanya berbicara dengan satu server tunggal yang sangat cepat.

Load balancer vs reverse proxy

Dua istilah ini sering disebut bersamaan, dan keduanya memang beririsan. Reverse proxy adalah server mana pun yang menerima permintaan atas nama satu atau beberapa backend lalu meneruskannya. Load balancer adalah reverse proxy yang tugas khususnya membagi trafik ke beberapa backend memakai strategi tertentu. Singkatnya: setiap load balancer itu reverse proxy, tapi tidak setiap reverse proxy sedang membagi beban. Banyak tool di dunia nyata yang menjalankan dua peran ini sekaligus.

Kenapa satu server tidak cukup

Kalau satu mesin bisa menangani segalanya selamanya, semua ini tidak akan ada. Tapi server punya batas yang keras, dan kamu menabraknya lewat dua jalan.

Yang pertama adalah kapasitas. Setiap server punya langit-langit — seberapa besar memorinya, berapa banyak permintaan yang bisa diolah CPU-nya per detik, berapa banyak koneksi yang bisa dia buka bersamaan. Dorong melewati langit-langit itu, dan permintaan mulai mengantre, waktu respons membengkak, dan akhirnya mesinnya tumbang. Kamu memang bisa membeli mesin yang lebih besar (ini disebut scaling up), tapi selalu ada batas seberapa besar satu kotak bisa dibuat, dan kotak besar cepat sekali jadi mahal.

Yang kedua adalah keandalan. Satu server adalah satu titik kegagalan tunggal. Kalau dia crash, reboot saat update, atau data center-nya kehilangan listrik, seluruh situsmu langsung gelap. Tidak ada rencana cadangan. Satu mesin berarti cuma satu hal yang berdiri di antara kamu dan tumbangnya layanan.

Load balancing menyelesaikan keduanya sekaligus dengan membiarkanmu menjalankan banyak server yang lebih kecil dan lebih murah secara berdampingan — pendekatan yang disebut scaling out. Butuh kapasitas lebih? Tambahkan satu backend lagi ke pool. Satu server mati? Load balancer menyadarinya lalu berhenti mengirimkan trafik ke sana, sementara yang lain terus jalan. Situsmu tetap hidup.

SCALE UP                        SCALE OUT
(satu mesin lebih besar)        (lebih banyak mesin, dibagi)

   ┌─────────────┐                ┌──┐ ┌──┐ ┌──┐ ┌──┐
   │             │                │  │ │  │ │  │ │  │
   │   SERVER    │                └──┘ └──┘ └──┘ └──┘
   │   BESAR     │                  ▲    ▲    ▲    ▲
   │             │                  └────┴─┬──┴────┘
   └─────────────┘                    load balancer
   batas: seberapa besar     batas: nyaris tidak ada —
   satu kotak bisa dibuat?   tinggal terus tambah kotak

Bagaimana load balancer memilih server

Jadi load balancer punya, katakanlah, tiga backend yang sehat dan satu permintaan baru saja mendarat. Bagaimana dia memilih? Di sinilah algoritma masuk. Tiap algoritma adalah aturan berbeda untuk menentukan siapa giliran berikutnya, dan pilihan yang tepat bergantung pada seperti apa server dan trafikmu.

Round robin

Aturan paling sederhana dari semuanya: ikuti urutan saja. Permintaan pertama ke Server A, berikutnya ke B, berikutnya ke C, lalu balik lagi ke A, dan begitu seterusnya. Mudah ditebak, adil, dan tidak butuh informasi apa pun soal kondisi server.

permintaan 1 → A
permintaan 2 → B
permintaan 3 → C
permintaan 4 → A   (balik ke awal)
permintaan 5 → B

Round robin bekerja mulus ketika semua server-mu kira-kira sama kuat dan tiap permintaan butuh kerja yang kurang lebih sama. Kelemahannya muncul saat asumsi itu rontok — kalau satu permintaan butuh sepuluh detik dan berikutnya cuma sepuluh milidetik, berputar tanpa berpikir bisa membuat satu server terkubur sementara yang lain menganggur.

Least connections

Alih-alih bergiliran, kirim tiap permintaan baru ke server yang saat ini sedang menangani koneksi terbuka paling sedikit. Logikanya, server dengan koneksi aktif lebih sedikit kemungkinan besar sedang lebih senggang, jadi bisa menampung kerja lebih banyak.

Cara ini menangani perbedaan waktu permintaan jauh lebih baik daripada round robin. Kalau Server A tersangkut pada beberapa permintaan lambat, jumlah koneksinya tetap tinggi, jadi balancer secara alami mengarahkan trafik baru ke B dan C yang lebih lengang. Ini default yang lebih cerdas untuk kebanyakan aplikasi nyata, di mana biaya tiap permintaan bervariasi.

Varian berbobot (weighted)

Kedua aturan di atas punya versi berbobot untuk kondisi ketika server-mu tidak setara. Mungkin Server A mesin yang gahar dan B lebih kecil. Kamu beri A bobot 3 dan B bobot 1, lalu balancer mengirim trafik kira-kira tiga kali lebih banyak ke A. Ini membuatmu bisa mencampur perangkat keras dengan ukuran berbeda dalam satu pool tanpa membebani kotak yang lebih lemah.

IP hash

Di sini balancer mengambil alamat IP pengunjung, melewatkannya ke sebuah fungsi hash, lalu memakai hasilnya untuk memilih server. Bagian cerdiknya: pengunjung yang sama selalu mendarat di server yang sama, karena IP mereka selalu menghasilkan angka hash yang sama. Sebentar lagi kita lihat kenapa itu kadang justru yang kamu butuhkan.

Tidak ada algoritma 'paling baik' yang tunggal

Round robin dan least connections sudah mencakup sebagian besar kasus, dan kebanyakan setup mulai dari salah satunya. Jangan terlalu pusing memilih di awal — ambil default yang masuk akal (least connections cukup aman kalau waktu permintaan bervariasi), buat situsmu jalan dulu, dan baru sentuh opsi yang lebih canggih kalau memang ada alasan nyata. Menyetel terlalu dini di sini adalah cara klasik membuang-buang waktu seharian.

Masalah sticky session

Sekarang jebakan yang hampir selalu bikin orang tersandung saat pertama kali menaruh situs di belakang load balancer.

Bayangkan seorang pengguna login. Server yang menangani login itu menyimpan sesinya — “orang ini adalah Jane Doe, dia sudah terautentikasi” — di dalam memorinya sendiri. Pada klik berikutnya, load balancer (memakai round robin, misalnya) mengirimnya ke server yang berbeda, yang sama sekali belum pernah mendengar nama Jane. Tiba-tiba dia terlempar keluar tanpa alasan. Refresh, dan dia mungkin login lagi, lalu keluar lagi — kekacauan yang berkedip-kedip dan bikin frustrasi.

Akar masalahnya: data pengguna tadi tersimpan di memori satu server tertentu, padahal permintaannya disebar ke semua server. Ada dua jalan keluar yang rapi.

Sticky session (disebut juga session affinity) menyuruh load balancer untuk selalu mengirim pengguna yang sama kembali ke server yang sama selama kunjungan mereka — sering memakai trik IP-hash tadi, atau sebuah cookie kecil. Jane selalu kembali ke server yang mengenalnya. Cara ini berhasil, tapi agak rapuh: kalau server yang satu itu mati, semua orang yang dipasangkan padanya tetap kehilangan sesinya, dan distribusi trafikmu bisa jadi tidak merata.

Solusi jangka panjang yang lebih baik adalah membuat server-mu stateless — simpan data sesi di tempat bersama (sebuah database atau penyimpanan in-memory yang cepat) yang bisa dijangkau semua backend, bukan di memori lokal satu server. Sekarang tidak penting lagi server mana yang menjawab klik berikutnya Jane; mereka semua mengambil sesinya dari tempat bersama yang sama. Inilah pendekatan yang bisa diperbesar dengan rapi, dan layak dirancang sejak awal.

STICKY SESSION               STATELESS + PENYIMPANAN BERSAMA

Jane ─┐                      Jane ─┐
      └─ selalu → Server B          ├─ server mana pun
         (sesinya                       ▼      ▼      ▼
          tinggal di sini)          ┌───┐  ┌───┐  ┌───┐
                                    │ A │  │ B │  │ C │
   kalau B mati, sesi              └─┬─┘  └─┬─┘  └─┬─┘
   Jane ikut hilang                  └──────┼──────┘
                                            ▼
                                    ┌──────────────────┐
                                    │ penyimpanan      │  ← sesi tinggal di sini
                                    │ bersama          │
                                    └──────────────────┘
                                    server mana pun bisa melayani Jane

Health check: tahu siapa yang masih hidup

Load balancer baru berguna kalau dia tidak mengirim trafik ke server yang sudah mati. Maka tiap load balancer yang layak menjalankan health check — secara berkala dia menyenggol tiap backend untuk bertanya “kamu baik-baik saja?” dan hanya mengarahkan trafik sungguhan ke yang menjawab dengan benar.

Health check bisa sesederhana membuka koneksi ke port server, atau seteliti meminta sebuah URL khusus (sering berupa sesuatu seperti /health) lalu mengecek apakah responsnya kembali dengan status yang benar. Kalau sebuah server gagal beberapa kali pemeriksaan berturut-turut, balancer menandainya tidak sehat dan diam-diam berhenti mengirim permintaan ke sana. Begitu dia pulih dan kembali lolos pemeriksaan, dia otomatis dimasukkan lagi ke rotasi.

   ┌──────────────┐
   │ LOAD BALANCER│  tiap beberapa detik: "masih hidup?"
   └──┬────┬────┬─┘
      │    │    │
     OK   OK   ✗ tidak menjawab
      ▼    ▼    ▼
   ┌───┐┌───┐┌───┐
   │ A ││ B ││ C │  ← C ditandai tidak sehat,
   └───┘└───┘└───┘     tidak diberi trafik sampai pulih

Mekanisme inilah yang mengubah “kita punya beberapa server” menjadi “kita punya situs yang selamat saat satu server mati.” Tanpa health check, backend yang crash akan terus menerima jatah permintaannya, dan tiap pengguna yang sialnya diarahkan ke sana akan menabrak error. Dengannya, kegagalan jadi nyaris tak terlihat oleh pengunjungmu.

Di lapisan mana load balancer bekerja

Load balancing bukan satu hal yang baku — dia bisa terjadi di lapisan yang berbeda-beda, dan kamu bakal menjumpai beberapa rasa.

Balancer layer 4 bekerja di tingkat transport (dunia TCP/IP dan nomor port). Dia mengambil keputusan murni berdasarkan info tingkat koneksi, tanpa mengintip ke dalam isi permintaannya. Dia cepat dan sederhana karena tidak membaca atau memahami trafiknya — dia tinggal melempar koneksi ke backend. Kalau nomor port dan bentuk dasar trafik jaringan masih terasa kabur, tulisan kami soal alamat IP dan port menyiapkan fondasinya.

Balancer layer 7 bekerja di tingkat aplikasi — dia benar-benar memahami HTTP. Karena bisa membaca permintaan, dia bisa mengambil keputusan yang lebih cerdas: mengirim semua permintaan untuk /images/ ke satu kelompok server dan /api/ ke kelompok lain, mengarahkan berdasarkan bahasa pengunjung, atau menangani HTTPS untuk seluruh pool. Lebih fleksibel, tapi sedikit lebih banyak kerja per permintaan. Untuk sebuah website, layer 7 biasanya yang kamu mau.

Ada juga perbedaan soal di mana balancer-nya berjalan. Software load balancer adalah program yang jalan di server biasa — fleksibel, murah, dan inilah yang dipakai kebanyakan proyek. Hardware load balancer adalah perangkat fisik khusus yang dibangun untuk kecepatan mentah, kebanyakan ada di perusahaan besar. Dan di cloud, penyedia layanan menawarkan load balancing sebagai layanan terkelola yang tinggal kamu nyalakan tanpa menjalankan apa pun sendiri, dan begitulah banyak setup modern menanganinya. Kalau bedanya antara menjalankan kotakmu sendiri dan menyewa infrastruktur terkelola masih buram, ulasan kami soal shared vs VPS vs dedicated vs cloud menempatkan opsi-opsi itu dalam konteks.

Balancer-nya sendiri bisa jadi titik kegagalan tunggal

Ada ironi yang perlu disebut: kalau semua trafikmu mengalir lewat satu load balancer dan mesin itu mati, kamu tumbang lagi — kamu cuma memindahkan titik kegagalan tunggal, bukan menghilangkannya. Setup yang serius menjalankan balancer-nya sendiri secara redundan (dua atau lebih, dengan failover otomatis di antaranya) supaya tidak ada satu kotak pun yang kematiannya menjatuhkan segalanya. Ini detail yang gampang terlupa sampai hari ketika dia menggigitmu.

Model pikir yang gampang nempel

Kalau kamu cuma boleh mengingat satu hal, peganglah ini: load balancer adalah pengatur lalu lintas yang berdiri di depan satu tim pekerja yang bisa saling menggantikan. Tiga tugas intinya adalah membagi pekerjaan dengan adil, menyadari ketika seorang pekerja tumbang lalu mengarahkan trafik melewatinya, dan menjaga agar tim itu tampak seperti satu layanan tunggal yang bisa diandalkan dari luar.

Selebihnya — algoritma, sticky session, layer 4 versus layer 7 — cuma detail yang ditumpuk di atas satu ide itu. Pasang gambaran intinya dengan kokoh, dan sisanya bakal masuk dengan sendirinya saat kamu membutuhkannya. Dan karena load balancer itu sendiri sejenis server yang menerima permintaan atas nama yang lain, ada baiknya kamu sudah mantap soal apa itu web server sebelum menyelam lebih jauh di sini.

Penutup

Mari kita kumpulkan semuanya dalam satu tempat:

Load balancing menyebar permintaan yang masuk ke beberapa server backend yang identik supaya tidak ada satu pun yang kewalahan. Load balancer adalah bagian yang menghadap publik dan menentukan siapa menjawab tiap permintaan.
Dia menyelesaikan dua masalah sekaligus: kapasitas (scale out dengan menambah banyak server murah ketimbang satu yang raksasa) dan keandalan (satu server mati tidak lagi menjatuhkan seluruh situs).
Server dipilih memakai sebuah algoritma — round robin (bergiliran), least connections (kirim ke yang paling lengang), versi berbobot untuk perangkat keras yang tidak setara, atau IP hash untuk kelengketan.
Menyebar pengguna ke banyak server merusak memori per-server, dan memunculkan masalah sticky session. Atasi dengan session affinity, atau lebih baik lagi, buat server stateless dengan penyimpanan sesi bersama.
Health check membuat balancer bisa mendeteksi backend yang mati dan mengarahkan trafik melewatinya — inilah yang benar-benar menepati janji “tetap hidup”.
Balancing bisa terjadi di layer 4 (cepat, tingkat koneksi) atau layer 7 (cerdas, paham HTTP), dan berjalan sebagai software, hardware, atau layanan cloud terkelola. Jangan lupa membuat balancer-nya sendiri redundan.

Begitu kamu nyaman dengan cara trafik disebar ke banyak mesin, langkah berikutnya yang wajar adalah melihat bagaimana satu server menampung beberapa situs berbeda sekaligus — dan untuk itulah virtual host ada.