Horizontal vs Vertical Scaling #

Ketika sebuah aplikasi web atau sistem API yang kita bangun mulai mengalami pertumbuhan pengguna yang masif, sistem infrastruktur di bawahnya secara otomatis akan menghadapi beban kerja (workload) yang semakin berat. Respon sistem akan melambat, antrean transaksi tertunda, dan server berisiko mengalami crash akibat kehabisan resource komputasi. Di dalam dunia rekayasa infrastruktur, terdapat dua paradigma fundamental yang dapat kita pilih untuk meningkatkan kapasitas sistem demi menampung lonjakan beban tersebut: Vertical Scaling (penskalaan vertikal / memperbesar kapasitas satu node) dan Horizontal Scaling (penskalaan horizontal / menambah jumlah node). Kedua pendekatan ini memiliki tempatnya masing-masing di dalam arsitektur sistem, namun di era arsitektur cloud-native modern, horizontal scaling merupakan pola baku (default) yang wajib dikuasai karena ia adalah satu-satunya mekanisme yang memungkinkan tercapainya elastisitas dan resiliensi sistem secara maksimal.

Konsep Dasar: Menambah Daya vs Menambah Pasukan #

Untuk memahami perbedaan konseptual antara kedua model penskalaan ini, mari kita gunakan analogi sederhana tentang sistem pengiriman barang logistik di sebuah perusahaan:

• Vertical Scaling (Scale Up / Scale Down): Kita memiliki satu orang kurir pengirim barang yang menggunakan sepeda kayuh. Ketika jumlah pesanan barang meningkat, kita me-scale up kurir tersebut dengan membelikannya sepeda motor, lalu meng-upgradenya lagi menjadi mobil box, dan akhirnya membelikannya sebuah truk tronton raksasa. Kita meningkatkan daya angkut satu unit kurir yang sama.
• Horizontal Scaling (Scale Out / Scale In): Alih-alih membelikan truk tronton raksasa untuk satu kurir, kita merekrut 10 orang kurir baru yang masing-masing menggunakan sepeda motor untuk bekerja secara paralel membagi beban pengiriman barang secara merata.

flowchart TD
    subgraph ScaleUp["Vertical Scaling (Scale Up)"]
        direction TB
        VM_Small["VM Kecil<br>2 vCPU, 4GB RAM"] -->|"Ubah Tipe Instance (Reboot)"| VM_Huge["VM Raksasa<br>32 vCPU, 64GB RAM"]
    end
    
    subgraph ScaleOut["Horizontal Scaling (Scale Out)"]
        direction TB
        VM_1["VM 1<br>2 vCPU"] -->|"Scale Out (Tambah Node)"| Nodes["Kluster Node Paralel"]
        subgraph Nodes
            VM_A["VM A<br>2 vCPU"]
            VM_B["VM B<br>2 vCPU"]
            VM_C["VM C<br>2 vCPU"]
        end
    end

Analisis Mendalam: Keterbatasan Fisik dan Ekonomi Vertical Scaling #

Vertical Scaling (Scale Up) dilakukan dengan mengalokasikan spesifikasi vCPU, RAM, dan kapasitas penyimpanan yang lebih besar pada instans Virtual Machine yang sama. Meskipun terdengar sangat praktis karena tidak mengubah arsitektur aplikasi kita, model ini memiliki keterbatasan serius yang tidak dapat dihindari ketika sistem mulai berkembang pesat:

1. Batas Maksimum Fisik Hardware (Physical Ceiling) #

Hukum fisika membatasi seberapa besar chip CPU dan memori RAM dapat dipasang di dalam satu motherboard server fisik induk. Ada titik jenuh di mana kita tidak bisa lagi membeli instans VM yang lebih besar karena batasan manufaktur teknologi semikonduktor. Ketika server kita sudah mencapai spesifikasi tertinggi yang tersedia di cloud provider, kita tidak memiliki jalan lagi untuk tumbuh kecuali beralih ke penskalaan horizontal.

2. Kebutuhan Reboot Server (Downtime) #

