Kalkulator Sumber Daya VPS

Bukan nama paket, tapi karakter beban

Saat memilih VPS, nama paket mudah menipu. “Basic”, “standard”, “premium”, “general purpose”… Kedengarannya bagus. Tetapi tidak satu pun dari nama-nama itu sendirian bisa memberi tahu berapa banyak RAM yang akan dimakan situs, kapan CPU akan kewalahan, atau pada hari apa disk akan penuh.

Situs statis dan toko WooCommerce, meskipun memiliki pengunjung yang sama, tidak membutuhkan server yang sama. Di satu sisi, file siap saji; di sisi lain, ada keranjang, pembayaran, stok, sesi pengguna, query database, panel admin, dan kadang pekerjaan antrian yang berjalan di latar belakang. Perbedaannya justru di sini.

Model perhitungan ini membaca VPS melalui empat sumber daya utama: vCPU, RAM, disk, dan trafik bulanan. Tetapi tidak mengambilnya sebagai angka mentah; ia mempertimbangkan jenis aplikasi, tingkat lingkungan, penggunaan cache/CDN, layanan yang berjalan di VPS yang sama, log, cadangan lokal, dan ruang pertumbuhan.

Tidak ada satu pun “rumus resmi VPS”. Lagipula, dalam dokumentasi penyedia cloud besar, masalahnya diperlakukan seperti ini: CPU, memori, jaringan, dan penyimpanan dipertimbangkan bersama; keluarga mesin juga dibedakan berdasarkan beban kerja. Mesin tujuan umum berbeda, mesin yang berat komputasi berbeda, mesin yang berat memori berbeda. Logika yang sama berlaku di sisi VPS, hanya saja dalam skala lebih kecil.

flowchart LR
  A["Jenis aplikasi"] --> E["Estimasi sumber daya"]
  B["Traffic dan cache"] --> E
  C["Database, worker, panel admin, Docker"] --> E
  D["Disk, log, backup, buffer pertumbuhan"] --> E
  E --> F["vCPU"]
  E --> G["RAM"]
  E --> H["Disk"]
  E --> I["Traffic bulanan"]

Kalimat yang paling tidak saya sukai dalam perhitungan semacam ini adalah: “2 vCPU sudah cukup.” Cukup untuk apa? Untuk situs statis, WooCommerce, Odoo, Node API, atau instalasi campuran di mana MySQL, Redis, mail, dan Docker berjalan di kotak yang sama? Selanjutnya, perbedaan antara CPU bersama dan CPU dedicated sering terlewat. Pada paket VPS kecil, CPU sering kali bersifat shared. Mungkin tidak menjadi masalah untuk situs web ringan. Tetapi pada sistem yang menjalankan worker secara teratur, menerima lonjakan trafik, menghasilkan laporan, atau sering membebani database, jumlah vCPU yang sama bisa terasa lebih lemah dari yang diharapkan.

Oleh karena itu, keluaran di sini bukanlah “rencana pasti”, melainkan perkiraan awal yang aman. Ini memberikan gambaran awal yang baik untuk pemilihan sumber daya. Dalam produksi, metrik yang berbicara terakhir: penggunaan CPU, konsumsi RAM, kepenuhan disk, trafik jaringan, query lambat, log error, antrian worker.

Di atas kertas berbeda, di server berbeda.

Dari mana kita mulai?

Perbedaan pertama dalam perhitungan berasal dari jenis aplikasi. Karena beban dasar setiap kelas aplikasi tidak sama.

Situs statis berada di sisi paling ringan. CPU dasar diasumsikan 1 vCPU, RAM dasar 1 GB; faktor CPU juga dijaga rendah, misalnya 0.2. Ini masuk akal. Karena di situs statis yang di-cache dengan baik, server biasanya menyajikan file siap pakai, lapisan aplikasi jarang bekerja.

Untuk WordPress/blog, titik awalnya naik: CPU dasar 1.5 vCPU, RAM dasar 2 GB, faktor CPU 1. WordPress memiliki basis PHP dan database. Dengan adanya tema, plugin, pemrosesan gambar, operasi admin, pencarian, komentar, ia tidak berperilaku seperti situs statis. Namun, dengan cache yang tepat, ia bisa sangat diringankan.

WooCommerce/e-commerce adalah kelas yang berbeda. Dalam model ini, CPU dasar diambil 2.5 vCPU, RAM dasar 4 GB, faktor CPU 2. Menurut saya, untuk e-commerce, pembedaan ini wajib. Karena WooCommerce menambahkan lapisan keranjang, pembayaran, pesanan, stok, dan keanggotaan di atas WordPress polos. Selain itu, beberapa halaman tidak cocok untuk cache penuh. Halaman produk bisa berasal dari cache, tetapi di sisi keranjang dan pembayaran, segalanya berubah.

