Load Balancing #

Dalam rekayasa sistem berskala besar di cloud, Load Balancer (penyeimbang beban) bertindak sebagai gerbang terdepan sekaligus polisi lalu lintas jaringan yang sangat vital. Secara umum, load balancer bertugas menerima seluruh paket data dan koneksi masuk dari internet publik dan mendistribusikannya secara adil dan merata ke beberapa instans server backend (target group) di belakangnya. Tanpa adanya load balancer, kita tidak akan pernah bisa menjalankan lebih dari satu instans server untuk satu layanan — seluruh trafik akan menumpuk di satu tempat. Load balancer adalah fondasi mutlak yang memungkinkan penskalaan horizontal (horizontal scaling), ketersediaan tinggi (high availability), pemulihan mandiri (auto-healing), serta rilis aplikasi tanpa downtime (zero-downtime deployment) dapat terwujud secara efektif.

Masalah Inti yang Dipecahkan oleh Load Balancer #

Untuk memahami urgensi load balancer, mari kita bandingkan arsitektur sistem tanpa load balancer dengan arsitektur modern yang memanfaatkannya:

1. Sistem Tanpa Load Balancer (Single Node) #

Pada sistem tanpa penyeimbang beban, nama domain aplikasi kita di DNS server dipetakan secara langsung ke alamat IP publik satu-satunya server aplikasi kita.

flowchart LR
    User["Pengguna (Internet)"] -->|"DNS resolve: 54.123.45.1"| ServerA["Server A (Satu-satunya VM)"]

Masalah Operasional:

• Kemacetan Komputasi (Bottleneck): Begitu trafik pengguna melonjak, server A akan kehabisan CPU dan RAM, mengakibatkan respons sistem melambat hingga crash.
• Single Point of Failure (SPOF): Jika Server A mati akibat kerusakan fisik hardware di cloud, seluruh aplikasi kita akan mati total seketika.
• Hambatan Scaling: Kita tidak bisa membagi beban komputasi ke server baru karena DNS hanya mencatat satu alamat IP Server A.

2. Sistem dengan Load Balancer (Multi Node) #

Dengan memasang Load Balancer di depan, domain aplikasi kita di DNS diarahkan ke alamat IP (atau DNS name) milik Load Balancer.

flowchart TD
    User["Pengguna (Internet)"] -->|"DNS resolve: IP Load Balancer"| LB["Load Balancer (Managed Gateway)"]
    LB --> ServerA["Server A (IP Privat)"]
    LB --> ServerB["Server B (IP Privat)"]
    LB --> ServerC["Server C (IP Privat)"]

Kelebihan Operasional:

• Distribusi Beban Merata: Beban trafik dibagi secara adil ke Server A, B, dan C.
• Resiliensi Tinggi: Jika Server B mengalami crash, Load Balancer akan mendeteksi kegagalan tersebut dan mengalihkan lalu lintas data ke Server A dan C secara otomatis tanpa disadari pengguna.
• Fleksibilitas Scaling: Kita bebas menambah atau mengurangi jumlah server backend kapan saja (auto-scaling) di belakang Load Balancer.

Layer 4 vs Layer 7 Load Balancer: Kecepatan vs Kecerdasan #

Berdasarkan Model OSI (Open Systems Interconnection), load balancer dibagi menjadi dua jenis utama berdasarkan tingkat kedalaman inspeksi paket data yang dilakukannya:

1. Layer 4 Load Balancing (Transport Layer) #

Layer 4 load balancer (L4) bekerja di tingkat protokol transport (TCP/UDP). L4 tidak membaca isi data (payload) dari paket HTTP/HTTPS yang dikirimkan pengguna; ia hanya memeriksa alamat IP pengirim/penerima dan port jaringan pada header paket TCP/UDP.

