Vertical vs horizontal scaling; stateless service
Dua cara menambah kapasitas, kenapa horizontal scaling menuntut service yang stateless, dan di mana session disimpan
Sebelumnya, lesson 0004 menunjukkan bahwa 1.000 user aktif harian berarti di bawah 1 QPS rata-rata: satu server dan satu database sudah cukup. Lesson ini menjawab pertanyaan berikutnya: kalau angka itu naik 100 kali dan satu server mulai kewalahan, apa pilihan Anda, dan apa yang harus diubah di aplikasi supaya pilihan itu bisa dipakai?
1. Dua cara menambah kapasitas
Vertical scaling (scale up) berarti mengganti kapasitas satu resource, misalnya memindahkan aplikasi ke virtual machine yang lebih besar. Horizontal scaling (scale out) berarti menambah atau mengurangi jumlah instance. Dokumentasi Azure mencatat bahwa vertical scaling sering membuat sistem tidak tersedia sementara selama redeploy, sedangkan pada horizontal scaling instance lama tetap melayani request saat instance baru menyala. [1]
| Vertical (scale up) | Horizontal (scale out) | |
|---|---|---|
| Perubahan | Mesin lebih besar: CPU, RAM, disk | Mesin lebih banyak di belakang load balancer |
| Perubahan kode | Tidak ada | Server harus stateless (bagian 2) |
| Batas | Ukuran mesin terbesar yang tersedia | Bottleneck lain, biasanya database |
| Saat satu mesin mati | Seluruh layanan mati | Instance lain tetap melayani |
| Biaya tambahan | Harga mesin besar | Load balancer, session store, deploy lebih rumit |
Ukuran keberhasilannya: "Scalability is measured by the ratio of throughput gain to resource increase." Idealnya dua kali resource memberi dua kali throughput. Yang merusak rasio itu adalah bottleneck atau titik sinkronisasi di dalam sistem. [2] Throughput dan latency sudah dibahas di lesson 0003.
Kalimat penting untuk interview: menambah web server tidak menolong kalau database yang menjadi bottleneck. Azure menyarankan "Identify and resolve the bottlenecks in the system first, before throwing more instances at the problem", dan bagian stateful dari sistem adalah penyebab bottleneck yang paling mungkin. [2]
Latihan 1 — Vertical atau horizontal?
Jawab tanpa scroll ke atas. Soal yang sama akan muncul lagi, diacak, di review 0012.
Kuis di lesson ini adalah feedback cepat, bukan bukti penguasaan; yang dicatat hanya hasil review 0012.
2. Syarat horizontal scaling: service yang stateless
Begitu ada dua server di belakang load balancer, request kedua dari user yang sama bisa jatuh ke server lain. Kalau server pertama menyimpan session login di memorinya, server kedua tidak mengenal user itu. Azure merumuskan aturannya: "Make sure that any instance can handle any request." Penyebab umum pelanggarannya adalah menyimpan session state di memori dan memakai kunci enkripsi yang khusus per mesin. [2]
Stateless service berarti server tidak menyimpan data per user di antara dua request. Data itu tetap ada, tapi dipindah ke tempat yang bisa dibaca semua instance:
Ada satu keuntungan lain: instance bisa dikurangi lagi saat beban turun (scale in). Aplikasi harus siap instance-nya dimatikan: tangkap sinyal shutdown dan berhenti dengan rapi, dan taruh pekerjaan panjang di queue supaya instance lain bisa melanjutkan. [2]
3. Di mana session disimpan
HTTP sendiri stateless, jadi aplikasi selalu butuh state di luar request untuk mengenali user yang kembali. Dokumentasi Redis membandingkan pilihan-pilihannya: [3]
| Pilihan | Cara kerja | Biaya dan risiko |
|---|---|---|
| Memori server + sticky session | Load balancer selalu mengirim user ke server yang sama (lesson 0006) | Menurut Redis: menciptakan hot spot dan menghalangi failover. Server mati = user logout. |
| Database relasional | Session disimpan sebagai baris di tabel | Menurut Redis: menambah 5–20 ms per request, dan pada ribuan user bersamaan pembacaan session menghabiskan connection pool database utama. |
| Shared store di memori (Redis) | Satu key per session ID, dengan EXPIRE yang diperbarui di setiap request | Satu komponen lagi yang harus dijaga, tapi semua instance bisa melayani semua user. |
| Token di client | Server menandatangani data session dan client mengirimnya kembali di setiap request | Server tidak perlu menyimpan apa pun; mencabut token sebelum kedaluwarsa lebih sulit. |
Redis menyimpan setiap session sebagai hash dengan TTL yang diperpanjang setiap kali ada request, sehingga session yang tidak aktif terhapus sendiri tanpa job pembersih. [3] Angka "5–20 ms" di tabel adalah klaim vendor Redis, bukan hukum alam; di interview cukup sebut "satu round trip database tambahan di setiap request".
Baris terakhir biasanya memakai JWT (JSON Web Token): format ringkas untuk membawa klaim (mis. user ID dan masa berlaku) antara dua pihak, yang ditandatangani secara digital sehingga server bisa memeriksa keasliannya tanpa menyimpan session. [4]
Latihan 2 — Stateless dan session
Jawab tanpa scroll ke atas. Soal yang sama akan muncul lagi, diacak, di review 0012.
4. Kapan tidak perlu
Sinyal yang membenarkan horizontal scaling. Metrik menunjukkan app server yang jenuh (CPU atau memori tinggi terus-menerus, latency p99 naik bersama QPS) sementara database masih longgar; atau target availability (mis. 99,9%, lesson 0001) tidak tercapai karena setiap deploy atau restart satu server berarti downtime. Kalau database yang jenuh, menambah app server tidak menolong. [2]
Biaya dan risiko. Load balancer, session store, dan cara deploy yang menangani beberapa instance sekaligus. Bug yang hanya muncul di satu instance lebih sulit dilacak. Kode yang diam-diam menyimpan state di memori (cache lokal, file upload di disk) akan rusak begitu instance kedua menyala.
Alternatif lebih murah. Perbaiki query, index, atau kode yang lambat lebih dulu (ukur dengan profiling). Setelah itu scale up: satu perubahan konfigurasi, tanpa perubahan kode. Untuk 1.000 user aktif harian dari lesson 0004, satu server sudah cukup; dua instance di belakang load balancer baru dibenarkan oleh target availability, bukan oleh beban. Tetap tulis aplikasi yang stateless sejak awal: biayanya kecil, dan jalan ke scale out tetap terbuka.
Latihan lisan — Ucapkan dengan suara keras
Pasang timer dan jawab dengan suara keras, seolah sedang interview. Jangan buka jawaban contoh sebelum selesai. Soal ini juga ada di bank soal dan bisa ditarik review 0012.
"Aplikasi Anda berjalan di satu server dan CPU-nya penuh di jam sibuk. Apa yang Anda lakukan, dan apa yang harus diubah di aplikasi kalau ingin menambah server?" (60 detik)
Bandingkan dengan jawaban contoh dan checklist-nya
"Pertama saya ukur: apakah yang jenuh benar-benar app server, atau database? Kalau database, menambah app server tidak menolong. Kalau app server, saya cek dulu query atau kode yang lambat, lalu langkah termurah adalah scale up ke mesin lebih besar, tanpa ubah kode, walau ada batas ukuran dan biasanya ada downtime sebentar. Kalau beban terus naik atau saya butuh availability karena satu server berarti single point of failure, saya scale out: beberapa instance di belakang load balancer. Syaratnya server harus stateless, jadi session tidak boleh di memori server. Saya pindahkan ke shared store seperti Redis dengan TTL, atau ke token yang ditandatangani di client. Sticky session saya hindari karena menciptakan hot spot dan menghalangi failover."
Checklist: apakah Anda menyebut…
- mengukur dulu di mana bottleneck-nya (app server atau database)?
- scale up sebagai langkah termurah, beserta batasnya (ukuran mesin, downtime)?
- scale out: beberapa instance di belakang load balancer?
- syarat stateless: instance mana pun bisa melayani request mana pun?
- session dipindah ke shared store (Redis + TTL) atau token di client?
- membenarkan scale out dengan angka atau metrik (CPU, p99, target availability)?
Lulus jika minimal 4 dari 6.
Berikutnya, lesson 0006: komponen yang membagi request ke instance-instance itu, yaitu load balancer.
Istilah: GLOSSARY.md (bagian "Skalabilitas") · Indeks: semua lesson System Design
Ada yang belum jelas? Tanyakan ke saya (agent) di terminal, misalnya: "Kenapa vertical scaling butuh downtime?", "Kapan JWT lebih baik daripada session di Redis?"
Sumber: [1] Azure Architecture Center: Autoscaling (vertical vs horizontal scaling) · [2] Azure Architecture Center: Design to scale out · [3] Redis docs: Redis session store · [4] RFC 7519: JSON Web Token (JWT)