9.7 Perencanaan kapasitas dan peramalan permintaan

Tinjauan dan motivasi

Setiap sistem punya langit-langit. Inti komputasi habis, disk penuh, kolam koneksi kehabisan, dan antrean yang kosong saat sarapan meluap saat makan siang. Perencanaan kapasitas adalah disiplin mencocokkan pasokan komputasi, penyimpanan, dan jaringan dengan permintaan yang Anda harapkan, dengan ruang kepala cukup sehingga hari normal tak pernah mendekati langit-langit dan hari buruk gagal dengan anggun alih-alih katastrofik. Peramalan permintaan adalah separuh lainnya: memprediksi berapa banyak beban yang akan datang, kapan, dan mengapa, agar pasokan tiba sebelum permintaan alih-alih sesudah pemadaman.

Bab ini berada di antara dua tetangga dan tetap melengkapi keduanya. Bab 3.5 membahas skalabilitas sebagai properti arsitektur: bagaimana sistem dibangun agar dapat tumbuh sama sekali, lewat ketiadaan status, sharding, dan penskalaan horizontal. Bab 9.1 membahas site reliability engineering (SRE), yang menetapkan target keandalan yang harus dibela kapasitas. Di sini Anda menerima arsitektur sebagaimana adanya dan target sebagai tetap, lalu menjawab pertanyaan kuantitatif: berapa banyak dari segalanya yang perlu Anda beli, reservasi, dan simpan sebagai cadangan agar sistem memenuhi service level objective (SLO, target keandalan dari bab 9.1) melalui permintaan yang diperkirakan dan lonjakan yang tak Anda perkirakan. Autoscaling dan rekayasa kinerja (bab 2.16) adalah perkakas yang Anda pakai di sini, tetapi mereka bukan pengganti perencanaan, dan mengiranya perencanaan adalah kesalahan umum dan mahal.

Bagi tim besar, kapasitas berhenti menjadi spreadsheet yang disimpan satu insinyur dan menjadi model bersama yang bergantung banyak layanan. Platform ratusan layanan berbagi kolam terbatas: koneksi basis data, throughput broker pesan, kuota akun cloud, egress jaringan. Pertumbuhan satu tim dapat membuat tim lain kelaparan jika tak ada yang memegang gambaran utuh. Dalam pengaturan enterprise, galat kapasitas tampak sebagai juta-juta terbuang pada infrastruktur menganggur atau pemadaman memalukan pada saat paling penting. Di pemerintah, taruhannya makin tajam. Tenggat pajak, jendela pendaftaran tunjangan, atau kampanye registrasi kesehatan publik memusatkan permintaan satu bangsa ke beberapa jam, beban diwajibkan hukum alih-alih opsional, dan publik mengingat situs yang ambruk di bawah tenggat yang ditetapkannya sendiri. Perencanaan kapasitas adalah cara Anda menepati janji itu.

Prinsip utama

Rencanakan kapasitas untuk permintaan yang diperkirakan ditambah ruang kepala yang disengaja; jangan berjalan mendekati saturasi.
Pisahkan perencanaan kapasitas, autoscaling, dan rekayasa kinerja; masing-masing menyelesaikan masalah berbeda.
Perkirakan dari tren, musiman, peristiwa yang diketahui, dan pertumbuhan bisnis, bukan dari minggu lalu saja.
Temukan batas nyata Anda lewat pengujian beban dan tolok ukur, bukan dengan menebak atau menunggu produksi menemukannya.
Perlakukan latensi mendekati saturasi sebagai tebing, bukan lereng; target pemanfaatan ada karena teori antrean.
Ketahui bottleneck keras Anda: kolam koneksi, kuota, dan titik tunggal tidak berautoscale.
Seimbangkan biaya terhadap keandalan dengan sengaja, dan tinjau kapasitas pada irama reguler alih-alih setelah insiden.

Rekomendasi

Pisahkan perencanaan kapasitas, autoscaling, dan rekayasa kinerja

Ketiga disiplin ini sering dikacaukan, dan mengacaukannya menyebabkan membeli perbaikan yang salah. Perencanaan kapasitas adalah pertanyaan menengah-hingga-panjang tentang berapa total sumber daya yang harus Anda sediakan, reservasi, dan anggarkan selama minggu, kuartal, dan tahun. Autoscaling adalah penyesuaian otomatis jangka pendek sumber daya untuk mengikuti beban menit demi menit: ia menggerakkan Anda dalam amplop yang disediakan perencanaan, tetapi tidak dapat menyulap kuota yang tak pernah Anda reservasi, menghangatkan basis data dingin, atau menskalakan komponen yang hanya berjalan sebagai instans tunggal. Rekayasa kinerja (bab 2.16) mengubah bentuk masalah dengan membuat setiap unit kerja lebih murah, sehingga perangkat keras yang sama melayani lebih banyak permintaan.

Perbedaannya praktis. Ketika sistem lambat di bawah beban, autoscaling menambah instans, rekayasa kinerja membuat setiap instans lebih cepat, dan perencanaan kapasitas memutuskan apakah Anda mampu membayar instans dan apakah basis data hilir dapat menerima koneksi yang akan mereka buka. Tim yang hanya meraih autoscaling akan menabrak batas keras yang tak direncanakannya; tim yang hanya meraih rekayasa kinerja akan mengoptimalkan kode sementara kuota akun membatasi mereka bagaimanapun. Anda butuh ketiganya, dan Anda perlu tahu mana yang dibutuhkan masalah tertentu.

