Mimari (IT)Sistem Mimarisi

Küresel ölçekte dağıtılmış, otonom bir kapasite orkestrasyon düzlemi tasarlayın; iş yüklerini farklı bulut sağlayıcıları arasında dinamik olarak, gerçek zamanlı maliyet optimizasyonu, karbon ayak izi kısıtlamaları ve uyumluluk gereksinimlerine dayanarak kaydırırken, veri ikametini sağlarken ve sağlayıcı kesintileri sırasında alt dakikalık failover gerçekleştirirken.

Hintsage yapay zeka asistanı ile mülakatları geçin

Sorunun cevabı

Sorunun tarihi

Monolitik veri merkezlerinden çoklu bulut stratejilerine geçiş, ilk olarak satıcı çeşitlendirmesi ve kullanılabilirlik üzerinde yoğunlaşmıştı, ancak modern işletmeler artık operasyonel maliyetleri düşürmek, agresif sürdürülebilirlik hedeflerine ulaşmak ve GDPR ve CCPA gibi karmaşık veri egemenliği düzenlemeleriyle başa çıkmak gibi aynı anda gelen baskılarla karşı karşıyadır. Erken çoklu bulut uygulamaları, bölgesel kesintilere veya anlık fiyat dalgalanmalarına yanıt verirken ekonomik açıdan verimsiz ve operasyonel olarak yavaş olan statik felaket kurtarma yapılandırmalarına ve manuel kapasite planlamaya dayanıyordu. FinOps uygulamalarının ve karbon farkındalığına sahip bilgisayarların ortaya çıkması, insan müdahalesi olmadan fiyat, performans ve gezegensel etki boyutları arasında otonom olarak optimize edebilen akıllı sistemleri zorunlu hale getirmiştir.

Problemin tanımı

Temel zorluk, sürekli yük taşımayı sağlayan kontrol düzlemi durumunda güçlü tutarlılık garantilerini korurken, AWS, Microsoft Azure ve Google Cloud Platform arasındaki farklı API'leri ve anlamsal farklılıkları normalleştirmekte yatmaktadır. Bölgeler arasındaki ağ bölünmeleri, orkestratörlerin çelişkili programlama kararları vermesi riski yaratarak, düzenlenmiş verilerin uyumsuz yargılara taşınmasına neden olabilir. Ayrıca, Persistent Volume Claims (PVC'ler) kullanan durumsal iş yükleri, hızlı boşaltmayı karmaşıklaştıran depolama bağlılığı kısıtlamaları getirirken, agresif maliyet optimizasyon algoritmaları flapping gibi osilasyon döngülerinin tetiklenmesine neden olabilir ve hizmet düzeyi hedeflerini istikrarsızlaştırabilir.

Çözüm

