VPS Kaynak Hesaplama

Önce paketin adı değil, yükün huyu

VPS seçerken paketin adı insanı kolay kandırıyor. “Basic”, “standard”, “premium”, “general purpose”… Güzel duruyorlar. Ama o isimlerin hiçbiri tek başına sitenin ne kadar RAM yiyeceğini, CPU’yu ne zaman boğacağını ya da diskin hangi gün dolacağını söylemez.

Bir statik site ile WooCommerce mağazası aynı ziyaretçiyi alsa bile aynı sunucuya ihtiyaç duymaz. Birinde hazır dosya döner; diğerinde sepet, ödeme, stok, kullanıcı oturumu, veritabanı sorgusu, admin paneli, bazen de arka planda çalışan kuyruk işleri vardır. Aradaki fark tam burada.

Bu hesap modeli VPS’i dört ana kaynak üzerinden okur: vCPU, RAM, disk ve aylık trafik. Ama bunları çıplak sayı gibi almaz; uygulama tipi, ortam seviyesi, cache/CDN kullanımı, aynı VPS içinde çalışan servisler, loglar, yerel yedekler ve büyüme payıyla birlikte değerlendirir.

Tek bir “resmi VPS formülü” yok. Zaten büyük bulut sağlayıcılarının dokümanlarında da mesele böyle ele alınır: CPU, bellek, ağ ve depolama birlikte düşünülür; makine aileleri de iş yüküne göre ayrılır. Genel amaçlı makineler başka, compute ağırlıklı makineler başka, memory ağırlıklı makineler başka davranır. VPS tarafında da aynı mantık geçerli, sadece daha küçük ölçekte.

flowchart LR
  A["Uygulama tipi"] --> E["Kaynak tahmini"]
  B["Trafik ve cache"] --> E
  C["Veritabanı, worker, panel, Docker"] --> E
  D["Disk, log, yedek, büyüme payı"] --> E
  E --> F["vCPU"]
  E --> G["RAM"]
  E --> H["Disk"]
  E --> I["Aylık trafik"]

Benim bu tip hesaplarda en sevmediğim cümle şu: “2 vCPU yeter.” Neye yeter? Statik siteye mi, WooCommerce’e mi, Odoo’ya mı, Node API’ye mi, yoksa aynı kutuda MySQL, Redis, mail ve Docker çalışan karışık bir kuruluma mı?

Ayrıca paylaşımlı CPU ile ayrılmış/dedike CPU farkı da gözden kaçıyor. Küçük VPS planlarında CPU çoğu zaman paylaşılır. Hafif web siteleri için sorun olmayabilir. Ama düzenli worker çalıştıran, anlık trafik alan, rapor üreten ya da veritabanına sık yüklenen sistemlerde aynı vCPU sayısı beklenenden daha zayıf hissedilebilir.

Bu yüzden buradaki çıktı “kesin plan” değil, güvenli başlangıç tahmini olarak okunmalı. Kaynak seçimi için iyi bir ilk fotoğraf verir. Üretimde son sözü yine metrikler söyler: CPU kullanımı, RAM tüketimi, disk doluluğu, ağ trafiği, yavaş sorgular, hata logları, worker kuyruğu.

Kâğıt başka, sunucu başka.

Nereden başlıyoruz?

Hesabın ilk ayrımı uygulama tipinden gelir. Çünkü her uygulama sınıfının taban yükü aynı değildir.

Statik site en hafif tarafta durur. Taban CPU 1 vCPU, taban RAM 1 GB kabul edilir; CPU faktörü de 0.2 gibi düşük tutulur. Bu mantıklı. Çünkü iyi cachelenen statik bir sitede sunucu çoğu zaman hazır dosya servis eder, uygulama katmanı çok az çalışır.

WordPress / blog için başlangıç yükselir: taban CPU 1.5 vCPU, taban RAM 2 GB, CPU faktörü 1. WordPress’in PHP ve veritabanı tabanı var. Tema, eklenti, görsel işleme, admin işlemleri, arama, yorumlar derken statik site gibi davranmaz. Yine de düzgün cache ile epey rahatlatılabilir.

WooCommerce / e-ticaret başka bir sınıf. Bu modelde taban CPU 2.5 vCPU, taban RAM 4 GB, CPU faktörü 2 alınır. Bana sorarsanız e-ticaret için bu ayrım şart. Çünkü WooCommerce, düz WordPress’in üzerine sepet, ödeme, sipariş, stok ve üyelik katmanı koyar. Ayrıca bazı sayfalar tam cache’e uygun değildir. Ürün sayfası cache’den gelebilir ama sepet ve ödeme tarafında iş değişir.

Laravel / PHP uygulaması ve Node.js / API için taban CPU 2 vCPU, taban RAM 3 GB, CPU faktörü 1.2. Burada gerçek ihtiyaç koda çok bağlıdır. Basit bir API çok hafif çalışabilir; dış servislerle konuşan, sürekli veri işleyen, kuyruk kullanan bir uygulama aynı sınıfta çok daha ağır olabilir.

Küçük SaaS için taban CPU 3 vCPU, taban RAM 4 GB, CPU faktörü 1.8. Kullanıcı oturumu, arka plan işleri, bildirimler, raporlar ve veritabanı trafiği genelde birlikte gelir. Ziyaretçi sayısı az görünür, ama uygulama içi işlem fazladır. Web sitesi gibi bakınca yanlış paket seçilir.

Odoo / ERP benzeri sistemler ağır tarafta: taban CPU 4 vCPU, taban RAM 8 GB, CPU faktörü 3. Odoo kurulumlarında worker ve bellek planlaması zaten ayrıca düşünülür. Raporlama, kullanıcı oturumu, modüller, veritabanı işlemleri ve uzun süren görevler bu sınıfı normal blog sitesinden ayırır.

Game server için taban CPU 3 vCPU, taban RAM 4 GB, CPU faktörü 2.5; bot / worker tarafında ise taban CPU 2 vCPU, taban RAM 2 GB, CPU faktörü 1.5 kabul edilir. Özellikle worker tipi işlerde ziyaretçi sayısı yanıltıcı olabilir. Kimse siteye girmese bile arka planda veri işleniyordur.

Ortam seçimi taban değerin üstüne katsayı gibi biner. Test / hobi ortamı 0.75, küçük production 1, production 1.25, yüksek erişilebilirlik hazırlığı 1.6 katsayısıyla düşünülür. Yüksek erişilebilirlik hazırlığı demek “tek VPS artık HA oldu” demek değil; sadece daha geniş kaynak payı bırakmak demek. Gerçek HA ayrı mimari ister.

Büyüme payı da en sonda devreye girer. Varsayılan yüzde 30. Bence makul. 3-6 aylık büyüme beklentisini karşılamak için iyi bir aralık. Yüzde 300 yazılabilir, ama gerçekten öyle bir büyüme beklenmiyorsa hesap korku hesabına döner.

Trafik hesabı: ay ortalaması biraz aldatır

Aylık ziyaretçi sayısı ilk bakılacak veri, ama son karar için zayıf kalır. 100 bin ziyaretçi alan iki site aynı yükü üretmeyebilir. Biri ziyaretçi başına 1.5 sayfa gösterir, sayfa boyutu 1 MB’tır, CDN iyi çalışıyordur. Diğeri ziyaretçi başına 4 sayfa gösterir, sayfa boyutu 3 MB’tır, dinamik alanları fazladır. Aynı ziyaretçi, bambaşka sunucu yükü.

Trafik hesabı ziyaretçi sayısını, sayfa / oturum değerini ve ortalama sayfa boyutunu birlikte ele alır. Üstüne cache etkisi düşülür, büyüme payı eklenir ve sonuç GB’a çevrilir. Son değer 50 GB’lık basamaklara yuvarlanır; çok küçük senaryolarda bile minimum 50 GB trafik gösterilir.

Cache tarafında kullanılan kabuller şöyle: cache yoksa tasarruf 0, temel cache yüzde 35, sayfa + object cache yüzde 60, CDN + güçlü cache yüzde 75. Bunlar resmi garanti değerleri değil. NGINX cache veya CDN kullanıldığında origin sunucu yükünün azalması beklenir; fakat gerçek tasarruf cache hit oranına, sayfa yapısına ve dinamik alanlara bağlıdır.

Özellikle WooCommerce’de buna dikkat. CDN var diye sepet ve ödeme sayfası birden bedavaya gelmez. Kişiye özel içerik, oturum, admin işlemleri, ödeme akışı, stok kontrolü gibi yerlerde cache daha sınırlıdır. Cache iyi bir fren; motorun yerine geçmiyor.