Perkirakan permintaan dari tren, musiman, peristiwa, dan pertumbuhan bisnis

Perkiraan yang dibangun di atas rata-rata minggu lalu akan melewatkan setiap momen menarik. Bangun milik Anda dari empat komponen berbeda. Tren adalah arah mendasar: apakah permintaan tumbuh, datar, atau menyusut, dan seberapa cepat? Musiman adalah pola berulang: puncak harian pukul 9 pagi, jeda mingguan di akhir pekan, lonjakan tahunan sebelum liburan. Lonjakan digerakkan peristiwa adalah konsentrasi sekali jalan: peluncuran produk, kampanye pemasaran, sebutan di televisi, tenggat pengajuan pemerintah. Pertumbuhan digerakkan bisnis adalah permintaan yang diciptakan peta jalan Anda sendiri: pasar baru, onboarding pelanggan besar, fitur yang melipattigakan permintaan per sesi.

Pakai teknik yang tepat untuk masing-masing. Deret waktu beban historis, didekomposisi menjadi tren dan musiman, memberi Anda baseline yang dapat dipertahankan untuk permintaan stabil. Peristiwa tak dapat diekstrapolasi dari riwayat karena tak punya riwayat; mereka datang dari berbicara dengan bisnis, membaca peta jalan, dan bertanya kepada pemasaran dan produk apa yang akan mereka luncurkan. Kegagalan kapasitas paling merusak hampir selalu peristiwa yang tak pernah didengar rekayasa. Obatnya organisasi, bukan statistik: kanal tetap tempat produk, pemasaran, dan operasi mendeklarasikan lonjakan mendatang cukup jauh di muka untuk disediakan.

Tetapkan target pemanfaatan dan hormati tebing teori antrean

Naluri menjalankan infrastruktur “panas” pada pemanfaatan 90% untuk menghemat uang adalah jebakan, dan alasannya teori antrean, dibahas mendalam di bab 11.3. Saat sumber daya mendekati pemanfaatan penuh, waktu tunggu tidak naik lembut dan linear; ia meledak. Server pada pemanfaatan 50% punya ruang kepala nyaman; server yang sama pada 90% dapat melihat latensi beberapa kali lebih buruk, dan pada 95% antrean dapat lepas kendali sepenuhnya. Latensi mendekati saturasi adalah tebing, bukan lereng, dan pengguna Anda merasakan tebing itu sebagai timeout, retry, dan galat jauh sebelum sumber daya secara teknis “penuh.”

Inilah mengapa perencana kapasitas menetapkan target pemanfaatan jauh di bawah 100%, umumnya dalam rentang 50% hingga 70% untuk layanan peka latensi, lebih tinggi untuk kerja batch berorientasi throughput yang menoleransi antrean. Target bukan pemborosan; ia harga latensi yang dapat diprediksi. Pilih target dari SLO: jika tujuan latensi Anda ketat, plafon pemanfaatan Anda lebih rendah, karena latensi ekor yang dihasilkan antrean persis yang menghancurkan SLO. Ruang kepala dan margin keselamatan adalah gagasan yang sama dari dua arah. Ruang kepala adalah celah antara beban normal dan kapasitas; margin keselamatan adalah celah itu diekspresikan sebagai asuransi terhadap perkiraan yang tinggi, failover yang memusatkan beban, atau lonjakan yang tak Anda lihat datang.

Temukan batas nyata lewat pengujian beban dan tolok ukur

Anda tak dapat merencanakan di sekitar batas yang belum Anda ukur. Pengujian beban mengarahkan lalu lintas sintetis atau terputar ulang ke sistem untuk mengamati bagaimana latensi, throughput, dan tingkat galat berperilaku seiring beban naik, dan di mana mereka patah. Tolok ukur mengukur komponen secara terisolasi untuk menetapkan langit-langitnya: permintaan per detik per instans, penulisan per detik per node basis data, pesan per detik per partisi broker. Bersama-sama keduanya memberi tahu dua angka yang dibutuhkan perencanaan: seberapa banyak yang diberikan satu unit kapasitas, dan di mana seluruh sistem jatuh.

Jalankan beberapa uji berbeda. Uji beban menanjak ke puncak yang diharapkan dan memastikan SLO bertahan dengan ruang kepala. Uji stres mendorong melampaui titik patah untuk melihat bagaimana sistem gagal, karena sistem yang terdegradasi anggun sangat berbeda dari yang runtuh. Uji rendam menahan beban sedang berjam-jam atau berhari-hari untuk mengungkap kebocoran memori, kehabisan koneksi, dan masalah disk penuh yang hanya muncul seiring waktu. Uji lonjakan menghantam beban tiba-tiba untuk memeriksa apakah autoscaling dan buffer menyerapnya sebelum pengguna menyadari. Uji terhadap data dan topologi mirip-produksi, karena batas yang diukur pada dataset mainan berbohong. Jalankan ulang uji ini ketika sistem berubah, agar angka Anda mendeskripsikan sistem yang Anda punya, bukan yang Anda punya setahun lalu.

Pilih strategi penyediaan dengan sengaja

