Bulut Sunucu mu Fiziksel Sunucu mu: Maliyet ve Performans Karşılaştırması

Yazar:komut.io ekibi Rehber & İpuçları
0 Yorum

Yıllar önce bir müşterimiz beni aradı: “Abicim buluta geçtik, fatura geçen aya göre üç katına çıktı, ne yapacağız?” O telefon konuşması benim için bir dönüm noktasıydı. Bulut vs. fiziksel sunucu tartışması aslında hiç de “hangisi daha iyi” meselesi değil, “ne zaman hangisi” meselesi. Bu yazıda sizi pazarlama laflarından uzak tutarak gerçek sayılara, gerçek senaryolara ve gerçek hesaplara davet edeceğim.

Temel Farkları Anlamak: Yanılgılar ve Gerçekler

İlk yanılgıyla başlayalım: “Bulut her zaman daha pahalıdır.” Yanlış. İkinci yanılgı: “Fiziksel sunucu her zaman daha performanslıdır.” O da yanlış.

Gerçek şu ki her ikisi de kendi kullanım senaryosunda kazanır. Bir startup için AWS ya da Azure’da başlamak mantıklı; donanım yatırımı yapmadan büyüyebilirsiniz. Ama aynı startup iki yıl sonra sabit bir yük altında çalışıyorsa, o noktada fiziksel sunucuya geçiş ciddi maliyet tasarrufu sağlar.

Önce neyi karşılaştırdığımızı netleştirelim:

  • IaaS bulut (AWS EC2, Azure VM, GCP Compute): Saatlik/aylık kiralama, tam yönetilen altyapı
  • Colocation (colo): Kendi sunucunuzu veri merkezine yerleştirme, yalnızca yer ve bant genişliği kiralama
  • On-premise: Kendi ofis ya da veri merkezinizde fiziksel sunucu

Bu üçü arasındaki fark hem maliyet hem sorumluluk açısından çok farklı. Yazımızda çoğunlukla IaaS bulut ile colocation/on-premise fiziksel sunucu karşılaştırmasını yapacağız.

Maliyet Hesabı: Gerçek Rakamlarla Yüzleşmek

Teorik konuşmak yerine somut bir senaryo üzerinden gidelim. Diyelim ki şu özelliklerde bir iş yükünüz var:

  • 8 vCPU, 32 GB RAM
  • 500 GB SSD depolama
  • Aylık 10 TB trafik
  • 7/24 çalışan, kritik olmayan bir web uygulaması

AWS üzerinde bu yük ne kadar tutar?

# AWS EC2 fiyat hesabı (yaklaşık, 2024 yılı us-east-1 fiyatları)
# m5.2xlarge: 8 vCPU, 32 GB RAM
# On-demand: ~0.384 USD/saat
# Aylık: 0.384 * 730 = ~280 USD

# 1 yıllık rezervasyon ile: ~0.228 USD/saat
# Aylık: 0.228 * 730 = ~166 USD

# EBS gp3 500 GB: ~40 USD/ay
# Veri transferi 10 TB (ilk 1 TB ücretsiz): ~0.09 * 9 * 1024 = ~830 USD
# Toplam on-demand: 280 + 40 + 830 = ~1150 USD/ay
# 1 yıl rezervasyon: 166 + 40 + 830 = ~1036 USD/ay

echo "Dikkat: Veri transferi maliyeti genellikle göz ardı edilir!"

Evet, gözünüz yanlış okumadı. Veri transferi maliyeti bazen compute maliyetinin üç katına çıkabiliyor. Bu “egress trap” dediğimiz tuzak, pek çok ekibin faturalarını patlatıyor.

Fiziksel sunucu aynı iş yükü için ne kadar tutar?

# Örnek Dell PowerEdge R450 yapılandırması
# 2x Intel Xeon Silver 4314 (16 core/32 thread toplam)
# 32 GB DDR4 ECC RAM
# 2x 480 GB SSD (RAID 1)
# Tahmini donanım maliyeti: ~25.000 - 35.000 TL (2024)
# Ya da ~800 - 1100 USD

# Colocation maliyeti (örnek Türkiye veri merkezi)
# 1U yer: ~50-80 USD/ay
# 1 Gbps port (100 Mbps garantili): ~100-150 USD/ay
# Toplam aylık: ~150-230 USD/ay

# 3 yıl üzerinden hesap:
# Donanım: 1000 USD (tek seferlik)
# Colo 36 ay x 200 USD = 7200 USD
# Toplam 3 yıl: ~8200 USD
# Aylık ortalama: ~228 USD

