Apa itu load balancer dan cara kerjanya: ia berdiri di depan beberapa server, menerima semua permintaan masuk, lalu menyebarkannya ke server yang sehat. Manfaat utamanya bukan kecepatan, melainkan satu server bisa mati tanpa layanan berhenti.
Load balancer sering dijelaskan sebagai cara membuat situs lebih cepat. Itu keliru, atau setidaknya bukan bagian terpentingnya.
Yang sebenarnya diberikan adalah kemampuan mengeluarkan satu server dari rotasi — karena mati, atau karena sedang diperbarui — tanpa ada pengunjung yang merasakannya.
Cara kerjanya dalam satu alur
Pengunjung mengarahkan permintaan ke satu alamat, yaitu load balancer. Ia bukan yang menjalankan aplikasi; ia hanya memutuskan server mana yang akan menangani permintaan itu, meneruskannya, lalu mengembalikan jawabannya.
Keputusan itu dibuat berdasarkan algoritma. Yang paling umum round robin — bergiliran satu per satu. Ada juga least connections yang memilih server dengan koneksi aktif paling sedikit, dan ini biasanya lebih baik untuk aplikasi yang lama proses tiap permintaannya berbeda-beda.
Karena semua lalu lintas melewatinya, load balancer sendiri menjadi titik yang harus diperhatikan. Layanan terkelola dari penyedia cloud sudah redundan di dalamnya; kalau Anda memasang sendiri dengan HAProxy atau Nginx, perlu dua instance dengan alamat mengambang agar tidak menjadi titik kegagalan tunggal.
Health check load balancer: bagian yang menentukan segalanya
Fungsi health check load balancer adalah memeriksa apakah setiap server di belakang masih layak menerima permintaan. Tanpa ini, load balancer akan tetap mengirim pengunjung ke server yang sudah mati.
Yang sering disetel terlalu dangkal: pemeriksaan hanya memastikan port terbuka. Server yang portnya terbuka tetapi aplikasinya mengembalikan kesalahan tetap dianggap sehat, dan sepertiga pengunjung tetap mendapat halaman error.
Pemeriksaan yang baik memanggil satu endpoint khusus yang benar-benar menguji jalur penting — misalnya bisa terhubung ke basis data — lalu mengembalikan status 200 hanya bila semuanya baik. Endpoint itu juga sebaiknya ringan, karena ia dipanggil setiap beberapa detik.
Ambang batasnya perlu dipikirkan: terlalu sensitif membuat server keluar-masuk rotasi karena satu kegagalan sesaat, terlalu longgar membuat server mati bertahan lama di rotasi.
Load balancer layer 4 dan 7: bedanya di mana
Pembagian load balancer layer 4 dan 7 mengacu pada seberapa dalam ia membaca lalu lintas. Layer 4 bekerja pada tingkat TCP: ia melihat alamat dan port, lalu meneruskan tanpa membaca isinya. Cepat dan hemat sumber daya.
Layer 7 membaca permintaan HTTP-nya — jalur URL, header, cookie. Itu membuka kemampuan yang tidak dimiliki layer 4: mengarahkan `/api` ke satu kelompok server dan `/` ke kelompok lain, menghentikan TLS di load balancer, menyisipkan header, atau menolak permintaan tertentu.
Untuk aplikasi web, layer 7 hampir selalu yang dipakai. Layer 4 lebih cocok untuk lalu lintas non-HTTP — basis data, atau protokol khusus — dan untuk kasus di mana enkripsi harus tetap utuh sampai ke server aplikasi.
Sticky session: solusi yang sebaiknya dihindari
Masalah muncul ketika aplikasi menyimpan sesi pengguna di memori server yang menanganinya. Permintaan berikutnya yang diarahkan ke server lain tidak menemukan sesi itu, dan pengguna keluar dari akunnya.
Penyelesaian cepatnya sticky session: load balancer mengingat pengunjung dan selalu mengarahkannya ke server yang sama. Ini bekerja, tetapi mengorbankan sebagian manfaat load balancer — kalau server itu mati, pengunjungnya tetap kehilangan sesi, dan beban tidak lagi tersebar merata.
Cara yang lebih baik: keluarkan sesi dari memori server ke penyimpanan bersama. Dengan sesi di tempat yang bisa dibaca semua server, permintaan mana pun bisa ditangani server mana pun — dan itulah kondisi yang seharusnya sebelum load balancer dipasang.
Kapan butuh load balancer, dan kapan belum
Pertanyaan kapan butuh load balancer punya jawaban yang cukup tegas. Beberapa tanda yang menunjukkan sudah waktunya:
- Layanan tidak boleh mati saat pemeliharaan, sehingga perlu memperbarui server satu per satu.
- Satu server sudah tidak cukup pada beban puncak, dan menaikkan spesifikasi sudah mendekati batas.
- Ada komitmen ketersediaan tertulis ke pelanggan yang tidak bisa dipenuhi satu server.
- Ingin menguji versi baru pada sebagian kecil lalu lintas sebelum diterapkan ke semua.
Reverse proxy dan load balancer: istilah yang sering tertukar
Perbedaan reverse proxy dan load balancer membingungkan karena satu perangkat lunak sering menjadi keduanya. Nginx dan HAProxy bisa berperan sebagai reverse proxy sekaligus load balancer.
Reverse proxy adalah perantara yang menerima permintaan lalu meneruskannya ke belakang — dengan satu server di belakang pun ia sudah disebut reverse proxy. Fungsinya bisa termasuk menghentikan TLS, menyajikan cache, dan menyaring permintaan.
Load balancer adalah reverse proxy yang punya lebih dari satu server di belakang dan memutuskan pembagiannya. Jadi setiap load balancer adalah reverse proxy, tetapi tidak setiap reverse proxy adalah load balancer.
Praktisnya: kalau Anda sudah memakai Nginx di depan aplikasi, sebagian pekerjaan menuju load balancer sudah selesai. Menambahkan server kedua ke blok `upstream` adalah langkah yang jauh lebih kecil daripada memasang sistem baru.
Yang perlu disiapkan sebelum memasangnya
Load balancer memberi manfaatnya hanya bila aplikasi di belakangnya siap berjalan lebih dari satu. Beberapa hal yang biasanya perlu dibereskan lebih dulu.
Satu kesalahan yang sering muncul setelah load balancer dipasang: sertifikat TLS hanya diperbarui di satu server. Kalau TLS dihentikan di load balancer, sertifikat cukup dikelola di satu tempat — tetapi bila diteruskan ke server aplikasi, setiap server perlu sertifikat yang sama dan tanggal perpanjangannya harus terpantau bersama.
- Sesi pengguna dipindahkan dari memori atau berkas lokal ke penyimpanan yang bisa dibaca semua server.
- Berkas yang diunggah pengguna disimpan di penyimpanan bersama atau penyimpanan objek, bukan di disk salah satu server.
- Tugas terjadwal dipastikan berjalan di satu tempat saja, supaya tidak dieksekusi berkali-kali.
- Log dikumpulkan terpusat, karena menelusuri masalah dengan log yang terpisah per server sangat melelahkan.
- Proses penerapan kode diotomatiskan, sebab menerapkan manual ke beberapa server akan menghasilkan versi yang berbeda.