Bulut sunucu mu sanal sunucu mu? Gerçek fark nedir

Sunucunu yeniden başlattın ve beş dakikadır SSH yanıt vermiyor. Ya da daha kötüsü: disk %98'de kilitlenmiş ve iostat -x 1 nvme0n1 üzerindeki %util değerinin sürekli 100 olduğunu gösteriyor. Şimdi karar vermen gerekiyor: aynı VPS'i mi büyüteyim, yoksa tüm yükü bulut sunucuya mı taşıyayım? Bu karar bir karşılaştırma tablosuyla çözülmez, çünkü bu ikisi arasındaki asıl fark, arıza anında ve büyüme anında anladığın şeydedir.

Fark nereden başlıyor: depolama katmanı

Klasik VPS'te disk, aynı hipervizör üzerindeki yerel bir volume'dür. O fiziksel makine ölürse, verin de onunla gider; tabii harici bir yedeğin yoksa. Bulut sunucuda ise disk genellikle birkaç düğüme dağıtılmış ve eşzamanlı replication ile tutulan bir ağ volume'üdür. Bu farkı pratikte tek bir sayıyla anlarsın: IOPS.

Özel sunucudaki yerel bir NVMe volume, kolayca 500 bin rastgele 4K IOPS verir. Aynı hacim bulut ağ depolamasında, volume tipine bağlı olarak genellikle 3 bin ile 20 bin arası temel IOPS'tir ve daha yükseğe çıkmak için provisioned IOPS satın alman gerekir. Yükün yoğun yazma yapan bir MySQL veritabanıysa, her şeyi belirleyen bu sayıdır, vCPU sayısı değil.

fio --name=randwrite --ioengine=libaio --rw=randwrite \
  --bs=4k --numjobs=4 --size=2G --runtime=60 --group_reporting

Bunu geçişten önce her iki tarafta çalıştır. IOPS farkı iki kattan fazlaysa ve yükün I/O-bound ise, doğru volume tipini seçmeden buluta geçiş sadece sorunu başka yere taşır.

Canlı geçiş: VPS'te olmayan şey

Canlı geçiş (live migration), hipervizörün makinenin RAM'ini servis çalışırken diğer düğüme kopyalaması ve son anda birkaç yüz milisaniyeden az bir duraklama uygulamasıdır. Gerçek bir bulut sunucuda, fiziksel düğümün bakıma ihtiyacı olduğunda bu iş arka planda yapılır ve sen sadece latency grafiğinde küçük bir sıçrama görürsün.

VPS'te bu olmaz. Düğüm bakımı, planlı downtime demektir; ya da daha kötüsü, makinenin başka bir düğüme restore edilmesi ve IP'nin değişmesi demektir. Ekibinin iç SLA'sı ayda beş dakikanın altında downtime ise, bu belirleyici bir farktır.