Di sebagian besar platform cloud, mengubah ukuran Virtual Machine (misalnya dari tipe t3.micro ke m5.large) mengharuskan kita mematikan (shutdown) instans tersebut terlebih dahulu untuk memberikan kesempatan hypervisor mengonfigurasi ulang alokasi virtual hardware baru, baru kemudian menghidupkannya kembali. Hal ini memicu terjadinya interupsi layanan (downtime) selama beberapa menit yang sangat dihindari untuk aplikasi produksi dengan SLA tinggi.

3. Kurva Biaya Non-Linear (Premium Cost Penalty) #

Harga sewa VM di cloud naik secara eksponensial setelah melewati batas ukuran tertentu. Contohnya, menyewa satu server raksasa berkekuatan 128 vCPU dan 512GB RAM sering kali jauh lebih mahal dibandingkan menyewa 16 server kecil berkekuatan 8 vCPU dan 32GB RAM secara bersamaan, meskipun total kapasitas komputasi keduanya adalah sama. Kita membayar harga premium untuk kepadatan hardware tersebut.

4. Single Point of Failure (SPOF) #

Meskipun kita memiliki server raksasa yang sangat mahal dan kencang, jika sistem operasi mengalami kernel panic, terjadi kerusakan fisik pada hypervisor host, atau terjadi serangan DDoS yang melumpuhkan port server tersebut, seluruh aplikasi kita akan mati total karena tidak ada server cadangan yang membackupnya secara otomatis.

Horizontal Scaling: Pilar Penskalaan Cloud-Native #

Horizontal Scaling (Scale Out) dilakukan dengan menambah jumlah instans server yang identik di bawah koordinasi satu pintu gerbang penyeimbang beban (Load Balancer). Penskalaan horizontal menawarkan keunggulan resiliensi yang luar biasa:

• Tidak Ada Batas Kapasitas (Infinite Scaling): Kita dapat menambahkan puluhan, ratusan, bahkan ribuan instans server kecil secara paralel untuk melayani trafik skala dunia. Batasan kapasitas kita murni hanya dibatasi oleh anggaran finansial perusahaan, bukan teknologi hardware.
• High Availability Bawaan (Resilience): Jika salah satu server dari kluster horizontal kita mati akibat kegagalan sistem, Load Balancer akan langsung mendeteksi kerusakan tersebut dan menghentikan pengiriman trafik ke sana. Server-server lain yang sehat akan mengambil alih beban request tanpa ada downtime yang dirasakan pengguna.
• Efisiensi Biaya yang Elastis: Kita dapat mengonfigurasi auto-scaling agar jumlah server menyusut secara drastis saat malam hari (misalnya dari 20 server menjadi 2 server) untuk menghemat biaya sewa bulanan.
• Zero-Downtime Deployment: Penskalaan horizontal memungkinkan kita melakukan update versi aplikasi secara bertahap (rolling update) dengan merilis server server versi baru secara paralel sebelum server versi lama dimatikan.

Peran Load Balancer dalam Horizontal Scaling #

Penskalaan horizontal tidak dapat berfungsi tanpa adanya Load Balancer di depan kluster server kita. Load balancer bertindak sebagai polisi lalu lintas jaringan yang bertugas menerima seluruh request masuk dari internet publik dan mendistribusikannya secara adil ke server-server backend yang sehat.

flowchart TD
    User["Pengguna"] --> LB["Load Balancer"]
    LB -->|"trafik diteruskan"| A["Instance A (healthy)"]
    LB -->|"trafik diteruskan"| B["Instance B (healthy)"]
    LB -->|"trafik diteruskan"| C["Instance C (healthy)"]
    LB -. "trafik TIDAK diteruskan" .-> D["Instance D (unhealthy)"]

Algoritma Distribusi Trafik Load Balancer #

Untuk mendistribusikan beban secara adil, Load Balancer menggunakan algoritma berikut:

1. Round Robin: Membagikan request secara berurutan dan adil satu per satu ke setiap server backend.
2. Least Connections: Mengarahkan request baru ke server yang saat itu sedang menangani jumlah koneksi aktif paling sedikit. Sangat cocok untuk request yang memiliki durasi pemrosesan bervariasi.
3. IP Hash: Mengunci alamat IP client ke server backend tertentu agar pengguna selalu mendarat di server yang sama (berguna jika aplikasi masih bersifat stateful/sticky session).

