Belajar Cloud Architect - Scalability Patterns
Skala bukan tentang "lebih banyak server" — ia desain yang membiarkan sistem tumbuh tanpa redesign. Episode ini membedah scaling vertikal vs horizontal, desain stateless sebagai prasyarat skala, dan pola scaling database yang menjadi bottleneck arsitektur paling sering
#Pendahuluan
Di episode 21 kita memastikan arsitektur memenuhi janji performa. Sekarang pertanyaannya berubah: bagaimana performa itu bertahan saat beban naik — 2x, 10x, 100x? Inilah scalability: kemampuan tumbuh tanpa harus menulis ulang sistem.
Kesalahpahaman terbesar: scalability = "tambah server". Padahal scalability adalah desain — aplikasi yang tidak stateless tidak bisa diskalakan berapa pun server yang ditambahkan. Episode ini membangun tiga fondasi: perbedaan scaling vertikal/horizontal, desain stateless, dan pola scaling database yang paling sering menjadi penghambat.
#Vertical vs Horizontal Scaling
| Vertical (scale up) | Horizontal (scale out) | |
|---|---|---|
| Cara | Perbesar resource satu mesin (CPU/RAM) | Tambah jumlah mesin |
| Batas | Batas fisik perangkat keras | Praktis tak terbatas |
| Complexity | Rendah | Tinggi |
| Downtime | Sering perlu restart | Tidak |
| Kapan | Awal, beban sederhana | Setelah melewati batas vertikal |
Aturan praktis: mulai vertikal (sederhana), pindah horizontal saat perlu — dan pastikan desain siap sebelum butuh.
#Desain Stateless: Prasyarat Skala
#Mengapa State Membunuh Skala
Aplikasi yang menyimpan sesi di memory instance lokal tidak bisa diskalakan horizontal: request yang jatuh ke instance lain kehilangan sesinya. Solusi: state dipindah keluar — ke external store (cache/database) sehingga setiap instance identik dan bisa diganti kapan saja.
#Pola Stateless
- Sesi di external store — sesi user di Redis/sesi store, bukan memory instance.
- No sticky sessions — load balancer bebas mengarahkan request ke instance mana pun.
- Immutability — instance = stateless petak yang bisa dibuat/dihancurkan kapan saja.
- File di object storage — upload tidak disimpan di disk instance (episode 5).
[ ] Sesi user disimpan di external store, bukan memory?
[ ] File/upload ke object storage, bukan disk lokal?
[ ] Instance bisa dihancurkan kapan saja tanpa kehilangan data?
[ ] Tidak ada konfigurasi yang bergantung pada instance tertentu?Jika salah satu jawabannya "tidak", arsitektur belum siap diskalakan — berapa pun instance yang ditambahkan.
#Pola Auto-Scaling
#Scaling Berdasarkan Metrik
Auto-scaling menambah/mengurangi instance berdasarkan metrik. Kuncinya adalah metrik yang benar:
| Metrik | Arti | Kapan |
|---|---|---|
| CPU / Memory | Beban dasar | Umum |
| Request rate | Beban dari traffic | Web API |
| Queue depth | Beban asinkron (episode 12) | Worker/queue |
| Custom metric | Metrik bisnis | Kebutuhan khusus |
#Desain Auto-Scaling yang Sehat
- Scale out cepat, scale in lambat — menambah instance harus cepat (merespons lonjakan), mengurangi harus hati-hati (jangan flapping).
- Cool-down period — beri waktu instance stabil sebelum mengukur lagi.
- Predicted scaling — untuk beban yang bisa diprediksi (jam sibuk), jadwalkan scaling sebelum puncak.
scaling_policy:
metric: "RequestCountPerTarget"
scale_out:
threshold: 1000 # request/detik
adjustment: 2 # +2 instance
cooldown: 300
scale_in:
threshold: 400
adjustment: -1
cooldown: 600Perhatikan asimetri: scale-out +2 dengan cooldown 300s, scale-in -1 dengan cooldown 600s. Ini mencegah sistem "gemetar" di sekitar ambang batas.
#Database Scaling
#Database Adalah Bottleneck Pertama
Compute bisa diskalakan horizontal dengan mudah; database tidak. Ini bottleneck paling umum. Empat pola scaling database, dari sederhana ke kompleks:
#1. Vertical Database
Perbesar instance database. Batasnya nyata — dan mahal. Titik awal yang sah, bukan solusi jangka panjang.
#2. Read Replicas
Replika baca menangani query read; primary menangani write. Bagus untuk read-heavy (mayoritas workload).
#3. Sharding
Bagi data ke beberapa database berdasarkan key (misal: user ID). Skalabilitas besar, tapi kompleksitas tinggi: cross-shard query sulit, distribusi key harus merata.
#4. Partitioning (Membaca dan Menulis Terpisah)
Pola arsitektur dari episode 5: transaction store untuk write, warehouse/analytics untuk read berat — data dibaca dari tempat yang tepat, masing-masing diskalakan sendiri.
#Memilih Pola
| Kondisi | Pola |
|---|---|
| Beban masih kecil | Vertical DB |
| Read-heavy | Read replicas |
| Write-heavy / data besar | Sharding |
| Analytics berat | Pisahkan ke warehouse (episode 5) |
Tip
Urutan optimal: optimasi query → cache (episode 21) → vertical → read replicas → sharding. Kebanyakan sistem tidak pernah sampai sharding jika cache dan query-nya benar. Sharding adalah solusi terakhir — mahal dan permanen — bukan langkah pertama.
#Praktik: Mendesain Skala Elastis
Kerangka desain:
- Mulai vertical untuk kesederhanaan; rencanakan jalur ke horizontal sejak awal.
- Pastikan stateless: sesi external, file di object storage, instance disposable.
- Rancang auto-scaling dengan metrik benar; scale-out cepat, scale-in hati-hati.
- Siapkan database scaling bertahap: query → cache → replica → sharding.
- Uji dengan load test (episode 21) untuk memvalidasi perilaku scaling.
- Dokumentasikan pola dan batasnya di ADR.
#Penutup
Inti yang harus dibawa pulang:
- Vertical sederhana tapi terbatas; horizontal tak terbatas tapi butuh desain stateless.
- Stateless adalah prasyarat skala: sesi, file, dan konfigurasi di luar instance.
- Auto-scaling: metrik benar, scale-out cepat, scale-in hati-hati.
- Database: query → cache → vertical → replica → sharding, berurutan.
- Sharding adalah solusi terakhir yang mahal — bukan langkah pertama.
Di episode 23 selanjutnya kita akan membahas architecture review & governance — architecture review board, dokumentasi ADR, dan governance. Sampai jumpa di episode 23!