Yoğun saat çarpanı ayrıca var. Aylık trafik düzgün dağılmaz. Kampanya günü, bülten gönderimi, sosyal medya paylaşımı, haber sitelerinde ani yükselişler… Ortalama değer sakin görünürken sunucu bir saatliğine terleyebilir. Bu hesapta Peak RPS yaklaşık olarak aylık ziyaretçi × sayfa / oturum × yoğun saat çarpanı değerinin 30 günlük saniye sayısına bölünmesiyle bulunur. 30 gün, 2.592.000 saniye.

CPU’daki trafik etkisi daha da ilginç. Ziyaretçi sayısı 50.000’e oranlanır, iş yükü CPU faktörüyle çarpılır, yoğun saat çarpanı eklenir, cache etkisinin yarısı CPU tarafından düşülür. Yani cache trafiği ciddi düşürür ama CPU etkisi daha temkinli azaltılır. Bence doğru yaklaşım; çünkü her istek cache’den dönmez.

Statik cached site testinde 100 bin aylık ziyaretçi, 1.5 sayfa / oturum, 1 MB sayfa boyutu, yoğun saat çarpanı 2, CDN + güçlü cache ve yüzde 20 büyüme payı ile sonuç 1 vCPU, 2 GB RAM, 40 GB disk, 50 GB aylık trafik seviyesinde kalıyor. Trafik var ama yük hafif.

E-ticaret örneğinde aynı rahatlık yok. 200 bin aylık ziyaretçi, 4 sayfa / oturum, 3 MB ortalama sayfa boyutu, yoğun saat çarpanı 5, sayfa + object cache ve yüzde 50 büyüme payı ile aylık trafik 1450 GB’a çıkıyor. CPU önerisi 32 vCPU. İlk bakışta yüksek gelebilir; ama sayıları üst üste koyunca tablo sertleşiyor: daha fazla ziyaretçi, daha fazla sayfa, daha büyük sayfa, daha ağır iş yükü, daha yüksek peak.

Sayfa boyutu ayrı bir bela. “Site hafif” demek yetmez, ölçmek gerekir. Büyük görseller, fontlar, üçüncü taraf scriptler, reklam kodları, analytics etiketleri, gereksiz JS dosyaları trafiği şişirir. Tarayıcıda hızlı açılıyor olması veri transferinin küçük olduğu anlamına gelmez.

Aynı kutuda kimler çalışıyor?

Küçük VPS’lerde asıl kavga çoğu zaman burada çıkar. Web sunucusu tek başına durmaz. MySQL de aynı yerde, Redis de, panel de, belki mail servisi de. Bir de Docker container’ları ve worker süreçleri eklendi mi 2 GB RAM’in nefesi kesilir.

Veritabanı aynı VPS içindeyse modele RAM ek yükü girer. Veritabanı boyutu 20’ye bölünür; sonuç en az 1 GB, en fazla 8 GB olacak şekilde sınırlandırılır. Mesela 5 GB veritabanı için bile 1 GB RAM payı ayrılır. 30 GB veritabanı için 1.5 GB civarı ek yük oluşur. CPU tarafında veritabanı için 0.5 vCPU eklenir.

Bu değerler veritabanı tuning hesabı değil. İndeksler kötüyse, sorgular uzunsa, tablo kilitleri varsa 0.5 vCPU yetmez. Ama ilk planlama için veritabanını “sıfır maliyetli” saymaktan iyidir.

Redis / object cache aynı VPS içindeyse RAM’e 0.5 GB eklenir. Redis bellekte çalışır; bunu unutunca küçük sunucuda garip yavaşlamalar görülür. Cache performansı artırmak için kurulmuştur, evet, ama kendisi de RAM ister.

Yönetim panelinde üç seviye var: yok, hafif panel, cPanel / Plesk benzeri tam panel. Hafif panel RAM’e 0.3 GB, CPU’ya 0.15 vCPU ekler. Tam panel RAM’e 1 GB, CPU’ya 0.3 vCPU ekler. cPanel veya Plesk benzeri sistemleri 1 GB RAM’li VPS’e kurup sonra uygulamadan performans beklemek pek iyi fikir değil. Panel rahatlık sağlar; bedelini kaynakla ödersiniz.

Worker / queue sayısı doğrudan etkilidir. Her worker için 0.5 GB RAM ve 0.5 vCPU eklenir. Bu biraz yüksek gibi durabilir, ama arka plan işleri ciddiyse mantıklıdır. Görsel işleme, rapor üretme, dış API’den veri çekme, mail kuyruğu boşaltma, ödeme sonrası görevler… Worker boş durmuyorsa kaynak yer.

