Multi-cloud tasarımı: iş yükünü birden fazla buluta dağıtmanın yöntemi

Çoklu bulut nedir, neden tercih edilir?

Çoklu bulut (multi-cloud), bir kuruluşun iş yüklerini birden fazla genel bulut sağlayıcısına dağıtarak kullanmasıdır. Her sağlayıcı farklı güçlü hizmetlere, farklı bölgesel kapsama ve farklı fiyat yapısına sahiptir. Kimi kuruluşlar bunu bilinçli bir strateji olarak seçer, kimi ise birleşme ve satın almalar ya da ekiplerin bağımsız kararları sonucu kendiliğinden çoklu buluta ulaşır.

Tercih nedenleri genellikle şunlardır: belirli bir sağlayıcının öne çıkan bir hizmetinden yararlanmak, tek sağlayıcıya bağımlılığı azaltmak, düzenleyici ya da veri yerleşimi gereksinimlerini karşılamak, farklı bölgelerde müşteriye yakın olmak ve pazarlık gücünü korumak. Her gerekçe somut bir iş sorusuna bağlanmalıdır; 'bağımlı olmamak' tek başına yeterli bir tasarım gerekçesi değildir.

Çoklu bulut, hibrit buluttan farklıdır. Hibrit bulutta şirket içi ya da özel altyapı ile bir genel bulut birleşir; çoklu bulutta ise birden çok genel bulut sağlayıcısı bir arada kullanılır. Her ikisi aynı kuruluşta birlikte de bulunabilir.

Çoklu bulut ne zaman mantıklı, ne zaman değil?

Çoklu bulut ek karmaşıklık getirir: her sağlayıcının kendi kimlik modeli, ağ yapısı, izleme araçları ve faturalama mantığı vardır. Ekibin bunların hepsinde yetkin olması gerekir. Bu yüzden karar, getirdiği değerin bu karmaşıklık bedelini aşıp aşmadığına göre verilir.

Mantıklı olduğu durumlar şunlardır:

• Bir sağlayıcının hizmeti, ihtiyaç duyulan iş yükü için belirgin biçimde daha uygun olduğunda.
• Mevzuat veya müşteri sözleşmesi, verinin belirli bir bölgede ya da belirli bir sağlayıcıda tutulmasını gerektirdiğinde.
• Kritik bir hizmette tek sağlayıcı kesintisinin iş sürekliliği riskini kabul edilemez kıldığında.
• Şirket birleşmesi sonucu ayrı bulut ortamları fiilen bir arada yaşadığında.

Mantıksız olduğu durumlar da vardır: küçük bir ekibin, tek bir sağlayıcının yönetilen hizmetlerini bırakıp 'taşınabilirlik' adına en düşük ortak paydaya inmesi, çoğu zaman hem maliyeti hem de hızı olumsuz etkiler. Her sağlayıcıda yalnızca sanal makine kullanmak, çoklu bulutun avantajını sunmaz, yalnız karmaşıklığını ödetir.

Adım adım çoklu bulut mimarisi nasıl tasarlanır?

Tasarım teknoloji seçiminden önce iş yükü ve ilkeler üzerinden yürür.

• İş yüklerini sınıflandırın: hangi uygulama hangi gecikme, süreklilik, veri hassasiyeti ve ölçek gereksinimine sahip?
• Yerleştirme ilkelerini yazın: bir iş yükünün hangi buluta gideceğini hangi ölçüt belirliyor? Hizmet uyumu, veri konumu, maliyet, ekip yetkinliği.
• Kimlik modelini birleştirin: kullanıcı ve servis kimliklerinin tek bir merkezi kimlik sağlayıcıdan federasyon yoluyla yönetilmesi, her bulutta ayrı hesap dağınıklığını önler.
• Ağ ve bağlantıyı tasarlayın: bulutlar arası özel bağlantı, adres planı çakışmaları, DNS ve trafik yönetimi, çıkış (egress) ücretinin etkisi.
• Veri stratejisini kurun: verinin nerede doğduğu, nereye kopyalandığı, tutarlılığın nasıl sağlandığı ve hangi verinin bulutlar arası dolaşmaması gerektiği.
• Ortak operasyon katmanı tanımlayın: izleme, günlük toplama, uyarı, olay yönetimi ve otomasyon için tek bakış noktası.
• Güvenlik ve uyum ilkelerini ortaklaştırın: politikalar kod olarak tanımlanıp her ortama uygulanabilmeli.
• Maliyet görünürlüğü kurun: her bulutun maliyeti etiketlerle ürün, ekip ve ortam bazında izlenmeli.
• Referans mimariyi küçük bir iş yüküyle doğrulayın.

İlk uygulamanın başarısı, bütün stratejiyi yazmaktan daha fazla şey öğretir.

Kimlik, ağ ve veri: çoklu bulutun zorlu alanları

