Perkirakan kebutuhan sumber daya

Pertanyaan

Berapa sumber daya yang dibutuhkan beban kerja ini, dan seberapa jauh dari kapasitas yang kita punya?

Hasil yang bisa diamati: kamu bisa mengisi tabel kebutuhan-versus-kapasitas untuk empat komponen dan menunjuk komponen mana yang paling dekat ke batasnya.

Prasyarat dan contoh

Kamu sudah bisa menyatakan beban kerja dalam request puncak per detik dan rasio baca/tulis (M01.02). Kamu nyaman dengan aritmetika dasar dan konversi satuan.

Contoh yang menipu: sebuah tim menghitung "2 juta request per hari, jadi butuh 23 request/detik". Angka itu benar untuk rata-rata dan hampir tidak berguna untuk kapasitas. Puncaknya 8×, dan setiap tulisan menghasilkan dua query. Kapasitas yang perlu disiapkan hampir sepuluh kali angka pertama.

Mekanisme

Perkiraan yang baik selalu punya tiga bagian: input dengan satuan, rumus, dan hasil dengan satuan yang sama. Jangan pernah menulis angka tanpa satuan.

1. Laju request.

rpsRataRata = request per hari / 86.400
rpsPuncak   = rpsRataRata × pengali puncak

86.400 adalah jumlah detik dalam sehari. Pengali puncak berasal dari M01.02.

2. Beban basis data. Setiap request belum tentu satu query. Asumsi yang harus dinyatakan: satu baca = satu query, satu tulis = dua query (menulis baris dan memperbarui indeks).

queryRps = rpsPuncak × rasioBaca + rpsPuncak × (1 − rasioBaca) × 2

3. Transfer jaringan. Ukuran respons dikalikan laju, lalu dikonversi dari kilobyte ke megabit. Satu byte sama dengan 8 bit; satu megabit sama dengan 1024 kilobit dalam konvensi yang dipakai di sini.

egressMbps = rpsPuncak × ukuranResponsKb × 8 / 1024

4. Penyimpanan. Hanya tulisan yang menambah data. Retensi menentukan berapa lama data itu tinggal.

tulisanPerHari = request per hari × (1 − rasioBaca)
penyimpananGb  = tulisanPerHari × retensiHari × ukuranTulisKb / 1.048.576

5. Perbandingan. Untuk setiap komponen, hitung utilisasi = kebutuhan / kapasitas. Komponen dengan utilisasi tertinggi adalah pembatas pertama. Inilah angka yang menentukan langkah berikutnya, bukan total request.

Perhatikan bahwa hasil ini bergantung pada asumsi. Mengganti satu tulis menjadi tiga query mengubah beban basis data 50%, tetapi tidak mengubah kesimpulan. Perkiraan yang baik cukup akurat untuk keputusan, bukan untuk prediksi presisi.

Saat rancangan ini gagal

• Kesalahan satuan. Menghitung kilobyte sebagai kilobit membuat kebutuhan bandwidth delapan kali lebih kecil. Selalu tulis satuan di setiap baris.
• Melupakan biaya turunan. Penyimpanan bukan hanya baris data: ada indeks, replika, tombstone, dan overhead filesystem. Kalikan dengan faktor yang dinyatakan, misalnya 1,5–2×.
• Menganggap payload seragam. Halaman daftar dan endpoint redirect punya ukuran berbeda. Rata-ratakan per jenis request.
• Mengabaikan pertumbuhan. Retensi 365 hari terlihat aman sampai volume tulisan naik 4×. Hitung juga skenario pertumbuhan, bukan hanya hari ini.
• Menganggap kapasitas linear. Dua kali CPU belum tentu dua kali throughput. Query yang bersaing atas lock bisa membuat throughput turun saat konkurensi naik.

Contoh tandingan: perhitungan menunjukkan basis data hanya 0,2% terpakai, tetapi p99 latensi tinggi. Penyebabnya bukan kapasitas, melainkan satu query tanpa indeks. Menambah kapasitas tidak memperbaiki apa pun; perbaikan ada di M04.

Latihan

Hitung kebutuhan untuk kasus berikut: 2 juta request/hari, puncak 2×, respons 1 KB, tulis 8 KB, 40% baca, retensi 3.650 hari. Kapasitas: aplikasi 1.000 req/detik, basis data 2.000 query/detik, bandwidth 500 Mbit/detik, penyimpanan 5.000 GB.

1. Hitung keempat kebutuhan.
2. Tentukan pembatas pertama.
3. Sebutkan satu asumsi yang paling memengaruhi kesimpulan.

rpsRataRata   = 2.000.000 / 86.400 ≈ 23,1 req/detik
rpsPuncak     = 23,1 × 2 ≈ 46,3 req/detik
queryRps      = 46,3 × 0,4 + 46,3 × 0,6 × 2 ≈ 74,1 query/detik
egressMbps    = 46,3 × 1 × 8 / 1024 ≈ 0,36 Mbit/detik
tulisan/hari  = 2.000.000 × 0,6 = 1.200.000
penyimpananGb = 1.200.000 × 3.650 × 8 / 1.048.576 ≈ 33.400 GB

Terkait

• Lab L01 menghitung rumus yang sama secara interaktif. Coba skenario "arsip tulis berat" dan bandingkan dengan jawabanmu.
• M01.04 Tentukan sasaran yang berguna membahas kapan utilisasi 60% masih bisa diterima dan kapan tidak.
• M04.03 Rancang indeks menjelaskan biaya query yang diasumsikan di sini.

Catatan

• Asumsi: satu tulis = dua query; egress hanya badan respons; penyimpanan belum termasuk replika dan indeks.
• Model ini tidak memodelkan antrean, cache, kompresi, CDN, atau burst mikro.
• Konvensi: 1 GB = 1.048.576 KB; 1 Mbit = 1024 Kbit.
• Terakhir ditinjau: 25 Oktober 2026.