Nginx Bisa Jadi Load Balancer TANPA Kubernetes

Nginx Bisa Jadi Load Balancer TANPA Kubernetes

Banyak orang mengasosiasikan load balancing dengan Kubernetes, service mesh, atau cloud-native stack yang kompleks.

Padahal, jauh sebelum Kubernetes populer, Nginx sudah lama dan sangat stabil digunakan sebagai load balancer—bahkan sampai hari ini masih dipakai di production skala besar tanpa Kubernetes sama sekali.

Artikel ini membahas bagaimana Nginx bekerja sebagai load balancer, kapan cocok digunakan tanpa Kubernetes, serta kesalahpahaman umum yang sering terjadi.

1. Load Balancer ≠ Kubernetes

Salah kaprah paling umum:

“Kalau mau load balancing, harus pakai Kubernetes.”

Faktanya:

  • Kubernetes bukan load balancer, ia orchestrator
  • Load balancing adalah konsep, bukan produk
  • Nginx, HAProxy, Envoy sudah melakukan load balancing jauh lebih dulu

Kubernetes hanya:

  • Mengotomasi scaling
  • Mengelola service discovery
  • Menyediakan abstraction (Service, Ingress)

Tanpa Kubernetes pun, load balancing tetap bisa dilakukan secara manual dan stabil.

2. Apa yang Bisa Dilakukan Nginx sebagai Load Balancer?

Nginx mampu melakukan:

  • Layer 7 (HTTP/HTTPS) load balancing
  • Layer 4 (TCP/UDP) load balancing
  • Health check (basic)
  • SSL termination
  • Sticky session
  • Rate limiting
  • Failover backend

Dengan resource kecil, Nginx mampu menangani puluhan ribu request per detik.

3. Konsep Dasar: upstream

Kunci load balancing di Nginx adalah directive upstream.

Contoh Sederhana

upstream backend_app {
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
    server 10.0.0.3:8080;
}

Kemudian dipakai di proxy_pass:

location / {
    proxy_pass http://backend_app;
}

Artinya:

  • Request akan dibagi ke tiga server backend
  • Jika satu mati, request dialihkan ke server lain

4. Algoritma Load Balancing di Nginx

Secara default, Nginx menggunakan round-robin.

Namun tersedia opsi lain:

1. Round Robin (Default)

upstream backend {
    server app1;
    server app2;
}

Paling sederhana dan cukup untuk sebagian besar kasus.

2. Least Connections

upstream backend {
    least_conn;
    server app1;
    server app2;
}

Cocok jika:

  • Request punya durasi berbeda
  • Ada endpoint berat (report, export, dsb)

3. IP Hash (Sticky Session)

upstream backend {
    ip_hash;
    server app1;
    server app2;
}

Kegunaan:

  • User yang sama → backend yang sama
  • Berguna untuk aplikasi stateful

Catatan:

  • Tidak cocok jika backend sering bertambah/berkurang

5. Health Check: Jangan Asal Percaya Backend Hidup

Tanpa Kubernetes, Anda bertanggung jawab penuh terhadap health check.

Passive Health Check (Default)

upstream backend {
    server app1 max_fails=3 fail_timeout=30s;
    server app2 max_fails=3 fail_timeout=30s;
}

Artinya:

  • Jika 3 kali gagal dalam 30 detik
  • Backend dianggap down sementara

⚠️ Ini bukan active health check.

Active Health Check (Nginx Plus)

Versi open-source:

  • Tidak mendukung active health check HTTP

Alternatif:

  • Script eksternal
  • Monitoring + reload config
  • Gunakan HAProxy jika perlu health check agresif

6. Contoh Nyata: Load Balancer Tanpa Kubernetes

Arsitektur Umum

Internet
   |
[Nginx LB]
   |
--------------------
|        |         |
App-1   App-2     App-3

Biasanya digunakan pada:

  • VM on-premise
  • VPS (DigitalOcean, Linode, dsb)
  • Bare metal

7. SSL Termination di Load Balancer

Nginx sering dipakai untuk:

  • Terminate HTTPS
  • Backend tetap HTTP
server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /etc/ssl/cert.pem;
    ssl_certificate_key /etc/ssl/key.pem;

    location / {
        proxy_pass http://backend_app;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}

Keuntungan:

  • Backend lebih ringan
  • Sertifikat hanya di satu tempat
  • Debug lebih mudah

8. Sticky Session TANPA Kubernetes

Untuk aplikasi PHP lama / session di memory:

Dengan Cookie

upstream backend {
    hash $cookie_SESSIONID consistent;
    server app1;
    server app2;
}

Catatan:

  • Butuh konsistensi session key
  • Masih rentan jika backend mati

Solusi lebih baik:

  • Shared session (Redis / Memcached)

9. Kapan Nginx TANPA Kubernetes Lebih Masuk Akal?

Nginx lebih cocok jika:

  • Backend statis (tidak auto-scale)
  • Tim kecil
  • Infra sederhana
  • Traffic stabil
  • Tidak perlu self-healing kompleks

Contoh:

  • Aplikasi internal perusahaan
  • API private
  • Website company profile
  • Legacy system

10. Kapan Kubernetes Lebih Tepat?

Kubernetes unggul jika:

  • Scaling dinamis
  • Banyak service
  • Deployment sering
  • Butuh auto-healing
  • Tim DevOps matang

Masalahnya:

Banyak tim belum butuh Kubernetes, tapi sudah terlanjur pakai.

11. Kesalahan Umum Load Balancing dengan Nginx

  1. Tidak set timeout → request menggantung
  2. Tidak kirim header X-Forwarded-*
  3. Menganggap backend “pasti sehat”
  4. Reload config terlalu sering
  5. Tidak monitoring error rate

12. Kesimpulan

Nginx bukan alternatif murahan Kubernetes. Ia adalah:

  • Lebih sederhana
  • Lebih mudah dipahami
  • Lebih mudah di-debug
  • Sangat stabil untuk banyak use case

Kalau infrastrukturnya sederhana, Nginx sebagai load balancer sudah lebih dari cukup.

Kubernetes itu powerful, tapi power tidak selalu berarti perlu.

Related Posts