Reseller’dan Dedicated’a geçiş ne zaman yapılmalı? Net karar rehberi

Reseller hosting, çok başlangıçlı projeler için pratik bir çözümdür; ancak büyüdükçe kaynak paylaşımı (paylaşımlı ortamın doğası gereği) darboğaz üretir. Dedicated sunucuya geçmek yalnızca “daha güçlü” olmak değildir; izolasyon, performans öngörülebilirliği ve yönetim kontrolü sağlar. Bu rehberde reseller’dan dedicated’a geçiş için net eşikleri, izlenecek metrikleri ve geçiş planını adım adım bulacaksınız.

1) Reseller’da kalmanın maliyeti: görünmeyen darboğazlar

Reseller ortamında kaynaklar fiziksel sunucu üzerinde birden fazla müşteri arasında paylaşılır. Bu paylaşım; CPU dalgalanması, I/O (disk) gecikmesi ve ağ kuyruklanması şeklinde “arada geliyor” performans sorunları üretir. Dedicated’a geçişi düşünmeniz gereken durumlar genellikle tek bir semptoma değil, birkaç metriğin aynı anda kötüleşmesine dayanır.

Ne zaman “performans” diye değil “istikrar” diye bakmalısınız?

Aşağıdaki senaryolarda sorun “anlık yavaşlık” değil, sistemin çalışma biçimidir: - Kullanıcı trafiği belirli saatlerde (ör. akşam) düzenli olarak artıyor ve sayfa açılışı her seferinde uzuyorsa. - PHP tarafında (FPM/CGI) yanıt süreleri yükseliyor ama aynı zamanda sistem yükü (load average) veya “busy” durumları da görünür hale geliyorsa. - Sunucu diskinde (özellikle veritabanı) işlem beklemeleri artıyor; bu da “veritabanı sorgusu yavaş” şikayetlerine dönüşüyor. - Aynı paketle devam ettiğiniz halde geri dönüş süresi giderek uzuyor; yani toparlanma eşiği kaçmış durumda.

2) Geçiş sinyalleri: CPU, RAM, disk ve ağ için net eşikler

Karar vermeyi kolaylaştıran yaklaşım, reseller’da kalmaya devam ettiğiniz her ayın “fırsat maliyetini” ölçmektir. Aşağıdaki eşikler, yaygın uygulama yüklerinde (web + uygulama + veritabanı) kullanılan pratik eşik setleridir.

Not: Değerler mutlak sayı değil, sizin uygulamanıza göre kalibre edilir. Ancak yön aynı kalır: İstikrar bozulduysa dedicated’a geçiş zamanı yaklaşmıştır.

Trafik ve uygulama metrikleri

• Web yanıt süresi (TTFB/yanıt süresi): Son 30 günde P95 değerinde belirgin yükseliş.
• 5xx hataları: Özellikle kısa aralıklarla artış.
• Worker/PHP-FPM doygunluğu: İstek kuyruğu büyüyor, “timeout” artıyor.
• Aynı anda birden fazla servis etkileniyorsa: (web + DB + cache) bu reseller izolasyonunun yetmediğini gösterir.

Dedicated’a geçişi hızlandıran “yük türü” örnekleri

• WordPress’te yoğun eklenti yükü, yüksek admin trafiği, staging/cron işleri aynı anda çalışıyorsa.
• SaaS ya da API ağırlıklı uygulamalarda uzun sorgular ve eş zamanlı bağlantı sayısı artıyorsa.
• Veri tabanı yazma/okuma yükü yüksek uygulamalarda (log tabanlı sistemler, raporlama) disk I/O tıkanması yaşanıyorsa.

NetKıyas’ta karşılaştırma yaparken bir kontrol listesi

Aşağıdaki tablo, karar anında neye bakmanız gerektiğini özetler.

3) “Ne zaman” sorusunun kesin cevabı: 4 net kriter

Reseller’dan dedicated’a geçişi tek bir “ne zaman”e indirgemez; ancak pratikte dört kriter birlikte olduğunda karar nettir. Aşağıdaki kriterlerin en az ikisi 2-4 hafta içinde tekrar ediyorsa dedicated planlaması başlatın.

Kriter 1: Performans hedefi tutmuyor (P95 şart)

• 30 gün içinde P95 yanıt süresi, hedefinizin üzerinde ısrarla kalıyorsa.
• Önbelleğe (cache) rağmen düzelmiyorsa.

Kriter 2: Kaynak kısıtı görünür hale geliyor

• Loglarda zaman aşımları (timeout), worker doygunluğu veya DB kilitleri artıyorsa.
• Sunucu yükü (load average) ve disk beklemeleri belirginleşiyorsa.

Kriter 3: Yönetim yükü büyüdü

Reseller ortamında bazı şeylere “paket izin verdiği ölçüde” müdahale edersiniz. Şunlar artıyorsa dedicated daha mantıklı olur: - Uygulama ayarı için sürekli host tarafı ile iletişim kurma ihtiyacı - Kernel parametresi, servis yapılandırması veya özel güvenlik katmanlarının istenmesi - Zamanla daha profesyonel operasyon isteyen bir yapı (cron, log rotasyon, monitoring, otomasyon)

Kriter 4: Maliyet karşılaştırması “toplam sahip olma maliyeti”nde lehine dönüyor

Dedicated’ın maliyeti yalnızca aylık fiyata bakılarak değil, operasyon toplamına bakılarak kıyaslanır. Şu hesap netleştirir: - İyileştirme için harcanan saat (saat × maliyet) - Oluşan kesinti/performans düşüşünün iş kaybı - Gerekli eklenti/backup/ek kaynak paketleri (reseller’da ek ücretlerle büyüyen kalemler)