Penyedia cloud memungkinkan Anda membeli kapasitas yang sama dengan cara yang menukar harga dengan fleksibilitas, dan memadukannya dengan baik adalah tempat uang nyata dihemat. Kapasitas on-demand fleksibel dan mahal: Anda membayar tarif penuh untuk kemampuan memulai dan menghentikan kapan saja, yang cocok untuk beban tak terduga dan berumur pendek. Kapasitas reservasi (komitmen satu atau tiga tahun, atau savings plan) lebih murah per unit dengan imbalan janji terus memakainya, yang cocok untuk baseline stabil Anda. Instans spot menjual kapasitas cadangan dengan diskon dalam tetapi dapat direklamasi dengan sedikit peringatan, yang cocok untuk kerja toleran-kegagalan dan dapat diinterupsi seperti pemrosesan batch dan pekerja tanpa status.

Pola yang berhasil berlapis. Tutup baseline stabil Anda dengan kapasitas reservasi untuk biaya satuan terendah, serap variasi harian dan mingguan dengan autoscaling on-demand, dan dorong kerja batch yang dapat diinterupsi ke spot untuk memanen diskon. Simpan kolam buffer hangat kapasitas yang disediakan sebelumnya untuk layanan yang tak dapat menoleransi penundaan cold-start penskalaan dari nol, agar lonjakan mendadak bertemu kapasitas siap alih-alih antrean sementara instans baru menyala. Perpaduan yang tepat adalah keputusan portofolio, dan ia bergeser seiring bentuk permintaan Anda dan harga penyedia berubah, jadi tinjau ulang.

Petakan bottleneck keras yang tidak berautoscale

Autoscaling melahirkan keyakinan berbahaya, karena banyak batas berada di hilir dari yang berskala dan tidak bergerak ketika ia bergerak. Kolam koneksi basis data adalah contoh klasik: skalakan tingkat tanpa status Anda dari 10 ke 100 instans dan masing-masing membuka koneksi ke basis data yang sama, yang punya batas keras koneksi bersamaan dan akan mulai menolak yang baru. Akun cloud membawa kuota pada hampir segalanya: instans per wilayah, alamat IP, panggilan API per detik, konkurensi fungsi. Setiap titik tunggal arsitektur, basis data primer, node pemimpin, cache bersama, appliance berlisensi, adalah langit-langit yang tak dapat dinaikkan penskalaan horizontal di tempat lain.

Jadikan ini eksplisit. Simpan inventaris tertulis setiap batas keras antara permintaan dan responsnya: ukuran kolam, nilai kuota, komponen instans tunggal, batas laju pihak ketiga, jumlah kursi lisensi. Untuk masing-masing, catat nilai saat ini, pemakaian saat ini, dan beban di mana ia mengikat. Inventaris ini adalah beda antara rencana kapasitas yang mendeskripsikan seluruh sistem dan yang hanya mendeskripsikan bagian mudah dan elastis sementara kolam koneksi diam-diam menunggu mengakhiri peluncuran Anda. Naikkan kuota sebelum dibutuhkan, karena peningkatan kuota penyedia dapat memakan berhari-hari untuk disetujui.

Sediakan untuk peristiwa puncak, bukan hanya rata-rata

Rata-rata menyembunyikan momen yang penting. Sistem yang ditakar untuk beban rata-rata akan gagal pada puncak, dan bagi banyak organisasi puncak adalah seluruh maksudnya: lonjakan ritel pada hari belanja terbesar, lonjakan streaming pada final langsung, portal pajak pada tenggat pengajuan, situs tunjangan ketika pendaftaran dibuka. Rencanakan peristiwa bernama ini secara individual. Perkirakan puncak dari bisnis (pengguna bersamaan yang diharapkan, permintaan per sesi, kelipatan di atas hari normal), sediakan hingga puncak itu dengan ruang kepala, uji beban pada tingkat itu, dan tahapkan kapasitas sebelum peristiwa alih-alih berebut selama itu.

Perlakukan peluncuran atau tenggat sebagai peristiwa operasional dengan runbook. Hangatkan cache dan kolam buffer terlebih dulu, naikkan kuota di muka, bekukan deployment berisiko selama jendela, dan taruh manusia on-call yang dapat bertindak jika perkiraan ternyata rendah. Setelah peristiwa, tangkap puncak aktual dan seberapa dekat Anda mencapai batas, karena angka itu masukan terbaik untuk rencana tahun depan. Tenggat pemerintah layak perhatian khusus: ia ditetapkan sendiri, diketahui publik, dan tak dapat digeser, jadi tak ada alasan untuk terkejut dan tak ada cara bersembunyi ketika Anda terkejut.

Instrumentasi kapasitas dan tinjau pada irama

Perencanaan kapasitas berjalan dengan data, dan data datang dari observabilitas bab 9.2. Lacak pemanfaatan setiap sumber daya terkendala (CPU, memori, disk, jaringan, kolam koneksi, kedalaman antrean) terhadap batasnya, agar Anda dapat melihat ruang kepala menyusut sebelum ia lenyap. Awasi sinyal saturasi langsung: panjang antrean, waktu tunggu, dan tingkat penolakan mengungkap tebing antrean yang mendekat. Tren ini selama berminggu-minggu untuk memproyeksikan kapan sumber daya akan menyentuh langit-langitnya pada laju pertumbuhan saat ini, dan beri peringatan atas proyeksi alih-alih nilai saat ini saja, agar Anda menyediakan sebelum dinding alih-alih di dalamnya.