• Mekanisme: Begitu koneksi TCP masuk, L4 langsung memilih salah satu server backend dan meneruskan paket data tersebut ke sana (packet forwarding).
• Kelebihan: Sangat cepat dengan penggunaan CPU yang sangat minim (low latency), karena tidak perlu melakukan proses dekripsi SSL/TLS atau parsing HTTP.
• Kekurangan: Tidak bisa merutekan trafik berdasarkan URL path, HTTP header, atau cookie.
• Contoh Teknologi: AWS Network Load Balancer (NLB), HAProxy (TCP mode).

2. Layer 7 Load Balancing (Application Layer) #

Layer 7 load balancer (L7) bekerja di tingkat aplikasi (HTTP/HTTPS/WebSockets). L7 membaca dan memahami isi lalu lintas HTTP secara mendalam.

• Mekanisme: L7 menerima koneksi TCP dari client, mendekripsi SSL/TLS, menganalisis struktur HTTP request (URL path, header, cookie), lalu membuat koneksi TCP baru untuk meneruskan request tersebut ke backend yang tepat.
• Kelebihan: Memiliki fitur perutean yang sangat cerdas (content-based routing) dan mendukung integrasi Web Application Firewall (WAF).
• Kekurangan: Memerlukan pemrosesan CPU yang lebih tinggi untuk menangani proses dekripsi enkripsi data.
• Contoh Teknologi: AWS Application Load Balancer (ALB), Nginx (HTTP mode), Traefik.

Perutean Berbasis Konten (Content-Based Routing) di Layer 7 #

Kekuatan utama dari Layer 7 Load Balancer adalah kemampuannya melakukan perutean lalu lintas data berdasarkan informasi di tingkat aplikasi. Ini memungkinkan kita menyatukan ratusan layanan mikro (microservices) di bawah satu alamat domain tunggal.

flowchart TD
    LB["Load Balancer L7<br>(api.example.com)"]
    
    LB -->|"Rule 1: Path /api/v1/users/*"| UserSvc["User Service"]
    LB -->|"Rule 2: Path /api/v1/orders/*"| OrderSvc["Order Service"]
    LB -->|"Rule 3: Header 'X-Canary: true'"| CanaryApp["Canary App Version"]
    LB -->|"Rule 4: Default"| FrontendApp["Frontend Web App"]

Jenis-Jenis Perutean L7: #

• Path-Based Routing: Mengarahkan trafik berdasarkan path URL (misal: /api/v1/users diarahkan ke User Service, sedangkan /api/v1/orders ke Order Service).
• Host-Based Routing: Menggunakan satu load balancer untuk melayani beberapa domain sekaligus (misal: request ke api.example.com diarahkan ke API backend, sedangkan admin.example.com diarahkan ke panel admin).
• Header-Based & Cookie Routing: Merutekan trafik berdasarkan header khusus (misal: jika request memiliki HTTP Header X-Developer: true, arahkan ke staging environment, atau gunakan cookie untuk merutekan pengguna ke versi aplikasi Canary).

Algoritma Distribusi Trafik Load Balancer #

Untuk menentukan ke server mana request pengguna akan dikirimkan, load balancer menggunakan algoritma distribusi berikut:

1. Round Robin: Membagikan request secara bergantian satu per satu ke setiap server backend. Cocok jika spesifikasi server di belakang sama rata.
2. Weighted Round Robin: Modifikasi dari Round Robin di mana kita memberikan bobot (weight) pada server yang memiliki kapasitas hardware lebih besar agar menerima porsi request lebih banyak.
3. Least Connections: Mengarahkan request baru ke server yang saat itu sedang menangani jumlah koneksi aktif paling sedikit. Sangat ideal untuk request dengan durasi pemrosesan yang bervariasi.
4. IP Hash: Melakukan hashing alamat IP client untuk mengunci pengguna ke satu server backend yang sama (Session Affinity/Sticky Sessions). Namun pola ini merupakan anti-pattern untuk aplikasi cloud-native karena merusak distribusi beban merata.
5. Consistent Hashing: Algoritma canggih yang meminimalkan redistribusi data saat server backend ditambah atau dikurangi, sangat penting dalam perancangan distributed caching.