Ama gizli bir maliyeti var: canlı geçiş, düğümler arası yüksek hızlı ağa bağlıdır. Yükün çok fazla belleğe sahipse (örneğin 64 GB dataset'li bir Redis), her geçiş birkaç dakika sürer ve o aralıkta yazma latency'si yükselir. Yüksek RAM'li kümelerde canlı geçişin kendisinin alert tetiklediğini görmüşümdür.

Faturalama modeli: maliyet nerede elinden kaçıyor

VPS genellikle sabit aylık fiyata sahiptir. Bulut sunucu ise genellikle saatlik tüketime göre faturalandırılır ve en büyük yanlış anlaşılma tam da burada ortaya çıkar.

Burada hata yapıyorlar: ekipler bir bulut instance'ı oluşturuyor, kapatmayı unutuyor ve ay sonunda beklenenin kat kat üzerinde bir fatura görüyor. Belirtisi de şu: panelde hesaplama maliyeti düşük ama depolama ve trafik maliyeti zirve yapmış. Instance'ın bağlı olmadığı volume'ler de para yiyor.

Pratik çözüm: baştan etiketle ve bütçe uyarısı koy. Ekibin birkaç kişiyse, IaC ve etiket olmadan maliyet kontrolü imkânsız hale gelir. Altyapıyı kod olarak ilk günden ciddiye al, ilk sürpriz faturandan sonra değil.

Hangisi hangi yük için daha iyi

Tutumum net: yükün kararlı, tek sunuculu ve I/O-bound ise (yoğun trafikli bir WordPress, orta ölçekli bir veritabanı, dahili bir servis), VPS veya özel sunucu daha doğru seçimdir. Daha az para verirsin ve daha fazla IOPS alırsın. Burada buluta geçiş sadece fazladan karmaşıklık ekler.

Bulutu, aşağıdakilerden en az biri doğruysa seç:

• Yükün ciddi dalgalanma gösteriyor ve düşük yoğunluk saatlerinde daha az para ödemek istiyorsun.
• Otomatik ölçeklendirmeye ihtiyacın var ve manuel müdahale olmadan instance eklenmesini istiyorsun. Otomatik ölçeklendirme; yatay mı dikey mi? doğru seçim rehberi tam da bu kararı açıyor.
• Birkaç zone'a dağıtılması gereken ve sıfır downtime istediğin birkaç servisin var.
• Yönetilen Kubernetes veya nesne depolama gibi yönetilen servisleri kullanmak ve düğüm bakımıyla kendin uğraşmamak istiyorsun.

Az söylenen pratik bir nokta: yükün statikse, sunucu hakkında herhangi bir karardan önce içeriği içerik dağıtım ağına taşı. Çoğu zaman trafiğin %70'i ana sunucudan alınır ve mimariyi değiştirmene gerek kalmadan asıl sorun çözülür.

Pratik geçiş: öncesinde neyi ölçmelisin

Herhangi bir taşımadan önce, mevcut sunucuda şu dört sayıyı kaydet:

1. İki haftalık dönemde ortalama ve 95. yüzdelik CPU ve RAM kullanımı.
2. Yoğun saatlerde disk IOPS ve throughput.
3. Aylık çıkış trafiği gigabayt cinsinden.
4. Sunucu ile veritabanı arasındaki latency, eğer ayrılarsa.

Geçişten sonra aynı dört sayıyı tekrar al. Veritabanı latency'sinin 95. yüzdelik değeri kötüleştiyse, muhtemelen volume tipini yanlış seçmişsindir, bulut kötü olduğundan değil. Bu karşılaştırmanın anlamlı olması için doğru izlemeye sahip olman gerekir; Akıllı izleme ve uyarı için pratik rehber tam da bu boşluğu dolduruyor.

Mimarin çok katmanlıysa ve trafik bir load balancer'dan geçiyorsa, geçişten önce yük dağıtım algoritmasını da gözden geçir. Load balancer ve yük dağıtım algoritmalarını bir kez gözden geçir; bulutun üzerine atılan birçok sorunun kökü load balancer ayarlarındadır.

Ve yükün genel erişime açıksa, her şeyden önce zararlı trafiğe karşı koruma katmanına sahip olduğundan emin ol. Bir hacim saldırısı her iki mimariyi de çökertebilir, ama bulutta buna çıkış trafiği faturası da eklenir. DDoS'a karşı gerçek koruma yöntemlerini ciddiye al.

Bir başlangıç noktasından başlamak istiyorsan, Bulut altyapısı (IaaS) donanımla kendin uğraşmadan instance, volume ve ağ üzerinde tam kontrol verdiğin yerdir. Her bileşenin teknik detayları için dokümantasyon ve bilgi tabanı daha kesin bir referanstır.

Sık sorulan sorular

Bulut sunucu her zaman VPS'ten pahalı mıdır?

Hayır, ama maliyet modeli farklıdır. Yükün dalgalanıyorsa ve yoğun saatler dışında instance'ı kapatabiliyorsan, bulut maliyeti sabit aylık bir VPS'ten daha düşük olabilir. Ama yükün 24 saat kararlıysa, VPS neredeyse her zaman daha ucuza gelir, çünkü depolama ve trafik maliyetleri ayrı ayrı üst üste toplanır.

Canlı geçişin bana ne faydası var?

Faydası, fiziksel düğümün sorun çıkardığı anda ortaya çıkar. Servisin planlı downtime olmadan sağlıklı düğüme taşınır. Ekibinin iç SLA'sı katıysa veya servisin dış müşterilere sahipse, bu özellik tek başına bulutu seçmeye değer.

Buluta geçtikten sonra veritabanım neden yavaşladı?

Çoğu durumda sorun CPU'da değil, IOPS'tedir. Temel ağ volume'ü genellikle yerel NVMe'den daha az IOPS verir. Her iki tarafta fio ile test yap ve fark büyükse, daha yüksek IOPS'lu volume'e geç veya veritabanını yerel diskli instance üzerinde tut.

Başlamak için VPS'i mi büyüteyim yoksa buluta mı geçeyim?

Sorunun sadece kapasiteyse ve yükün kararlıysa, VPS'i büyütmek en hızlı ve en ucuz yoldur. Sorunun yük dalgalanması, otomatik ölçeklendirme ihtiyacı veya birden fazla zone ihtiyacıysa, VPS'i büyütmek sadece zaman kazandırır. Önce dört tüketim sayısını ölç, sonra karar ver.