Bu kalemler bir araya geldiğinde, dedicated’ın “daha yüksek aylık ücret” olmasına rağmen daha düşük toplam maliyete döndüğü noktayı yakalarsınız.

4) Dedicated’a geçmeden önce yapılacak teknik ön test

Dedicated’a geçişten önce iki şeyi netleştirin: (1) sorun gerçek kaynak darboğazı mı yoksa konfigürasyon/uygulama kaynaklı mı, (2) cache ve veritabanı optimizasyonu fayda sağladı mı.

Ön test 1: Performansın nerede kırıldığını bulun

Köke inmek için şunları kontrol edin: - Uygulama yanıt süresi: TTFB mi yükseliyor yoksa tamamen sayfa render mı uzuyor? - Veritabanı: Sorguların en yavaş ilk 10’u ve bunların çalıştığı saatler. - Cache: Cache hit oranı düşüyor mu, purging/eksport mekanizması var mı? - Cron: Ağır cron işleri trafiğin tepe saatleriyle aynı zamana denk geliyor mu?

Ön test 2: Cache prewarming ve cron zamanlaması

Önbellek (cache) tek başına değil, doğru zamanda doluyorsa fark yaratır: - Cache prewarming uygulanınca P95 düşüyorsa, tam bir dedicated zorunluluğu olmayabilir. - Cron işlerini yoğun saatlerden kaydırınca zaman aşımı azalıyor ve DB yükü düşüyorsa, önce operasyon disiplini kurun.

Ön test 3: Yedekleme (backup) ve veri büyümesi

Reseller’da yedekleme zamanlaması sınırlı olabilir. Şunlar büyüyorsa dedicated’a geçiş daha hızlı haklı çıkar: - Backup penceresinde performans çökmesi - Yedeklerin geç alınması nedeniyle veri kaybı riski - Dosya sayısı/medya boyutu nedeniyle restore sürelerinin uzaması

5) Geçiş planı: downtime’ı kontrol altına almak ve rollback hazırlamak

Dedicated’a geçiş “taşıma” işidir; doğru planlanmazsa risk büyür. Bu yüzden geçişi 4 aşamada yürütün.

1. Aşama: Hedef mimariyi yazın

• Dedicated üzerinde işletim sistemi (OS) seçimi
• Web sunucusu (Nginx/Apache) ve uygulama katmanı (PHP-FPM vb.)
• Veritabanı (MySQL/MariaDB/PostgreSQL) ve disk düzeni (data/log ayırma gibi)
• Cache katmanı (CDN, reverse proxy cache, Redis vb.)

2. Aşama: Staging ile üretim pariteli test

• Mevcut ortamdan veri ve konfigürasyonları staging’e aktarın.
• Aynı trafik profiline yakın testler yapın.
• P95 yanıt süresini ölçün; DB query süreleri düştü mü bakın.

3. Aşama: Kademeli cutover (ana geçiş)

• DNS TTL değerini düşürün.
• Önce küçük kullanıcı yüzdesi ile test edin (veya belirli IP/ülke/URL segmenti).
• Performans metrikleri hedefe oturunca tam geçişi yapın.

4. Aşama: Rollback planı

• Cutover sırasında sorun çıkarsa “geri dönüş” prosedürü net olmalı.
• Son çalışır yedek ve son senkronizasyon adımı dokümante edilmelidir.

6) NetKıyas ile kararınızı hızlandırın: soru seti ve sonuç akışı

Aşağıdaki soru setini yanıtlayınca “reseller’da kal” mı “dedicated’a geç” mi kararı daha hızlı netleşir.

Karar soruları

1. Son 30 günde P95 yanıt süresi hedefin üstünde mi?
2. Timeout/5xx hataları belirgin arttı mı?
3. DB sorguları ve I/O gecikmesi kaynakla ilişkili görünüyor mu?
4. Cache ve cron zamanlaması iyileştirmeleri etkiliyor mu?
5. Yönetim için host tarafına bağımlılık artmış mı?
6. Dedicated fiyat farkı, toplam operasyon maliyetinizi düşürüyor mu?

Sonuç akışı (net)

• 2+ kriter sağlanıyorsa + cache optimizasyonuna rağmen P95 düşmüyorsa → dedicated planlayın.
• 1 kriter sağlanıyor + cache/cron ile P95 belirgin iyileşiyorsa → önce uygulama ve operasyon optimizasyonu yapın.
• Ayrık bir sorun (ör. sadece yanlış yapılandırma veya tek bir hatalı eklenti) varsa dedicated’a sıçramadan önce giderin; çünkü dedicated daha pahalı bir “kör nokta” çözüm olabilir.

Sonuç: Hemen taşımak mı, önce testi mi beklemek?

Reseller’dan dedicated’a geçiş zamanını “hissettiğiniz yavaşlık” değil, P95 performans sapması, timeout/5xx artışı, DB/I/O tıkanması ve yönetim kısıtları gibi somut sinyaller belirlemelidir. Son 2-4 haftada bu sinyallerden en az ikisi bir arada görünüyorsa dedicated’a geçiş planını başlatın; önce staging testleri ve kademeli cutover ile downtime riskini yönetin. Eğer isterseniz mevcut senaryonuz için (tür: WordPress mi, API mı, trafik ölçeği) metriklerinizi yazın; bu rehberdeki kriterlere göre geçiş eşiğini birlikte netleştirelim.