Untuk aplikasi Laravel/PHP dan Node.js/API, CPU dasar 2 vCPU, RAM dasar 3 GB, faktor CPU 1.2. Di sini kebutuhan sebenarnya sangat bergantung pada kode. API sederhana bisa berjalan sangat ringan; aplikasi yang berbicara dengan layanan eksternal, terus memproses data, dan menggunakan antrian bisa jauh lebih berat di kelas yang sama.

Untuk SaaS kecil, CPU dasar 3 vCPU, RAM dasar 4 GB, faktor CPU 1.8. Sesi pengguna, pekerjaan latar belakang, notifikasi, laporan, dan trafik database biasanya datang bersamaan. Jumlah pengunjung mungkin terlihat sedikit, tetapi operasi dalam aplikasi banyak. Jika dilihat seperti situs web, paket yang salah akan dipilih.

Sistem seperti Odoo/ERP berada di sisi berat: CPU dasar 4 vCPU, RAM dasar 8 GB, faktor CPU 3. Dalam instalasi Odoo, perencanaan worker dan memori memang sudah dipikirkan secara terpisah. Pelaporan, sesi pengguna, modul, operasi database, dan tugas berdurasi panjang membedakan kelas ini dari situs blog normal.

Untuk game server, CPU dasar 3 vCPU, RAM dasar 4 GB, faktor CPU 2.5; sedangkan untuk bot/worker, diasumsikan CPU dasar 2 vCPU, RAM dasar 2 GB, faktor CPU 1.5. Terutama pada pekerjaan bertipe worker, jumlah pengunjung bisa menyesatkan. Bahkan jika tidak ada yang mengunjungi situs, data tetap diproses di latar belakang.

Pemilihan lingkungan menambahkan koefisien di atas nilai dasar. Lingkungan uji/hobi dianggap dengan koefisien 0.75, production kecil 1, production 1.25, persiapan ketersediaan tinggi 1.6. Persiapan ketersediaan tinggi bukan berarti “satu VPS sekarang menjadi HA”; itu hanya berarti menyisakan alokasi sumber daya yang lebih besar. HA sejati membutuhkan arsitektur terpisah.

Alokasi pertumbuhan juga masuk pada akhirnya. Secara default 30%. Menurut saya masuk akal. Ini rentang yang baik untuk memenuhi ekspektasi pertumbuhan 3-6 bulan. Bisa ditulis 300%, tetapi jika pertumbuhan sebesar itu tidak benar-benar diharapkan, perhitungan menjadi perhitungan ketakutan.

Perhitungan trafik: rata-rata bulanan sedikit menyesatkan

Jumlah pengunjung bulanan adalah data pertama yang dilihat, tetapi lemah untuk keputusan akhir. Dua situs dengan 100 ribu pengunjung mungkin tidak menghasilkan beban yang sama. Yang satu menampilkan 1.5 halaman per pengunjung, ukuran halaman 1 MB, CDN bekerja baik. Yang lain menampilkan 4 halaman per pengunjung, ukuran halaman 3 MB, banyak area dinamisnya. Pengunjung yang sama, beban server yang sangat berbeda.

Perhitungan trafik mempertimbangkan jumlah pengunjung, nilai halaman/sesi, dan ukuran halaman rata-rata secara bersamaan. Di atasnya, efek cache dikurangkan, alokasi pertumbuhan ditambahkan, dan hasilnya dikonversi ke GB. Nilai akhir dibulatkan ke kelipatan 50 GB; bahkan dalam skenario yang sangat kecil, trafik minimum 50 GB ditampilkan.

Asumsi yang digunakan untuk cache adalah: tanpa cache penghematan 0, cache dasar 35%, halaman + object cache 60%, CDN + cache kuat 75%. Ini bukan nilai jaminan resmi. Ketika NGINX cache atau CDN digunakan, beban server asal diharapkan berkurang; tetapi penghematan sebenarnya bergantung pada rasio cache hit, struktur halaman, dan area dinamis.

Terutama perhatikan ini di WooCommerce. Kehadiran CDN tidak membuat halaman keranjang dan pembayaran menjadi gratis. Cache lebih terbatas di konten personal, sesi, operasi admin, alur pembayaran, kontrol stok, dan sejenisnya. Cache adalah rem yang baik; ia tidak menggantikan mesin.

