Fiziksel Sunucu Kapasite Planlama Rehberi 2025 İpuçları

Sharing is caring!

Yeni bir uygulama yayına alacaksın, fiziksel sunucu seçeceksin ama kafanda milyon soru var. 8 çekirdek mi yeter, yoksa 16 mı? 32 GB RAM güvenli midir, yoksa abartı mı? Bir de işin depolama ve ağ tarafı var. Tahmin ederek ilerlemek kolay geliyor ama yıllarca peşinden sürükleyen hatalar genelde burada başlıyor.

İyi yapılmış bir sunucu kapasite planlama çalışması, hem gereksiz donanım maliyetini keser hem de performans krizlerinin önüne geçer. Yani iş sadece güçlü bir sunucu almak değil, o gücü gerçekten ihtiyacın olan yere göre ayarlamak. Sunucu kaynak hesaplama sürecine sistematik bakmadığında kimi yerde CPU patlar, kimi yerde disk tıkanır, kimse mutlu olmaz.

Peki donanım ihtiyacı nasıl hesaplanır, nereden başlanır, nelere dikkat edilir? Teoride karmaşık görünen bu konuyu, günlük hayatta kullanabileceğin adımlara bölerek ilerleyelim. Özellikle fiziksel sunucu tarafında geri dönüş maliyetli olduğu için, ilk seferde olabildiğince isabetli karar vermek önemli.

Fiziksel sunucuda kapasite planlamaya nereden başlanır?

Çoğu ekip önce bütçeye, sonra da kampanyadaki sunucu modellerine bakar. Asıl başlangıç noktası ise iş yüküdür. Yani bu sunucu üzerinde tam olarak ne koşacak, hangi saatlerde ne kadar trafik alacak, ne kadar süre boyunca büyüme bekliyorsun, önce bunlar netleşmeli. Aksi halde donanım seçiminde hep sezgiyle hareket edersin.

Mevcut yükü anlamadan tahmin yapmak riskli

Eğer hali hazırda çalışan bir sistemin donanımını yenileyeceksen işin biraz daha kolay. İzleme araçlarından CPU, RAM, disk ve ağ kullanımı metriklerini çekip, en yoğun saatlerde ne olduğuna bakabilirsin. Örneğin son 3 aydaki pik CPU kullanımı ortalama yüzde 75 ise ve büyüme de beklentilerin doğrultusunda gidiyorsa, bunu yeni tasarımın için başlangıç verisi kabul edebilirsin.

Sıfırdan bir proje kuruyorsan, referans olarak benzer uygulamalardan ve üretici dokümantasyonundan faydalanmak mantıklı. Web uygulaması, veritabanı, cache, arka plan işler, dosya depolama gibi bileşenleri ayrıştırıp her biri için ayrı kapasite tahmini yapmak, tek bir büyük kutuya tahmin yürütmekten çok daha net sonuç verir.

Sunucu Kapasite Planlama için temel yaklaşım

Sunucu kapasite planlama sürecinde kendine şu basit soruyu sorabilirsin: Belirli bir zaman diliminde bu sisteme kaç istek gelecek ve her istek sistem kaynaklarını ne kadar süre kullanacak? Aslında tüm hesap bunun etrafında dönüyor. Kullanıcı sayısı, eşzamanlı bağlantı, işlem başına CPU süresi, hafıza ihtiyacı ve disk erişim yoğunluğu birleşince tablo ortaya çıkıyor.

İş yükü tipini doğru tanımlamak

Her iş yükü aynı karakterde değil. Örneğin raporlama ve analitik ağırlıklı bir sistemde CPU yoğun kullanım görürken, büyük dosya servis eden bir sunucuda ağ ve disk daha kritik hale gelir. Veritabanı sunucusunda RAM yüksek, web sunucusunda ise CPU ve ağ öne çıkar. Önce uygulamanın IO ağırlıklı mı, CPU ağırlıklı mı, yoksa hafıza ağırlıklı mı olduğunu netleştirmen gerekiyor.

