Apa Itu Load Balancing? Cara Menjaga Website Tetap Stabil saat Traffic Tinggi

Apa Itu Load Balancing?

Load balancing adalah proses mendistribusikan request pengguna ke beberapa server atau application instance.

Tanpa load balancer:

Pengguna
↓
Server A

Semua traffic masuk ke satu server.

Dengan load balancer:

                ┌─ Server A
Pengguna → Load Balancer ─ Server B
                └─ Server C

Load balancer menerima request terlebih dahulu, kemudian memilih server yang akan memprosesnya.

NGINX menjelaskan bahwa load balancing dapat digunakan untuk meningkatkan pemanfaatan resource, throughput, skalabilitas, performa, dan ketahanan aplikasi dengan mendistribusikan request ke beberapa application server.

Mengapa Website Bisa Down saat Traffic Tinggi?

Setiap server memiliki kapasitas tertentu.

Ketika jumlah request terlalu besar, server dapat mengalami:

1. CPU tinggi.

2. RAM penuh.

3. PHP-FPM kehabisan worker.

4. Database menerima terlalu banyak koneksi.

5. Response menjadi lambat.

6. Request mengalami timeout.

7. Website menghasilkan error 502 atau 503.

8. Server berhenti merespons.

Menambah spesifikasi server dapat membantu, tetapi terdapat batas seberapa besar satu server dapat ditingkatkan.

Load balancing memungkinkan aplikasi menggunakan beberapa server sekaligus.

Cara Kerja Load Balancer

Misalnya terdapat tiga application server:

App Server 1
App Server 2
App Server 3

Ketika 3.000 request masuk, load balancer mencoba mendistribusikan request tersebut berdasarkan algoritma yang digunakan.

Contohnya:

Request 1 → Server 1
Request 2 → Server 2
Request 3 → Server 3
Request 4 → Server 1

Dengan demikian, seluruh request tidak menumpuk pada satu server.

Load balancer modern juga dapat memeriksa kondisi target dan menghentikan sementara pengiriman traffic ke server yang dianggap tidak sehat. AWS Elastic Load Balancing, misalnya, hanya merutekan traffic ke target sehat dan berhenti mengirim request ke target yang gagal health check.

Jenis Algoritma Load Balancing

1. Round Robin

Round Robin membagikan request secara bergantian.

Contohnya:

Request 1 → Server A
Request 2 → Server B
Request 3 → Server C
Request 4 → Server A

NGINX menggunakan Round Robin secara default ketika metode load balancing lain tidak ditentukan.

Metode ini cocok jika setiap server memiliki kapasitas yang relatif sama.

2. Least Connections

Request berikutnya diberikan kepada server yang memiliki jumlah koneksi aktif paling sedikit.

Contohnya:

Server A = 100 koneksi
Server B = 40 koneksi
Server C = 70 koneksi

Request berikutnya akan diarahkan ke Server B.

Metode ini berguna ketika waktu pemrosesan setiap request berbeda.

3. IP Hash

IP Hash menggunakan alamat IP pengguna untuk menentukan server tujuan.

Dengan metode ini, pengguna yang sama cenderung diarahkan kembali ke server yang sama selama server tersebut tersedia.

Metode ini dapat digunakan ketika aplikasi membutuhkan session persistence.

4. Weighted Load Balancing

Tidak semua server harus menerima jumlah request yang sama.

Misalnya:

Server A = 8 Core
Server B = 8 Core
Server C = 4 Core

Server A dan B dapat diberikan bobot lebih besar dibandingkan Server C.

Pendekatan ini cocok ketika kapasitas setiap server berbeda.

Health Check

Load balancing tidak hanya membagi traffic.

Sistem juga sebaiknya melakukan health check.

Contohnya:

Server A → Healthy
Server B → Healthy
Server C → Down

Ketika Server C tidak merespons:

                ┌─ Server A
Traffic → LB ───┤
                └─ Server B

Server C tidak menerima traffic hingga kembali sehat.

Cloudflare Load Balancing menyediakan active monitoring untuk memeriksa endpoint berdasarkan status code, response, dan timeout serta melakukan failover ketika endpoint tidak sehat.

Load Balancing dan High Availability

Load balancing sering digunakan sebagai bagian dari arsitektur High Availability.

Tujuannya adalah mengurangi ketergantungan terhadap satu server.

Contohnya:

Internet
↓
Load Balancer
↓
┌─────────────┬─────────────┐
Server 1      Server 2      Server 3
↓             ↓             ↓
        Database Cluster

Jika satu application server mengalami masalah, server lainnya masih dapat menerima traffic.

Namun, load balancing saja belum membuat seluruh sistem otomatis high availability.

Komponen lain juga perlu diperhatikan, seperti:

1. Database.

2. Storage.

3. Cache.

4. Queue.

5. DNS.

6. Load balancer itu sendiri.

7. Network.

8. Backup.

Contoh Load Balancing Menggunakan NGINX

NGINX dapat digunakan sebagai HTTP load balancer.

Contoh konfigurasi sederhana:

upstream aplikasi_backend {
    server 10.0.0.11:80;
    server 10.0.0.12:80;
    server 10.0.0.13:80;
}

server {
    listen 80;

    server_name example.com;

    location / {
        proxy_pass http://aplikasi_backend;
    }
}

Pada konfigurasi tersebut:

example.com
↓
NGINX
↓
10.0.0.11
10.0.0.12
10.0.0.13

NGINX akan menggunakan Round Robin secara default untuk membagi request ke server dalam upstream tersebut.

Menggunakan Least Connections

Tambahkan:

upstream aplikasi_backend {
    least_conn;

    server 10.0.0.11:80;
    server 10.0.0.12:80;
    server 10.0.0.13:80;
}

Sekarang request akan diarahkan ke server dengan koneksi aktif paling sedikit.

Load Balancing untuk Laravel

Arsitektur Laravel dapat dibuat seperti berikut:

User
↓
Cloudflare / Load Balancer
↓
NGINX
↓
┌─────────────────────┐
Laravel App Server 1
Laravel App Server 2
Laravel App Server 3
└─────────────────────┘
↓
Redis
↓
Database

Pada arsitektur multi-server, Laravel perlu dirancang agar application server tidak terlalu bergantung pada data lokal.

Session Laravel Harus Terpusat

Masalah yang sering muncul pada load balancing adalah session.

Misalnya:

Login → Server A
Request berikutnya → Server B

Jika session hanya tersimpan pada file Server A, Server B mungkin menganggap pengguna belum login.

Hindari:

SESSION_DRIVER=file

untuk arsitektur multi-server.

Lebih baik menggunakan penyimpanan bersama seperti:

SESSION_DRIVER=redis

atau database, tergantung kebutuhan aplikasi.

Cache Harus Terpusat

Masalah yang sama berlaku pada cache.

Jika masing-masing server memiliki cache berbeda:

Server A → Cache A
Server B → Cache B
Server C → Cache C

data dapat menjadi tidak konsisten.

Untuk sistem multi-server, cache terpusat seperti Redis sering digunakan:

Server A ─┐
Server B ─┼→ Redis
Server C ─┘

File Upload Jangan Hanya Disimpan Lokal

Misalnya pengguna mengupload:

foto.jpg

dan file tersebut tersimpan hanya di Server A.

Ketika request berikutnya diarahkan ke Server B, file mungkin tidak ditemukan.

Gunakan shared storage seperti:

1. Object storage.

2. Amazon S3.

3. Compatible S3 storage.

4. Network File System.

5. Dedicated file storage.

Prinsipnya, file harus dapat diakses semua application server.

Queue Worker Dapat Dipisahkan

Pada aplikasi dengan traffic besar, proses berat sebaiknya tidak dikerjakan langsung melalui web request.

Contohnya:

Generate laporan
Kirim email
Kirim WhatsApp
Generate PDF
Import data
Proses gambar

Gunakan queue:

Web Server
↓
Queue
↓
Worker Server

Dengan demikian, application server dapat lebih fokus menangani request pengguna.

Database Bisa Menjadi Bottleneck

Menambahkan banyak application server tidak akan membantu apabila seluruh server tetap membebani satu database yang sudah penuh.

Contohnya:

10 App Server
↓
1 Database
↓
CPU Database 100%

Website tetap dapat lambat.

Karena itu, pantau:

1. Slow query.

2. Index.

3. Jumlah connection.

4. CPU database.

5. RAM.

6. Disk I/O.

7. Query per second.

8. Cache.

Load balancing harus menjadi bagian dari optimasi arsitektur secara keseluruhan.

Horizontal Scaling vs Vertical Scaling

Vertical Scaling

Meningkatkan spesifikasi satu server.

Contohnya:

4 CPU → 8 CPU
8 GB RAM → 32 GB RAM

Cara ini sederhana, tetapi terdapat batas hardware dan biaya.

Horizontal Scaling

Menambahkan jumlah server.

Contohnya:

1 Server
↓
3 Server
↓
10 Server

Load balancing digunakan untuk membagi traffic ke server-server tersebut.

Arsitektur dengan horizontal scaling lebih fleksibel ketika jumlah pengguna terus bertambah.

Cloud Load Balancer

Selain menggunakan NGINX sendiri, bisnis dapat menggunakan managed load balancer dari cloud provider.

Contohnya:

