Scaling Vertikal vs Horizontal

Kapasitas sebuah sistem dapat dikembangkan melalui dua arah: satu mesin yang makin besar, atau sekumpulan server biasa yang makin banyak. Topik ini membahas kedua sumbu tersebut, batas masing-masing, dan kriteria memilih arah pengembangan. Perbandingan efisiensi biaya di bagian akhir dihitung dengan program Python singkat sehingga setiap angkanya dapat direproduksi. Setelah membacanya, keputusan scaling yang lazim muncul pada dokumen desain dapat dinilai dengan kerangka yang jelas.

Dua sumbu pengembangan kapasitas#

Scaling adalah penambahan kapasitas sistem untuk menahan beban yang tumbuh, dan terdapat dua sumbu untuk melakukannya. Scaling vertikal (scale up) mengganti satu mesin dengan mesin yang lebih besar: prosesor yang lebih cepat, memori yang lebih banyak, atau penyimpanan yang lebih cepat. Scaling horizontal (scale out) menambah jumlah mesin yang menjalankan perangkat lunak yang sama, sehingga beban dibagi ke lebih banyak pemroses.

Kedua sumbu memenuhi kebutuhan yang sama dengan cara yang berbeda. Apabila satu server mampu melayani 100 permintaan (request) per detik, kapasitas total dari $n$ server sejenis adalah $n \times 100$ permintaan per detik, sedangkan scaling vertikal menaikkan angka 100 itu sendiri dengan mengganti mesinnya. Perbedaan ini terasa pada biaya, risiko kegagalan, dan perubahan perangkat lunak yang disyaratkan, sebagaimana diuraikan pada dua bagian berikut.

Batas scaling vertikal#

Scaling vertikal bekerja tanpa menyentuh perangkat lunak: mesin baru dipasang, aplikasi berpindah, lalu sistem berjalan seperti sebelumnya dengan sumber daya yang lebih besar. Kemudahan inilah yang menjadikan arah ini pilihan pertama pada sistem yang masih kecil. Tidak ada pemecahan data, tidak ada koordinasi antarmesin, dan tidak ada kode yang diubah.

Batasnya juga tegas. Kelas perangkat keras tertinggi selalu berhingga, sehingga setelah mesin terbesar tercapai, tidak ada tingkat berikutnya. Harganya naik tidak sebanding dengan kapasitasnya, karena mesin kelas atas diproduksi dalam jumlah kecil dan komponennya mahal, sehingga kapasitas yang dua kali lipat sering dihargai lebih dari dua kali lipat. Selain itu, satu mesin besar tetap satu titik kegagalan: apabila mesin itu mati, seluruh layanan ikut berhenti. Penggantian kelas mesin pun biasanya disertai jeda, karena mesin lama berhenti sebelum mesin baru mengambil alih tugasnya.

Syarat dan batas scaling horizontal#

Scaling horizontal menambah kapasitas dengan menggandakan server yang berisi perangkat lunak yang sama, lalu menugaskan satu load balancer, yaitu komponen yang membagi trafik ke seluruh anggota kumpulan server. Syarat utamanya, setiap server harus mampu melayani permintaan mana pun tanpa bergantung pada data yang tersimpan di mesinnya sendiri, sifat yang disebut stateless. Apabila syarat itu terpenuhi, kapasitas bertambah hanya dengan menyalakan server tambahan, dan server yang rusak dapat dicabut tanpa menghentikan layanan.

Harganya adalah kompleksitas. Kumpulan server menuntut load balancer, memperkenalkan kegagalan parsial, yaitu keadaan sebagian server mati sementara sisanya hidup, dan menuntut kebijakan bagi data yang dulu cukup tinggal di memori satu mesin, misalnya session pengguna. Sebagai gantinya, jumlah server dapat disesuaikan mengikuti jam sibuk, sesuatu yang tidak dimungkinkan oleh satu mesin besar yang harus dibeli untuk beban puncak sepanjang waktu.

Membandingkan efisiensi biaya#

Selisih kedua sumbu paling mudah dilihat dari biaya per satuan kapasitas. Model berikut menyederhanakan kenyataan menjadi dua pola. Pada pola vertikal, setiap tingkatan mesin menggandakan kapasitas tetapi menaikkan biayanya menjadi tiga kali lipat. Pada pola horizontal, server sejenis digandakan sehingga kapasitas dan biaya tumbuh berbarengan. Program Python berikut menghitung kapasitas per biaya untuk kedua pola.

# Perbandingan kapasitas dan biaya: scaling vertikal vs horizontal.
# Angka bersifat ilustratif dan sengaja dipilih agar mudah dihitung ulang.

# Scaling vertikal: mesin tunggal diganti mesin yang lebih besar.
# Setiap tingkat menggandakan kapasitas, tetapi biayanya menjadi tiga kali lipat.
tingkatan_vertikal = [
    (1, 100, 1),
    (2, 200, 3),
    (3, 400, 9),
    (4, 800, 27),
]

