Load Balancing Strategy & Multiple Instances

Load balancing membagi trafik ke beberapa instance agar aplikasi lebih tahan beban dan tidak bergantung pada satu proses.

Mengapa multiple instance?Copy Anchor Link

• Throughput lebih tinggi.
• Failover jika satu instance mati.
• Deployment rolling/zero-downtime.
• Isolasi kegagalan lebih baik.

Aplikasi harus statelessCopy Anchor Link

Instance aplikasi sebaiknya tidak menyimpan state lokal.

Dengan stateless, request bisa dilayani instance mana pun.

Algoritma load balancingCopy Anchor Link

Nginx round robin (default)Copy Anchor Link

upstream app_backend {
    server 10.10.10.11:3000;
    server 10.10.10.12:3000;
}

Least connectionsCopy Anchor Link

upstream app_backend {
    least_conn;
    server 10.10.10.11:3000;
    server 10.10.10.12:3000;
}

IP hashCopy Anchor Link

upstream app_backend {
    ip_hash;
    server 10.10.10.11:3000;
    server 10.10.10.12:3000;
}

IP hash membuat client yang sama cenderung ke instance yang sama. Namun jika IP berubah (mobile network, proxy), session bisa hilang. Lebih baik gunakan session store terpusat.

Menjalankan dua instance dengan ComposeCopy Anchor Link

services:
  app1:
    image: ghcr.io/org/app:${IMAGE_TAG}
    env_file: .env
    ports:
      - "127.0.0.1:3001:3000"

  app2:
    image: ghcr.io/org/app:${IMAGE_TAG}
    env_file: .env
    ports:
      - "127.0.0.1:3002:3000"

Nginx:

upstream app_backend {
    least_conn;
    server 127.0.0.1:3001 max_fails=3 fail_timeout=10s;
    server 127.0.0.1:3002 max_fails=3 fail_timeout=10s;
}

Deployment bertahapCopy Anchor Link

1. Deploy instance baru di port berbeda.
2. Health check instance baru.
3. Tambahkan ke upstream.
4. Reload Nginx.
5. Hapus instance lama setelah draining.

nginx -t && systemctl reload nginx

Reload Nginx tidak memutus koneksi lama.

Session dan sticky sessionCopy Anchor Link

Jika terpaksa memakai sticky session:

upstream app_backend {
    ip_hash;
    server 10.10.10.11:3000;
    server 10.10.10.12:3000;
}

Namun solusi yang lebih baik:

// session disimpan di Redis
app.use(session({
  store: new RedisStore({ client: redisClient }),
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
}));

Database connection poolCopy Anchor Link

Setiap instance membuka koneksi ke database. Dengan 5 instance dan pool 20, total koneksi bisa 100.

const pool = new Pool({
  host: process.env.DB_HOST,
  max: 10,
  idleTimeoutMillis: 30000,
  connectionTimeoutMillis: 5000,
});

Hitung: jumlah instance × max pool harus di bawah batas database.

Health check dan failoverCopy Anchor Link

server 10.10.10.11:3000 max_fails=3 fail_timeout=10s;

Jika instance gagal beberapa kali, Nginx mengeluarkannya sementara. Pastikan health endpoint benar-benar mencerminkan kesiapan.

ScalingCopy Anchor Link

Horizontal scaling lebih fleksibel, tetapi menuntut aplikasi stateless dan koordinasi resource.

Praktik: uji distribusiCopy Anchor Link

for i in $(seq 1 10); do
  curl -s http://app.example.com/whoami
  echo
done

Endpoint /whoami dapat mengembalikan hostname/instance ID untuk memastikan trafik terdistribusi.

RingkasanCopy Anchor Link

• Multiple instance meningkatkan kapasitas dan ketersediaan.
• Aplikasi harus stateless; session disimpan terpusat.
• Pilih algoritma sesuai karakter trafik.
• Perhitungkan connection pool saat menambah instance.