Health Check: Mekanisme Pendeteksi Kesehatan Backend #

Health Check (Uji Kesehatan) adalah jantung dari keandalan load balancer. Load balancer secara berkala mengirimkan HTTP request atau ping TCP ke setiap server backend untuk memastikan server tersebut masih berfungsi normal.

Konfigurasi Ambang Batas (Threshold) Health Check:
  - Interval: 15 detik (Waktu tunggu antar-ping).
  - Timeout: 3 detik (Batas toleransi server menjawab).
  - Unhealthy Threshold: 3 kali (Gagal 3 kali berturut-turut = Server ditandai Unhealthy).
  - Healthy Threshold: 2 kali (Sukses 2 kali berturut-turut = Server ditandai Sehat kembali).

Jika server A gagal menjawab sebanyak 3 kali berturut-turut, Load Balancer akan langsung mengeluarkan server A dari rotasi pengiriman trafik. Begitu server A sehat kembali (misalnya selesai melakukan restart otomatis), Load Balancer akan memasukkannya kembali ke rotasi secara otomatis.

Pola SSL/TLS Management: Termination vs Passthrough #

Load balancer juga bertindak sebagai pintu dekripsi keamanan menggunakan dua pola utama:

1. SSL/TLS Termination (SSL Offloading) #

Koneksi HTTPS terenkripsi dari client didekripsi di tingkat Load Balancer. Trafik dari Load Balancer ke instans server backend diteruskan menggunakan HTTP biasa melalui jaringan privat VPC yang terpercaya.

• Kelebihan: Menghemat penggunaan CPU server backend karena tidak perlu melakukan proses komputasi kriptografi dekripsi TLS. Manajemen sertifikat SSL/TLS menjadi terpusat di satu tempat (Load Balancer), mempermudah proses perpanjangan otomatis sertifikat.

2. SSL/TLS Passthrough #

Load Balancer melewatkan paket data terenkripsi langsung ke server backend tanpa melakukan dekripsi di tingkat Load Balancer. Proses dekripsi dilakukan secara mandiri di masing-masing server backend.

• Kelebihan: Sangat aman secara end-to-end. Berguna untuk industri dengan kepatuhan hukum super ketat (compliance) seperti finansial yang melarang dekripsi data di tingkat perantara.
• Kekurangan: Load Balancer tidak bisa melakukan Layer 7 routing karena isi HTTP terenkripsi.

Integrasi Auto-Scaling: Connection Draining & Target Tracking #

Untuk mendukung kelincahan auto-scaling secara dinamis, Load Balancer terintegrasi erat dengan Auto-Scaling Group (ASG) melalui dua fitur kritis:

1. Connection Draining (Deregistration Delay) #

Ketika sistem auto-scaling mendeteksi trafik menurun dan memutuskan untuk mematikan satu instans VM (scale-in), atau ketika satu instans ditandai unhealthy dan akan dihancurkan, Load Balancer tidak boleh memutuskan koneksi secara sepihak.

• Mekanisme: Load Balancer menempatkan instans tersebut dalam status Draining. Load Balancer segera berhenti mengirimkan request baru ke instans tersebut, namun memberikan kelonggaran waktu (timeout default 300 detik) bagi instans tersebut untuk menyelesaikan transaksi aktif yang sedang berjalan (in-flight requests). Setelah waktu habis atau semua koneksi selesai diproses, instans baru boleh dimatikan secara fisik tanpa merusak transaksi pengguna.

2. Target Tracking Scaling Policy #

Load Balancer menyediakan metrik real-time khusus yang dapat memicu auto-scaling.

• Metrik Utama: ALBRequestCountPerTarget (Jumlah request per server). Kita dapat menetapkan aturan: “Jika rata-rata request per instans melebihi 1000 request per menit, segera deploy 2 instans VM baru secara horizontal.”