Bu noktada basit bir sınıflandırma işini kolaylaştırır. Web ve API sunucuları genelde CPU ve ağ odaklıdır. Veritabanları ve cache katmanı RAM ve disk IO tarafında hassastır. Yedekleme, arşiv ve log tutma gibi işlerde ise depolama kapasitesi ve ardışık yazma performansı öne çıkar. Hangi kategoride olduğunu bildiğinde sunucu kaynak hesaplama daha öngörülebilir hale gelir.

CPU kaynağını hesaplarken kullanılabilecek metrikler

İşin beyni CPU ve fiziksel sunucuda yükseltmesi en zor bileşenlerden biri. O yüzden burada yapacağın hata uzun süre seninle gelir. CPU kapasitesi için bakabileceğin birkaç temel nokta var: çekirdek sayısı, çekirdek başına performans, eşzamanlı istek sayısı ve işlem başına ortalama CPU süresi.

Örneğin web uygulaman için kaba bir hesap yapalım. Diyelim ki pik saatte saniyede 500 istek bekliyorsun. İzleme ya da test sonuçlarına göre her isteğin ortalama 20 milisaniye CPU süresine ihtiyacı var. Saniyede toplam CPU ihtiyacın 500 x 0,02 yani 10 CPU saniyesi. Teoride 10 tam çekirdek ile bu yükü karşılayabilirsin ama gerçek hayatta bağlam değiştirme, işletim sistemi yükü, arka plan işler gibi ek masraflar olacağı için güvenlik payı eklemek çok daha sağlıklı.

Genelde kritik üretim sistemlerinde CPU kullanımı için yüzde 50 ila 70 bandını hedeflemek akıllıca olur. Yüzde 90 ve üzeri kullanımları uzun süre görmek, pik anlarda sistemin kitlenmesine ve yanıt sürelerinin sıçramasına neden olabilir. Buna göre hesap yaparken sadece bugün ihtiyacını değil, büyüme ve ani trafik sıçramalarını da düşünmek gerekiyor.

Çekirdek sayısını belirlerken lisans ve mimari etkisi

Veritabanı ya da bazı kurumsal uygulamalarda lisanslar çekirdek sayısına göre fiyatlanır. Bu durumda sadece çok çekirdekli bir işlemci almak yerine, daha az çekirdekte daha yüksek saat hızına sahip CPU tercih etmek lisans maliyetini ciddi biçimde etkileyebilir. Ayrıca uygulamanın paralelleşme kabiliyeti de önemli. Tek iş parçacıklı çalışan eski bir uygulama için 32 çekirdekli işlemci almak pek bir şey değiştirmez, yüksek frekanslı az çekirdekli bir model daha iyi iş çıkarır.

RAM ihtiyacını hesaplamak için pratik yöntemler

RAM genelde işin görünmeyen kahramanı. Yetersiz olduğunda sistem swap kullanmaya başlar ve bir anda her şey ağırlaşır. Fazla aldığında ise çoğu zaman boş boş bekler. İdeal seviyeyi bulmak için önce ana bileşenleri sayman şart: işletim sistemi, uygulama sunucusu, veritabanı, cache sistemi, arka plan işler ve izleme ajanları.

Yaklaşım şu olabilir. Önce işletim sistemi için üreticinin önerdiği minimum değere makul bir marj ekle. Ardından veritabanı için buffer pool, query cache gibi alanlar için dokümantasyondaki önerileri kullan. Örneğin orta ölçekli bir veritabanı için 16 ila 32 GB arası alan ayırman gerekebilir. Uygulama sunucusu tarafında ise her worker ya da thread için ortalama bellek tüketimini çarpıp, eşzamanlı worker sayısıyla çarparak toplamı bulabilirsin.

Cache sistemleri (Redis, Memcached gibi) kullanıyorsan, burada RAM doğrudan performansı belirler. Tüm sıcak veriyi RAM içinde tutmak istiyorsan veri büyüklüğü tahminlerini gerçekçi yapmak gerekiyor. Log, temp dosyaları ve sistem buffer alanlarını da unutmadan, çıkan değerin üzerine yüzde 20 ila 30 arasında bir güvenlik payı eklemek pratikte iyi sonuç veriyor.