Perbandingan Load Balancing: Layer 4 vs Layer 7 #

Dalam perancangan arsitektur jaringan cloud, kita harus memahami perbedaan antara penyeimbang beban pada Layer 4 dan Layer 7:

Otomatisasi dengan Auto-Scaling Group #

Keunggulan terbesar dari penskalaan horizontal di cloud adalah kemampuannya untuk dikonfigurasi secara otomatis menggunakan Auto-Scaling Group (ASG). Kita tidak perlu lagi menyuruh Sysadmin memantau grafik CPU di tengah malam untuk membuat VM baru.

Kita cukup mendefinisikan aturan kebijakan (scaling policies) seperti berikut:

• Scale-Out Target: “Jika rata-rata utilitas CPU kluster server melebihi 70% selama 3 periode pemantauan, tambahkan 2 instans server baru.”
• Scale-In Target: “Jika rata-rata utilitas CPU kluster server berada di bawah 30% selama 10 menit berturut-turut, matikan 1 instans server secara perlahan.”

Sistem auto-scaler akan terus mengevaluasi metrik tersebut secara real-time dan berinteraksi langsung dengan API cloud provider untuk memicu proses pembuatan atau penghancuran VM secara dinamis.

Strategi Scaling pada Tingkat Database #

Meskipun server aplikasi stateless sangat mudah di-scale out secara horizontal, layer database relasional adalah komponen yang paling sulit untuk di-scale secara horizontal karena masalah konsistensi penulisan data.

Oleh karena itu, arsitektur database modern mengadopsi kombinasi kedua metode scaling:

1. Database Read Replicas (Horizontal Read) #

Untuk aplikasi yang didominasi oleh operasi membaca data (seperti portal berita atau e-commerce), kita membuat satu server database utama (Primary) untuk menangani operasi tulis (INSERT/UPDATE), dan menduplikasi data tersebut secara otomatis ke beberapa server database cadangan (Read Replicas). Server aplikasi akan mengarahkan seluruh query SELECT ke Read Replicas untuk membagi beban kerja secara horizontal.

2. Database Sharding (Horizontal Write) #

Untuk aplikasi dengan trafik penulisan data yang sangat masif, kita terpaksa memecah baris data tabel database ke beberapa server database fisik yang berbeda berdasarkan kunci sharding tertentu (misalnya, memisahkan data transaksi nasabah berdasarkan region tempat tinggal mereka).

Berikut adalah contoh konfigurasi Terraform deklaratif untuk mendeploy sistem compute layer horizontal (Auto Scaling Group) di bawah Application Load Balancer yang menjamin resiliensi Multi-AZ:

# ✓ BENAR: Gunakan Auto Scaling Group & Application Load Balancer untuk Compute Horizontal Scaling

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