Selenggarakan tinjauan kapasitas pada irama reguler, bulanan atau kuartalan, alih-alih hanya setelah insiden. Dalam setiap tinjauan, bandingkan perkiraan dengan permintaan aktual dan koreksi model, telusuri inventaris batas keras dan periksa ruang kepala terhadap masing-masing, lihat peristiwa mendatang dan rencana bisnis, dan putuskan apa yang direservasi, dinaikkan, atau dipensiunkan. Simpan model kapasitas hidup: dokumen atau spreadsheet sederhana yang memetakan pendorong permintaan ke kebutuhan sumber daya, agar siapa pun dapat bertanya “apa yang terjadi pada basis data jika lalu lintas berlipat dua” dan mendapat jawaban dari model alih-alih pemadaman. Model tak pernah sempurna, tetapi model tertulis yang dikoreksi rutin mengalahkan intuisi setiap saat.

Trade-off: kelebihan dan kekurangan

Pendekatan	Kelebihan	Kekurangan
Target pemanfaatan tinggi	Biaya per unit lebih rendah; kapasitas menganggur lebih sedikit	Latensi meledak mendekati saturasi; tak ada ruang untuk lonjakan atau failover
Ruang kepala murah hati	Latensi dapat diprediksi; menyerap lonjakan dan failover	Biaya mapan lebih tinggi; dapat menyembunyikan ketidakefisienan
Kapasitas reservasi	Harga satuan terendah untuk baseline stabil	Risiko komitmen jika permintaan turun atau bergeser
Kapasitas on-demand	Fleksibel; mencocokkan beban variabel menit demi menit	Harga satuan tertinggi; dapat mengejutkan anggaran
Instans spot	Diskon dalam untuk kerja yang dapat diinterupsi	Direklamasi tanpa pemberitahuan; tak cocok untuk kerja berstatus atau kritis latensi
Autoscaling	Melacak beban otomatis dalam amplop	Tak dapat melampaui kuota reservasi; cold start; menutupi batas hilir
Kolam buffer (kapasitas hangat)	Menyerap lonjakan mendadak seketika	Membayar kapasitas menganggur di antara lonjakan

Ketegangan sentralnya antara biaya dan keandalan, dan tak ada pengaturan yang mengoptimalkan keduanya. Jalankan ramping dan Anda menghemat uang sampai hari ketika lonjakan bertemu sumber daya jenuh dan latensi jatuh dari tebing antrean. Jalankan murah hati dan Anda tidur nyenyak sambil membayar ruang kepala yang menganggur sebagian besar waktu. Selesaikan ketegangan dengan SLO alih-alih ketakutan atau kehematan. Sediakan ruang kepala cukup untuk memenuhi target keandalan melalui puncak yang diperkirakan ditambah margin, dan tidak lebih, lalu biarkan FinOps (operasi keuangan untuk pengeluaran cloud, bab 9.4) memburu pemborosan yang tidak membela SLO. Tujuannya keseimbangan sengaja: setiap dolar ruang kepala dibeli dengan sengaja untuk membeli sejumlah keandalan yang diketahui, dan setiap dolar pemborosan dihilangkan dengan sengaja karena tak membeli apa-apa.

Pertanyaan untuk didiskusikan dengan tim Anda