Ada juga pengali jam sibuk. Trafik bulanan tidak terdistribusi merata. Hari kampanye, pengiriman buletin, berbagi media sosial, lonjakan mendadak di situs berita... Sementara nilai rata-rata terlihat tenang, server bisa terbebani untuk sementara. Dalam perhitungan ini, Peak RPS kira-kira ditemukan dengan membagi nilai (pengunjung bulanan × halaman/sesi × pengali jam sibuk) dengan jumlah detik dalam 30 hari. 30 hari adalah 2.592.000 detik.

Efek trafik pada CPU bahkan lebih menarik. Jumlah pengunjung dinormalisasi ke 50.000, beban kerja dikalikan dengan faktor CPU, pengali jam sibuk ditambahkan, dan setengah efek cache dikurangkan dari CPU. Jadi cache mengurangi trafik secara signifikan, tetapi efek CPU dikurangi dengan lebih hati-hati. Menurut saya itu pendekatan yang tepat; karena tidak setiap permintaan berasal dari cache.

Dalam pengujian situs statis dengan cache, 100 ribu pengunjung bulanan, 1.5 halaman/sesi, ukuran halaman 1 MB, pengali jam sibuk 2, CDN + cache kuat, dan alokasi pertumbuhan 20%, hasilnya tetap di level 1 vCPU, 2 GB RAM, 40 GB disk, 50 GB trafik bulanan. Trafik ada, tetapi bebannya ringan.

Dalam contoh e-commerce, kenyamanan yang sama tidak ada. Dengan 200 ribu pengunjung bulanan, 4 halaman/sesi, ukuran halaman rata-rata 3 MB, pengali jam sibuk 5, halaman + object cache, dan alokasi pertumbuhan 50%, trafik bulanan naik menjadi 1450 GB. Rekomendasi CPU adalah 32 vCPU. Sekilas mungkin terlihat tinggi; tetapi ketika angka-angka ditumpuk, gambaran menjadi keras: lebih banyak pengunjung, lebih banyak halaman, halaman lebih besar, beban kerja lebih berat, puncak lebih tinggi.

Ukuran halaman adalah masalah tersendiri. Mengatakan “situs ringan” tidak cukup, perlu diukur. Gambar besar, font, skrip pihak ketiga, kode iklan, tag analytics, file JS yang tidak perlu membengkakkan trafik. Terbuka cepat di browser tidak berarti transfer data kecil.

Siapa saja yang berjalan di kotak yang sama?

Pada VPS kecil, pertarungan sebenarnya sering terjadi di sini. Server web tidak berdiri sendiri. MySQL ada di sana, Redis juga, panel juga, mungkin juga layanan mail. Begitu juga dengan container Docker dan proses worker ditambahkan, 2 GB RAM akan kehabisan napas.

Jika database berada di VPS yang sama, model menambahkan beban RAM. Ukuran database dibagi 20; hasilnya dibatasi minimal 1 GB, maksimal 8 GB. Misalnya, untuk database 5 GB pun, dialokasikan 1 GB RAM. Untuk database 30 GB, beban tambahan sekitar 1.5 GB. Di sisi CPU, ditambahkan 0.5 vCPU untuk database.

Nilai-nilai ini bukan perhitungan tuning database. Jika indeks buruk, query panjang, ada kunci tabel, 0.5 vCPU tidak akan cukup. Tetapi untuk perencanaan awal, ini lebih baik daripada menganggap database “tanpa biaya”.

Jika Redis/object cache berada di VPS yang sama, tambahkan 0.5 GB ke RAM. Redis berjalan di memori; jika ini dilupakan, akan terlihat perlambatan aneh di server kecil. Ya, cache dipasang untuk meningkatkan kinerja, tetapi ia sendiri juga butuh RAM.

Ada tiga level panel manajemen: tidak ada, panel ringan, panel penuh seperti cPanel/Plesk. Panel ringan menambah 0.3 GB RAM dan 0.15 vCPU ke CPU. Panel penuh menambah 1 GB RAM dan 0.3 vCPU ke CPU. Memasang sistem seperti cPanel atau Plesk di VPS dengan RAM 1 GB lalu mengharapkan performa dari aplikasi bukanlah ide yang baik. Panel memberikan kenyamanan; Anda membayarnya dengan sumber daya.

Jumlah worker/queue berpengaruh langsung. Untuk setiap worker, ditambahkan 0.5 GB RAM dan 0.5 vCPU. Ini mungkin terlihat agak tinggi, tetapi masuk akal jika pekerjaan latar belakang serius. Pemrosesan gambar, pembuatan laporan, menarik data dari API eksternal, mengosongkan antrian mail, tugas pasca-pembayaran... Jika worker tidak menganggur, ia memakan sumber daya.