# Target Group tempat Auto Scaling mendaftarkan VM secara dinamis
resource "aws_lb_target_group" "app_tg" {
  name     = "app-target-group"
  port     = 80
  protocol = "HTTP"
  vpc_id   = aws_vpc.main.id

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

# Launch Template untuk mendefinisikan blueprint instans VM yang akan dibuat oleh ASG
resource "aws_launch_template" "app_lt" {
  name_prefix   = "app-v1-template-"
  image_id      = "ami-0c55b159cbfafe1f0" # Golden Image Ubuntu
  instance_type = "t3.medium"              # Ukuran instans seimbang (cost-effective)

  network_interfaces {
    associate_public_ip_address = false # VM diletakkan di private subnet demi keamanan
    security_groups             = [aws_security_group.app_sg.id]
  }

  user_data = base64encode(<<-EOF
              #!/bin/bash
              echo "Starting App Service..."
              # Skrip startup aplikasi ditaruh di sini
              EOF
  )
}

# Auto Scaling Group untuk mengatur jumlah instans dinamis
resource "aws_autoscaling_group" "app_asg" {
  desired_capacity    = 2  # Kapasitas awal target
  max_size            = 10 # Batas maksimum server demi keamanan anggaran
  min_size            = 2  # Menjamin redundansi minimum 2 server di 2 AZ berbeda
  vpc_zone_identifier = [aws_subnet.private_az1.id, aws_subnet.private_az2.id]

  target_group_arns = [aws_lb_target_group.app_tg.arn]

  launch_template {
    id      = aws_launch_template.app_lt.id
    version = "$Latest"
  }

  # Kebijakan perlindungan saat shutdown (Connection Draining)
  suspended_processes = []
  
  # Integrasi monitoring
  metrics_granularity = "1Minute"
  enabled_metrics     = ["GroupMinSize", "GroupMaxSize", "GroupDesiredCapacity", "GroupInServiceInstances"]
}

Hambatan Operasional dan Koordinasi State dalam Penskalaan Horizontal #

Meskipun penskalaan horizontal menawarkan skalabilitas yang hampir tanpa batas, pendekatan ini membawa kompleksitas baru yang dikenal sebagai koordinasi terdistribusi. Ketika kita menjalankan aplikasi di atas puluhan server paralel, kita harus menyelesaikan masalah-masalah berikut:

1. Konsistensi Data (Teorema CAP) #

Berdasarkan Teorema CAP, sistem terdistribusi hanya dapat menjamin dua dari tiga properti berikut: Consistency (Konsistensi), Availability (Ketersediaan), dan Partition Tolerance (Toleransi Partisi). Ketika kita melakukan skala horizontal (menjamin ketersediaan dan toleransi partisi), kita harus siap menerima konsekuensi Eventual Consistency (konsistensi tertunda). Misalnya, data yang ditulis ke database utama membutuhkan waktu beberapa milidetik hingga detik untuk tereplikasi ke seluruh read replicas. Pengguna mungkin membaca data yang sedikit usang jika membaca dari replica yang mengalami lag.

2. Penanganan Unggahan Berkas (File Upload Storage) #

Pada arsitektur satu server (vertical), file yang diunggah pengguna disimpan di harddisk lokal server. Pada arsitektur horizontal, file yang diunggah ke Server-A tidak akan dapat diakses jika request berikutnya dilayani oleh Server-B. Oleh karena itu, kita dilarang keras menyimpan file di disk lokal VM. Semua file harus dialihkan ke layanan penyimpanan objek terpusat agnostik seperti Amazon S3 atau Google Cloud Storage.

3. Sinkronisasi Pekerjaan Terjadwal (Scheduled Tasks / Cron Jobs) #

Jika aplikasi kita memiliki tugas background terjadwal (seperti mengirimkan email laporan harian setiap jam 12 malam), dan kode tersebut berjalan di 10 server horizontal, tugas tersebut akan dieksekusi 10 kali secara duplikat. Solusinya, kita harus memisahkan proses worker terjadwal ini agar hanya berjalan pada instans tunggal khusus, atau menggunakan mekanisme distributed locking (kunci terdistribusi) menggunakan Redis (SETNX) untuk menjamin bahwa hanya satu server yang berhasil mengeksekusi tugas tersebut.

Ringkasan #

• Vertical Scaling meningkatkan kapasitas satu server (vCPU/RAM), sedangkan Horizontal Scaling menambah jumlah instans server secara paralel.
• Vertical Scaling memiliki batas fisik keras (ceiling), memerlukan reboot (downtime) saat upgrade, dan memicu Single Point of Failure (SPOF).
• Horizontal Scaling menyediakan resiliensi tinggi, auto-healing otomatis, dan efisiensi biaya elastis menggunakan Auto Scaling Group.
• Load Balancer adalah pintu gerbang wajib penskalaan horizontal; Layer 7 ALB menawarkan perutean cerdas berbasis URL sedangkan Layer 4 NLB fokus pada kecepatan throughput.
• Database di-scale horizontal menggunakan Read Replicas untuk membagi beban pembacaan data, atau Sharding untuk menyebarkan transaksi penulisan.
• Terapkan Auto Scaling Group di cloud dengan konfigurasi minimum 2 node yang tersebar di Availability Zone yang berbeda guna menjamin High Availability.
• Pindahkan media unggahan ke Object Storage eksternal dan gunakan distributed locking untuk mencegah duplikasi cron jobs pada sistem horizontal.

← Sebelumnya: Stateless vs Stateful   Berikutnya: Immutable Infrastructure →