Apakah kita benar-benar tahu beban di mana setiap bottleneck keras kita mengikat, atau kita mengasumsikan autoscaling akan menyelamatkan kita? Sebagian besar tim dapat memberi tahu instans mereka berautoscale, dan sebagian besar tak dapat memberi tahu batas koneksi bersamaan pada basis data primer mereka, batas laju API pihak ketiga terpenting mereka, atau kuota akun yang membatasi konkurensi fungsi mereka. Itulah batas yang mengakhiri peluncuran, dan mereka tidak bergerak ketika tingkat tanpa status berskala. Bawa inventaris tertulis batas keras jika ada, dan jika tidak, ketiadaan itu adalah temuannya. Untuk setiap batas, Anda ingin tiga angka: langit-langit, pemakaian hari ini, dan tingkat permintaan di mana keduanya bertemu. Di mana pun Anda tak dapat menghasilkan ketiganya, Anda punya bottleneck yang dikelola dengan harapan.
Kapan terakhir kita menguji beban hingga tingkat puncak mendatang terburuk kita, pada data mirip-produksi, dan apakah SLO bertahan dengan ruang kepala? Rencana kapasitas adalah sekumpulan klaim tentang bagaimana sistem berperilaku di bawah beban, dan klaim tak teruji adalah tebakan berjas. Puncak yang penting bukan rata-rata bulan lalu tetapi peluncuran, liburan, atau tenggat berikutnya, dan uji hanya bermakna jika data dan topologi menyerupai produksi, karena batas yang diukur pada dataset mainan berbohong. Bawa hasil uji stres dan rendam terbaru Anda, termasuk di mana sistem patah dan bagaimana ia gagal ketika patah. Jika jawaban jujurnya Anda tak pernah mendorong sistem ke titik patahnya dengan sengaja, maka Anda akan menemukan titik itu di produksi, pada waktu terburuk, dengan pengguna menonton.
Bagaimana produk, pemasaran, dan operasi memberi tahu rekayasa tentang lonjakan sebelum terjadi, dan seberapa jauh di muka? Kegagalan kapasitas paling mahal bukan galat pemodelan; mereka peristiwa yang tak pernah didengar rekayasa sampai lalu lintas tiba. Perkiraan dapat mengekstrapolasi tren dan musiman dari riwayat, tetapi peristiwa tak punya riwayat, jadi ia hanya dapat datang dari orang yang merencanakannya. Bawa tiga lonjakan permintaan terakhir dan tanyakan, untuk masing-masing, berapa hari peringatan yang didapat rekayasa dan apakah itu cukup untuk mereservasi kapasitas dan menguji beban. Bukti yang Anda inginkan adalah kanal tetap dengan lead time cukup panjang untuk disediakan, karena peningkatan kuota cloud saja dapat memakan berhari-hari. Jika kanal itu tidak ada, rencana kapasitas Anda buta terhadap persis momen yang ada untuk dilindunginya.
Target pemanfaatan apa yang sebenarnya dijalankan setiap layanan peka latensi, dan dapatkah kita menelusuri angka itu kembali ke SLO-nya alih-alih ke target biaya? Ini penting karena tekanan menjalankan infrastruktur panas konstan dan datang dari bagian organisasi yang melihat tagihan tetapi bukan tebing antrean, jadi kecuali target dituliskan dan dibenarkan dari tujuan latensi, ia melayang naik sampai lonjakan menemukan tepinya. Pertimbangan yang bersaing adalah uang nyata di satu sisi dan latensi ekor di sisi lain, dan posisi jujurnya adalah ruang kepala di bawah 100% adalah harga latensi yang dapat diprediksi, bukan pemborosan untuk dipangkas. Bawa pemanfaatan saat ini dari beberapa layanan teratas Anda, SLO yang dibela masing-masing, dan latensi yang Anda ukur pada pemanfaatan itu di bawah beban, agar ruangan berargumen dari bukti alih-alih naluri. Dalam platform enterprise atau pemerintah di mana satu kolam bersama menopang banyak layanan, sepakati target secara terpusat dan catat siapa yang boleh mengubahnya, karena satu tim yang diam-diam menaikkan plafonnya dapat mendorong sumber daya yang diandalkan yang lain melewati tebing untuk semua orang.
Apa perpaduan kapasitas reservasi, on-demand, dan spot kita, kapan terakhir kita meninjaunya, dan apakah ia masih cocok dengan bentuk permintaan kita? Perpaduan adalah tempat penghematan berkelanjutan terbesar dan pemborosan berkelanjutan terbesar bersembunyi, karena baseline stabil yang dibayar pada tarif on-demand membakar uang setiap jam sementara posisi reservasi yang terlalu berkomitmen membayar kapasitas yang telah dilampaui permintaan atau turun di bawahnya. Ketegangannya biaya melawan fleksibilitas dan risiko komitmen: kapasitas reservasi termurah per unit tetapi mengunci Anda, spot lebih murah lagi tetapi dapat direklamasi tanpa pemberitahuan, dan on-demand membeli kebebasan dengan premi. Bawa pembagian saat ini menurut biaya, kurva permintaan yang dimaksudkan untuk ditutupnya, dan tingkat reklamasi serta radius ledakan beban kerja spot mana pun, agar ruangan dapat melihat apakah kerja yang dapat diinterupsi benar-benar dapat diinterupsi. Dalam pengaturan enterprise dan pemerintah, kaitkan komitmen reservasi dengan siklus pengadaan dan anggaran, karena komitmen multitahun dan savings plan adalah kewajiban finansial yang akan ingin dibenarkan keuangan dan audit terhadap permintaan yang diperkirakan, bukan terhadap kenyamanan kuartal lalu.
Ketika peristiwa puncak bernama akan datang, siapa yang memiliki pemanasan awal, kenaikan kuota, pembekuan deployment, dan keputusan go/no-go, dan apakah itu tertulis sebagai runbook yang telah kita latih? Peristiwa puncak adalah momen yang ada untuk dilindungi perencanaan kapasitas, dan mereka paling sering gagal bukan karena rencana salah tetapi karena tak ada yang akuntabel menjalankannya di bawah tekanan pada hari itu. Pertimbangan yang bersaing di sini adalah kecepatan dan otonomi melawan koordinasi: tim ingin terus mengirim, namun deployment berisiko selama jendela lonjakan dapat membatalkan berbulan-bulan penyediaan, jadi seseorang harus memegang wewenang membekukan dan menghentikan peluncuran. Bawa runbook untuk peristiwa besar berikutnya, lead time untuk kenaikan kuota dan pemanasan kolam buffer, dan catatan siapa yang memegang setiap peran terakhir kali dan apakah serah terima bertahan. Untuk tenggat pemerintah yang ditetapkan sendiri, diketahui publik, dan tak dapat digeser, namai pemilik akuntabel dan jalur eskalasi secara eksplisit, karena tak ada opsi membuang beban atau meminta warga kembali nanti, dan puncak yang tak dimiliki siapa pun adalah puncak yang tak akan dibela siapa pun ketika tiba.

Lensa sektor

Startup. Sumber daya Anda yang paling langka adalah perhatian rekayasa, jadi jaga perencanaan kapasitas murah dan ramping serta bersandarlah pada elastisitas penyedia cloud untuk variasi harian. Satu hal yang tak boleh Anda lewati adalah daftar tertulis batas keras yang tidak berautoscale: batas koneksi basis data primer Anda, batas laju pihak ketiga terpenting Anda, dan kuota akun yang akan Anda tabrak di bawah lonjakan fitur atau pers mendadak. Uji beban hingga beberapa kali puncak normal Anda pada data berukuran produksi sebelum lonjakan nyata pertama Anda, karena keyakinan rapuh yang diberikan autoscaling adalah persis yang patah ketika basis data menolak koneksi.

