Bulut sunucu nasıl çalışır? Sıfırdan net açıklama

Bulut sunucu, uygulamalarınızı “tek bir fiziksel makineye” değil, kaynak havuzundan alınan hesaplama gücü ve depolama kapasitesine bağlar. Bu modelde performans, erişim, yedekleme ve ölçekleme; altyapının nasıl tasarlandığına göre şekillenir. Bu yazıda bulut sunucunun bileşenlerini tek tek ele alacak, bir isteğin sunucuya gelmesinden uygulamanın çalışmasına kadar akışı sıfırdan anlatacağım.

Bulut sunucu neyi “bulut” yapar?

Bulut sunucuda “bulut” terimi, tek bir bilgisayarın uzaktan çalıştırılması değil; hesaplama (CPU/RAM), ağ (network) ve depolama (disk/obj storage) gibi kaynakların sanallaştırma katmanıyla soyutlanması anlamına gelir.

Örneğin bir VDS/VPS gibi kavramlar her zaman “bulut” kelimesiyle anılmasa da, mimarinin mantığı benzerdir: fiziksel donanım üzerinde sanal makine/izole ortamlar oluşturulur. Fark, bulut platformlarında bu kaynakların genellikle otomasyonla yönetilmesi ve talep oldukça ölçeklenebilmesidir.

Sanallaştırma katmanı (hypervisor)

Bulut altyapısında en kritik parçalardan biri hypervisor katmanıdır. Bu katman, fiziksel sunucuyu birden fazla sanal ortamla paylaşmayı sağlar.

VM (Virtual Machine) yaklaşımı: Uygulama, sanki kendi makinesi varmış gibi çalışır.
Container yaklaşımı: Uygulamalar daha hafif izolasyonla çalışır (her zaman “sunucu” gibi görünmeyebilir).

NetKıyas gibi hosting karşılaştırma platformlarında kullanıcıların gördüğü “VDS/VPS” genelde VM tabanlı yaklaşıma daha yakındır. Managed servislerde ise (ör. yönetilen veritabanı) uygulama ve ortam yönetimi sağlayıcı tarafına taşınır.

Kaynak havuzu: Sunucu tek değil, kapasite havuzdan gelir

Bulut sunucuyu “çalıştıran şey” fiziksel sunucunuzdan çok, veri merkezindeki çok sayıda fiziksel sunucudan oluşan kaynak havuzudur. Siz bir bulut sunucu oluşturduğunuzda, platform otomatik olarak size belirli bir miktarda kaynak (CPU/RAM), sanal ağ arayüzleri ve bir depolama bağlantısı tahsis eder.

Bu yüzden bulut sunucuda şu yapı sık görülür:

Compute havuzu: CPU/RAM
Network havuzu: bant genişliği/erişim politikaları
Storage havuzu: blok depolama (block storage) veya nesne depolama (object storage)

Fiyatlandırma neden “kullandıkça”ya döner?

Bulut platformları kaynak tahsisini otomatik yaptığı için faturalama çoğunlukla şu mantığa dayanır:

Sabit paket (ör. belirli RAM/CPU): aylık ücret
Kullanıma dayalı (ör. transfer, ek işlem): tüketim arttıkça maliyet artışı

Bu ayrım, doğru boyutlandırma yapıldığında maliyeti düşürür. Yanlış boyutlandırmada ise hem performans hem de bütçe etkilenir.

Depolama: VM diski mi, ayrı depolama mı?

Bulut sunucuda depolama iki ana modelde karşımıza çıkar:

Blok depolama (block storage): VM’ye “disk” gibi bağlanır.
Nesne depolama (object storage): dosyalar parçalı saklanır; genellikle yedek, statik içerik veya arşiv için kullanılır.

Kullanıcı açısından önemli pratik fark şudur:

Blok depolama: uygulama dosyaları, veritabanı verisi (uygun kurulumla)
Nesne depolama: yedek (backup) arşivi, medya dosyaları, günlük log arşivi

Kalıcı veri ve performans

Bulut sunucuda “instance” yeniden oluşturulsa bile verinin kalıcı olması, genellikle depolama katmanının tasarımına bağlıdır. Doğru kurulmuş sistemde:

Uygulama dosyaları için VM diski veya mount edilmiş blok depolama kalıcıdır.
Kritik veriler (veritabanı) düzenli yedeklenir ve ayrı bir güven alanına aktarılır.

Depolama performansı; IOPS, throughput ve disk tipi (ör. NVMe benzeri düşük gecikmeli katmanlar) ile belirlenir. Bu yüzden bulutta “CPU/RAM aldım” tek başına yeterli değildir; disk/IO ayarı da belirleyicidir.

Ağ (network): Alan adından sunucuya giden yol

Bulut sunucunun çalışması sadece “VM açmak” değildir. İletişimin temel akışı DNS ve yönlendirme katmanlarıyla ilerler.

Adresleme: DNS kayıtları

Bir alan adını (domain) tarayıcıya yazdığınızda ilk aşamada DNS devreye girer. DNS, domain’i IP adresine çevirir.

Bulutta IP adresi, genellikle sanal ağ bileşenlerine bağlıdır.
CDN (varsa) araya girer ve bazı istekleri en yakın noktadan karşılar.

Yönlendirme ve portlar

DNS sonrası trafik, IP üzerinden portlara gider.

Web için genellikle 80/443
Uygulama servisleri için farklı portlar (örn. 3000, 8080)
Yönetim erişimi için (örn. SSH) port ve güvenlik politikaları

Burada “security group / firewall” benzeri katmanlar (sağlayıcıya göre ad değişir) trafiği filtreler. Bu filtreleme doğru kurulmazsa hem güvenlik riski oluşur hem de performans etkilenir.

Sunucu içinde istek nasıl işlenir? (uçtan uca)

Bulut sunucuda bir HTTP isteğinin işlenme akışı şu şekilde düşünülür:

İstek internete girer (tarayıcı → domain çözümleme → IP)
Trafik yük dengeleyici/edge üzerinden doğru hedefe yönlendirilir (varsa)
Sunucu üzerinde web sunucusu veya uygulama katmanı gelen isteği alır
Uygulama kodu çalışır (runtime)
Gerekirse veritabanına sorgu gider
Cevap hazırlanır, geri gönderilir

Web sunucusu ve uygulama katmanı

Çoğu kurulumda şu bileşimler görülür:

Nginx/Apache: HTTP/HTTPS uç noktası, statik dosya, reverse proxy
Uygulama runtime: PHP-FPM, Node.js, Python (uWSGI/Gunicorn), Java uygulama sunucusu veya container runtime

Buradaki kritik nokta: Bulut sunucunun kaynakları bu katmanların her birini etkiler. Örneğin CPU artışı sadece kodu hızlandırmakla kalmaz; TLS işlemleri ve proxy katmanı da dolaylı olarak etkilenir.

Ölçekleme: Bulutun asıl farkı burada görünür

Bulut sunucunun “bulut” değerini en çok ölçekleme kısmı verir.

İki temel yaklaşım vardır:

Dikey ölçekleme (scale-up): VM’in CPU/RAM kapasitesini artırma
Yatay ölçekleme (scale-out): Aynı uygulamadan birden fazla instance çalıştırma ve trafik dağıtma

Ölçekleme neyi çözer?

Ani trafik artışı → instance sayısı artar
Tek noktada darboğaz → yük dengeleyici ile dağıtım yapılır
Bakım/arıza → başka instance üzerinden servis devam eder

Yatay ölçeklemenin ön şartı şudur: Uygulama “tek instance’a bağlı” kalmamalıdır. Oturum (session) yönetimi, dosya paylaşımı, cache ve veritabanı mimarisi ölçeklemeye uygun tasarlanmalıdır.

Yük dengeleme (load balancing)

Yük dengeleyici genellikle şu işleri yapar:

Gelen trafiği birden fazla hedefe dağıtmak
Sağlık kontrolü (health check) ile arızalı instance’ı devre dışı bırakmak
TLS (HTTPS) sonlandırma veya passthrough senaryoları

Bu sayede bir instance düşse bile trafik diğerlerine yönlenir.

Yedekleme ve dayanıklılık: Bulutta “veriyi koruma” tasarım meselesi

Bulut sunucuda yedekleme sadece “snapshot almak” değildir. Başarılı yedekleme planında şu üç kavram net olmalıdır:

Neyi yedekliyorsun? (VM diski, veritabanı, uygulama dosyaları)
Ne sıklıkla? (günlük, saatlik)
Nereye gidiyor? (aynı depolama alanında mı, ayrı lokasyonda mı)

Snapshot vs gerçek yedek

Snapshot: Belirli anın kopyası gibi düşünülebilir. Hızlı geri dönüş sağlar.
Gerçek yedek: Veritabanı için mantıksal dump, dosyalar için arşiv veya replikasyon tabanlı yaklaşım olabilir.

Uygulama türüne göre ikisi birlikte kullanılır. Örneğin veritabanında saatlik restore ihtiyacı varsa sadece snapshot yetmez.

Bulut sunucu ile “managed” arasındaki fark

Bulutta her zaman “ben VM alıp kendim her şeyi yönetirim” modeli yoktur. Managed servislerde sağlayıcı bazı operasyonları sizin yerinize yürütür.

Managed veritabanı: yama (patch), replikasyon, yedek planı sağlayıcı tarafından yönetilebilir
Managed cache: Redis/Memcached kümesi yönetilir
Container platformları: dağıtım ve ölçekleme otomasyonu sağlar

Bu ayrım, arıza anında müdahale süresini ve güvenilirliği etkiler. Aynı zamanda sorumluluk sınırını belirler: Loglar, alarm kuralları ve erişim izinleri sizde mi sağlayıcıda mı?

Güvenlik: Bulut sunucuda yanlış kurulumun bedeli büyür

Bulut sunucuda güvenlik; VM’in içindeki ayarlardan başlayıp bulut ağ politikalarına kadar uzanır.

Kritik kontrol listesi:

Kim erişebilir? (SSH/RDP erişimi: IP bazlı kural ve anahtar)
Hangi portlar açıktır? (sadece gerekli portlar)
Şifreleme var mı? (HTTPS, disk encryption)
Güncellemeler takip ediliyor mu? (OS ve servisler)
Saldırı yüzeyi azalıyor mu? (gereksiz servisleri kapatma)

Loglar ve olay takibi

Bulutta troubleshooting için loglar şarttır. En azından şu günlükler izlenmelidir:

Web sunucusu erişim/log
Uygulama hataları (error log)
Sistem olayları (OS log)
Uygulanıyorsa veritabanı sorgu/slow query log

Bu sayede “yük geldiğinde ne oldu?” sorusuna veriyle cevap verilir.

Bulut sunucu tasarımında karar veren temel değişkenler

Bulut sunucu kurarken teknik olarak şu başlıklarda net karar vermek gerekir:

İş yükü tipi: web uygulaması, API, batch job, gerçek zamanlı servis
Trafik profili: tepe saatleri var mı, ani artış oluyor mu
Veri kalıcılığı: dosya mı, veritabanı mı yoğun?
Ölçekleme hedefi: dikey mi yatay mı
Yedekleme hedefi: RPO/RTO (kurtarma süresi)

Aşağıdaki tablo, “hangi parçayı nereye koymalıyım?” sorusunu somutlaştırır:

İhtiyaç	Genelde doğru yaklaşım	Neden
Web uygulaması trafiği dalgalı	Yatay ölçek + load balancer	Instance sayısını otomatik artırma
Kritik veri kaybını azaltmak	Veritabanı için düzenli backup + ayrı saklama	Restore güvenliği
Dosya yükleme ve arşiv	Object storage + kısa süreli cache	VM diski şişmez
Düşük gecikmeli performans	Uygun disk/IO planı + cache	DB/IO darboğazı azalır
Güvenlik ihlali riskini düşürmek	Security group + minimum portlar	Saldırı yüzeyi küçülür

Sonuç: İlk hedefin “mimari akışı” olsun

Bulut sunucu, doğru kurulduğunda tek bir makineye bağımlılığı azaltır; kaynakları otomasyonla yönetilebilir hale getirir. Aksiyon önerim şudur: Önce uygulamanın istek akışını (web → uygulama → veritabanı) ve veri akışını (dosya → depolama → yedek) yazın; sonra dikey/yatay ölçek ihtiyacını ve backup hedeflerini belirleyin. Bu netleştikten sonra bulut sunucu seçimi ve yapılandırması hızlanır ve sürpriz maliyetler azalır.