Depolama kapasitesi ve IOPS planı

Disk tarafında çoğu kişi sadece kapasiteye odaklanıyor, oysa performansı belirleyen en kritik değer IOPS ve gecikme. Yüzlerce GB boş alanın olabilir ama disk başına düşen IOPS yetmiyorsa veritabanı sorguları ve dosya erişimleri çakılı kalır. Özellikle fiziksel sunucularda disk sayısı, disk tipi ve RAID düzeyi kararını planlamadan vermemek gerekiyor.

Önce hangi veri tiplerini saklayacağını ayır. Veritabanı, loglar, yedekler, statik dosyalar ve geçici dosyalar için ayrı disk grupları planlamak hem performans hem de yönetilebilirlik açısından avantaj sağlar. Örneğin veritabanını hızlı SSD üzerinde, log ve yedekleri daha yavaş ama yüksek kapasiteli disklerde tutmak maliyet dengesini korur.

Kapasite değil hız tıkanıklık yaratır

Örnek bir senaryo düşünelim. Veritabanın saniyede ortalama 200 rastgele okuma ve 100 yazma işlemi yapıyor ve pik anlarda bu sayı iki katına çıkıyor. Seçtiğin disklerin her biri 150 IOPS veriyor ve RAID ile beraber efektif IOPS belli bir noktaya kadar düşüyor. Kağıt üzerinde kapasite fazlasıyla yeterli görünse bile, toplam IOPS ihtiyacını karşılayamadığın an bekleme süreleri artmaya başlar. Sunucu kaynak hesaplama yaparken bu detayı atlamayan ekipler, performans sorunlarını daha tasarım aşamasında çözmüş oluyor.

Ayrıca büyüme planını da işin içine katmalısın. Veri her ay yüzde 5 büyüyorsa, bir yıl sonra neredeyse yüzde 80 ek kapasite anlamına gelir. Sadece bugünkü tabloya göre disk boyutu seçmek, seni ummadığın bir gece veri taşıma operasyonu ile baş başa bırakabilir.

Ağ bant genişliği ve bağlantı sayısı nasıl planlanır?

Ağ tarafı genelde son dakikaya bırakılan ama servis deneyimini doğrudan etkileyen bir bileşen. Burada iki boyut var: toplam bant genişliği ve eşzamanlı bağlantı sayısı. Yüksek trafikli web siteleri ya da dosya sunucularında ikisini de doğru tahmin etmek gerekiyor.

Bant genişliği için ortalama istek boyutu ve saniyedeki istek sayısını çarpıp kabaca bir değer bulabilirsin. Örneğin ortalama 500 KB boyutunda içerik sunuyorsan ve saniyede 300 istek bekliyorsan, teoride 150 MB saniye trafik ortaya çıkar. Buna ağ protokolü ek yükünü ve ani sıçramaları da ekleyerek, bağlantı hızını bir iki kademe yukarıdan seçmek daha güvenli olur.

Eşzamanlı bağlantı tarafında ise TCP bağlantı süresi, keep alive ayarları ve istemci davranışı büyük rol oynar. Çok sayıda uzun ömürlü bağlantı tutan bir servis (örneğin websocket tabanlı gerçek zamanlı uygulamalar) için çekirdek ve network stack ayarlarını da planlamaya dahil etmek gerekir. Aksi halde sunucu kaynak hesaplama sadece donanım üzerinden yapılmış olur ve yazılım sınırları gözden kaçar.

Donanım ihtiyacı nasıl hesaplanır? Adım adım pratik model

Teori güzel ama eline kağıt kalem alıp donanım ihtiyacı nasıl hesaplanır diye sorduğunda, kullanabileceğin basit bir model lazım. Aşağıdaki adımlar sana iskelet bir yöntem sunar, her projede ayrıntıları özelleştirmen yeterli.

