Sanallaştırma & Bulut

    Bulut Sunucu mu Fiziksel Sunucu mu

    Bulut ve fiziksel sunucu arasındaki gerçek farklar ve karar verme kriterleri.

    10 dk okuma Güncellendi: 25 Ağustos 2026

    Altyapı kararı verirken karşına çıkan ilk çatal genellikle şudur: kaynağı bulut sunucu olarak dakikalar içinde açıp kullandığın kadar mı ödeyeceksin, yoksa fiziksel bir makineyi baştan kiralayıp tüm donanımı sen mi kullanacaksın? İki tarafın da savunucuları var ve ikisi de kendi bağlamında haklı; yanlış olan, kararı moda ya da alışkanlıkla vermek. Aynı iş yükü için biri diğerinin üç katı maliyet çıkarabilir ya da yarısı performans verebilir.

    Bu rehberde bulut sunucu ile fiziksel (bare metal) sunucu arasındaki farkı somut kriterlerle karşılaştıracağım: performans karakteristiği, maliyet yapısı, ölçeklenme hızı, dayanıklılık, veri konumu ve uyumluluk. Ayrıca sık yapılan hesap hatalarını, iki modeli birlikte kullanmanın nasıl göründüğünü ve kararını sayıya dökmek için kullanabileceğin basit bir yöntemi paylaşacağım.

    İki Modelin Temel Farkı#

    Fiziksel sunucu, adı üstünde, tek kiracılı bir makinedir: işlemcisi, belleği, diskleri ve ağ arayüzü tamamen senindir. Üzerinde hipervizör yoktur (sen kurmadıysan), kaynak paylaşımı yoktur, komşu yoktur. Bulut sunucu ise bir hipervizör üzerinde çalışan, API ile yönetilen, dakikalar içinde oluşturulup silinebilen ve genellikle kullandığın süre kadar faturalandırılan bir sanal makinedir.

    Buradaki asıl ayrım "sanal mı fiziksel mi" değil, elastikiyet ile tekil sahiplik arasındaki takastır. Bulut sana hızlı büyüyüp hızlı küçülme yeteneği verir; fiziksel sunucu ise sabit ve öngörülebilir bir kapasite ile katmansız bir performans verir. Bu takası anlamadan yapılan karşılaştırmalar hep eksik kalır.

    KriterBulut sunucuFiziksel sunucu
    Kurulum süresiDakikalarSaatler – günler
    Kaynak modeliPaylaşımlı ya da ayrılmışTamamen tekil
    ÖlçeklenmeAPI ile anlıkYeni donanım gerekir
    Maliyet yapısıDeğişken, kullanıma bağlıSabit aylık
    Sanallaştırma ek yüküVar (küçük ama var)Yok
    Donanım kontrolüYokTam
    Kesinti sonrası kurtarmaAnlık görüntüden hızlıYedekten daha yavaş

    Tablodaki "sanallaştırma ek yükü" satırı yanlış anlaşılmaya çok müsaittir: modern KVM üzerinde CPU tarafındaki kayıp çoğu iş yükü için %2%5 bandındadır, yani ihmal edilebilir. Fark asıl olarak I/O yoğun işlerde ve gecikmeye duyarlı senaryolarda ortaya çıkar.

    Performans: Fark Nerede Gerçekten Hissedilir#

    Bulut sunucuların performansı yıllar içinde ciddi biçimde iyileşti; virtio sürücüleri, SR-IOV ve NVMe geçişi sayesinde birçok iş yükünde fiziksel makineye yakın sonuçlar alınır. Yine de üç alanda fark ölçülebilir düzeyde kalır.

    Birincisi disk gecikmesi. Paylaşımlı depolama katmanı ya da ağ üzerinden bağlı blok cihazlar, yerel NVMe'ye göre daha yüksek ve daha değişken gecikme üretir. Bunu kendin ölçebilirsin:

    # Rasgele okuma gecikmesi ve IOPS ölçümü
    fio --name=gecikme-testi --ioengine=libaio --rw=randread --bs=4k \
        --size=1G --numjobs=1 --iodepth=1 --runtime=60 --time_based \
        --group_reporting
    
    # Çıktıda bakılacak alan:
    #   lat (usec): min=..., avg=..., 99.00th=[...]
    

    Ortalama gecikmeden çok 99. yüzdelik dilime bak; kullanıcıların hissettiği yavaşlık ortalamada değil kuyrukta saklanır. Yerel NVMe'li bir fiziksel makinede bu değer genellikle çok dar bir bantta kalır, paylaşımlı depolamada ise sıçramalar görülür.

    İkincisi CPU öngörülebilirliği. Bulut tarafında kaynak paylaşımlıysa steal time devreye girer ve aynı iş farklı zamanlarda farklı sürelerde biter. Ölçümü ve eşikleri CPU steal time nedir yazısında ayrıntılandırdım.

    Üçüncüsü ağ gecikmesi ve kararlılığı. Sanal ağ arayüzleri ek bir işlem katmanı ekler; yüksek paket hızı gerektiren iş yüklerinde (oyun sunucusu, VoIP, yüksek frekanslı API) bu fark hissedilir. Basit bir kontrol için:

    # Aynı veri merkezindeki bir hedefe gecikme dağılımı
    ping -c 100 185.12.34.56 | tail -2
    # rtt min/avg/max/mdev = 0.184/0.241/1.902/0.106 ms
    
    # Paket kaybı ve rota kararlılığı
    mtr -rwc 100 185.12.34.56
    

    Buradaki mdev (standart sapma) değeri ortalamadan daha bilgilendiricidir: yüksek sapma, ağın kalabalık olduğunu ve yükün paylaşıldığını gösterir.

    Maliyet: Sabit mi Değişken mi#

    Maliyet karşılaştırması, çoğu kararın gerçekte üzerinde döndüğü eksendir ve en çok hata da burada yapılır. Bulut, değişken maliyet modelidir: kullanmadığında ödemezsin, ihtiyaç anında hemen ölçeklenirsin. Fiziksel sunucu ise sabit maliyet modelidir: makine boşta dursa da aylık bedeli aynıdır.

    Kritik nokta şu: yük profilin sabit ve yüksekse, sabit maliyet neredeyse her zaman daha ucuzdur. Yük profilin dalgalıysa ve tepe noktası ortalamanın çok üstündeyse, değişken maliyet kazanır. Basit bir hesap örneği:

    SenaryoOrtalama kullanımTepe kullanımDaha ekonomik model
    Kurumsal site, sabit trafik%25%35Fiziksel / sabit kaynak
    E-ticaret, kampanya dönemli%20%300Bulut (esnek kapasite)
    Video kodlama, 7/24 dolu%85%95Fiziksel
    Test ve CI ortamı, iş saatleri%30%80Bulut (gece kapatılır)
    Veritabanı, sürekli yük%60%75Fiziksel / VDS

    Kendi durumunu değerlendirmek için basit bir kural kullanabilirsin: kaynağın ayda %60'tan fazla dolu çalışıyorsa sabit maliyetli bir model genellikle daha ucuza gelir. Bu eşiğin altında ve dalgalı bir profildeysen bulut esnekliği maliyeti düşürür. Hesabın ayrıntılarını, gizli kalem başlıklarını ve optimizasyon yollarını bulut maliyeti hesaplama yazısında ele aldım.

    Ölçeklenme, Dayanıklılık ve Kurtarma#

    Bulutun en güçlü tarafı ölçeklenme hızıdır. Kampanya sabahı iki sunucu daha açıp yük dengeleyiciye eklemek dakikalar sürer; akşam kapatırsın, fatura durur. Fiziksel tarafta aynı işlem donanım tedariki, kurulum ve konfigürasyon gerektirir — günler alır ve geri dönüşü yoktur, çünkü makineyi kapatsan da kirası devam eder.

    Dayanıklılık tarafında ise resim daha dengelidir. Bulut sağlayıcıları anlık görüntü (snapshot), imaj kopyalama ve otomatik yeniden başlatma gibi mekanizmalar sunar; bir makine öldüğünde yenisini dakikalar içinde ayağa kaldırabilirsin. Fiziksel tarafta ise donanım arızası gerçek bir kesinti demektir: disk değişimi, RAID yeniden yapılandırması ya da yedekten geri dönüş gerekir.

    # Fiziksel makinede disk sağlığını düzenli kontrol et
    smartctl -H /dev/sda
    smartctl -A /dev/sda | grep -E 'Reallocated|Pending|Wear_Leveling'
    
    # RAID durumunu izle (mdadm)
    cat /proc/mdstat
    

    Disk arızasının erken belirtilerini okumayı disk arızası tespiti (SMART ve RAID) yazısında anlattım; fiziksel sunucu kullanıyorsan bu, ihmal edilmemesi gereken bir alışkanlıktır. Her iki modelde de asıl güvence yedeklemedir: bulutta anlık görüntü almak kolay olduğu için yedekleme sanılır, oysa aynı altyapıda duran bir görüntü gerçek bir felaket kurtarma planı sayılmaz. Yedekleme stratejini Borg ile sunucu yedekleme yazısındaki gibi ayrı bir konuma kurmalısın.

    Veri Konumu, Uyumluluk ve Tekil Kiracılık#

    Bazı kararlarda performans ve maliyet ikinci plandadır; belirleyici olan mevzuattır. Kişisel veri işleyen kurumlarda verinin nerede tutulduğu, kimlerin fiziksel erişimi olduğu ve altyapının başka kiracılarla paylaşılıp paylaşılmadığı denetim konusudur. KVKK kapsamındaki verilerde veri merkezinin Türkiye'de olması ve erişim kayıtlarının tutulması, birçok kurumsal sözleşmenin ön şartıdır.

    Fiziksel sunucunun burada net bir üstünlüğü vardır: tek kiracılısındır. Aynı işlemcide başka bir müşterinin kodu çalışmaz, yan kanal riskleri gündeme gelmez, disk şifrelemesini uçtan uca sen yönetirsin. Kendi donanımını bir veri merkezine yerleştirmek istiyorsan bunun adı colocation'dır; ayrıntılarını colocation nedir yazısında bulabilirsin.

    Bulut tarafında ise izolasyon hipervizör seviyesindedir ve pratikte çok büyük çoğunluk için yeterlidir. Yine de sözleşmelerde şu üç maddeyi netleştirmen gerekir: verinin fiziksel konumu, yedeklerin nerede saklandığı ve sağlayıcı personelinin erişim politikası. Bu maddeleri yazılı olarak almadan hassas veri taşıma kararı verme.

    İkisini Birlikte Kullanmak#

    Karar her zaman "ya o ya bu" değildir; pratikte en verimli mimarilerin çoğu karmadır. Yaygın ve işe yarayan bir düzen şöyledir: sabit ve ağır yükü fiziksel makinede tut, dalgalanan ve geçici yükü bulutta karşıla.

    1. Veritabanı fiziksel makinede. Sürekli yük, yüksek I/O, gecikme hassasiyeti — hepsi fiziksel tarafın güçlü olduğu alanlar.
    2. Uygulama sunucuları bulutta. Trafik arttığında yeni örnek ekle, azaldığında kapat.
    3. Toplu işler ve CI bulutta. Gece derlemeleri için sabit kapasite tutmak israftır.
    4. Yedekler üçüncü bir konumda. Ne uygulamanın ne de veritabanının bulunduğu yerde.

    Bu düzenin bedeli ağ karmaşıklığıdır: iki ortam arasında güvenli ve düşük gecikmeli bir bağlantı kurman gerekir. Özel ağ (private network) ya da site-to-site VPN bunun standart çözümüdür. Karma modelin bulut tarafındaki adı hybrid cloud'dur; kurgusunu ve tuzaklarını public, private ve hybrid cloud modelleri yazısında ayrıntılandırdım.

    Sık Yapılan Hatalar ve Tuzaklar#

    En yaygın hata, buluta taşınıp mimariyi olduğu gibi bırakmak. Bulutun maliyet avantajı elastikiyetten gelir; makineleri 7/24 açık tutup hiç ölçeklemiyorsan, sabit kaynaklı bir üründen daha pahalıya çalışırsın ve karşılığında sadece paylaşımlı performans alırsın. Buluta geçiyorsan otomatik ölçekleme ya da en azından planlı açma-kapama kurmalısın.

    İkinci hata, fiziksel sunucuyu "her zaman daha hızlı" saymak. Eski nesil bir işlemciye sahip fiziksel makine, yeni nesil bir bulut sunucudan yavaş olabilir. Karşılaştırmayı model adına göre değil ölçümle yap; sysbench ve fio sonuçları ilan metninden daha güvenilirdir.

    Üçüncü tuzak, maliyeti sadece sunucu bedeli üzerinden hesaplamak. Bulutta çıkış trafiği (egress), anlık görüntü depolaması, yedek saklama, IP adresleri ve yönetilen servisler faturanın büyük bölümünü oluşturabilir. Fiziksel tarafta ise donanım arızası riskini karşılamak için ihtiyaç duyacağın yedek kapasite bir maliyet kalemidir. İki tarafı da toplam sahip olma maliyeti üzerinden karşılaştır.

    Dördüncü hata, geri dönüşü planlamamak. Bir modele geçerken, gerekirse geri dönüşün ne kadar süreceğini ve neye mal olacağını baştan yaz. Sağlayıcıya özgü yönetilen servislere ne kadar bağlanırsan geri dönüş o kadar zorlaşır; bu riskin adı satıcı kilididir ve vendor lock-in yazısında nasıl azaltılacağını anlattım.

    Sıkça Sorulan Sorular#

    Bulut sunucu fiziksel sunucudan yavaş mı#

    Genel olarak hayır, ama iş yüküne bağlı. Modern sanallaştırmada CPU tarafındaki ek yük çoğu uygulama için %2%5 bandında kalır ve fark edilmez. Asıl ayrışma disk gecikmesi ve ağ paket işleme performansında görülür; paylaşımlı depolama kullanan bir bulut sunucu, yerel NVMe'li fiziksel makineye göre daha değişken gecikme üretebilir. Karar vermeden önce kendi iş yükünle fio ve sysbench ölçümü yapmak en doğrusudur.

    Fiziksel sunucu ne zaman daha ucuza gelir#

    Kaynağın sürekli dolu çalıştığı senaryolarda. Pratik bir eşik olarak, ortalama kullanımın ayda %60'ın üzerindeyse sabit maliyetli model genellikle öne geçer. Video kodlama, sürekli çalışan veritabanları, büyük derleme sunucuları ve yoğun veri işleme bu kategoriye girer. Dalgalı ve tepe noktası ortalamanın kat kat üstünde olan iş yüklerinde ise bulut daha ekonomiktir.

    Bulut sunucuda verim daha mı güvensiz#

    Güvenlik seviyesi modelden çok yapılandırmaya bağlıdır. Bulut sağlayıcıları hipervizör izolasyonu, ağ segmentasyonu ve altyapı sertifikasyonları sunar; çoğu kurum için bu yeterlidir. Fiziksel sunucunun üstünlüğü tek kiracılı olmasıdır — aynı donanımda başka müşteri bulunmaz. Hassas veri işliyorsan asıl bakman gereken şey verinin konumu, şifreleme ve erişim politikalarıdır; her iki modelde de kötü yapılandırma en büyük risktir.

    Fiziksel sunucudan buluta taşınmak ne kadar sürer#

    Uygulamanın karmaşıklığına bağlı olarak birkaç saatten birkaç haftaya kadar değişir. Tek sunuculu basit bir web sitesi için veri kopyalama ve DNS geçişi birkaç saatte tamamlanır. Çok bileşenli, durum tutan (stateful) sistemlerde ise veri senkronizasyonu, bağımlılık haritası ve geri dönüş planı hazırlamak asıl zamanı alır. Kesintiyi azaltmak için DNS TTL'ini geçişten en az bir gün önce düşürmek şarttır.

    Aynı anda hem bulut hem fiziksel kullanabilir miyim#

    Evet ve bu, pratikte en verimli mimarilerden biridir. Sabit ve ağır yükü (veritabanı, depolama) fiziksel makinede tutup, dalgalanan uygulama katmanını bulutta ölçeklemek hem maliyeti hem performansı optimize eder. Bu kurulumun tek gerçek zorluğu iki ortam arasındaki güvenli ve düşük gecikmeli bağlantıdır; özel ağ ya da site-to-site VPN standart çözümdür.

    Karar vermek için hangi ölçümleri toplamalıyım#

    En az bir aylık veri toplamanı öneririm: saat bazında CPU kullanımı, bellek kullanımı, disk IOPS ve gecikme, aylık toplam çıkış trafiği ve tepe eşzamanlı istek sayısı. Bu beş metrik hem doğru boyutlandırma yapmanı hem de iki modeli aynı temelde fiyatlandırmanı sağlar. Ölçüm olmadan yapılan karşılaştırmalar neredeyse her zaman ya aşırı kapasiteyle ya da beklenmedik yavaşlıkla sonuçlanır.

    Kapanış#

    Bulut ile fiziksel sunucu arasındaki seçim, teknoloji tercihi değil iş yükü profili kararıdır. Yükün dalgalı ve öngörülemezse esneklik kazandırır; sabit ve yoğunsa tekil sahiplik kazandırır. Aklında tutman gereken dört alışkanlık şunlar: kararı en az bir aylık ölçümle ver, maliyeti sunucu bedeliyle değil toplam sahip olma maliyetiyle hesapla, karma mimariyi bir seçenek olarak masada tut ve geri dönüş planını baştan yaz.

    Esneklik ve hızlı ölçeklenme senin için öncelikliyse bulut sunucu paketlerimiz doğru başlangıçtır; sabit ve yoğun yükte en iyi fiyat/performansı arıyorsan dedicated sunucu ya da ara bir çözüm olarak VDS seçeneklerine bakabilirsin. Kendi donanımını veri merkezimize yerleştirmek istersen colocation hizmetimiz, tüm bu altyapının işletimini bize bırakmak istersen sunucu yönetimi hizmetimiz devreye girer.

    BulutFiziksel SunucuAltyapı

    Uygulamaya geçmeye hazır mısınız?

    NVMe SSD, ücretsiz SSL ve %99.9 uptime garantisiyle Clou.TR hosting ve sunucu çözümleriyle projenizi hayata geçirin.