Bisnis kecil. Anda tidak punya spesialis kapasitas dan anggaran ketat, jadi perlakukan ini sebagai masalah beli-dan-konfigurasi alih-alih proyek pemodelan. Pilih layanan terkelola yang menyerap penskalaan untuk Anda, tetapkan peringatan pengeluaran dan dasbor pemanfaatan sederhana agar tagihan liar atau sumber daya jenuh terlihat lebih awal, dan ketahui beberapa peristiwa bernama (kesibukan musiman, pelanggan besar go-live) yang akan mendefinisikan tahun Anda. Reservasi kapasitas untuk baseline stabil Anda untuk memotong tagihan, dan tolak membangun mesin peramalan yang tak dapat Anda pelihara ketika bentuk permintaan nyaris tak bergerak.

Enterprise. Masalahnya kolam bersama terbatas di belakang ratusan layanan, sehingga kapasitas menjadi tata kelola portofolio: inventaris batas keras yang dipelihara, target pemanfaatan diturunkan secara terpusat dari SLO, dan perpaduan sengaja kapasitas reservasi, on-demand, dan spot yang ditinjau ulang terhadap harga langsung. Bakukan uji beban, stres, rendam, dan lonjakan agar setiap tim mengukur dengan cara sama pada data mirip-produksi, dan jalankan tinjauan kapasitas pada irama yang menangkap ruang kepala menyusut sebelum insiden melakukannya. Anggarkan koordinasi secara eksplisit, karena pertumbuhan satu tim dapat membuat tim lain kelaparan ketika tak ada yang memegang model utuh.

Pemerintah. Permintaan sering terpusat secara hukum ke tenggat yang tak dapat digeser dan diketahui publik, jadi rencanakan untuk puncak bernama itu secara spesifik dan sediakan margin keselamatan lebar, karena Anda tak dapat membuang beban atau meminta warga kembali nanti. Aturan pengadaan membentuk penyediaan: komitmen reservasi multitahun dan kesepakatan kuota vendor harus dibenarkan terhadap permintaan yang diperkirakan dan selamat dari audit, jadi simpan perkiraan, bukti uji beban, dan inventaris batas keras terdokumentasi dan dapat dipertahankan. Terbitkan ekspektasi realistis di mana bisa, naikkan batas penyedia jauh sebelum jendela, dan catat puncak sebenarnya setiap siklus, karena akuntabilitas publik berarti portal yang ambruk di bawah tenggat yang ditetapkannya sendiri adalah kegagalan yang dilihat seluruh negeri.

Contoh

Startup. Startup sepuluh orang menjalankan aplikasi konsumen pada infrastruktur cloud berautoscale dan merasa aman karena jumlah instans tumbuh bersama beban. Fitur televisi pertama mereka melipattigakan lalu lintas dalam sejam, tingkat tanpa status berskala indah, dan aplikasi tetap jatuh: setiap instans baru membuka koneksi basis data sampai basis data mencapai batas koneksinya dan mulai menolaknya. Pelajaran itu membentuk ulang praktik mereka. Mereka menambah connection pooler di depan basis data, menuliskan setiap batas keras antara permintaan dan respons, dan menguji beban hingga beberapa kali puncak normal pada dataset berukuran produksi. Mereka menutup baseline stabil dengan komitmen kapasitas reservasi untuk diskon dan menyimpan kolam buffer hangat kecil agar lonjakan berikutnya bertemu kapasitas siap. Perubahan itu memakan seminggu dan mengubah keyakinan rapuh mereka menjadi rencana yang dapat mereka pertahankan.

Enterprise. Sebuah pengecer global memperlakukan hari obral terbesarnya sebagai peristiwa kapasitas tahun itu. Berbulan-bulan sebelumnya, tim lintas fungsi membangun perkiraan permintaan dari tren dan musiman tahun-tahun sebelumnya plus rencana merchandising, menerjemahkan perkiraan menjadi kebutuhan sumber daya lewat model kapasitas, dan menyediakan hingga puncak yang diproyeksikan dengan ruang kepala murah hati. Mereka menguji beban, stres, rendam, dan lonjakan seluruh jalur pada data mirip-produksi, menaikkan setiap kuota cloud relevan berminggu-minggu di muka, menghangatkan cache dan kolam buffer terlebih dulu, dan membekukan deployment berisiko untuk jendela sekitarnya. Kapasitas reservasi menutup baseline stabil demi biaya, autoscaling on-demand menyerap kurva harian, dan kerja batch yang dapat diinterupsi berjalan di spot. Observabilitas melacak setiap sumber daya terkendala terhadap batasnya secara real-time selama peristiwa, dengan peringatan atas saturasi yang diproyeksikan alih-alih nilai saat ini. Hari itu berlalu tanpa drama, yang persis hasil yang dibeli perencanaan.