echo "Bulut (yıllık rezervasyon, trafik hariç): ~206 USD/ay"
echo "Fiziksel (colo, 3 yıl ortalama): ~228 USD/ay"
echo "Ama: Buluta trafik eklenince fark dramatik açılıyor"

Trafiği hesaba katınca bulutun maliyeti ayda 1000 USD’ye yaklaşırken, fiziksel sunucuda trafik maliyeti sabit kalıyor. İşte asıl fark burada.

Performans Karşılaştırması: Sayılar Yalan Söylemez

Bulut sunucuları “noisy neighbor” problemiyle tanınır. Aynı fiziksel donanımı paylaşan sanal makineler birbirini etkiler. Özellikle disk I/O ve ağ performansında bu etki belirgindir.

# Disk I/O testi - fio ile
# Bulut sunucusunda (AWS gp3 EBS)
fio --name=randwrite --ioengine=libaio --iodepth=32 
    --rw=randwrite --bs=4k --direct=1 --size=4G 
    --numjobs=4 --runtime=60 --group_reporting

# Tipik sonuç (AWS gp3):
# IOPS: ~3000-16000 (gp3 baseline 3000, burst ile)
# Latency: ~1-2ms

# Fiziksel NVMe SSD (Samsung 980 Pro gibi)
# IOPS: ~500.000+
# Latency: ~0.1ms

# Fark: 10-50x daha iyi disk performansı fiziksel sunucuda

Bu fark veritabanı yoğun uygulamalar için kritik önem taşır. PostgreSQL, MySQL veya MongoDB gibi sistemler disk I/O’ya hassastır. Ancak dikkat: AWS io2 Block Express gibi yüksek performanslı seçenekler var, ama onların fiyatı da buna göre artıyor.

# Ağ performansı testi
# iperf3 ile throughput ölçümü

# Bulut içi (aynı AZ'de iki VM arası)
iperf3 -c <hedef_ip> -t 30 -P 4
# Tipik: 5-25 Gbps (instance tipine göre)

# Fiziksel sunucu (10GbE ile)
iperf3 -c <hedef_ip> -t 30 -P 4
# Tipik: 9.4-9.8 Gbps (10GbE line-rate'e yakın)

# CPU performansı - sysbench ile
sysbench cpu --cpu-max-prime=20000 --threads=8 run
# Bulut: CPU steal time problemi olabilir
# vmstat ile kontrol:
vmstat 1 10 | awk '{print $16}' # steal sütunu
# Steal > 5% ise ciddi performans kaybı var demektir

CPU steal time bulut ortamlarında sıkça karşılaşılan ve genellikle göz ardı edilen bir metriktir. Fiziksel sunucuda bu sıfırdır.

Ne Zaman Bulut, Ne Zaman Fiziksel?

Bu sorunun cevabı teknik değil, iş gereksinimleri odaklı olmalı. Yıllar içinde şu kalıbı fark ettim:

Bulut Tercih Edilmeli: Dinamik Yükler

# Auto-scaling örneği - bir e-ticaret sitesinin yük profili
# Normal gün: 2 instance yeterli
# Kampanya günü: 20 instance gerekiyor

# AWS Auto Scaling Group yapılandırması
aws autoscaling create-auto-scaling-group 
    --auto-scaling-group-name "ecommerce-asg" 
    --min-size 2 
    --max-size 20 
    --desired-capacity 2 
    --launch-template LaunchTemplateId=lt-xxxxxxxx 
    --target-group-arns arn:aws:elasticloadbalancing:...

# Ölçekleme politikası - CPU %70 üzerinde yeni instance aç
aws autoscaling put-scaling-policy 
    --auto-scaling-group-name "ecommerce-asg" 
    --policy-name "scale-out-cpu" 
    --policy-type TargetTrackingScaling 
    --target-tracking-configuration '{
        "PredefinedMetricSpecification": {
            "PredefinedMetricType": "ASGAverageCPUUtilization"
        },
        "TargetValue": 70.0
    }'

Eğer yükünüz öngörülemez ve anlık ölçekleme gerekiyorsa, bulut tartışmasız kazanır. Siyah Cuma’da 10 katına çıkan bir trafik için fiziksel sunucu satın almanın mantığı yok; yılın 350 günü boş kalacak.

