Ana içeriğe geç
BULUT MİMARİSİ

Google Cloud, AWS ve Azure: Bulut Platformu Nasıl Seçilir?

İş yükü, servis modeli, veri yerleşimi, güvenlik, kurtarma ve toplam maliyet üzerinden Google Cloud, AWS ve Azure değerlendirmesi.

İçerik güncellemesi:

Mimari ve çalışma modeli

Platform seçimi bir marka sıralaması değil, gereksinim eşleştirmesidir. Önce uygulamanın transaction davranışı, veri hacmi, gecikme toleransı, mevcut lisansları ve ekip işletim yetkinliği çıkarılır. Ardından sanal makine, container, serverless veya yönetilen servis modelinin uygunluğu sınanır. Bir sağlayıcıda uygun olan servis, başka sağlayıcıda aynı isim veya varsayılanla çalışmayabilir.

IaaS sanal makinede işletim sistemi ve uygulama bakımı çoğunlukla müşteri kapsamındadır; yönetilen serviste bazı altyapı işleri sağlayıcıya geçer. Kimlik, veri yetkisi, doğru yapılandırma ve uygulama sorumluluğu yine değerlendirilir. Yönetilen servis seçmek backup, erişim politikası veya maliyet takibini otomatik tamamlamaz.

Bölge, zone, servis kullanılabilirliği ve quota ayrı karar girdileridir. Aynı sayıda vCPU, aynı işlemci nesli veya performans garantisi anlamına gelmez. Veriyi tek bölgede tutmak, tüm logların, yedeklerin ve yönetim verisinin aynı yerde kaldığını kanıtlamaz. Veri yollarını ürün bazında inceleyin.

Birden fazla bulut kullanmak yalnız bağımsızlık sağlayan bir seçim değildir; kimlik, ağ, izleme, veri aktarımı ve olay müdahalesine ek maliyet getirir. İş yükü bunu gerektirmiyorsa tek platformda iyi tasarlanmış ve dışa aktarılabilir bir mimari daha uygulanabilir olabilir. Her iki durumda çıkış planı ölçülebilir olmalıdır.

  1. 1Gereksinimler
  2. 2Servis modeli
  3. 3Pilot ve kabul
  4. 4İşletim ve çıkış
Üç platformu aynı kabul kriterleriyle karşılaştırın.

Tasarım parametreleri

Servis modeli
OS, runtime, veri ve yama sorumlularını servis bazında yazın.
Performans ölçütü
Aynı veri ve eşzamanlı yükle p95/p99, hata ve kaynak tüketimini karşılaştırın.
Veri ve kurtarma
Yerleşim, anahtar, backup ve RPO/RTOyu bir tasarım olarak değerlendirin.
Çıkış ve maliyet
Lisans, egress, dönüşüm ve işletimi hesaba katın; yalnız VM saatini kıyaslamayın.

Platformlardaki uygulama karşılıkları

Servis adları teknik karşılıklardır. Kapsam, varsayılanlar, bölge kullanılabilirliği ve işletim koşulları farklıdır; birebir aynı garanti anlamına gelmez.

KonuGoogle CloudAmazon Web Services (AWS)Microsoft Azure
Sanal makineCompute EngineAmazon EC2Azure Virtual Machines
Nesne depolamaCloud StorageAmazon S3Azure Blob Storage
Yönetilen ilişkisel veriCloud SQL; desteklenen engine/sürümü doğrulayın.Amazon RDS; engine seçenekleri ve davranışı ayrıca değerlendirilir.Azure SQL ve Azure Database servisleri; engine ihtiyacına göre seçilir.
Container işletimiGoogle Kubernetes Engine (GKE)Amazon EKS; alternatif ECS kapsamı farklıdır.Azure Kubernetes Service (AKS)

Hesap ve uygulama örneği

Örnek bir ERP için 2 TB veri, 150 eşzamanlı kullanıcı ve kritik sorgularda 300 ms p95 hedefi olsun. Üç platform için aynı transaction kümesini, aynı veri dağılımını ve aynı ağ mesafesini olabildiğince temsil eden pilot kurun. vCPU, RAM ve storage boyutlarını başta eşleştirin, sonra her platformda ölçülen ihtiyaca göre boyutlandırın.

Maliyet tablosuna üretim, staging, backup, log, lisans, destek ve veri çıkışını ekleyin. Teknik kabulü sağlayamayan seçeneği daha düşük faturası nedeniyle kazanan ilan etmeyin. Pilot sonunda restore, erişim reddi ve veri dışa aktarımını da test edin; platform kararı yalnız benchmark sonucu değildir.