Pemerintah. Sebuah otoritas pajak nasional menjalankan portal pengajuan yang permintaannya terpusat secara hukum ke hari-hari sebelum tenggat yang tak dapat digeser, ketika seluruh negara mengajukan sekaligus. Lembaga merencanakan untuk puncak itu secara spesifik alih-alih untuk rata-rata tahunan yang tak bermakna. Ia memperkirakan pengaju bersamaan dari tahun-tahun sebelumnya dan data penduduk, menyediakan hingga puncak itu dengan margin keselamatan lebar karena tak ada opsi membuang beban atau meminta warga kembali nanti, dan menguji beban hingga konkurensi yang diproyeksikan pada data realistis. Tim menyimpan inventaris tertulis setiap kuota dan titik kegagalan tunggal, menaikkan batas dengan penyedia jauh sebelum jendela, dan menetapkan target pemanfaatan cukup rendah agar tebing antrean tetap jauh dari lonjakan tenggat. Setelah setiap musim pengajuan mereka mencatat puncak sebenarnya dan seberapa banyak ruang kepala tersisa, memberi makan model tahun depan. Publik melihat portal yang tetap hidup pada hari yang dirancang untuknya, yang seluruh maksud janji institusi itu.

Kasus bisnis: motivasi, ROI, dan TCO

Imbal hasil perencanaan kapasitas tampak sebagai dua biaya yang dihindari yang menarik ke arah berlawanan, yang membuat disiplin ini berharga. Penyediaan kurang berbiaya pemadaman, dan pemadaman selama peristiwa puncak paling mahal: pendapatan hilang, transaksi hilang, dan kerusakan reputasi persis ketika audiens terbesar. Situs ritel yang mati pada hari terbesarnya atau portal pemerintah yang runtuh pada tenggat pengajuannya membayar bertahun-tahun perencanaan dalam satu jam buruk. Penyediaan berlebih berbiaya sebaliknya, dalam tagihan cloud untuk kapasitas yang menganggur, dan pada skala enterprise beberapa poin penyediaan berlebih kronis di seluruh armada mencapai jutaan dolar per tahun. Perencanaan kapasitas adalah praktik yang menemukan tengah yang disengaja: cukup untuk membela SLO melalui puncak, tidak lebih.

Biaya adopsi sebagian besar disiplin alih-alih perkakas. Anda membangun perkiraan permintaan, menuliskan batas keras Anda, menjalankan uji beban pada irama, memadukan strategi penyediaan Anda, dan menyelenggarakan tinjauan kapasitas reguler. Total biaya kepemilikan (TCO) membaik dari kedua sisi sekaligus: lebih sedikit insiden digerakkan kapasitas menurunkan biaya downtime dan respons darurat, dan penyesuaian ukuran berkelanjutan plus perpaduan reservasi-dan-spot yang masuk akal menurunkan tagihan infrastruktur mapan. Untuk mengajukan kasus kepada pimpinan, hubungkan kapasitas dengan angka yang sudah mereka awasi. Kaitkan penyediaan kurang dengan pendapatan hilang per jam downtime puncak dan dengan pelanggaran SLO dengan penalti kontraktual, dan kaitkan penyediaan berlebih dengan laporan pemborosan FinOps dari bab 9.4. Argumennya bukan kehati-hatian abstrak; ia uang di kedua sisi tombol yang dapat Anda setel dengan sengaja.

Anti-pola dan jebakan

Autoscaling sebagai rencana: memercayai instans elastis sementara kolam koneksi basis data, kuota akun, atau titik tunggal diam-diam membatasi seluruh sistem.
Berjalan panas untuk menghemat uang: menargetkan pemanfaatan 90% ke atas dan bertemu tebing antrean, di mana latensi meledak dan SLO patah.
Rata-rata alih-alih puncak: menakar untuk beban rata-rata sehingga sistem gagal persis pada peristiwa puncak yang membenarkan pembangunannya.
Meramal dari riwayat saja: mengekstrapolasi tren dan musiman sambil melewatkan peluncuran atau kampanye yang tak pernah diberi tahu kepada rekayasa.
Batas tak teruji: merencanakan di sekitar titik patah yang tak diukur siapa pun, lalu menemukannya di produksi pada saat terburuk.
Uji beban data mainan: mengukur kapasitas pada data dan topologi tak realistis, menghasilkan angka yang berbohong tentang sistem nyata.
Tanpa inventaris batas keras: mengelola kuota, kolam, dan titik tunggal lewat ingatan dan harapan alih-alih daftar tertulis yang dipelihara.
Reservasi-semua atau reservasi-nihil: terlalu berkomitmen pada kapasitas reservasi yang dilampaui atau diturunkan di bawah oleh permintaan, atau membayar tarif on-demand penuh untuk baseline stabil.
Tinjauan kapasitas hanya setelah insiden: memperlakukan perencanaan sebagai pemadaman kebakaran reaktif alih-alih irama reguler yang menyediakan sebelum dibutuhkan.

Model kematangan