E-posta servisi aynı VPS içinde çalışıyorsa 0.5 GB RAM ve 0.3 vCPU eklenir. Kaynak kısmı bir yana, mail servisi operasyonel olarak da zahmetlidir. DNS, SPF, DKIM, DMARC, spam, kuyruk, teslim edilebilirlik. Bu hesap yalnızca kaynak payını görür; baş ağrısını hesaplamaz.

Docker / container kullanımı için 0.5 GB RAM ve 0.2 vCPU eklenir. Docker düzen getirir ama bedava değildir. Docker’ın bellek sınırı, swap davranışı ve CPU payı doğru ayarlanmazsa bir container bütün makineyi sıkıştırabilir. “Container yaptık, rahatladık” her zaman doğru cümle değil.

CPU hesabının özü şöyle: taban CPU ile trafik CPU ihtiyacından büyük olan alınır, servis CPU yükleri eklenir, ortam katsayısı ve büyüme payı uygulanır. RAM’de taban RAM ile servis RAM’i toplanır, yine ortam ve büyüme payı eklenir. Sonra sonuç pratik paket basamaklarına yuvarlanır: CPU’da 1, 2, 4, 6, 8, 12, 16, 24, 32, 64; RAM’de 1, 2, 4, 8, 16, 32, 64, 128 GB.

Küsuratlı dünya yok. 5.3 GB RAM ihtiyacı çıktıysa 8 GB’a bakılır. 3.1 vCPU çıktıysa 4 vCPU mantıklıdır. Production ortamında milimetrik hesap yapmak insanı küçük dalgalanmada duvara yaklaştırır.

Diskte asıl yük bazen görünmeyen şeylerdir

Kod klasörü küçük diye disk ihtiyacı küçük sanılıyor. Çok gördüğümüz hesap hatası bu. Uygulama 3 GB, medya 10 GB; “20 GB disk yeter” deniyor. Sonra loglar, veritabanı, yerel yedek, sistem dosyaları, container image’ları, geçici dosyalar geliyor.

Disk hesabı uygulama dosyaları, medya / upload, veritabanı boyutu, günlük log, log saklama günü ve yerel yedek kopyasıyla yapılır. Veritabanı aynı VPS içinde değilse disk hesabına girmez. Aynı VPS içindeyse girer.

Önce disk ara toplamı oluşur: uygulama dosyaları + medya dosyaları + aynı VPS içindeyse veritabanı + günlük log × saklama günü. Sonra yerel yedek kopyası sayısı hesaba katılır. Bir yerel yedek, veri setini kabaca bir kez daha büyütür. Üzerine 15 GB sistem payı eklenir, yüzde 20 güvenlik boşluğu uygulanır, büyüme payı da eklenir. Sonuç 10 GB’lık basamaklara yuvarlanır ve minimum 20 GB önerilir.

15 GB sistem payı küçük görünmesin. İşletim sistemi, paketler, güncelleme artıkları, geçici dosyalar, servis logları, Docker image’ları, veritabanı geçici dosyaları oradan yer. Üretimde disk sadece sizin upload klasörünüz değildir.

Loglar da sinsidir. Günde 0.5 GB log ve 14 gün saklama 7 GB eder. Günde 2 GB log ve 30 gün saklama 60 GB. Sessizce büyür. Disk yüzde 80’i geçer, sonra 90, sonra bir deploy sırasında o meşhur hata: no space left on device.

Yerel yedek ayrıca dikkat ister. Aynı diskte yedek tutmak felaket senaryosunda tam güvence değildir; disk giderse yedek de gider. Ama hızlı geri dönüş için bir yerel kopya iş görebilir. Model bunu kaynak hesabına dahil eder. Uzak yedek, obje depolama, ayrı backup sunucusu gibi kararlar ayrıca planlanmalı.

WordPress production testinde 5 GB uygulama dosyası, 10 GB medya, 5 GB veritabanı, günlük 0.5 GB log, 14 gün saklama, 1 yerel yedek ve yüzde 30 büyüme payıyla disk 90 GB öneriliyor. İlk bakışta fazla. Ama log, yedek, sistem payı ve güvenlik boşluğu eklenince fazla değil, daha çok tedbirli.

