Bulut Sunucu Nasıl Çalışır? Sıfırdan Teknik Anlatım

Bulut sunucu, geleneksel tek bir fiziksel sunucuda “tek cihaz” mantığı yerine, ihtiyaca göre kaynakların (CPU, RAM, ağ bant genişliği, disk) sanal katmanlar üzerinden yönetilmesini sağlar. Bu sayede uygulamalar kapasiteyi günlere değil dakikalara göre ayarlayabilir. Bu rehberde bulut sunucunun çekirdekte nasıl çalıştığını; sanallaştırma (virtualization), işlem planlama (scheduling), ağ ve depolama katmanları, ölçekleme ve yedek (backup) akışına kadar sıfırdan anlatacağım.

Bulut sunucu = sanal makine + altyapı servisleri

Bulut sunucu terimi genelde iki kavrama dayanır: - Sanal sunucu (VPS/VDS benzeri “VM” yaklaşımı): Bir işletim sistemi görüntüsü (image) üzerinde çalışan, sanki ayrı bir sunucuymuş gibi davranan yapı. - Altyapı servisleri: Bu VM’nin yanında sunulan ağ, depolama, IP, yük dengeleme (load balancer), otomasyon ve yedekleme gibi “ek katmanlar”.

Bulut sağlayıcısında aslında birden fazla veri merkezi/raf yapısı vardır. Senin için çalışan şey, veri merkezi içinde “paylaşılan ama yalıtımlı” kaynak havuzudur. Yani tek bir fiziksel makineyi kiralamak yerine, ihtiyaca göre fiziksel kaynaklardan ayrılmış bir parça kullanırsın.

Sanallaştırma nasıl yalıtım sağlar?

Bulut platformları genellikle şu yöntemleri kullanır: - Hypervisor (ör. KVM tabanlı çözümler): Fiziksel sunucu üzerinde VM’leri çalıştıran katman. - Kaynak kotaları: CPU/RAM gibi kaynaklar VM’ye tahsis edilir. - Disk yalıtımı: Her VM kendi mantıksal disk alanını görür; temel depolama ortak altyapıda olsa bile VM seviyesi ayrım korunur.

Önemli nokta şudur: Senin VM’nin performansı, aynı fiziksel altyapıyı paylaşan diğer VM’lerle bazı durumlarda dalgalanabilir. Bu dalgalanma, sağlayıcının kaynak yönetim politikalarına ve “overselling” yaklaşımına göre değişir. Bu yüzden bir bulut sunucuda sadece fiyat değil, kaynakların nasıl tahsis edildiği (CPU modeli, I/O limiti, ağ kalitesi) kritik olur.

VM’nin yaşam döngüsü: image → boot → işletim sistemi

Bulut sunucu satın aldığında veya örnek oluşturduğunda gerçekleşen akış kabaca şu şekildedir:

Image seçimi: Ubuntu 22.04, Debian 12, CentOS Stream gibi hazır bir işletim sistemi görüntüsü seçilir.
Boot (önyükleme): VM, image üzerinden önyüklenir.
Ağ yapılandırması: VM’ye özel IP ataması (genellikle public IP) ve güvenlik kuralları (security group/firewall) uygulanır.
Depolama bağlama: Sistem diski (boot disk) oluşturulur ve/veya kalıcı disk (block storage) eklenir.
Agent/entegrasyon (bazı sağlayıcılarda): Sağlayıcı, VM metrikleri ve otomasyon için ince bir servis katmanı kurabilir.

Bu adımların tamamı “tek seferlik” bir kurulum gibi görünse de aslında çoğu bulut platformunda otomasyonla sürekli tekrar edilebilir şekilde tasarlanır. Bu da ölçeklemeyi kolaylaştırır.

İmaj (image) ve anlık örnek farkı

Image: İşletim sistemi ve temel yapılandırma şablonudur.
Örnek (instance/VM): Image’ın çalışır halidir.

Bir uygulamayı güncellediğinde, doğrudan VM içinde değişiklik yapmak yerine “yeni image” üretip aynı yapıdan birden fazla instance başlatmak bazı ekiplerde hataları azaltır. Bu yaklaşım, özellikle CI/CD kullanan yapılarda “tekrarlanabilirlik” sağlar.

Kaynak tahsisi: CPU, RAM ve performans beklentisi

Bulut sunucuda performansı belirleyen ilk mekanizma tahsis ve zamanlamadır. Burada iki kavram sık geçer: - Guaranteed / tahsis edilen kaynak: VM’ye pratikte “istikrarlı” bir pay verileceğini varsaydığımız kısım. - Burst (ani artış): VM’nin kısa süreli daha yüksek performansla çalışabildiği durumlar.