Contoh Kode: Konfigurasi Application Load Balancer dengan Terraform #

Berikut adalah contoh deklarasi Terraform untuk mendeploy Application Load Balancer (ALB), Target Group dengan parameter Health Check, Listener HTTPS (Port 443), serta Listener Rules untuk menerapkan perutean berbasis path (path-based routing):

# ✓ BENAR: Gunakan Terraform untuk merancang Load Balancer L7 dengan perutean berbasis path

# 1. Membuat Application Load Balancer (ALB)
resource "aws_lb" "main_alb" {
  name               = "production-alb"
  internal           = false # Internet-facing
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb_sg.id]
  subnets            = [aws_subnet.public_az1.id, aws_subnet.public_az2.id]
}

# 2. Target Group untuk API Service
resource "aws_lb_target_group" "api_tg" {
  name     = "api-target-group"
  port     = 8080
  protocol = "HTTP"
  vpc_id   = aws_vpc.main.id

  # Konfigurasi Health Check berkala
  health_check {
    path                = "/api/v1/healthz"
    protocol            = "HTTP"
    matcher             = "200"
    interval            = 15
    timeout             = 3
    healthy_threshold   = 2
    unhealthy_threshold = 3
  }
}

# 3. Target Group untuk Web Frontend
resource "aws_lb_target_group" "web_tg" {
  name     = "web-target-group"
  port     = 80
  protocol = "HTTP"
  vpc_id   = aws_vpc.main.id

  health_check {
    path                = "/"
    protocol            = "HTTP"
    matcher             = "200"
    interval            = 30
    timeout             = 5
    healthy_threshold   = 2
    unhealthy_threshold = 3
  }
}

# 4. Listener HTTPS (Port 443) dengan SSL Certificate
resource "aws_lb_listener" "https_listener" {
  load_balancer_arn = aws_lb.main_alb.arn
  port              = "443"
  protocol          = "HTTPS"
  ssl_policy        = "ELBSecurityPolicy-2016-08"
  certificate_arn   = "arn:aws:acm:ap-southeast-1:123456789012:certificate/abc-123-xyz" # Dummy ARN

  # Aksi Default: Kirim trafik ke Web Frontend
  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.web_tg.arn
  }
}

# 5. Aturan Rute Berbasis Path (Path-Based Routing Rule)
resource "aws_lb_listener_rule" "api_routing" {
  listener_arn = aws_lb_listener.https_listener.arn
  priority     = 10 # Prioritas aturan paling kecil dievaluasi pertama

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.api_tg.arn
  }

  # Evaluasi URL: Jika request diawali dengan /api/, arahkan ke API Target Group
  condition {
    path_pattern {
      values = ["/api/*"]
    }
  }
}

Ringkasan #

• Load balancer adalah prerequisite horizontal scaling — trafik tidak bisa didistribusikan ke beberapa instans tanpa adanya penyeimbang beban terpusat.
• Layer 4 NLB sangat cepat dan cocok untuk game server/database, sedangkan Layer 7 ALB cerdas dan ideal untuk routing web app.
• Perutean berbasis konten di Layer 7 memungkinkan pemisahan traffic mikroservis berdasarkan URL path, domain host, atau HTTP header.
• Health check memantau kesehatan server secara real-time untuk secara otomatis mengeluarkan server yang crash dari rotasi lalu lintas data.
• SSL Termination di Load Balancer memusatkan sertifikat dan meringankan beban CPU server backend dari proses dekripsi TLS.
• Connection Draining (Deregistration Delay) mencegah pemutusan request aktif pengguna saat proses scale-in atau penggantian server berlangsung.
• Hindari sticky session jika bisa agar trafik dapat terdistribusi secara merata ke semua backend.

← Sebelumnya: NAT, Firewall, Security Group   Berikutnya: Object Storage →