Tingkat 1, Memulai: Kapasitas reaktif dan ad hoc. Tim menambah sumber daya setelah habis, memercayai autoscaling menangani segalanya, dan tak punya perkiraan, inventaris batas keras, dan pengujian beban. Peristiwa puncak dihadapi dengan harapan, dan pemadaman selama peluncuran dan tenggat diperlakukan sebagai nasib buruk.
Tingkat 2, Mengembangkan: Praktik dasar muncul tetapi bervariasi menurut tim. Sebagian pemantauan menunjukkan pemanfaatan, sebagian pengujian beban terjadi sebelum peristiwa besar, kuota utama diketahui, dan perkiraan kasar ada di beberapa tempat, tetapi model tak dipelihara, bottleneck hilir sering terlewat, dan ruang kepala ditetapkan dengan aturan praktis alih-alih dari SLO.
Tingkat 3, Membakukan: Perencanaan kapasitas adalah disiplin terdokumentasi yang ditegakkan di seluruh organisasi. Perkiraan permintaan memadukan tren, musiman, peristiwa, dan pertumbuhan bisnis; inventaris batas keras tertulis dipelihara; target pemanfaatan diturunkan dari SLO; uji beban, stres, rendam, dan lonjakan berjalan pada irama terhadap data mirip-produksi; dan penyediaan memadukan reservasi, on-demand, dan spot dengan sengaja. Kanal tetap membawa peringatan peristiwa dari produk dan pemasaran ke rekayasa.
Tingkat 4, Mengelola: Kapasitas diukur dan dikendalikan terhadap garis dasar. Perkiraan dibandingkan dengan permintaan aktual setiap siklus dan galatnya dilacak serta ditekan; pemanfaatan, sinyal saturasi, dan ruang kepala terhadap setiap batas keras ditren dan diberi peringatan sebagai proyeksi alih-alih nilai saat ini; peristiwa puncak ditinjau sesudahnya terhadap puncak teramati sebenarnya; dan perpaduan penyediaan, cakupan komitmen reservasi, dan biaya-per-SLO dilaporkan sebagai metrik yang menggerbangi keputusan go atau no-go. Data, bukan intuisi, memutuskan apa yang direservasi, dinaikkan, atau dipensiunkan.
Tingkat 5, Mengorkestrasi: Perencanaan kapasitas terus diperbaiki dan terintegrasi di seluruh organisasi. Perkiraan divalidasi dan diperhalus secara otomatis, saturasi diproyeksikan dan disediakan sebelum tiba, perpaduan penyediaan dioptimalkan terhadap harga langsung, peristiwa puncak berjalan dari runbook terlatih, dan biaya serta keandalan diseimbangkan dengan sengaja terhadap SLO di seluruh platform. Model kapasitas adalah aset bersama dan adaptif yang menyeimbangkan ulang armada seiring bentuk permintaan dan harga penyedia bergeser.

Gagasan untuk didiskusikan

Apa target pemanfaatan Anda saat ini untuk layanan peka latensi, dan dapatkah Anda membenarkannya dari SLO dan perilaku antrean alih-alih dari keinginan menghemat uang?
Komponen Anda yang mana tidak dapat berautoscale sama sekali, dan apa yang terjadi pada sisa sistem ketika salah satunya jenuh?
Jika lalu lintas Anda berlipat dua kuartal depan, sumber daya mana yang menyentuh langit-langitnya lebih dulu, dan berapa hari lead time yang Anda butuhkan untuk menaikkannya?
Bagaimana Anda memutuskan perpaduan kapasitas reservasi, on-demand, dan spot, dan kapan terakhir Anda meninjaunya terhadap bentuk permintaan aktual Anda?
Ketika peristiwa puncak akan datang, siapa yang memiliki pemanasan awal, kenaikan kuota, dan keputusan go/no-go, dan apakah itu tertulis sebagai runbook?
Apakah peringatan kapasitas Anda menyala atas saturasi yang diproyeksikan berminggu-minggu di muka, atau hanya atas pemanfaatan saat ini ketika dinding sudah dekat?

Poin-poin utama

Perencanaan kapasitas mencocokkan pasokan dengan permintaan yang diperkirakan dengan ruang kepala sengaja; ia berbeda dari autoscaling (jangka pendek, dalam amplop) dan rekayasa kinerja (unit kerja lebih murah).
Perkirakan dari tren, musiman, peristiwa yang diketahui, dan pertumbuhan bisnis, dan dapatkan peringatan peristiwa dari produk dan pemasaran, karena peristiwa tak punya riwayat untuk diekstrapolasi.
Hormati tebing teori antrean (bab 11.3): latensi meledak mendekati saturasi, jadi tetapkan target pemanfaatan dari SLO Anda dan pegang ruang kepala nyata.
Temukan batas lewat pengujian beban, stres, rendam, dan lonjakan pada data mirip-produksi, dan simpan inventaris tertulis bottleneck keras yang tidak berautoscale.
Padukan kapasitas reservasi, on-demand, dan spot dengan kolam buffer hangat, rencanakan peristiwa puncak bernama secara individual, dan tinjau kapasitas pada irama alih-alih setelah pemadaman.

Referensi dan bacaan lanjutan

Betsy Beyer, Chris Jones, Jennifer Petoff, dan Niall Richard Murphy (ed.), Site Reliability Engineering: How Google Runs Production Systems
Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, dan Stephen Thorne (ed.), The Site Reliability Workbook: Practical Ways to Implement SRE
John Allspaw, The Art of Capacity Planning: Scaling Web Resources in the Cloud
Neil J. Gunther, Guerrilla Capacity Planning: A Tactical Approach to Planning for Highly Scalable Applications and Services
Martin L. Abbott dan Michael T. Fisher, The Art of Scalability: Scalable Web Architecture, Processes, and Organisations for the Modern Enterprise
Brendan Gregg, Systems Performance: Enterprise and the Cloud
Leonard Kleinrock, Queueing Systems, Volume 1: Theory
J. R. Storment dan Mike Fuller, Cloud FinOps: Collaborative, Real-Time Cloud Financial Management