1. AWS Elastic Load Balancing.

2. Google Cloud Load Balancing.

3. Azure Load Balancer.

4. Cloudflare Load Balancing.

5. Load balancer dari penyedia VPS.

Managed load balancer biasanya menyediakan kombinasi health check, failover, routing, dan integrasi infrastruktur yang lebih mudah dikelola. Cloudflare, misalnya, dapat mendistribusikan traffic berdasarkan kesehatan endpoint, latency, dan wilayah.

Kapan Website Membutuhkan Load Balancing?

Tidak semua website langsung membutuhkan tiga atau lima server.

Load balancing mulai layak dipertimbangkan ketika:

1. Traffic meningkat signifikan.

2. CPU server sering tinggi.

3. RAM sering penuh.

4. Website sering timeout.

5. Downtime tidak dapat ditoleransi.

6. Aplikasi digunakan banyak cabang.

7. Jumlah transaksi meningkat.

8. Terdapat banyak request API.

9. Bisnis membutuhkan high availability.

10. Satu server sudah mendekati kapasitas maksimal.

Untuk website company profile dengan traffic rendah, satu server yang dikonfigurasi dengan baik biasanya masih mencukupi.

Load Balancing Tidak Menggantikan Optimasi

Kesalahan yang sering dilakukan adalah menambahkan server tanpa memperbaiki aplikasi.

Sebelum melakukan scaling, periksa:

1. Query database.

2. Database index.

3. Cache.

4. PHP-FPM.

5. NGINX.

6. Queue.

7. File gambar.

8. API eksternal.

9. Source code.

10. Monitoring.

Aplikasi yang tidak efisien tetap dapat menghabiskan resource meskipun server ditambah.

Monitoring Tetap Diperlukan

Setelah load balancing diterapkan, monitor:

1. CPU setiap server.

2. RAM.

3. Response time.

4. Error rate.

5. Request per second.

6. Database connection.

7. Slow query.

8. Queue.

9. Health check.

10. Disk usage.

Tujuannya adalah mengetahui kapan kapasitas harus ditambah atau masalah aplikasi perlu diperbaiki.

Contoh Arsitektur Website Traffic Tinggi

Arsitektur sederhana dapat dibuat seperti berikut:

Internet
↓
Cloudflare
↓
Load Balancer
↓
┌─────────────────────┐
App Server 1
App Server 2
App Server 3
└─────────────────────┘
↓
Redis
↓
Database
↓
Object Storage

Kemudian tambahkan:

Queue Worker
Monitoring
Backup
Logging

sesuai kebutuhan aplikasi.

Kesalahan yang Perlu Dihindari

Menggunakan Session File

Session lokal dapat menyebabkan pengguna logout ketika request berpindah server.

Menyimpan Upload di Server Lokal

File harus dapat diakses seluruh application server.

Tidak Menggunakan Health Check

Load balancer dapat terus mengirim traffic ke server bermasalah.

Database Tidak Dioptimalkan

Database dapat menjadi bottleneck baru setelah application server ditambah.

Tidak Memiliki Monitoring

Tanpa monitoring, sulit mengetahui server mana yang mengalami masalah.

Menganggap Load Balancing Sama dengan Backup

Load balancing meningkatkan ketersediaan layanan, tetapi bukan pengganti backup data.

Load Balancing Bersama Ovla Media

Ovla Media dapat membantu bisnis membangun dan mengoptimalkan infrastruktur aplikasi melalui:

1. Setup NGINX Load Balancer.

2. Optimasi Laravel.

3. Konfigurasi Redis.

4. Optimasi database.

5. Setup Laravel Queue.

6. Monitoring server.

7. Implementasi Laravel Pulse.

8. Migrasi shared hosting ke VPS.

9. Arsitektur multi-server.

10. Pengembangan aplikasi bisnis custom.

Arsitektur dapat disesuaikan dengan jumlah pengguna, traffic, jumlah cabang, kebutuhan uptime, serta anggaran bisnis.

Kesimpulan

Load balancing adalah metode membagi traffic ke beberapa server agar satu server tidak menerima seluruh beban aplikasi.

Alur sederhananya:

Pengguna
↓
Load Balancer
↓
Server 1
Server 2
Server 3

Beberapa metode load balancing yang umum digunakan adalah:

1. Round Robin.

2. Least Connections.

3. IP Hash.

4. Weighted Load Balancing.

Untuk aplikasi Laravel multi-server, pastikan session, cache, storage, database, dan queue juga dirancang dengan tepat.

Load balancing bukan hanya solusi untuk traffic tinggi. Teknologi ini juga membantu meningkatkan skalabilitas, ketersediaan, dan ketahanan aplikasi ketika salah satu server mengalami gangguan.