print("SCALING VERTIKAL (satu mesin makin besar)")
print(f"{'tingkat':>7} {'kapasitas':>9} {'biaya':>5} {'kapasitas per biaya':>19}")
for tingkat, kapasitas, biaya in tingkatan_vertikal:
    efisiensi = kapasitas / biaya
    print(f"{tingkat:>7} {kapasitas:>9} {biaya:>5} {efisiensi:>19.1f}")

# Scaling horizontal: sejumlah server sejenis digandakan di balik load balancer.
print()
print("SCALING HORIZONTAL (banyak server sejenis)")
print(f"{'server':>6} {'kapasitas':>9} {'biaya':>5} {'kapasitas per biaya':>19}")
for jumlah in (1, 2, 4, 8):
    kapasitas = 100 * jumlah
    efisiensi = kapasitas / jumlah
    print(f"{jumlah:>6} {kapasitas:>9} {jumlah:>5} {efisiensi:>19.1f}")

SCALING VERTIKAL (satu mesin makin besar)
tingkat kapasitas biaya kapasitas per biaya
      1       100     1               100.0
      2       200     3                66.7
      3       400     9                44.4
      4       800    27                29.6

SCALING HORIZONTAL (banyak server sejenis)
server kapasitas biaya kapasitas per biaya
     1       100     1               100.0
     2       200     2               100.0
     4       400     4               100.0
     8       800     8               100.0

Kolom terakhir memperlihatkan pola yang khas. Efisiensi scaling vertikal menurun dari 100,0 menjadi 29,6 kapasitas per biaya karena harganya naik lebih cepat daripada kapasitasnya. Efisiensi horizontal tetap 100,0 pada setiap baris karena setiap server tambahan membawa kapasitas dan biaya dalam proporsi yang sama. Untuk kapasitas 800 permintaan per detik, pola vertikal memerlukan biaya 27, sedangkan pola horizontal cukup 8. Model ini sengaja sederhana, sehingga biaya operasional horizontal berupa load balancer dan alat pengelolaan belum terhitung, dan justru karena itulah keduanya perlu dibandingkan pada tingkat kesederhanaan yang sama.

Kriteria memilih arah scaling#

Empat pertanyaan mengarahkan keputusan. Pertama, seberapa jauh kebutuhan kapasitas akan tumbuh, karena kebutuhan yang berhenti di bawah kelas mesin terbesar dapat ditutup dengan vertikal. Kedua, apakah perangkat lunak sudah stateless, karena horizontal menuntut kerja perubahan yang tidak sedikit pada aplikasi stateful lama. Ketiga, bagaimana tuntutan ketersediaan, karena satu mesin besar yang mati menghentikan seluruh layanan. Keempat, bagaimana bentuk biayanya, karena vertikal memusatkan belanja pada satu mesin kelas atas, sedangkan horizontal menyebarkannya ke banyak mesin biasa.

Dalam praktiknya kedua sumbu dipakai bergantian. Sistem yang masih muda sering dimulai secara vertikal karena cepat dan murah, lalu beralih horizontal ketika kelas mesin tidak lagi mengikuti pertumbuhan. Basis data juga sering dinaikkan kelasnya lebih dahulu sebelum pendekatan pemecahan data dipertimbangkan.

Kesalahan umum#

1. Menambah server tanpa menata state terlebih dahulu. Penyebabnya, session masih tersimpan di memori masing-masing server sehingga routing menempel pada satu server (sticky session). Perbaikannya, pindahkan session ke penyimpanan bersama sebelum kumpulan server diperbesar.
2. Menaikkan kelas mesin tanpa mengukur hambatan. Penyebabnya, anggapan bahwa seluruh komponen tumbuh seiring spesifikasi, padahal kelemahan sering berada pada satu komponen saja. Perbaikannya, ukur latensi dan pemanfaatan tiap komponen, lalu naikkan kelas komponen yang menjadi hambatan.
3. Menganggap horizontal scaling bebas biaya karena angkanya linear. Penyebabnya, tabel efisiensi tidak memuat biaya operasional berupa load balancer, pemantauan, dan penanganan kegagalan parsial. Perbaikannya, masukkan biaya operasional tersebut ke dalam perbandingan sebelum keputusan diambil.

Ringkasan#

• Scaling vertikal mengganti mesin dengan yang lebih besar, mudah dijalankan tetapi berbatas pada kelas perangkat keras tertinggi dan harganya naik tidak linear.
• Scaling horizontal menggandakan server sejenis di balik load balancer, efisiensinya linear tetapi menuntut layanan stateless dan menambah kompleksitas operasional.
• Pemilihan sumbu mempertimbangkan pertumbuhan kapasitas, kesiapan state, ketersediaan, dan bentuk biaya, setelah komponen hambatan diukur.

Referensi#

• System Design Primer — Donne Martin — Bagian load balancer membandingkan horizontal scaling dengan vertical scaling beserta kelebihan dan kekurangannya.