Hata teşhisi

BelirtiOlası neden / ayrımDoğrulama
Aynı boyut farklı performans veriyorCPU nesli, disk sınırı veya ağ yolu farklı olabilir.Sorgu planı, depolama gecikmesi ve instance özelliklerini aynı iş yükünde karşılaştırın.
Servis seçilen bölgede yokÜrün ve region kapsamı farklı olabilir.Servis kullanılabilirliği, quota ve veri yolu gereksinimini tasarım öncesi doğrulayın.
Pilot ucuz, üretim pahalıHA, backup, log veya egress pilotta eksik olabilir.Tam hizmet kapsamını ve gerçek aylık kullanım birimlerini eşleştirin.

Kabul ve doğrulama kontrolleri

  1. Üç platformu aynı kabul kriterleriyle karşılaştırın.
  2. Her servisin sorumluluk sınırını belgeleyin.
  3. Gecikme ve hata oranını gerçekçi yükte ölçün.
  4. Backup ve geri dönüşü ayrı hedefte test edin.
  5. Toplam maliyet ve egress varsayımlarını yazın.
  6. Veri, konfigürasyon ve anahtar çıkış yolunu sınayın.

İlgili kavramlar

Kapasite ve kullanılabilir pay

Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.

Gecikme dağılımı

Gecikme, bir işlemin başlangıcı ile yanıtı arasındaki süredir. Ortalama değer, az sayıdaki çok yavaş işlemi gizleyebilir; medyan ile p95/p99 gibi yüzdelikler farklı sorulara cevap verir. Ağ RTT, disk bekleme, işlemci sırası ve uygulama işlemesi toplam süreye katkıda bulunur. Ölçümün istemci tarafında mı sunucuda mı yapıldığını yazın. Gecikme artışının trafik yükselmesine, bakım işine veya kapasite sınırına denk gelip gelmediğini karşılaştırın. Bir eşik seçmeden önce normal yük ve yoğun saat için temel davranışı kaydedin.

Bağımlılık ve geri açılış sırası

Bir hizmet çoğu zaman kimlik, DNS, zaman, ağ, veritabanı ve lisans servislerine bağlıdır. Bağımlılıkları yalnız cihaz listesi olarak değil, hangi hizmetin hangi koşulla çalışabildiğini gösteren bir grafik olarak kaydedin. Geri açılış sırası buna göre belirlenir; bazı döngüsel bağımlılıklar özel acil erişim gerektirir. Çalışan altyapı bileşenleri ile işin yeniden başlayabildiği anı ayırın. Her bağımlılığa sorumlu, doğrulama yöntemi ve alternatif erişim yolu atayın. Uçtan uca testte bir bileşeni bilerek erişilemez hale getirerek varsayımları sınayın.

Yüksek erişilebilirlik ile kurtarma ayrımı

Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve backup birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.

Maliyet ölçümünün sınırı

Maliyeti yalnız satın alma veya aylık kaynak bedeli olarak görmeyin. Lisans kapsamı, depolama, veri çıkışı, yedekleme, destek, işletim emeği ve arıza etkisi farklı kalemlerdir. Hesap için aynı hizmet seviyesi, kapasite ve süreyi kullanın; ucuz görünen seçenek başka bir yükümlülüğü dışarıda bırakıyor olabilir. Tahmin ile gerçekleşeni kaynak veya iş birimi bazında karşılaştırın. Taahhütlü modelde kullanım azalması, esnek modelde ise kontrolsüz büyüme riskini değerlendirin. Fiyat ve lisans koşullarını karar günündeki resmî belgelerden doğrulayın.

Sürüm ve destek yaşam döngüsü

Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.

Birincil teknik dokümantasyon

İçeriğin hazırlanması

Doz Teknoloji Teknik Ekibi. Açıklamalar ilgili sağlayıcıların teknik dokümantasyonu, ortak mimari ilkeler ve açık varsayımlı örneklerle hazırlanmıştır. Hesap ve senaryolar açıklama amaçlıdır; müşteri ortamında yapılmış test veya sonuç iddiası taşımaz. Uygulamada sürüm, bölge, servis kapsamı ve destek koşulları yeniden doğrulanmalıdır.

Kurumsal IT Ürün Satışı, Lisanslama ve Kurulum
Kurumsal IT Proje & Çözüm Senaryoları
Tüm ilgili içerikleri görüntüleyin
WhatsApp'tan Yazın
Kopyalandı!