CPU için genellikle şu stratejiler görülür: - VCPU eşleştirmesi: VM’ye belirli sayıda vCPU tahsis edilir. - Scheduler politikası: Hypervisor, VM’lerin CPU zamanını hangi sırayla alacağını belirler.

RAM tarafında ise temel hedef, VM’nin ayrılmış bellek alanının başka VM tarafından sıkıştırılmamasıdır. Yine de disk/swap ayarları gibi konular uygulama seviyesinde etkili olabilir.

NetKıyas mantığıyla kontrol edilecek teknik göstergeler

Bulut sunucu karşılaştırırken şu başlıklara bakmak gerekir: - vCPU sayısı ve CPU tipi - RAM miktarı - Depolama türü: SSD/NVMe (I/O performansı farkı yaratır) - Disk büyüklüğü ve IOPS limiti (varsa) - Ağ bant genişliği / uplink kalitesi

Bu göstergeler, “aynı fiyatlı” iki bulutta neden farklı performans görüldüğünü açıklayan ana gruplardır.

Ağ katmanı: public IP, routing ve güvenlik duvarı

Bulut sunucunun çalışması için ağ şarttır. Tipik öğeler: - Public IP: İnternet üzerinden erişilebilir adres. - Private ağ: Aynı VPC/VNet içindeki instance’lar arası iletişim. - Routing: Paketlerin hangi yoldan gideceği. - Firewall / security group: Hangi portların açılacağı.

Klasik bir sunucuda firewall ayarlarını yerel yaparsın; bulutta ise çoğu zaman ayrıca sağlayıcı seviyesinde de kural katmanı bulunur. Bu nedenle “portu dinliyor ama açılmıyor” sorununun iki nedeni sık görülür: - Uygulama servisinin yanlış interface’e bağlanması (ör. sadece 127.0.0.1’e dinlemek) - Sağlayıcı firewall’ında veya security group’ta ilgili portun kapalı olması

Doğru testi nasıl yaparsın?

Bir instance ayağa kalktıktan sonra şunu kontrol et: - VM içinde ss -lnt ile servis hangi portta ve hangi adreste dinliyor? - VM dışında (başka bir ağdan) hedef port açık mı? (örn. curl/nc ile) - Security group’ta TCP/UDP kuralı var mı?

Depolama katmanı: boot disk, block storage ve kalıcılık

Bulut sunucuda iki disk türü sık görülür: - Boot disk: VM açıldığında sistemi barındıran disk. - Kalıcı block storage: Veriyi VM’den bağımsız saklamayı amaçlayan disk.

Bu ayrım çok önemlidir. Çünkü sağlayıcı, VM kapanıp açıldığında boot disk üzerinde ne olacağını farklı politikalarla yönetebilir. Bazı senaryolarda VM yeniden oluşturulabilir (rebuild) ve boot disk yeniden sağlanır; kalıcı block storage ise veriyi korumaya odaklanır.

Anlık snapshot ve yedek (backup) farkı

Bulutta iki benzer kavram var: - Snapshot: Belirli bir zaman noktasında disk/dizin durumunun anlık kopyası. - Backup: Daha uzun vadeli saklama planı (retention), çoğu zaman otomatik ve testli süreç içerir.

Snapshot “iyi bir acil durum aracı” olabilir; ancak işletim ekibi açısından backup stratejisi, geri dönüş süresini (RTO/RPO) ve kurtarma doğruluğunu kapsar.

Otomasyon ve ölçekleme: neden bulut daha hızlı?

Bulut sunucunun asıl farkı, ölçekleme (scaling) ve otomasyonun daha kolay olmasıdır.

Yatay ölçekleme (scale out): Trafik arttığında yeni instance eklemek.
Dikey ölçekleme (scale up): Tek instance’ın vCPU/RAM’i artırmak.
Otomatik yeniden başlatma: Sağlayıcı, instance sağlıksız olduğunda restart akışı sunabilir.

Bu mekanizmalar genellikle şu parçalarla çalışır: - load balancer veya reverse proxy - uygulama katmanında stateless mimari - verinin kalıcı storage’da tutulması

Ölçeklemede en sık sorun: durum (state)

Instance’lar eklenince sorunlar genelde “session/state” katmanında çıkar. Örneğin uygulama oturumlarını (session) yerel diskte tutuyorsa ölçeklediğinde kullanıcılar kaybolur.

Bu yüzden pratikte kullanılan yaklaşımlar: - session’ı dışarı taşımak (Redis gibi) - dosyaları shared storage/CDN’ye almak - veritabanını tek instance’a gömmemek; managed DB veya ayrı bir cluster tercih etmek

Maliyet modeli: kaynak kullandıkça ödeme ve sürpriz kalemler