Bölgesel Kubernetes kümelerinden oluşan hiyerarşik bir kontrol düzlemi tasarlayın ve bunları merkezi bir Fleet Manager aracılığıyla federasyon yapın, bulut-spesifik uygulamaları birleştirilmiş bir gRPC hizmet ağı arayüzü arkasında soyutlayın. Gerçek zamanlı kısıtlamaları (karbon yoğunluk API'leri, anlık örnek fiyatı akışları ve veri ikameti kurallarını) değerlendirmek için bir politika motoru uygulayın ve taşınma kararlarını onaylayın. Her bir bulut sağlayıcısına özgü kapsamda etcd kümeleri kullanarak çapraz bulut konsensüs gecikmesinden kaçının; kritik olmayan meta veriler için çatışma-free replicated data types (CRDTs) ile asenkron çoğaltma uygulayın, aynı zamanda Velero ve Container Storage Interface (CSI) anlık görüntü alma aracıları ile durumsal iş yükü hareketliliğini düzenleyin.

Hayattan bir durum

AB (Frankfurt), ABD (Virginia) ve APAC (Singapur) bölgelerinde faaliyet gösteren bir küresel maaş işleme şirketi, aylık maaş hesaplamalarını kırk milyon çalışanı için en az bulut harcaması ile işlemek ve Avrupa vatandaş verileri için GDPR uyumluluğunu sağlamak zorundaydı.

AWS us-east-1 kesintisi sırasında, bir yandan Azure batı Avrupa'da yüksek talep nedeniyle anlık fiyat artışı yaşandı. Mevcut statik felaket kurtarma yapılandırması, AB iş yüklerini GCP Belçika'ya kaydırmış olacaktı; bu durum veri ikamet gereksinimlerini ihlal ederken, operasyon ekibi, manuel çalışma kitaplarını uygulamak için kırk beş dakika gerektiriyordu ve bu, maaş sunum pencereleri için beş dakikalık SLA süresini çok aşmaktadır.

Çözüm 1: Manuel Çalışma Kitabı Tabanlı Felaket Kurtarma

Bu yaklaşım, önceden onaylı değişiklik talepleri ile nöbetçi mühendisler tarafından gerçekleştirilen Terraform scriptlerine dayanıyordu; DNS kayıtlarını manuel olarak ayarlamak ve hedef küme boyutlarını değiştirmek gerekiyordu.

Artılar: Karmaşık otomasyon gerektirmeyen basit bir uygulama; uyumluluk açısından kritik kararlar için insan gözetimini sürdürür; otomasyonun isyan riskini en aza indirir.

Eksiler: Tepki süresi ortalama on beş ila otuz dakika sürüyor, alt dakikalık failover gereksinimlerini ihlal ediyor; acil durum olmayan dönemlerde maliyet ya da karbon optimizasyonu yapamıyor; yüksek stresli kesinti senaryolarında insan hatasına açıktır.

Çözüm 2: Statik Çoklu Bulut Kubernetes ile Federasyon V2

Her bölgedeki statik kümeler arasında iş yüklerini dağıtmak için Kubefed (şimdi SIG-Multicluster) dağıtarak, etiket seçicilere dayalı önceden tanımlı yerleştirme politikaları oluşturdular.

Artılar: Yerel Kubernetes entegrasyonu; YAML manfestoları aracılığıyla deklaratif yapılandırma; düğüm arızalarında kullanılabilir kümelere iş yüklerinin otomatik yayılması.

Eksiler: Federasyon V2 anlık fiyatlandırma veya karbon verileri hakkında bilgi taşımıyor; merkezi API sunucuları aracılığıyla aşırı çapraz-bulut trafiği maliyetleri oluşturuyor; manuel hacim yeniden eklenmesi gerektiren durumsal iş yükü taşınmalarında zorluk yaşıyor.

Çözüm 3: Otonom Kontrol Düzlemi ve Özel Operatörler

Go dilinde yazılmış Kubernetes Operatörleri kullanarak özelleştirilmiş bir orkestrasyon katmanı inşa edin; bulut faturalama API'leri, Electricity Maps karbon verileri ve bir Redis destekli dağıtık kilit mekanizması ile entegrasyon sağlayarak taşımaları koordine edin.

Artılar: Her altmış saniyede gerçek zamanlı optimizasyon kararları almayı sağlar; yasaklı taşımaları engelleyen OPA politikaları aracılığıyla uyumluluk sınırlarını uygular; operatör aracılığıyla düzenlenen CSI anlık görüntü çoğaltması ile durumsal iş yükü boşaltmasını destekler.

Eksiler: Bulut sağlayıcı adaptörlerini oluşturmak ve sürdürmek için önemli mühendislik yatırımı gerektirir; bölünme toleransı senaryolarını test etmede karmaşıklık yaratır; sağlayıcılar arasında thrashing'i önlemek için dikkatli ayarlama gerektirir.

Seçilen Çözüm ve Gerekçe

Ekip, yalnızca otonom karar almanın alt dakikalık failover SLA'sını karşılayabileceğini ve aynı zamanda maliyet, uyumluluk ve karbonun çelişkili hedeflerini optimize edebileceğini düşündüğü için Çözüm 3'ü seçti. Uyumluluk gereksinimleri, insan operatörlerin baskı altında güvenilir bir şekilde yerine getiremeyeceği kod olarak politika uygulamasını gerektiriyordu ve finansal ölçek (yıllık milyonlarca bulut harcaması) özel otomasyona yapılan mühendislik yatırımını haklı çıkarıyordu.

Sonuç

Sonraki AWS kesintisi sırasında, sistem Prometheus sağlık kontrolleri aracılığıyla arızayı otomatik olarak tespit etti, Azure ve GCP alternatiflerini gerçek zamanlı karbon ve maliyet kısıtlamalarına göre değerlendirdi ve on iki bin kritik maaş podunu on altı saniye içinde (uyumlu bölge) GCP'ye taşıdı. Şirket sıfır SLA ihlali sürdürdü, maliyetleri %34 oranında düşürdü ve akıllı anlık örnek arbtajı sayesinde karbon nötr hesaplama operasyonları elde etti.