Apa yang Dipecahkan oleh Buku Allspaw
Disiplin Tidak Kehabisan
John Allspaw menulis 'The Art of Capacity Planning' (O'Reilly, 2008; edisi kedua 2017) setelah menjalankan operasi di Flickr melalui tahun-tahun pertumbuhan yang eksplosif. Tesisnya: perencanaan kapasitas bukanlah latihan spreadsheet sekali jadi. Ini adalah disiplin berkelanjutan yang menggabungkan pengukuran, peramalan, & pertimbangan rekayasa. Lewatkan salah satu dari ketiga hal itu, & Anda akan kehabisan kapasitas dalam produksi atau membakar uang untuk hardware yang idle.
Perencanaan kapasitas duduk di antara dua mode kegagalan:
- Underprovisioning: layanan berjalan panas, lonjakan latensi, tingkat kesalahan naik, pelanggan pergi. Cara tercepat untuk kehilangan pengguna dalam fase pertumbuhan.
- Overprovisioning: hardware duduk di 10% utilisasi, keuangan bertanya mengapa anggaran terus bertambah tanpa revenue sesuai. Cara tercepat untuk kehilangan jumlah staf dalam tinjauan anggaran.
Seni terletak pada menemukan koridor di antara dua tebing itu dan tetap berada di dalamnya saat beban kerja berubah.
Tiga pertanyaan inti mendorong setiap latihan kapasitas:
- Apa yang kita miliki? Kapasitas saat ini dalam unit konkret: permintaan per detik, kueri per detik, gigabita penyimpanan, koneksi bersamaan.
- Apa yang kita butuhkan? Permintaan yang diprediksi pada tanggal di masa depan dengan batas ketidakpastian eksplisit.
- Kapan kami harus bertindak? Waktu timbal balik untuk pengadaan, provisioning, atau penskalaan. Cloud mengurangi ini menjadi menit; on-premise bisa berarti berbulan-bulan.
Mengapa Tidak Bisa Menjadi Spreadsheet
Sebuah perusahaan e-commerce merencanakan kapasitas sekali setahun, pada November, dengan mengekstrapolasi lalu lintas 12 bulan sebelumnya secara linear. Mereka berjalan di server khusus dengan waktu timbal balik pengadaan 6 minggu. Lalu lintas mereka menunjukkan musim mingguan yang kuat (puncak akhir pekan 3x), musim tahunan yang kuat (5x Black Friday), & telah tumbuh 40% tahun ke tahun selama tiga tahun.
Beban Kerja versus Utilisasi
Dua Angka Berbeda, Keduanya Diperlukan
Perencanaan kapasitas gagal ketika tim hanya mengukur salah satu dari dua dimensi esensial.
Beban kerja: permintaan pada sistem dari luar. Permintaan per detik, transaksi per menit, megabita per detik, pengguna bersamaan. Beban kerja menggambarkan apa yang diminta dunia dari Anda.
Utilisasi: seberapa penuh sistem berjalan sambil melayani permintaan itu. Persen CPU, memori yang digunakan, kedalaman antrian, bandwidth jaringan, IOPS disk. Utilisasi menggambarkan bagaimana sistem terasa di bawah permintaan itu.
Beban kerja saja memberi tahu Anda apa yang akan datang tetapi bukan apakah Anda dapat melayaninya. Utilisasi saja memberitahu Anda seberapa penuh Anda tetapi bukan apa yang diharapkan besok. Anda memerlukan keduanya, diplot berdampingan, untuk membuat keputusan kapasitas.
Rasio kapasitas = beban kerja / utilisasi. Jika Anda melayani 1.000 permintaan per detik pada 50% CPU, rasio kapasitas Anda adalah 2.000 RPS per 100% CPU per server. Faktor konversi ini memungkinkan Anda menerjemahkan beban kerja yang diprediksi menjadi jumlah server yang diperlukan.
Allspaw menekankan pengukuran pada granularitas yang tepat. Satu sampel per menit menyembunyikan puncak 30 detik. Satu sampel per jam menyembunyikan segalanya. Pekerjaan kapasitas nyata membutuhkan resolusi sub-menit untuk peristiwa puncak dan resolusi menit untuk trending. Apa pun yang lebih kasar menghasilkan kepercayaan diri yang berbahaya dan palsu.
Apa yang Harus Diinstrumen
Tim Anda meluncurkan instrumentasi kapasitas pada peluncuran produk baru (layanan transkoding video). Anda dapat memilih hingga 8 metrik untuk dilacak pada resolusi sub-menit. Layanan menyerap unggahan video, mengantrikannya, mentranscode ke berbagai format, & menulis output ke penyimpanan objek.
Tren, Musiman, Ketidakpastian
Tiga Lapisan Setiap Perkiraan
Allspaw dan buku Google SRE setuju tentang struktur perkiraan yang berguna: tren, musiman, & batas ketidakpastian. Lewatkan salah satunya dan perkiraan menjadi menyesatkan.
Tren: kemiringan permintaan selama berbulan-bulan atau bertahun-tahun. Sering dimodelkan dengan regresi linear untuk jendela pendek, eksponensial atau piecewise-linear untuk pertumbuhan majemuk. Garis tren menjawab 'ke mana permintaan menuju secara umum?'
Musiman: pola siklik pada berbagai skala waktu. Harian (puncak lalu lintas sore), mingguan (lonjakan akhir pekan), tahunan (Black Friday, musim pajak, tahun sekolah). Musiman multiplikatif berskala dengan tren; musiman aditif menambahkan offset konstan.
Batas ketidakpastian: kerucut perkiraan. Perkiraan tanpa batas adalah tebakan. Perkiraan nyata mempublikasikan perkiraan pusat dengan batas eksplisit, biasanya pada kepercayaan 90% atau 95%. Kerucut melebar saat Anda memproyeksikan lebih jauh ke masa depan. Perkiraan 4 minggu mungkin memiliki batas ±10%; perkiraan 12 bulan sering memiliki ±50%.
Memisahkan pertumbuhan bisnis dari permintaan teknis: perencanaan kapasitas meramalkan beban kerja teknis, tetapi tim bisnis meramalkan pendapatan, pendaftaran, atau kampanye. Pekerjaan perencana kapasitas adalah menerjemahkan perkiraan bisnis menjadi permintaan teknis: pertumbuhan pendaftaran 30% mungkin berarti 30% lebih banyak panggilan API, tetapi mungkin berarti 80% lebih banyak jika pengguna baru menggunakan sistem lebih berat, atau hanya 15% jika mereka mengonversi pada tingkat lebih rendah. Rasio konversi penting sebanyak perkiraan bisnis yang mendasarinya.
Peramalan Lalu Lintas Hari Libur
Layanan Anda melayani situs e-commerce. Lalu lintas Black Friday tahun lalu adalah 5x rata-rata November, dipertahankan selama 12 jam. Bisnis telah tumbuh 40% tahun ke tahun. Pemasaran meluncurkan promosi berbayar yang diharapkan menambah 20% tambahan ke lalu lintas Black Friday tahun ini.
Mengetahui Batas Anda
Temukan Batas Sebelum Produksi Melakukannya
Peramalan memberi tahu Anda apa yang akan datang. Pengujian batas memberi tahu Anda apakah sistem dapat melayaninya. Allspaw memperlakukan pengujian batas sebagai input yang tidak dapat dinegosiasikan untuk perencanaan kapasitas: Anda tidak tahu kapasitas nyata Anda sampai Anda telah mengujinya di bawah beban terkontrol.
Tiga jenis pengujian batas:
- Pengujian beban sintetis: generator beban (k6, Locust, JMeter, vegeta) mendorong lalu lintas ke layanan target dalam staging. Tingkatkan beban sampai sesuatu rusak. Titik kerusakan adalah batasnya. Terbaik untuk pengujian layanan terisolasi.
- Simulasi produksi: dengan sengaja kurangi kapasitas dalam produksi (mengeringkan persentase server, matikan wilayah) dan amati bagaimana kapasitas yang tersisa menangani lalu lintas nyata. Menguji perilaku produksi yang sebenarnya termasuk interaksi yang tidak terduga. Kepercayaan tertinggi tetapi risiko tertinggi.
- Beban bayangan: putar ulang lalu lintas produksi nyata pada layanan target yang berjalan paralel dengan produksi. Menangkap pola beban kerja nyata (campuran kueri langka, agen pengguna aneh) tanpa mempengaruhi pengguna. Kompromi tengah yang kuat.
Headroom adalah buffer antara beban saat ini dan batas. Aturan praktik SRE:
- Headroom 50% dalam kondisi mantap untuk layanan satu-wilayah (jadi kegagalan wilayah tidak menghabiskan wilayah yang bertahan)
- Headroom 30% untuk layanan multi-wilayah dengan redundansi N+2
- Headroom 100%+ mendekati acara puncak yang diketahui (Black Friday, final olahraga)
Headroom bukanlah pemborosan. Ini adalah biaya tidak memanggil insinyur pada pukul 3 pagi, tidak kehilangan pelanggan selama lonjakan, dan tidak mengalami kegagalan cascade saat satu wilayah gagal. Tim keuangan terkadang mendorong untuk mengurangi headroom; insinyur kapasitas harus mengartikulasikan biaya menjalankan ketat untuk membuat percakapan itu faktual daripada emosional.
Merancang Pengujian Batas
Anda mewarisi layanan tanpa batas kapasitas yang didokumentasikan. Beban produksi saat ini adalah 800 permintaan per detik di seluruh 12 server, rata-rata CPU 35%. Pemasaran mengumumkan kampanye dalam 6 minggu diharapkan mendorong lalu lintas ke puncak 3.000 RPS.
Naik, Keluar, atau Diagonal
Kapan Menambah Daya, Menambah Kotak, atau Keduanya
Tiga strategi penskalaan inti, masing-masing dengan profil biaya dan keandalan yang berbeda:
Penskalaan vertikal (scaling up): mesin yang lebih besar. Ganti server 8-inti dengan server 32-inti. Jalur paling sederhana; bekerja sampai Anda mencapai batas mesin tunggal. Titik kegagalan tunggal tetap ada. Biaya tumbuh non-linear: mesin 32-inti sering kali biaya lebih dari 4x mesin 8-inti.
Penskalaan horizontal (scaling out): lebih banyak mesin. Tambahkan server di belakang penyeimbang beban. Kapasitas berskala linear dengan jumlah server. Mode kegagalan bergeser: Anda harus menangani koordinasi terdistribusi, tetapi kegagalan server tunggal tidak lagi menghancurkan layanan. Kompleksitas operasional meningkat.
Penskalaan diagonal (istilah Allspaw): skala naik terlebih dahulu ke ukuran per-server yang nyaman, lalu skala keluar dari sana. Menggabungkan operasi yang lebih sederhana dari server besar dengan redundansi server multibel. Sebagian besar layanan produksi hidup di wilayah penskalaan diagonal.
Harga cadangan versus on-demand: penyedia cloud menghargai prediktabilitas. Kapasitas cadangan 30-60% lebih murah daripada on-demand tetapi memerlukan komitmen 1-3 tahun. Perencana kapasitas biasanya mengunci permintaan dalam keadaan mantap dengan kapasitas cadangan dan burst ke on-demand untuk puncak. Salah menghitung pembagian ini dapat membuang uang (over-cadangan) atau mengekspos anggaran ke kejutan (under-cadangan selama puncak).
Spot instance dan beban kerja yang dapat diinterupsi: 60-90% lebih murah daripada on-demand tetapi dapat dirampas dengan pemberitahuan hitungan menit. Cocok untuk pekerjaan batch, analitik, pelatihan beban kerja, atau layanan apa pun yang dirancang untuk interupsi yang anggun. Lalu lintas produksi menghadap pengguna biasanya menghindari spot.
Memilih Jalur Penskalaan
Layanan transkoding video Anda berjalan di 8 instans cloud berukuran menengah (8-inti masing-masing). Anda mengharapkan pertumbuhan 3x selama 6 bulan ke depan. Beban kerja terikat CPU, dapat diparalelkan per video, & setiap transkode video membutuhkan 90 detik dari ujung ke ujung. Instans cadangan biaya 50% dari on-demand. Instans spot biaya 30% dari on-demand tetapi dapat dihentikan dengan pemberitahuan 2 menit.
Karir Perencanaan Kapasitas
Di Mana Keterampilan Perencanaan Kapasitas Membayar
Perencanaan kapasitas jarang menjadi judul pekerjaan sendiri. Keterampilan muncul di bawah beberapa peran:
Site Reliability Engineer: perencanaan kapasitas adalah tanggung jawab SRE inti. Sebagian besar tim SRE memiliki satu atau dua insinyur yang berspesialisasi dalam kapasitas, memiliki model perkiraan, pengujian batas, dan otomasi provisioning.
Cloud Cost / FinOps Engineer: peran yang lebih baru berfokus pada optimasi pengeluaran cloud. Menggabungkan perencanaan kapasitas dengan pemodelan keuangan, negosiasi kontrak, dan manajemen portofolio instans cadangan. Membayar sangat baik di perusahaan cloud-native besar karena tagihan cloud sering kali pengeluaran terbesar kedua setelah gaji.
Performance Engineer: berfokus pada efisiensi per-node dan pengujian batas. Pekerjaan: mengekstrak kapasitas lebih dari hardware yang sama melalui profiling, optimasi, dan perubahan arsitektur. Pengetahuan sistem dan runtime bahasa yang berat.
Capacity Planning Specialist: di perusahaan sangat besar (Google, Meta, Amazon, Netflix), tim perencanaan kapasitas khusus ada. Mereka memiliki model perkiraan di seluruh armada, negosiasi pengadaan dalam skala besar, dan koordinat dengan keuangan di roadmap hardware multi-tahun.
Keterampilan yang bersenyawa: analisis time-series (R, Python statsmodels, Prophet), teori antrian (M/M/1, M/M/c, Hukum Little), setidaknya satu alat manajemen konfigurasi, setidaknya satu dashboard biaya cloud, dan kemampuan menulis laporan perkiraan yang dapat dipahami dan ditindaklanjuti oleh CFO. Keterampilan teknis membawa Anda ke wawancara; keterampilan komunikasi membawa Anda ke anggaran.
Menutup
Apa yang Sekarang Anda Tahu
Perencanaan kapasitas adalah disiplin berkelanjutan, bukan latihan tahunan. Anda telah mencakup:
- Koridor antara underprovisioning dan overprovisioning
- Beban kerja versus utilisasi sebagai dua dimensi pengukuran
- Tren, musiman, dan batas ketidakpastian sebagai tiga lapisan dari setiap perkiraan
- Pengujian batas (sintetis, bayangan, simulasi) sebagai satu-satunya cara untuk mengetahui kapasitas nyata
- Buffer headroom dan mengapa mereka bukan pemborosan
- Penskalaan diagonal dan keputusan harga cadangan/on-demand/spot
- Jalur karir di mana keterampilan ini mendapatkan otoritas anggaran
Dua ide paling penting. Peramalan dengan batas, tidak pernah dengan poin tunggal. Dan ukur batas Anda sebelum produksi melakukannya. Bawa dua hal itu maju dan sisanya mengikuti.
Bacaan yang direkomendasikan: 'The Art of Capacity Planning' karya Allspaw (O'Reilly, edisi kedua 2017), bab yang relevan dalam Google SRE Book (gratis di sre.google/books/), dan 'Systems Performance' karya Brendan Gregg untuk pekerjaan sistem yang mendasar. Pelajaran pendamping geometry-of menggali lebih dalam tentang struktur visual: Hukum Little sebagai area, kurva antrian, kemiringan tren, & amplop headroom.