Horizontal vs Vertical Scaling #

Ketika sistem mulai mengalami beban yang meningkat, ada dua cara fundamental untuk merespons: buat server yang ada lebih besar, atau tambahkan lebih banyak server. Inilah inti dari vertical scaling dan horizontal scaling. Keduanya valid, keduanya punya tempat yang tepat — tapi di cloud-native architecture, horizontal scaling adalah default yang harus dipahami dengan baik karena ia adalah yang memungkinkan elastisitas dan resiliensi.

Vertical Scaling — Buat yang Ada Lebih Besar #

Vertical scaling (scale up / scale down) berarti meningkatkan atau menurunkan spesifikasi satu instance: lebih banyak CPU, lebih banyak RAM, storage yang lebih cepat.

Vertical Scaling:

  Sebelum:                    Sesudah:
  ┌──────────────┐            ┌──────────────────────┐
  │  Server      │            │  Server (lebih besar) │
  │  4 vCPU      │  scale up  │  16 vCPU             │
  │  8 GB RAM    │ ─────────→ │  64 GB RAM           │
  │  100 GB SSD  │            │  500 GB SSD          │
  └──────────────┘            └──────────────────────┘
  
  Karakteristik:
  ✓ Sederhana — tidak ada perubahan arsitektur aplikasi
  ✓ Tidak ada overhead distribusi (network, coordination)
  ✓ Cocok untuk aplikasi yang sulit didistribusikan
  
  ✗ Ada batas maksimum hardware — tidak bisa scale tak terbatas
  ✗ Single point of failure tetap ada
  ✗ Biaya tidak linear — instance yang lebih besar mahal secara tidak proporsional
  ✗ Biasanya butuh downtime untuk resize (tergantung platform)
  ✗ Over-provisioning saat beban rendah karena tidak bisa scale down otomatis

Horizontal Scaling — Tambah Lebih Banyak #

Horizontal scaling (scale out / scale in) berarti menambah atau mengurangi jumlah instance yang bekerja paralel, dengan kapasitas yang terdistribusi di antara mereka.

Horizontal Scaling:

  Sebelum:                        Sesudah:
                                  ┌──────────────┐
  ┌──────────────┐                │  Server A    │
  │  Server A    │  scale out     │  4 vCPU      │
  │  4 vCPU      │ ─────────────→ ├──────────────┤
  │  8 GB RAM    │                │  Server B    │
  └──────────────┘                │  4 vCPU      │
                                  ├──────────────┤
                                  │  Server C    │
                                  │  4 vCPU      │
                                  └──────────────┘
  
  Karakteristik:
  ✓ Tidak ada batas teoritis — tambah instance sesuai kebutuhan
  ✓ Tidak ada single point of failure
  ✓ Biaya linear — 2x instance = 2x biaya (tidak lebih mahal per unit)
  ✓ Bisa scale in saat beban turun — hemat biaya
  ✓ Zero-downtime scaling — instance baru bisa ditambah tanpa henti
  
  ✗ Membutuhkan load balancer
  ✗ Aplikasi harus stateless atau state harus di-manage secara terpusat
  ✗ Lebih kompleks untuk dimonitor dan di-debug

Batas Vertical Scaling #

Vertical scaling memiliki ceiling yang nyata — baik secara teknis maupun ekonomis.

Batas Vertical Scaling di Cloud:

  Ukuran instance terbesar yang tersedia:
    → Ada limit maksimum yang bisa kamu pilih
    → Contoh: instance dengan 192 vCPU dan 1.5 TB RAM tersedia,
      tapi harganya bisa 50–100x instance standard

  Kurva biaya yang tidak linear:
    Misal: instance 4 vCPU = $0.10/jam
           instance 8 vCPU = $0.22/jam  (2x CPU, 2.2x harga)
           instance 16 vCPU = $0.50/jam (4x CPU, 5x harga)
           instance 32 vCPU = $1.20/jam (8x CPU, 12x harga)
    
    Makin besar instance, makin tidak efisien secara biaya

  Availability:
    → Instance besar tidak tersedia di semua AZ
    → Ketersediaan instance sangat besar terbatas

  Satu titik kegagalan:
    → Meski instance-nya besar, jika mati semua beban terdampak
    → Tidak ada native failover untuk compute failure