Bulut sunucuda maliyeti belirleyen kalemler genelde şu formatta düşünülür: - compute (CPU/RAM süresi) - storage (GB ayı) - snapshot/backup (kullanılan snapshot miktarı) - ağ çıkışı (egress) ve bazen ek trafik ücretleri

Sadece “instance saatlik fiyatı”nı değil, özellikle şu maliyetleri de hesaba kat: - Ayda kaç GB log ve veri üretiyorsun? - Yedeklerin saklama süresi kaç gün? - CDN/WAF kullanıyorsan trafik maliyetleri nasıl etkileniyor?

NetKıyas’ta fiyatı doğru okumaya yardım eden kontrol listesi

Aşağıdaki sorular, “ucuz görünüp sonra pahalıya dönen” durumları engeller: - Aynı vCPU/RAM için disk IOPS limiti var mı? - Public IP ücreti ayrı mı? - Yedek (backup) maliyeti dahil mi? - Trafik (özellikle egress) limitleri ve aşım fiyatları var mı?

Bulut sunucuda güvenilirlik: yedekleme ve kurtarma nasıl işler?

Kurtarma planının amacı “snapshot almak” değil, hızlı ve doğru şekilde geri dönmektir.

Basit bir kurtarma akışı şöyle tasarlanır: 1. Snapshot/backup alınır. 2. Veritabanı için tutarlılık (consistency) kontrol edilir. 3. Gerektiğinde yeni instance oluşturulur. 4. Veriler restore edilir. 5. Uygulama güncellemeleri ve konfigürasyonlar yeniden uygulanır.

Pratik RTO/RPO yaklaşımı

RTO (Recovery Time Objective): Ne kadar sürede geri dönmeliyim?
RPO (Recovery Point Objective): En fazla kaç dakika/saate kadar veri kaybını kabul edebilirim?

Örneğin e-ticaret sistemlerinde RPO’yu dakikalar seviyesinde tutmak gerekir. Bu durumda yedekleme aralığı ve restore testi kritik hale gelir.

Sıfırdan kurulumda tipik mimari örnek

Bir web uygulaması için en basit bulut senaryosu şu bileşenleri içerir: - 1 adet VM (application) - 1 adet veritabanı (managed DB veya ayrı instance) - domain ve DNS ayarları - SSL (HTTPS) için sertifika - güvenlik duvarı kuralları - yedekleme/restore prosedürü

Bunu daha somut görmek için mantıksal bir liste: - Domain → DNS → load balancer/reverse proxy → uygulama VM - Uygulama VM → veritabanı bağlantısı (private ağ) - Veritabanı → otomatik yedek + snapshot - Loglar → merkezi loglama (isteğe bağlı) veya instance üzerinde saklama

SSL/HTTPS ve ağ güvenliği neden ilk gün önemlidir?

Bulut VM ayağa kalktığında uygulama HTTP ile çalışabilir. Ancak gerçek kullanım için HTTPS şarttır. Sertifika yenileme ve otomasyon doğru kurgulanmadığında “bazı günler çalışıp bazı günler bozulma” gibi durumlar yaşanır.

Bulut sunucu çalışıyor mu? Doğrulama adımları (kontrol listesi)

Aşağıdaki maddeler, “kuruldu ama gerçek hayatta çalışıyor mu?” sorusunu teknik olarak cevaplar:

DNS çözümleme: Domain doğru IP’ye yönleniyor mu?
Port dinleme: Uygulama hedef portta dinliyor mu?
Firewall: Security group/iptables kuralı doğru mu?
TLS/HTTPS: Sertifika doğru kurulu mu ve zincir doğrulaması geçiyor mu?
Performans sinyali: Ortalama CPU/RAM ve disk I/O stabil mi?
Loglar: Uygulama hataları düzenli mi, sistem loglarında kritik hata var mı?
Yedek ve restore testi: Snapshot var, ancak restore senaryosu hiç denendi mi?

Sonuç: 1 VM kur, ama mimariyi baştan planla

Bulut sunucu; sanallaştırma katmanı, kaynak tahsisi, ağ ve depolama üzerinden çalışır. Bu yüzden “VM açıldı” demek tek başına başarı değildir; performans beklentisi, güvenlik kuralları, yedekleme ve ölçekleme tasarımı ilk günden net olmalıdır.

Aksiyon olarak şu sırayla ilerle: (1) Uygulama için temel instance’ı kur ve ağ/firewall testlerini yap, (2) veriyi nereye yazdığını ve snapshot/backup politikasını belirle, (3) ölçekleme gerekiyorsa stateless davranışı ya da state yönetimini tasarla, (4) en az bir kez restore senaryosu çalıştır. Böyle yaptığında bulut sunucu, sadece kurulum kolaylığı değil, ölçülebilir kontrol sağlar.