Dua Cara untuk Menanggung Beban Lebih Banyak
Selamat Datang
Ketika sebuah layanan mulai kewalahan oleh beban, operator menghadapi pilihan. Membuat mesin yang ada menjadi lebih besar (CPU lebih banyak, RAM lebih banyak, disk lebih cepat). Atau menambahkan lebih banyak mesin yang masing-masing melakukan pekerjaan yang sama.
Jalur pertama disebut skala vertikal (scale up). Jalur kedua disebut skala horizontal (scale out).
Pelajaran ini mengajarkan mengapa hampir setiap arsitektur web modern memilih skala horizontal & properti apa dari beban kerja yang membuat pilihan tersebut layak. Jawabannya tersembunyi dalam satu kata: state.
Pada akhir pelajaran, Anda akan memahami:
- Kurva biaya vertical vs horizontal scaling & di mana masing-masing paling tepat digunakan
- Apa arti 'stateful' & 'stateless' dalam praktiknya, & mengapa salah satunya dapat diperbanyak secara murah
- Matematika untuk menentukan ukuran armada replika di bawah beban yang diharapkan & lonjakan beban
- Aturan headroom yang mencegah sebuah tier runtuh melewati titik lutut antrean (queueing knee)
- Di mana state harus disimpan (tidak pernah hilang) & bagaimana memindahkannya keluar dari lapisan yang perlu diskalakan
Mengapa Horizontal Menang Melebihi Ambang Tertentu
Skala Vertikal: Satu Kotak yang Lebih Besar
Kelebihan: sederhana. Tidak ada perubahan kode. Tidak ada koordinasi. Proses yang sama kini memiliki lebih banyak CPU.
Kekurangan: adanya batas atas. VM komersial terbesar yang tersedia memiliki RAM & inti yang terbatas. Di atas itu, tidak ada uang yang bisa membeli lebih banyak ruang. Biaya menjadi superlinier melewati titik optimal dari penawaran vendor. Kegagalan satu mesin tersebut akan menjatuhkan seluruh layanan.
Skala Horizontal: Banyak Kotak Lebih Kecil
Kelebihan: tidak ada batas atas (hingga batas kesediaan Anda untuk membayar & mengoordinasikan mesin). Kapasitas bertambah secara linier dengan jumlah replika, secara dapat diprediksi. Kegagalan satu replika hanya menghilangkan 1/N dari kapasitas, bukan 100%.
Kekurangan: memerlukan beban kerja yang mendukungnya. Beberapa beban kerja (satu database besar, server game stateful yang menyimpan sesi aktif) sulit untuk diskalakan secara horizontal. Koordinasi & distribusi beban menjadi perhatian operasional.
Titik persimpangan: setiap layanan produksi yang harus bertahan dari kegagalan satu mesin apa pun harus berjalan di setidaknya dua mesin. Begitu Anda menerima dua, Anda sudah memilih skala horizontal. Dari sana, pertanyaannya bukan 'apakah kita harus?' tetapi 'seberapa murah kita bisa menambahkan replika berikutnya?'
Penggerak utama: beban kerja yang tidak menyimpan state per-request di mesin itu sendiri. Maka, replika mana pun dapat menjawab permintaan apa pun, & penambahan replika menambah kapasitas tanpa koordinasi.
Stateful vs Stateless dalam Praktik
State Tidak Pernah Hilang, Hanya Berpindah
Komponen ber-state: menyimpan informasi yang hilangnya akan mengubah perilaku. Basis data yang menyimpan akun pengguna. Cache yang menyimpan token sesi. Worker yang mengunci koneksi streaming jangka panjang ke pengguna tertentu.
Komponen tanpa state: tidak menyimpan informasi yang hilangnya akan berdampak. Lapisan web yang membaca permintaan, menanyakan basis data, & menulis respons. Setiap permintaan berdiri sendiri; lapisan ini tidak mengingat apa pun antar permintaan.
Wawasan kunci: state tidak pernah hilang dari sebuah sistem. Ia berpindah ke lapisan yang dirancang untuk menyimpannya (basis data, klaster Redis, object store). Lapisan yang menghadapi lalu lintas lalu bisa menjadi tanpa state, & lapisan tanpa state dapat diskalakan secara horizontal karena replika mana pun dapat menjawab permintaan apa pun.
Tes praktis: jika Anda secara acak mematikan satu proses di lapisan ini & mengujinya ulang, apakah pengguna akan mengalami jawaban yang salah atau sesi yang hilang? Jika ya, komponen tersebut menyimpan state. Jika tidak, maka tidak.
Contoh
- Proses web Python yang membaca permintaan, menanyakan Postgres, mengembalikan JSON: tanpa state. State berada di Postgres.
- Proses web Python yang menyimpan keranjang belanja pengguna di memori lokal: ber-state. Mematikan proses akan menghilangkan keranjang.
- Server WebSocket yang mempertahankan koneksi terbuka ke pengguna chat: stateful dalam arti koneksi. Jika proses dihentikan, koneksi akan terputus; klien harus terhubung ulang. Seringkali, sistem seperti ini tetap dapat diskalakan secara horizontal dengan kehati-hatian (sticky sessions, consistent hashing).
- Cache Redis di depan Postgres: stateful untuk isi cache, tetapi dapat diterima jika cache miss dapat ditoleransi. Kegagalan replika berarti cache miss, bukan kehilangan data.
Merancang untuk penskalaan horizontal = mengeluarkan state dari lapisan yang perlu diskalakan.
Audit Tier yang Curiga
Sebuah tim menjalankan API rekomendasi di 6 VM backend di belakang reverse proxy. Aplikasi tersebut: membaca user ID dari permintaan, mengambil aktivitas terbaru pengguna dari Postgres, menjalankan algoritma penilaian, dan mengembalikan daftar item yang direkomendasikan. Ada dua perilaku non-standar:
- Aplikasi menyimpan cache 'aktivitas pengguna terbaru' di memori proses, yang terisi pada permintaan pertama untuk seorang pengguna, dan digunakan kembali pada permintaan berikutnya.
- Aplikasi menggunakan sticky sessions: begitu seorang pengguna mengakses VM #3, semua permintaan berikutnya dari pengguna tersebut akan diarahkan ke VM #3 (proxy dikonfigurasi untuk sticky routing berdasarkan cookie).
Rumus Replika
Rumus Kapasitas Tersempel
Setelah sebuah tier menjadi stateless, penentuan ukurannya menjadi hitungan aritmatika. Anda membutuhkan cukup banyak replika agar beban keadaan stabil (steady-state) datang dan pergi pada laju yang sama, dengan ruang cadangan (headroom) untuk lonjakan.
Rumusnya:
replika = ⌈ (beban_puncak × faktor_lonjakan) / kapasitas_per_replika ⌉ + ruang_cadangan
Di mana:
- beban_puncak: jumlah permintaan per detik maksimum yang berkelanjutan yang Anda perkirakan dalam operasi normal
- faktor_lonjakan: pengali yang mencakup ledakan singkat di atas puncak (umumnya 1,5x hingga 2x untuk lalu lintas yang dapat diprediksi, 3x atau lebih untuk yang viral / tidak terprediksi)
- kapasitas_per_replika: jumlah permintaan per detik yang ditangani oleh satu replika pada latensi & utilisasi yang dapat diterima (umumnya diukur pada 70% CPU, bukan pada titik saturasi)
- ruang_cadangan: replika tambahan agar beberapa kegagalan replika tidak meruntuhkan tier tersebut (umumnya 1-2 replika untuk armada kecil, 10-20% untuk yang lebih besar)
Contoh pengerjaan: sebuah backend menangani 100 req/s dengan CPU 70% per replika. Beban puncak adalah 600 req/s. Anda mengharapkan lonjakan 2x sesekali. Anda ingin tetap bertahan jika 2 replika gagal.
replika = ⌈ (600 × 2) / 100 ⌉ + 2 = 12 + 2 = 14 replika
Aturan 80%
Kapasitas per replika bukan titik saturasi. Ukur kapasitas pada CPU 70-80%, jangan pernah pada 100%.
Di atas utilisasi sekitar 80%, kurva antrean naik tajam: antrean yang berjalan dalam 10 ms pada utilisasi 60% berjalan dalam 80 ms pada utilisasi 90%. Latensi, bukan throughput, yang rusak terlebih dahulu. (Pelajaran pendamping geometry_of_stateless_horizontal_scaling menurunkan kurva ini secara matematis.)
Autoscaling vs Provisioning Statis
Statis: provision untuk puncak × ruang lonjakan & terima biaya menjalankan pada utilisasi rendah di luar jam sibuk.
Autoscaling: pengontrol menambah & menghapus replika berdasarkan utilisasi yang diamati, latensi target, atau kedalaman antrean.
Catatan autoscaling: waktu cold-start sangat penting. Jika replika baru membutuhkan 2 menit untuk boot, autoscaling tidak dapat merespons lonjakan selama 30 detik. Autoscaling yang matang mempertahankan kolam (pool) replika yang sudah disiapkan sebelumnya (pre-provisioned) dalam keadaan hangat (warm) tepat di bawah ambang batas peningkatan skala (scale-up threshold).
Menentukan Ukuran Armada untuk Layanan Baru
Tim Anda berencana meluncurkan API metadata video. Benchmark menunjukkan satu replika menangani 250 req/s pada CPU 70% & latensi p99 50 ms. Pemasaran memprediksi beban puncak sebesar 4.000 req/s selama jam prime-time. Acara promosi yang direncanakan dapat melonjak hingga 3x puncak secara singkat. Anda ingin layanan tersebut bertahan dari 3 kegagalan replika simultan tanpa melebihi utilisasi 80% pada replika yang tersisa.
Cold Start, Drain Lambat, & Batasan Nyata Lainnya
Armada Nyata Memiliki Batasan Nyata
Rumus tersebut mengasumsikan bahwa replika muncul seketika, menerima lalu lintas seketika, & melepaskan lalu lintas seketika. Tidak ada satu pun dari asumsi tersebut yang berlaku di lingkungan produksi.
Cold start: replika baru perlu menghidupkan sistem operasi, memulai proses, memuat konfigurasi, menghangatkan cache, & lulus pemeriksaan kesehatan. Durasinya berkisar dari 5 detik (penyelarasan ulang kontainer) hingga 5 menit (boot VM penuh + penarikan image). Autoscaling tidak dapat merespons lonjakan lalu lintas yang lebih pendek dari penundaan ini.
Drain lambat: replika yang dihapus dari pool membutuhkan waktu untuk menyelesaikan permintaan yang sedang diproses sebelum diakhiri. Jika tidak, pengguna akan melihat respons yang terpotong. Proxy terbalik mendukung drain (berhenti menerima permintaan baru, menyelesaikan permintaan aktif) tetapi prosesnya memakan waktu dari beberapa detik hingga beberapa menit.
Warm pool: armada produksi mempertahankan kumpulan replika yang sudah diprovisikan tetapi masih menganggur, siap menerima lalu lintas saat ada sinyal. Ini menukar biaya tetap yang kecil dengan respons lonjakan yang cepat.
Connection draining vs immediate kill: shutdown yang anggun itu penting. SIGTERM yang memicu drain membutuhkan waktu lebih lama daripada SIGKILL tetapi tidak memutus permintaan pengguna.
Health check window: replika yang baru saja dimulai mungkin lolos health check pertamanya sebelum pool koneksi database-nya hangat; proxy kemudian mengirim lalu lintas asli & beberapa permintaan pertama menjadi lambat. Atur health check untuk menguji jalur nyata, bukan hanya liveness proses.
Stickiness creep: bahkan tier yang secara nominal stateless pun memperoleh stickiness seiring waktu (cache CDN, cache resolver DNS, pool koneksi). Bercurigalah terhadap 'replika identik' yang tetap saja berperilaku berbeda.
Warm Pool atau Autoscaling Reaktif?
API metadata video Anda (yang sama dari pertanyaan sebelumnya, berukuran 51 replika untuk puncak stabil + surge) mengalami surge 30 detik hingga 5x beban normal setiap kali video viral baru diunggah. Autoscaling saat ini membutuhkan 90 detik untuk menambahkan replika baru dari kondisi dingin (image pull + warmup). Selama celah 90 detik tersebut, latensi melonjak tajam & beberapa permintaan mengalami timeout.
Merancang Lapisan Stateless dengan Batasan
Sintesis
Anda telah mempelajari mengapa penskalaan horizontal menang melewati ambang batas kecil, apa arti state dalam praktiknya, bagaimana cara menentukan ukuran armada di bawah beban yang diharapkan & lonjakan, & di mana penskalaan horizontal gagal di batas-batasnya.
Terapkan keempatnya.
Desain tier backend untuk feed.example.com, sebuah API feed sosial. Batasan: kapasitas per-replica 200 req/s pada CPU 70%; beban puncak yang diharapkan 1500 req/s; faktor lonjakan 2,5x (cerita trending sesekali); bertahan dari 2 kegagalan replica simultan; waktu cold-start 60 detik; lonjakan dapat berlangsung 45 detik; anggaran mengizinkan beberapa kapasitas idle tetapi tidak provisioning permanen 2,5x.
Ke Mana Kursus Ini Berlanjut
Ke Mana Kursus Ini Berlanjut
Anda kini memiliki model mental yang berfungsi tentang tier tanpa status (stateless): mengapa ia dapat diskalakan, bagaimana cara menentukan ukurannya, apa yang rusak di batas-batasnya, & ke mana status (state) harus dipindahkan ketika Anda mendorongnya keluar dari lapisan yang perlu tumbuh.
Pelajaran berikutnya dalam kursus ini (cs_distsys_ingress_egress_separation) membahas masalah yang lebih halus: bahkan tier tanpa status yang berukuran sempurna pun dapat gagal dengan cara yang mengejutkan ketika lalu lintas masuk & keluar berbagi jalur jaringan yang sama. Contoh klasik melibatkan proxy yang mencoba terhubung ke dirinya sendiri; solusinya melibatkan pemisahan satu tier menjadi dua dengan tanggung jawab yang berbeda.
Pelajaran pendamping: geometry_of_stateless_horizontal_scaling menurunkan kurva antrean, Hukum Little yang diterapkan pada armada replika, & makna geometris dari lutut utilisasi 80%.
Bagus. Lanjutkan.