E-ticaret tarafında iş büyüyor: 10 GB uygulama dosyası, 80 GB medya, 30 GB veritabanı, günlük 2 GB log, 30 gün saklama, 1 yerel yedek ve yüzde 50 büyüme payı. Çıkan disk 480 GB. Ürün görselleri, sipariş verisi, log ve yedek aynı kutudaysa bu sonuç şaşırtıcı değil.

Diskte fazla kısmak kötü bir huy. CPU yetmezse yavaşlama görürsünüz. RAM yetmezse swap başlar. Disk dolarsa servisler bazen çok daha sert bozulur: veritabanı yazamaz, log oluşmaz, oturum dosyası açılamaz, deploy yarım kalır. Daha kötüsü, hata her zaman temiz anlatmaz kendini.

Sonucu pakete çevirirken

Çıktıda dört ana değer var: CPU, RAM, disk ve aylık trafik. Bunları aynı torbaya atmayın. Her biri başka bir sınırı gösterir.

CPU, anlık işlem gücüdür. PHP isteği, Node.js API yanıtı, veritabanı sorgusu, worker görevi, ödeme sonrası işlem… Bunlar CPU’ya dokunur. Trafik artınca CPU artabilir; cache bunu azaltabilir ama tamamen silmez.

RAM, çalışan servislerin alanıdır. MySQL, Redis, PHP-FPM, Node.js process’leri, panel, Docker container’ları, mail servisi, worker’lar. RAM azalınca sistem swap’a düşebilir. Çalışır gibi yapar, ama ağırlaşır. Özellikle dinamik uygulamalarda bu fark çabuk hissedilir.

Disk, kalıcı depolamadır. Uygulama dosyası, medya, veritabanı, log, yedek ve sistem dosyaları buraya bakar. Disk hesabında bugünkü boyutla değil, birkaç ay sonraki birikimle düşünmek gerekir.

Aylık trafik, veri transferidir. CDN, cache ve sayfa optimizasyonu düşürür. Sağlayıcının trafik politikası ayrıca kontrol edilmeli: kota mı var, aşım ücreti mi var, hız düşümü mü var? Hesap GB ihtiyacını verir; sağlayıcının ticari koşulunu vermez.

Bu modelde ham değerler pratik paket basamaklarına yuvarlanır. 3.4 vCPU ham ihtiyaç varsa 4 vCPU önerilir. 9 GB RAM ihtiyacı varsa 16 GB seviyesine çıkabilir. Disk de 10 GB’lık basamaklara tamamlanır. Bu yuvarlama bazen sonucu olduğundan büyük gösterir, ama VPS paketleri de zaten küsuratlı satılmaz.

Bir de şu var: 4 vCPU her sağlayıcıda aynı 4 vCPU gibi davranmayabilir. CPU jenerasyonu, paylaşımlı/dedike yapı, sanallaştırma katmanı, disk tipi, ağ kalitesi, komşu makineler, hepsi fark yaratır. DigitalOcean gibi sağlayıcıların plan seçimi dokümanlarında paylaşımlı ve ayrılmış CPU ayrımı boşuna vurgulanmaz.

O yüzden bu hesap, satın alma butonuna basmadan önceki teknik kontrol gibi düşünülmeli. Mevcut sisteminiz varsa gerçek metriklerle yan yana koyun: CPU grafiği, RAM kullanımı, disk doluluğu, network çıkışı, yavaş sorgular, 5xx hataları, kuyruk bekleme süresi. Yeni sistem kuruyorsanız birkaç senaryo deneyin.

Cache yokken ne oluyor? CDN seçince trafik ne kadar düşüyor? Veritabanını aynı VPS’ten ayırınca RAM rahatlıyor mu? Worker sayısı 0’dan 4’e çıkınca CPU nereye gidiyor? Yerel yedek kopyası diski ne kadar büyütüyor?

Paket seçimi bazen bu sorulara verilen cevaplardan çıkar, tek sonuç satırından değil.

Ben olsam özellikle üç değere tekrar bakarım: yoğun saat çarpanı, veritabanının aynı VPS içinde olup olmadığı ve yerel yedek kopyası. Çünkü gerçek hayatta hesabı en çok bunlar şaşırtıyor. Trafik bir saate yığılır, MySQL aynı kutuda beklenenden fazla RAM yer, yedekler diski doldurur. Sonra herkes CPU paketine kızar.

Bazen suç CPU’da değildir.