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.
- 1Gereksinimler
- 2Servis modeli
- 3Pilot ve kabul
- 4İşletim ve çıkış
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.
| Konu | Google Cloud | Amazon Web Services (AWS) | Microsoft Azure |
|---|---|---|---|
| Sanal makine | Compute Engine | Amazon EC2 | Azure Virtual Machines |
| Nesne depolama | Cloud Storage | Amazon S3 | Azure Blob Storage |
| Yönetilen ilişkisel veri | Cloud 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şletimi | Google 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
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Aynı boyut farklı performans veriyor | CPU 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
- Üç platformu aynı kabul kriterleriyle karşılaştırın.
- Her servisin sorumluluk sınırını belgeleyin.
- Gecikme ve hata oranını gerçekçi yükte ölçün.
- Backup ve geri dönüşü ayrı hedefte test edin.
- Toplam maliyet ve egress varsayımlarını yazın.
- 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.
İlgili bulut rehberleri
Bulut Kimlik ve Yetki Yönetimi: Google Cloud, AWS, Azure
İnsan ve uygulama kimlikleri, kısa ömürlü erişim, en az yetki, kaynak sınırları ve erişim doğrulaması için üç platformlu teknik rehber.
Bulut Ağ Tasarımı: Google Cloud VPC, AWS VPC ve Azure VNet
Adres planı, platform sınırları, routing, private erişim, firewall ve hibrit bağlantıların tasarımı ve hata teşhisi.
Bulut Geçişi: Google Cloud, AWS ve Azure Migration Planı
Keşif, bağımlılık analizi, servis seçimi, veri eşitleme, cutover ve rollback adımlarıyla kontrollü bulut geçişi.
Bulut Maliyeti ve FinOps: Google Cloud, AWS, Azure
Compute, storage, veri çıkışı, log ve lisans maliyetini; bütçe, rightsizing ve taahhütlerle birlikte yönetin.
Bulut Yedekleme ve Disaster Recovery: Google Cloud, AWS, Azure
Backup, replication ve HA ayrımı; bağımsız kurtarma erişimi, RPO/RTO, region kaybı ve failback testleri.
Bulut kurulum, işletim ve destek hizmetleri
Platform seçimini mevcut ürünleriniz, iş yükünüz ve işletim ihtiyaçlarınızla birlikte değerlendiriyoruz.