Bulutun avantajlı olduğu senaryolar:

  • Startup ve MVP aşaması: Donanım yatırımı olmadan hızlı başlangıç
  • Değişken trafik: Günlük/mevsimsel yük dalgalanması yüksek olan sistemler
  • Global dağılım: Birden fazla coğrafi bölgede düşük gecikme gereksinimi
  • Felaket kurtarma (DR): İkincil site için düşük maliyetli bekleme ortamı
  • Geliştirme/test ortamları: Gerektiğinde açılıp kapatılan kısa ömürlü ortamlar

Fiziksel Sunucu Tercih Edilmeli: Sabit ve Yoğun Yükler

Şu senaryoyu düşünün: 7/24 çalışan, sabit yük altında bir PostgreSQL veritabanı sunucusu. Ayda 50 TB veri işliyor, 100 GB RAM kullanıyor.

# PostgreSQL performans metrikleri izleme
# Fiziksel sunucuda bu sorgu sub-millisecond çalışır
# Bulut EBS'de 5-10ms gecikme eklenebilir

# Hangi tablolar disk I/O'ya yol açıyor?
SELECT schemaname, tablename, 
       heap_blks_read, heap_blks_hit,
       round(heap_blks_hit::numeric / 
             nullif(heap_blks_hit + heap_blks_read, 0) * 100, 2) as cache_hit_ratio
FROM pg_statio_user_tables
WHERE heap_blks_read > 0
ORDER BY heap_blks_read DESC
LIMIT 20;

# Cache hit ratio %95 altında ise disk I/O darboğaz
# Fiziksel NVMe'de bu sorun çok daha az belirgin

Fiziksel sunucunun avantajlı olduğu senaryolar:

  • Yoğun veritabanı iş yükleri: OLTP, yüksek I/O gerektiren sistemler
  • Düzenleyici uyumluluk: BDDK, KVKK gibi mevzuatlarda veri yerindeliği zorunluluğu
  • Sabit ve öngörülebilir yük: 3 yıl boyunca %70-80 CPU kullanımı
  • Büyük veri hacimleri: Aylık on’larca TB veri transferi olan sistemler
  • Düşük gecikme gereksinimleri: HFT, oyun sunucusu, gerçek zamanlı işleme
  • GPU yoğun iş yükleri: ML training, render farm (bulut GPU maliyeti çok yüksek)

Hybrid Yaklaşım: En İyi İki Dünya

Pratikte en akıllıca mimari çoğu zaman hibrit oluyor. Bir müşterimde şu mimarisini uyguladık:

# Hibrit mimari örneği
# Statik/sabit yük: Fiziksel sunucu (colo'da)
# Dinamik burst yük: Bulut

# Temel yük (baseline) - fiziksel sunucu:
# - Veritabanı sunucuları
# - Uygulama sunucuları (min 4 node)
# - Depolama sistemi

# Burst kapasitesi - bulut:
# - Ekstra uygulama node'ları (otomatik ölçekleme)
# - CDN ve edge servisleri
# - Yedekleme ve DR ortamı

# VPN ile hybrid bağlantı
# strongSwan ile site-to-site VPN
cat /etc/ipsec.conf
# conn hybrid-cloud
#     left=%defaultroute
#     leftsubnet=10.0.0.0/24
#     right=<bulut_gateway_ip>
#     rightsubnet=172.16.0.0/16
#     ike=aes256-sha2_256-modp2048
#     esp=aes256-sha2_256
#     auto=start

systemctl status strongswan

Bu yapıda fiziksel sunucular baseline yükü karşılıyor, kampanya dönemlerinde bulut devreye giriyor. Yılın 330 günü fiziksel sunucunun düşük maliyetinden faydalanıyorsunuz, 35 kritik günde bulutun esnekliğinden.

Gizli Maliyetler: Kimse Sizi Uyarmıyor

Karar verirken göz ardı edilen maliyet kalemleri var. İkisi için de geçerli:

Bulutun gizli maliyetleri:

  • Egress trafiği: Bahsettiğimiz AWS veri transfer ücreti, beklenmedik faturaların başlıca nedeni
  • Snapshot ve yedek depolama: EBS snapshot’ları birikince aylık yüzlerce dolar olabiliyor
  • NAT Gateway: VPC içindeki trafikte NAT Gateway ücreti GB başına ekleniyor
  • Support planları: Business destek planı aylık yüzlerce dolara başlıyor
  • Inter-AZ trafik: Aynı bölgede farklı AZ’ler arası trafik de ücretli