Jika layanan email berjalan di VPS yang sama, tambahkan 0.5 GB RAM dan 0.3 vCPU. Selain bagian sumber daya, layanan email juga merepotkan secara operasional. DNS, SPF, DKIM, DMARC, spam, antrian, deliverability. Perhitungan ini hanya melihat alokasi sumber daya; ia tidak menghitung sakit kepala.

Untuk penggunaan Docker/container, tambahkan 0.5 GB RAM dan 0.2 vCPU. Docker memberikan keteraturan tetapi tidak gratis. Jika batas memori Docker, perilaku swap, dan alokasi CPU tidak diatur dengan benar, satu container bisa menekan seluruh mesin. “Kita sudah pakai container, kita lega” tidak selalu benar.

Inti perhitungan CPU begini: ambil nilai yang lebih besar antara CPU dasar dan kebutuhan CPU trafik, tambahkan beban CPU layanan, terapkan koefisien lingkungan dan alokasi pertumbuhan. Untuk RAM, RAM dasar dan RAM layanan dijumlahkan, lalu koefisien lingkungan dan alokasi pertumbuhan ditambahkan. Kemudian hasilnya dibulatkan ke level paket praktis: CPU 1, 2, 4, 6, 8, 12, 16, 24, 32, 64; RAM 1, 2, 4, 8, 16, 32, 64, 128 GB.

Tidak ada angka pecahan. Jika kebutuhan RAM 5.3 GB, lihat ke 8 GB. Jika hasilnya 3.1 vCPU, 4 vCPU masuk akal. Melakukan perhitungan milimeter di lingkungan produksi akan mendekatkan Anda ke tembok saat ada fluktuasi kecil.

Beban sebenarnya di disk terkadang adalah hal yang tidak terlihat

Karena folder kode kecil, kebutuhan disk dianggap kecil. Ini kesalahan perhitungan yang sering kita lihat. Aplikasi 3 GB, media 10 GB; orang bilang “20 GB disk cukup”. Lalu datang log, database, cadangan lokal, file sistem, image container, file sementara.

Perhitungan disk dilakukan dengan file aplikasi, media/upload, ukuran database, log harian, hari penyimpanan log, dan salinan cadangan lokal. Jika database tidak berada di VPS yang sama, ia tidak masuk dalam perhitungan disk. Jika berada di VPS yang sama, ia masuk.

Pertama, buat subtotal disk: file aplikasi + file media + database (jika di VPS yang sama) + log harian × hari penyimpanan. Kemudian jumlah salinan cadangan lokal diperhitungkan. Satu cadangan lokal kira-kira menggandakan ukuran set data. Di atasnya ditambahkan alokasi sistem 15 GB, diterapkan ruang aman 20%, dan alokasi pertumbuhan juga ditambahkan. Hasilnya dibulatkan ke kelipatan 10 GB dan direkomendasikan minimal 20 GB.

Jangan anggap alokasi sistem 15 GB itu kecil. Sistem operasi, paket, sisa pembaruan, file sementara, log layanan, image Docker, file sementara database memakan tempat dari sana. Dalam produksi, disk bukan hanya folder upload Anda.

Log juga licik. Log 0.5 GB per hari dan penyimpanan 14 hari menghasilkan 7 GB. Log 2 GB per hari dan penyimpanan 30 hari menjadi 60 GB. Ia tumbuh diam-diam. Disk melewati 80%, lalu 90, lalu saat deploy muncul error terkenal: no space left on device.

Cadangan lokal juga perlu perhatian. Menyimpan cadangan di disk yang sama bukan jaminan penuh dalam skenario bencana; jika disk hilang, cadangan juga ikut hilang. Tetapi salinan lokal bisa berguna untuk pemulihan cepat. Model ini memasukkannya ke dalam perhitungan sumber daya. Keputusan seperti cadangan jarak jauh, object storage, server backup terpisah harus direncanakan secara terpisah.

Dalam pengujian produksi WordPress, dengan file aplikasi 5 GB, media 10 GB, database 5 GB, log harian 0.5 GB, penyimpanan 14 hari, 1 cadangan lokal, dan alokasi pertumbuhan 30%, disk yang direkomendasikan adalah 90 GB. Sekilas terlihat berlebihan. Tetapi ketika log, cadangan, alokasi sistem, dan ruang aman ditambahkan, itu bukan berlebihan, melainkan lebih hati-hati.

Di sisi e-commerce, urusannya membesar: file aplikasi 10 GB, media 80 GB, database 30 GB, log harian 2 GB, penyimpanan 30 hari, 1 cadangan lokal, dan alokasi pertumbuhan 50%. Hasilnya disk 480 GB. Jika gambar produk, data pesanan, log, dan cadangan berada di kotak yang sama, hasil ini tidak mengejutkan.

Terlalu menghemat disk adalah kebiasaan buruk. Jika CPU tidak cukup, Anda akan melihat perlambatan. Jika RAM tidak cukup, swap mulai berjalan. Jika disk penuh, layanan terkadang rusak jauh lebih parah: database tidak bisa menulis, log tidak terbentuk, file sesi tidak bisa dibuka, deploy berhenti di tengah jalan. Lebih buruk lagi, error tidak selalu menjelaskan dirinya dengan jelas.

Saat mengubah hasil menjadi paket

Ada empat nilai utama pada keluaran: CPU, RAM, disk, dan trafik bulanan. Jangan taruh semuanya dalam satu keranjang. Masing-masing menunjukkan batas yang berbeda.

CPU adalah daya pemrosesan sesaat. Permintaan PHP, respons API Node.js, query database, tugas worker, proses pasca-pembayaran... Semua itu menyentuh CPU. Ketika trafik naik, CPU bisa naik; cache bisa menguranginya tetapi tidak menghilangkan sepenuhnya.

RAM adalah ruang untuk layanan yang berjalan. MySQL, Redis, PHP-FPM, proses Node.js, panel, container Docker, layanan mail, worker. Ketika RAM menipis, sistem bisa jatuh ke swap. Ia seolah bekerja, tetapi menjadi berat. Terutama pada aplikasi dinamis, perbedaan ini cepat terasa.

Disk adalah penyimpanan persisten. File aplikasi, media, database, log, cadangan, dan file sistem bergantung di sini. Dalam perhitungan disk, perlu berpikir bukan dengan ukuran hari ini, tetapi akumulasi beberapa bulan ke depan.

Traffic bulanan adalah transfer data. CDN, cache, dan optimasi halaman menguranginya. Kebijakan trafik penyedia juga perlu diperiksa: apakah ada kuota, biaya kelebihan, atau penurunan kecepatan? Perhitungan memberikan kebutuhan GB; ia tidak memberikan syarat komersial penyedia.

Dalam model ini, nilai mentah dibulatkan ke level paket praktis. Jika kebutuhan mentah 3.4 vCPU, disarankan 4 vCPU. Jika kebutuhan RAM 9 GB, bisa naik ke level 16 GB. Disk juga dibulatkan ke kelipatan 10 GB. Pembulatan ini terkadang membuat hasil terlihat lebih besar dari sebenarnya, tetapi paket VPS memang tidak dijual dengan pecahan.

Ada juga ini: 4 vCPU di setiap penyedia mungkin tidak berperilaku seperti 4 vCPU yang sama. Generasi CPU, struktur shared/dedicated, lapisan virtualisasi, jenis disk, kualitas jaringan, mesin tetangga, semuanya membuat perbedaan. Perbedaan CPU shared dan dedicated tidak ditekankan tanpa alasan dalam dokumen pemilihan paket penyedia seperti DigitalOcean.

Oleh karena itu, perhitungan ini harus dianggap sebagai pemeriksaan teknis sebelum menekan tombol pembelian. Jika Anda memiliki sistem yang ada, bandingkan dengan metrik nyata: grafik CPU, penggunaan RAM, kepenuhan disk, lalu lintas jaringan, query lambat, error 5xx, waktu tunggu antrian. Jika Anda membangun sistem baru, coba beberapa skenario.

Apa yang terjadi tanpa cache? Seberapa besar trafik turun jika memilih CDN? Apakah RAM menjadi lega jika database dipisahkan dari VPS yang sama? Ketika jumlah worker naik dari 0 ke 4, ke mana CPU pergi? Seberapa besar salinan cadangan lokal memperbesar disk?

Pemilihan paket terkadang berasal dari jawaban atas pertanyaan-pertanyaan ini, bukan dari satu baris hasil.

Jika saya, saya akan melihat lagi tiga nilai: pengali jam sibuk, apakah database berada di VPS yang sama, dan salinan cadangan lokal. Karena dalam kehidupan nyata, inilah yang paling sering mengecoh perhitungan. Trafik menumpuk dalam satu jam, MySQL di kotak yang sama memakan RAM lebih dari yang diperkirakan, cadangan memenuhi disk. Lalu semua orang marah pada paket CPU.

Terkadang bukan CPU yang salah.