Load Balancer — Komponen Kunci Horizontal Scaling #

Horizontal scaling membutuhkan mekanisme untuk mendistribusikan trafik ke semua instance. Load balancer adalah komponen yang menjalankan peran ini.

Arsitektur Horizontal Scaling dengan Load Balancer:

  Pengguna
      │
      ▼
  [Load Balancer]
      │
      ├── Instance A (healthy) ← trafik diteruskan
      ├── Instance B (healthy) ← trafik diteruskan
      ├── Instance C (healthy) ← trafik diteruskan
      └── Instance D (unhealthy) ← trafik TIDAK diteruskan

  Load balancer melakukan:
  ✓ Distribusi trafik (round-robin, least connections, dll)
  ✓ Health check — deteksi instance yang tidak sehat
  ✓ Remove instance yang sakit dari rotation
  ✓ Add instance baru yang sehat ke rotation
  ✓ SSL termination
  ✓ Connection draining — request yang sedang diproses diselesaikan
    sebelum instance dikeluarkan dari rotation

Auto Scaling — Horizontal Scaling yang Otomatis #

Di cloud, horizontal scaling bisa diotomasi sepenuhnya dengan auto scaling group. Ini yang membuat elastisitas menjadi nyata.

Cara Kerja Auto Scaling:

  Policy: scale out jika CPU > 70% selama 3 menit
          scale in  jika CPU < 30% selama 10 menit
  Minimum: 2 instances, Maximum: 20 instances

  10:00 — Trafik mulai naik
  10:03 — CPU rata-rata 75% selama 3 menit
  10:03 — Auto scaling trigger: +2 instances
  10:05 — Instance baru healthy, trafik didistribusikan ke 4 instance

  14:00 — Trafik mulai turun
  14:10 — CPU rata-rata 25% selama 10 menit
  14:10 — Auto scaling trigger: -1 instance
  14:12 — Instance lama drain connections, kemudian terminated

  Hasilnya:
  ✓ Kapasitas selalu sesuai dengan kebutuhan aktual
  ✓ Tidak ada manual intervention
  ✓ Biaya proporsional dengan beban

Kapan Vertical, Kapan Horizontal #

Pilih Vertical Scaling jika:
  ✓ Aplikasi monolitik atau legacy yang tidak bisa didistribusikan
      → Database tradisional yang belum mendukung distributed mode
      → Software yang berlisensi per server dan mahal untuk scale out
  ✓ Workload yang membutuhkan shared memory dalam satu proses
      → In-memory analytics, large dataset yang harus fit in RAM
  ✓ Sebagai solusi cepat sebelum refactor arsitektur
      → Vertical scaling dulu untuk beli waktu, refactor untuk jangka panjang

Pilih Horizontal Scaling jika:
  ✓ Aplikasi stateless atau state sudah dikelola secara eksternal
  ✓ Beban yang fluktuatif dan butuh elastisitas
  ✓ High availability — tidak ada single point of failure
  ✓ Throughput tinggi yang melebihi kapasitas satu instance terbesar
  ✓ Cost efficiency untuk beban yang bervariasi

Banyak sistem modern menggunakan kombinasi keduanya: vertical scaling untuk komponen yang sulit di-scale-out (seperti database primary), dan horizontal scaling untuk application layer yang stateless. Database managed modern juga semakin mendukung read replicas (horizontal) dan instance resize (vertical) secara bersamaan.

Ringkasan #

Vertical scaling membuat instance lebih besar, horizontal scaling menambah instance lebih banyak — keduanya meningkatkan kapasitas dengan cara yang berbeda.
Vertical scaling punya ceiling dan kurva biaya yang tidak linear — semakin besar instance, semakin mahal per unit resource.
Horizontal scaling adalah default cloud-native — tidak ada batas teoritis, biaya linear, tidak ada single point of failure.
Horizontal scaling membutuhkan stateless application — state harus ada di external store agar semua instance bisa melayani request yang sama.
Auto scaling mengotomasi horizontal scaling — kapasitas menyesuaikan beban aktual secara otomatis berdasarkan policy yang dikonfigurasi.
Kombinasi keduanya umum — vertical untuk komponen yang tidak bisa di-scale-out, horizontal untuk application layer.

← Sebelumnya: Stateless vs Stateful Berikutnya: Immutable Infrastructure →