Menggunakan NGINX sebagai HTTP Load Balancer
NGINX adalah software open-source multifungsi yang dapat berperan sebagai web server, reverse proxy, dan HTTP load balancer. NGINX memiliki performa yang cepat dan efisien, serta mampu mengelola ribuan koneksi secara bersamaan dengan menggunakan sumber daya server yang tergolong sedikit.
Selain itu, NGINX juga memiliki fitur-fitur keamanan dan skalabilitas yang membuatnya menjadi favorit di kalangan Developer dan System Administrator. NGINX juga sangat fleksibel dan mudah disesuaikan dengan banyak teknologi dan application-stack.
Dalam artikel ini kita akan membahas NGINX sebagai HTTP load balancer.
- Apa itu Load Balancer?
- Load Balancer Cloud Raya
- NGINX sebagai HTTP Load Balancer
- Instalasi Cepat NGINX
- Mengkonfigurasi Server Block NGINX
- Kumpulan Opsi pada NGINX Load Balancer
- Kesimpulan
Apa itu Load Balancer?
Load balancer merupakan komponen penting dari setiap situs web atau aplikasi web yang memiliki volume lalu lintas tinggi. Dengan membagi permintaan di antara beberapa server, Load Balancer dapat mencegah terjadinya kelebihan beban pada satu server yang dapat membuat situs web menjadi lambat atau bahkan tidak berfungsi sama sekali. Dengan penggunaan Load Balancer, situs web dapat tetap responsif dan tersedia untuk pengguna setiap saat.
Load Balancer Cloud Raya
Cloud Raya sebenarnya juga telah dilengkapi dengan load balancer. Untuk informasi lebih lanjut mengenai load balancer dari Cloud Raya dan metode-metode load balancing yang dimilikinya, dapat Anda temukan pada Knowledge Base berikut.
Namun demikian, perlu diketahui bahwa load balancer dari Cloud Raya saat ini belum mendukung SSL termination, dikarenakan operasinya berada pada OSI layer 4. Jika salah satu pertimbangan Anda adalah terkait kebutuhan SSL termination pada load balancer, ayo kita lanjut ke poin berikutnya.
NGINX sebagai HTTP Load Balancer
Selain berfungsi sebagai web server, salah satu fitur terbaik dari NGINX adalah kemampuannya untuk berfungsi sebagai HTTP load balancer yang sudah berjalan pada OSI layer 7.
Akan ada modul “upstream” yang akan kita ketahui bersama di poin berikutnya, di mana modul ini berguna untuk menentukan grup web server yang menerima request dan juga sebagai tempat untuk deklarasi metode load balancer yang kita inginkan.
Grup web server tersebut bisa berada pada satu fisik yang sama atau berada pada beberapa server, baik dalam satu data center yang sama atau di lokasi yang berbeda di seluruh dunia.
Instalasi Cepat NGINX
Sebelum mengonfigurasi NGINX load balancer, Anda harus terlebih dahulu memasang NGINX pada VM Anda. Anda dapat menginstalnya menggunakan perintah berikut:
# apt-get install nginx
Mengkonfigurasi Server Block NGINX
Sekarang edit server block kita untuk mulai mengkonfigurasi load balancer NGINX.
Default Server Block dari NGINX adalah berada di:
/etc/nginx/sites-available/default
Namun bisa Anda sesuaikan kembali apabila Anda sempat custom lokasi server blocknya, seperti di sini contohnya saya akan membuka konfigurasi server block saya pada lokasi berikut:
/etc/nginx/sites-available/default
Sekarang kita mulai dengan konfigurasi load balancer yang simple. Konfigurasi server block berikut akan mengproxykan lalu lintas HTTP (port 80) dan meneruskannya secara round-robin ke kumpulan upstream backend yang bernama “my-webserver” dengan isinya yaitu web-server1 dan web-server2. Konfigurasi ini akan membuat koneksi HTTP yang baru di setiap prosesnya.
upstream my-webserver {
server 10.10.100.9 ; #web-server1
server 10.10.100.10 ; #web-server2
}
server {
listen 80;
location / {
proxy_pass http://my-webserver;
}
}
Kumpulan Opsi pada NGINX Load Balancer
Ada juga koleksi opsi lanjutan yang dapat kita atur untuk keperluan yang lebih detail. Opsi tersebut antara lain adalah :
- Metode Load Balancing
- Round Robin – default method
- Least Connections
- Least time (NGINX Plus)
- Hash
- IP Hash
- Random
- Server Weights
- HTTP Load Balancer Health Check (NGINX Open Source & NGINX Plus)
- Server Slow Start (NGINX Plus)
- TCP and UDP Load Balancing (NGINX Plus)
- Enabling Session Persistence (NGINX Plus)
- Connection Limiting (NGINX Plus), dll
Dari beberapa opsi tersebut, ada yang merupakan fitur basic namun menjadi lebih lengkap dengan bantuan NGINX Plus, ada juga fitur yang eksklusif hanya ada di NGINX Plus.
Untuk NGINX Plus sendiri dijual dalam bentuk software subscription. Untuk info lebih lengkapnya, bisa Anda cek pada NGINX Plus Product Page.
Sementara pada tutorial ini kita bahas terlebih dahulu penjelasan dan konfigurasi untuk NGINX Open Source.
1. Metode Load Balancing
NGINX mendukung beberapa metode load balancing dengan kelebihan dan kelemahan masing-masing, penting pilih metode yang sesuai dengan use case Anda.
▶️ Round Robin
Round Robin merupakan default method yang akan digunakan jika parameter pada konfigurasi server block tidak ditentukan. Metode ini membagi permintaan ke server secara bergiliran, sehingga setiap server menerima permintaan dengan jumlah yang sama.
upstream my-webserver {
server 10.10.100.9 ; #web-server1
server 10.10.100.10 ; #web-server2
}
▶️ Least Connection
Metode Least Connection akan memilih server dari grup upstream backend yang memiliki koneksi aktif dari pengakses paling sedikit, untuk mengoptimalkan penggunaan resources dan menghindari overload pada salah satu server.
Namun dibalik kelebihan tersebut, kekurangan dari metode ini adalah tidak mempertimbangkan kapasitas & kecepatan masing-masing server dan besaran beban akses di tiap koneksi.
Contoh gampangnya, semisal backend node A memiliki 70 koneksi aktif (koneksinya ringan-ringan) dan node B memiliki 55 koneksi aktif (koneksinya berat-berat), algoritma least connection akan tetap memilih node B untuk melayani permintaan selanjutnya.
upstream my-webserver {
least_conn;
server 10.10.100.9 ; #web-server1
server 10.10.100.10 ; #web-server2
}
▶️ Hash
Metode Hash akan mendistribusikan request ke upstream backend berdasarkan specified key yang kita tentukan, semisal IP dari pengakses, atau request URL tertentu. Algoritma ini memastikan bahwa klien yang memiliki kriteria yang sama akan selalu diarahkan ke server backend yang sama.
Contoh penggunaan metode hash pada NGINX adalah sebagai berikut:
....
map $request_uri $uri_hash {
default "";
~^/page1 $prefix1;
~^/page2 $prefix2;
}
map $uri_hash $server_prefix {
default "";
$prefix1 backend1;
$prefix2 backend2;
}
upstream my-webserver {
hash $uri_hash$server_prefix consistent;
server backend1.cloudforindonesia.com ; #web-server1
server backend2.cloudforindonesia.com ; #web-server2
}
....
Pada konfigurasi tersebut, kita menambahkan map baru bernama $server_prefix yang menghasilkan nilai backend1 jika nilai $uri_hash adalah $prefix1, dan nilai backend2 jika nilai $uri_hash adalah $prefix2. Dalam algoritma hash NGINX pada bagian hash $uri_hash$server_prefix consistent, nilai $server_prefix ditambahkan sebagai faktor tambahan untuk menentukan backend server yang sesuai.
Dengan cara ini, algoritma hash Nginx akan memilih backend server yang sesuai berdasarkan nilai $uri_hash dan $server_prefix. Misalnya, jika nilai $request_uri adalah /page2/index.html, maka nilai $uri_hash akan menjadi $prefix2, dan $server_prefix akan menjadi backend2. Oleh karena itu, algoritma hash Nginx akan memilih backend server dengan nilai $uri_hash dan $server_prefix yang sesuai, yaitu backend2.cloudforindonesia.com.
Berikut contoh opsi hash lainnya yang bisa kita gunakan:
- “
hash $cookie_cookie_name“: membuat hash berdasarkan nilai cookie tertentu yang disebut “cookie_name”. - “
hash $http_header_name“: membuat hash berdasarkan nilai header HTTP tertentu yang disebut “header_name”. - “
hash $ssl_session_id“: membuat hash berdasarkan ID sesi SSL. - “
hash $variable_name“: membuat hash berdasarkan nilai variabel NGINX tertentu yang disebut “variable_name”.
▶️ IP Hash
Hash dan IP Hash adalah teknik load balancing yang sama-sama menggunakan nilai hash untuk memilih server backend. Namun, perbedaannya terletak pada kriteria yang digunakan dalam menghasilkan nilai hash.
Jika Hash menggunakan nilai hash dari kriteria yang ditentukan, sedangkan IP Hash menggunakan nilai hash dari alamat IP pengakses. Metode IP Hash melakukan hash pada alamat IP pengakses dengan rumusan tertentu untuk menentukan server backend yang akan menangani request berdasarkan nilai hash tersebut.
upstream my-webserver {
ip_hash;
server 10.10.100.9 ; #web-server1
server 10.10.100.10 ; #web-server2
}
Keuntungan dari metode IP Hash adalah bahwa semua permintaan dari alamat IP yang sama akan selalu diteruskan ke server backend yang sama, sehingga lebih menjamin bahwa setiap pengakses tidak akan terputus sessionnya karena dibagi ke server yang berbeda-beda.
Kelemahan dari kedua metode ini adalah ketidakmampuannya dalam memastikan seimbangnya beban request dari tiap alamat IP pengakses yang didistribusikan ke setiap server. Namun, IP hash dapat memastikan konsistensi sesi pengguna dengan memastikan bahwa setiap alamat IP pengguna selalu terhubung ke server backend yang sama.
Dengan NGINX Plus, ada tambahan fitur yang sudah support cookie-based session persistence, salah satunya sticky cookie.
▶️ Random
Metode random dalam NGINX memungkinkan kita memilih server secara acak dari kumpulan server backend yang tersedia. Ada dua cara yang berbeda untuk menggunakan metode random di NGINX, yaitu dengan, atau tanpa parameter “two”.
upstream my-webserver {
random;
server 10.10.100.9 ; #web-server1
server 10.10.100.10 ; #web-server2
server 10.10.100.11 ; #web-server3
server 10.10.100.12 ; #web-server4
}
Metode random tanpa parameter “two” memilih satu server secara acak dari kumpulan backend setiap kali permintaan datang.
upstream my-webserver {
random two least_time=last_byte;
server 10.10.100.9 ; #web-server1
server 10.10.100.10 ; #web-server2
server 10.10.100.11 ; #web-server3
server 10.10.100.12 ; #web-server4
}
Sedangkan pada metode random berikutnya, kita menambahkan parameter “two” untuk menentukan bahwa NGINX akan memilih dua server secara acak dari kumpulan backend yang tersedia. Kemudian, dari dua server yang telah dipilih, NGINX akan memilih satu server dengan rata-rata waktu tercepat dalam memberikan respons kepada pengguna.
Metode penentu di dalam parameter “two” ini bisa diantara berikut:
- Least Connections: memilih server backend dengan jumlah koneksi aktif terendah saat ini.
- Least Time (Header): memilih server backend yang memiliki waktu rata-rata paling singkat dalam menerima respons header. (Menggunakan variabel
$upstream_header_time). - Least Time (Last Byte): memilih server backend yang memiliki waktu rata-rata paling singkat dalam menerima seluruh respons, termasuk body response.
2. Server Weights
Setelah kita ketahui tentang metode load balancing dari NGINX, sekarang ayo kita ketahui tentang opsi tingkat lanjut yaitu “server weights”.
Pada dasarnya server weight adalah opsi dimana kita bisa menentukan bobot tiap server backend dalam menerima sebuah request. Nilai server weight berupa number, dengan default weight tiap server yaitu 1.
upstream my-webserver {
server 10.10.100.9 weight=5 ; #web-server1
server 10.10.100.10 weight=2 ; #web-server2
server 10.10.100.11 ; #web-server3
}
Pada contoh di atas, apabila terdapat request access sebanyak 10, maka akan didapati proporsi sebagai berikut:
Jumlah total bobot untuk server A, B, dan C adalah 5+2+1=8.
- Server A: 5/8 x 10 = 6.25 (dibulatkan menjadi 6)
- Server B: 2/8 x 10 = 2.5 (dibulatkan menjadi 3)
- Server C: 1/8 x 10 = 1.25 (dibulatkan menjadi 1)
Jadi, dalam contoh ini, server A akan menerima 6 permintaan, server B akan menerima 3 permintaan, dan server C akan menerima 1 permintaan.
Dengan menentukan server weight yang tepat, kita dapat meningkatkan kinerja dan ketersediaan aplikasi web dengan memberikan bobot yang lebih tinggi pada server yang lebih kuat dan stabil.
Opsi server weight ini juga kita bisa gabungkan dengan opsi-opsi lainnya yang ada semisal ke dalam metode load balancer yang kita inginkan, menjadikan konfigurasi dan pengolahan load balancer kita lebih kompleks dan advance.
3. HTTP Load Balancer Health Check
Fitur HTTP health check memungkinkan untuk memverifikasi kesehatan dari server backend sebelum meneruskan permintaan klien. Jika server dianggap tidak sehat, NGINX akan menghentikan pengiriman permintaan ke server tersebut.
Ada dua jenis health check yang tersedia pada NGINX.
▶️ Passive Health Check (NGINX Open Source dan NGINX Plus)
Untuk Passive Health Check, NGINX dan NGINX Plus memantau hanya saat transaksi berlangsung, dan berusaha untuk melanjutkan koneksi yang gagal. Jika tetap tidak bisa, NGINX akan menandai server sebagai tidak tersedia dan berhenti sementara mengirim permintaan ke server tersebut sampai dianggap aktif lagi.
Parameter berikut dapat digunakan untuk mengatur kondisi-kondisi yang menunjukkan bahwa upstream server dianggap tidak tersedia.
- fail_timeout – menentukan waktu maksimal dalam menunggu percobaan komunikasi yang tidak berhasil dengan server. Waktu ini juga menentukan durasi ketika server dianggap tidak tersedia. Default-nya adalah 10 detik.
- max_fails – Menentukan jumlah percobaan yang harus gagal selama periode fail_timeout agar servernya dinyatakan tidak tersedia (default-nya 1 kali percobaan).
upstream my-webserver {
server 10.10.100.9 weight=5 max_fails=3 fail_timeout=30s;
server 10.10.100.10 weight=2 max_fails=3 fail_timeout=30s;
server 10.10.100.11 max_fails=3 fail_timeout=30s;
}
Pada contoh di atas, setiap server diberikan parameter max_fails dan fail_timeout dengan nilai 3 dan 30 detik. Jadi jika ada 3 percobaan gagal dalam 30 detik, server dianggap tidak tersedia dan NGINX tidak mengirim permintaan ke server tersebut selama 30 detik. Jika masih gagal dalam 3 percobaan berikutnya, server tidak akan menerima permintaan kembali dari load balancer.
▶️ Active Health Check (NGINX Plus)
Sebelum server backend mengalami kendala atau tidak tersedia, NGINX Plus sudah aktif memonitorinya.
NGINX Plus akan secara teratur mengirimkan permintaan ke setiap server backend dan mengukur waktu response dan kode status dari server tersebut. Jika server tidak meresponse dalam waktu yang diatur atau memberikan kode status yang salah, maka server dianggap tidak sehat dan dihapus dari pool server yang tersedia.
Kesimpulan
Masih banyak hal menarik seputar topik ini yang belum kita bahas, dan rasanya sangat menarik untuk dieksplorasi lebih lanjut. Untuk informasi lebih lengkap tentang parameter-parameter Load Balancer di NGINX, bisa langsung cek NGINX HTTP Upstream module.
Jika ingin mengetahui lebih banyak lagi tentang manfaat dan fitur-fitur keren yang ada di NGINX Plus, bisa juga langsung cek ke halaman guide-nya.
Eksplor lebih banyak tutorial di halam knowledge base di sini, atau tonton tutorial video di channel Youtube Cloud Raya di sini.