• İş yüklerini ayır: Web, API, veritabanı, cache, dosya sunucusu, arka plan işler gibi bileşenleri ayrı ayrı düşün.
• Her bileşen için trafik ve kullanım tahmini yap: Saniyedeki istek, eşzamanlı oturum, veri boyutu, sorgu sayısı gibi metrikleri kabaca çıkar.
• Kaynak başına düşen yükü tahmin et: Bir isteğin ortalama CPU süresi, RAM kullanımı, disk ve ağ erişimi ne kadar, test ya da referans sistemlerden ölç.
• Hedef kullanım oranını belirle: CPU, RAM, disk ve ağ için maksimum kullanımı yüzde 60 ila 70 bandında tutacak şekilde hesap yap.
• Güvenlik payı ve büyüme faktörü ekle: En az 1 ila 3 yıl sonrasını ve ani trafik sıçramalarını düşünerek yüzde 30 civarı ek kapasite ekle.

Bu adımları uyguladığında, ortaya çıkan tablo sana çekirdek sayısı, RAM miktarı, disk sayısı ve ağ kartı hızı için oldukça mantıklı bir aralık verir. Sonrasında bütçe, lisanslama ve donanım bulunabilirliği gibi pratik detaylara göre en yakın konfigürasyonu seçebilirsin.

Gelecek büyümeyi ve güvenlik payını hesaba katmak

Tek seferlik kampanya siteleri hariç, çoğu sistem için büyüme kaçınılmaz. Bugün rahat çalışan bir sunucu, altı ay sonra yeni özellikler, ek servisler ve artan kullanıcı sayısıyla aynı performansı vermeyebilir. Bu yüzden sunucu kapasite planlama yaparken sadece bugünü değil, işletmenin büyüme hedeflerini de denklemde tutmak gerekiyor.

Genelde iki tür güvenlik payından söz edilebilir. Biri trafik ve veri büyümesi için ayrılan fazladan kapasite, diğeri de donanım arızaları ve bakım senaryoları için ayırdığın rezerv. Örneğin iki fiziksel sunucu üzerinde çalışan bir kümede, tek sunucu devre dışı kaldığında diğerinin trafiğin tamamını makul bir performansla taşıyabilmesi önemli. Bunun için N artı 1, N artı 2 gibi tasarım kalıplarını da dikkate almak gerekiyor.

Ayrıca enerji, soğutma ve rack alanı gibi veri merkezi kaynaklarını da unutmamak lazım. Fiziksel sunucu seçerken güç tüketimi yüksek ama verimsiz bir model tercih etmek, ileride ek klima ve enerji maliyetleri olarak geri dönebilir. Yani donanım ihtiyacı nasıl hesaplanır sorusunun cevabı, sadece CPU ve RAM tablosundan ibaret değil.

Uzun vadede rahat nefes alacağın kapasite planı

Biraz zahmetli görünse de, başta sağlam bir kapasite analizi yapmak seni ileride çıkacak performans krizlerinden, panikle yapılan donanım siparişlerinden ve plansız gece çalışmalarından korur. Fiziksel sunucu tarafında değişiklik yapmak bulut kadar esnek olmadığı için, ilk satın alma kararını verirken elindeki veriyi sonuna kadar kullanmak ciddi avantaj sağlar.

Kendi projende hemen şimdi basit bir envanter çıkarabilirsin. Hangi bileşenler var, her biri bugün ne kadar kaynak kullanıyor, üç ay ve bir yıl içindeki büyüme hedefin ne, hepsini yan yana yaz. Ardından bu yazıdaki adımları bir kontrol listesi gibi üzerinden geçir ve mevcut tasarımını bu gözle yeniden değerlendir. Emin ol, küçük birkaç hesap bile sana yeni bakış açıları kazandıracak.

Son olarak şunu unutmamak iyi olur. Sunucu kapasite planlama tek seferlik bir iş değil, yaşayan bir süreç. İzleme verilerini düzenli gözden geçirir, darboğazları erken fark eder ve yeni projeleri bu perspektifle tasarlarsan, donanım tarafında uzun süre rahat edersin. Sıra sende, şimdi kendi sistemine şöyle gerçekçi bir gözle bakma zamanı.