Kimlik tarafında temel sorun, aynı kişi ya da servisin farklı bulutlarda farklı kimliklerle tanınmasıdır. Federasyon, merkezi bir kimlik sağlayıcının diğer ortamlara güven vermesiyle bu dağınıklığı azaltır. Rol ve yetkilerin her bulutta aynı mantıkla verilmesi, denetimde tutarlılık sağlar. Servis hesapları ve anahtarlar ise en çok hata çıkan yerdir; kalıcı anahtar yerine kısa ömürlü kimlik bilgileri tercih edilir.

Ağda bulutlar arası trafik hem gecikme hem maliyet getirir. Birçok sağlayıcı, verinin buluttan dışarı çıkışını ücretlendirir; bu yüzden sık konuşan bileşenleri aynı bulutta tutmak mimarinin basit ve güçlü ilkelerindendir. Adres aralıklarının baştan çakışmayacak biçimde planlanması, sonradan birleştirme sancısını önler.

Veride ise şu yaklaşımlar öne çıkar: veriyi kopyalayıp senkronize etmek ya da veriyi yerinde bırakıp sorguyu veriye götürmek. Kopyalama kolay erişim sağlar ama tutarlılık ve maliyet sorunu yaratır; yerinde sorgu ise gecikmeyi artırabilir. Hangisinin seçileceği iş yükünün okuma-yazma kalıbına ve hassasiyetine bağlıdır.

Operasyon, güvenlik ve maliyet yönetimi

Çoklu bulutta operasyonun ana ilkesi, sağlayıcıdan bağımsız bir yönetim katmanıdır. Altyapının kod olarak tanımlanması (infrastructure as code) ve aynı şablonların ortamlar arasında yeniden kullanılması, farklı konsollarda elle yapılan değişikliklerin yarattığı sapmayı azaltır. Merkezi günlük toplama ve izleme, bir olayın hangi bulutta başladığını hızla göstermelidir.

Güvenlikte her sağlayıcının kendi güvenlik hizmetleri vardır, ama politika tek yerde düşünülmelidir: şifreleme, erişim, ağ erişimi ve yapılandırma uyumu için ortak standartlar tanımlanır, her bulutun diline çevrilerek uygulanır. Yapılandırma hatası, çoklu bulutta bulut sayısıyla birlikte artan bir risktir.

Maliyette görünürlük, tasarruftan önce gelir. Etiketleme standardı, ortak raporlama ve sorumlu atama olmadan hangi harcamanın neye karşılık geldiği anlaşılmaz. Ardından taahhüt indirimleri, boşta kalan kaynakların temizliği ve ölçek ayarı gibi optimizasyonlar uygulanır. Burada sık görülen tuzak, indirimli taahhütleri bulutlara dağıtınca her birinde hacim avantajının seyrelmesidir.

Sık yapılan hatalar

• Gerekçesiz çoklu bulut: bir hizmet ihtiyacı yokken yalnızca bağımlılık kaygısıyla yeni bir buluta geçmek, getirisi belirsiz bir yük yaratır.
• En düşük ortak payda mimarisi: tüm yönetilen hizmetleri bırakıp her yerde aynı temel bileşenleri kullanmak, bulutların asıl avantajını kaybettirir.
• Kimliği sona bırakmak: önce iş yüklerini taşımak, sonra yetkileri toparlamaya çalışmak güvenlik açığı doğurur.
• Çıkış maliyetini hesaba katmamak: sık konuşan bileşenleri farklı bulutlara dağıtmak, trafik faturasını beklenmedik şekilde artırır.
• Ekibi hazırlamamak: her bulutu bilen yeterli kişi yoksa olay anında çözüm gecikir.
• Dağınık veri kopyaları: aynı verinin birçok yerde, farklı güncellik düzeyinde bulunması, raporlarda tutarsızlık demektir.
• Test edilmemiş süreklilik planı: iş yükünün başka buluta devredileceği varsayımı, gerçekten denenmediyse bir varsayımdan ibarettir.

Bu hataların çözümü, her kararı bir iş gerekçesine ve ölçülebilir bir kritere bağlamaktır.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Mindset kataloğundaki 'Multi-Cloud Mimari Tasarımı' eğitiminin modülleri iş yükü yerleştirme stratejisi, kimlik ve erişim federasyonu, ağ ve bağlantı tasarımı, veri yönetimi ve entegrasyon, operasyon, güvenlik ve maliyet yönetimi, multi-cloud referans mimarisi ve uygulama ile çok bulut stratejisinin temellerini kapsar.

'Hibrit ve Çok Bulutlu Veri Mimarisi' programı ise veri tarafına odaklanır: hibrit ve çok bulut stratejisi, veri hareketi ve senkronizasyon, federatif sorgulama ve erişim, kimlik ve yönetişim tutarlılığı, ağ, maliyet ve performans ile süreklilik ve geçiş planı.