# AWS maliyet anomalisi tespiti - Cost Explorer CLI ile
aws ce get-cost-and-usage 
    --time-period Start=2024-01-01,End=2024-01-31 
    --granularity MONTHLY 
    --metrics BlendedCost 
    --group-by Type=DIMENSION,Key=SERVICE 
    --query 'ResultsByTime[0].Groups[*].[Keys[0],Metrics.BlendedCost.Amount]' 
    --output table

# Beklenmedik maliyet artışı var mı diye kontrol:
aws ce get-anomalies 
    --date-interval StartDate=2024-01-01,EndDate=2024-01-31 
    --query 'Anomalies[*].[AnomalyId,RootCauses[0].Service,Impact.TotalImpact]'

Fiziksel sunucunun gizli maliyetleri:

  • Donanım arızası ve yedek parça: RAID kartı, disk, PSU arızaları beklenmedik masraf yaratır
  • Yönetim zamanı: IT ekibinin donanım bakımına harcadığı süre maaş maliyetine yansır
  • Kapasite planlaması hatası: 3 yıl sonraki yükü öngöremezseniz ya yetersiz ya da fazla donanım alırsınız
  • Lisanslama: Windows Server, RHEL gibi lisanslar donanım başına sabit maliyet
# Fiziksel sunucu sağlık izleme - iDRAC/IPMI ile
# Dell iDRAC üzerinden sistem durumu kontrolü
ipmitool -I lanplus -H <idrac_ip> -U root -P <pass> sdr type Temperature
ipmitool -I lanplus -H <idrac_ip> -U root -P <pass> sdr type Fan
ipmitool -I lanplus -H <idrac_ip> -U root -P <pass> sel list last 20

# Disk sağlık kontrolü - smartmontools
smartctl -a /dev/sda | grep -E "Reallocated|Pending|Uncorrectable|Temperature"

# RAID durumu
megacli -LDInfo -Lall -aALL | grep -E "State|Cache Policy|Disk Cache Policy"

Donanım yönetimi gerçekten zaman alır. Bir RAID grubu çöktüğünde gece 2’de uyandıysanız ne demek istediğimi anlarsınız.

Karar Vermek İçin Basit Çerçeve

Karmaşık formüllere gerek yok. Şu soruları kendinize sorun:

Yük profili ne?

  • Yük %30’dan fazla dalgalanıyorsa: Bulut lehine puan
  • Yük sabit ve öngörülebilirse: Fiziksel lehine puan

Trafik hacmi ne kadar?

# Aylık trafik hesaplama - nginx log analizi
awk '{sum += $10} END {printf "Toplam: %.2f GBn", sum/1024/1024/1024}' /var/log/nginx/access.log

# Ya da vnstat ile
vnstat --months -i eth0
  • Aylık 10 TB üzerinde trafik varsa: Fiziksel lehine puan (bulut egress maliyeti)
  • Trafik düşükse: Bulut avantajlı olabilir

Ekip kapasitesi var mı?

  • Donanım yönetecek yetkili sysadmin yoksa: Bulut daha uygun
  • Güçlü bir altyapı ekibi varsa: Fiziksel tercih edilebilir

Uyumluluk gereksinimleri?

  • KVKK kapsamında hassas veri varsa ve yurt dışı bulut düşünülüyorsa: Hukuki danışmanlık şart
  • Finansal sektör, sağlık: Özel mevzuat incelemesi gerekli

Sonuç

Sizi bir karardan uzak tutmak için değil, bilinçli karar vermeniz için bu yazıyı yazdım. Bulut sihirli değnek değil, fiziksel sunucu de dinozor değil. Her ikisi de 2024’te geçerli, mantıklı seçenekler.

Kendi deneyimlerimden çıkardığım sonuç şu: Yükünüz dinamikse ve veri transferiniz düşükse bulutla başlayın. Yılda %20’den az dalgalanan, sabit bir yük altında çalışıyorsanız ve özellikle veri hacmi büyükse, 18-24 ay içinde fiziksel sunucuya yatırım yapmak ekonomik açıdan çok daha mantıklı.

Hibrit mimari ise çoğu zaman en pragmatik cevap. Sabit yükünüzü fiziksel sunucuyla karşılayın, burst kapasitesini bulutla karşılayın. Bu yaklaşım hem maliyet optimizasyonu hem de esneklik açısından en iyi dengeyi sağlıyor.

Son bir not: Kararı yalnızca BT ekibi vermesin. CFO, geliştirme ekibi ve güvenlik ekibi bu tartışmaya dahil edilmeli. Çünkü “en iyi teknik seçim” ile “en iyi iş kararı” her zaman aynı şey değil.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir