Mulai dari satu mesin

Pertanyaan

Kapan satu mesin tidak lagi cukup, dan apa langkah termurah berikutnya?

Hasil yang bisa diamati: kamu bisa memilih satu langkah penskalaan pertama untuk sebuah beban kerja, menyebut bukti yang mendukungnya, dan menyebut apa yang menjadi lebih sulit setelah langkah itu diambil.

Prasyarat dan contoh

Kamu sudah punya beban kerja, perkiraan kebutuhan, dan sasaran yang terukur (M01.02–M01.04).

Sebuah aplikasi dengan 50.000 request per hari berjalan di satu mesin: satu proses aplikasi, satu basis data, dan satu direktori untuk berkas. Tim membacanya di konferensi dan memecahnya menjadi enam layanan. Hasilnya: enam deployment, enam dashboard, dan satu masalah lambat yang tetap sama karena penyebabnya query tanpa indeks.

Satu mesin yang benar mengalahkan banyak mesin yang belum perlu. Penskalaan adalah respons terhadap kendala yang terbukti, bukan proyek identitas.

Mekanisme

Vertikal vs horizontal. Vertikal berarti mesin lebih besar: CPU, RAM, disk lebih cepat. Horizontal berarti lebih banyak mesin. Vertikal sederhana dan tidak mengubah kode, tetapi punya batas fisik dan biasanya berhenti pada satu titik harga. Horizontal menambah kapasitas hampir linear, tetapi menuntut aplikasi tanpa state lokal, perutean trafik, dan koordinasi.

Susunan satu mesin yang jujur. Satu mesin bukan berarti tanpa struktur. Susunan minimal:

klien → reverse proxy → proses aplikasi → basis data
                                      ↘ penyimpanan berkas

Reverse proxy menangani TLS dan header. Proses aplikasi menangani logika. Basis data menyimpan status. Penyimpanan berkas menyimpan objek besar. Keempatnya boleh berada di mesin yang sama; yang penting batas tanggung jawabnya jelas, sehingga bisa dipisah nanti tanpa menulis ulang logika.

Monolit vs layanan. Monolit berarti satu unit deployment. Itu bukan cacat. Batas modul di dalam monolit bisa tegas: modul A tidak membaca tabel milik modul B, dan semuanya berkomunikasi lewat antarmuka fungsi. Memisahkan menjadi layanan baru berguna ketika ada alasan operasional yang konkret: tim yang berbeda perlu melepas secara independen, komponen punya pola beban yang sangat berbeda, atau batas keamanan menuntut isolasi.

Urutan langkah yang biasanya masuk akal. Untuk beban dominan baca:

1. Perbaiki query dan indeks — sering menyelesaikan sebagian besar masalah.
2. Tambahkan cache di proses atau di depan aplikasi.
3. Pisahkan basis data dari aplikasi agar masing-masing bisa diperbesar.
4. Tambahkan replika baca.
5. Baru kemudian pertimbangkan sharding.

Untuk beban dominan tulis, urutannya berbeda: batching, antrean, lalu partisi.

Biaya koordinasi. Setiap batas jaringan menambah mode kegagalan: timeout, retry, duplikasi, versi berbeda, dan observabilitas terpisah. Satu mesin tidak punya masalah ini. Itu keunggulan nyata, bukan romantisme.

Saat rancangan ini gagal

• Memecah layanan untuk masalah yang bukan batas layanan. Query lambat tetap lambat setelah dipindah ke layanan sendiri. Kamu hanya menambahkan jaringan di depannya.
• Horizontal tanpa stateless. Dua instans aplikasi dengan sesi di memori lokal membuat pengguna "hilang" saat berpindah instans. Solusinya bukan session affinity permanen, melainkan memindahkan state ke tempat bersama atau membuatnya dapat direkonstruksi.
• Menganggap satu mesin berarti tanpa batas. Satu mesin tetap punya batas: jumlah koneksi, file descriptor, IOPS disk, dan bandwidth jaringan. Ketahui batas itu sebelum mencapaiinya.
• Menunda pemisahan yang jelas dibutuhkan. Jika kebutuhan kepatuhan memisahkan data pelanggan dari data analitik, itu alasan sah untuk memisahkan sejak awal. Sederhana bukan berarti buta konteks.

Contoh tandingan: sebuah sistem menambahkan cache untuk mengatasi latensi. Cache menurunkan beban basis data, tetapi juga membuat data yang baru ditulis kadang tidak terlihat. Masalah kebenaran muncul karena langkah penskalaan diambil sebelum kendala sebenarnya dipahami.

Latihan

Sebuah katalog produk punya 1 juta request/hari, 95% baca. p95 latensi saat ini 1,2 detik. Basis data menunjukkan 85% waktu CPU pada satu query daftar produk yang memindai tabel penuh. Aplikasi berjalan di dua instans dengan sesi di memori.

Pilih langkah pertama dan jelaskan.

Lihat pembahasan+

Langkah pertama: perbaiki query dan tambahkan indeks, bukan menambah instans atau memecah layanan.

Alasannya: bukti menunjukkan satu query memindai tabel penuh dan menghabiskan 85% CPU basis data. Menambah instans aplikasi tidak mengurangi pekerjaan yang sama. Memecah layanan memindahkan query yang sama ke jaringan lain. Indeks yang tepat menurunkan pekerjaan basis data secara langsung, dan efeknya bisa diukur pada p95.

Langkah kedua yang masuk akal: pindahkan sesi keluar dari memori lokal, karena dua instans sudah ada. Ini masalah kebenaran, bukan performa.

Yang belum perlu: cache terdistribusi dan sharding. Cache bisa menutupi query yang lambat, tetapi setelah query diperbaiki mungkin tidak lagi dibutuhkan. Sharding menambah kompleksitas besar untuk beban yang belum terbukti memerlukannya.

Jawaban yang baik menyebut bukti (CPU basis data, rencana query), urutan langkah, dan satu hal yang sengaja ditunda.

Terkait

• M01.06 Kenali saat infrastruktur tambahan belum diperlukan melanjutkan kerangka keputusan ini.
• M02 Jaringan dan eksekusi request membahas reverse proxy dan load balancer.
• M06 Caching membahas cache setelah kendalanya terbukti.
• Lab L01 menunjukkan bagaimana satu beban kerja bisa berpindah pembatas saat parameternya berubah.

Catatan

• Asumsi: satu mesin menjalankan aplikasi dan basis data; tidak ada kebutuhan kepatuhan khusus.
• Yang tidak dibahas: pemilihan penyedia cloud, container, orkestrasi, dan autoscaling.
• Urutan langkah bersifat heuristik, bukan aturan mutlak; bukti pengukuran tetap menentukan.
• Terakhir ditinjau: 25 Oktober 2026.