Otomatik olarak, kritik yükleri geçici bulut örneklerinden alternatif erişim bölgelerine ve ikincil bulut sağlayıcılarına tahliye eden, sıfır kesinti ile hizmet sürekliliğini sağlayan ve 100ms altında gecikme SLO'larına kesinlikle uyan kendi kendini iyileştiren bir hesaplama dokusu tasarlayın.

Sorunun cevabı.

Mimari, bulut sağlayıcıyı veri sinyallerini (örneğin, AWS Spot Örneği kesilme bildirimleri, GCP önceden kesilme uyarıları) yakalayan bir Kontrol Uçağı etrafında şekilleniyor ve canlı iş yükü göçünü yönlendiriyor. Bir Zamanlayıcı, spot örneklerin sağlık durumlarının yanı sıra İhtiyaç Duyulduğunda ve ikincil bulut bölgelerinde önceden ısıtılmış yedek kapasiteleri içeren gerçek zamanlı bir sıcaklık haritası tutar. Kesilme uyarısı alındığında, sistem dağıtılmış depolamaya uygulama tutarlı checkpointing başlatır (örneğin, Ceph veya S3), aynı anda yedek kapasitelerdeki yerine geçici kapsayıcılar oluşturur. Hizmet Ağı yan bileşenleri (örneğin, Istio) bağlantı boşaltma ve HTTP/2 GOAWAY sinyalleri kullanarak trafiği nazikçe kaydırır ve isteklerin düşmesini engeller. Son olarak, Küresel Yük Dengeleyici, yalnızca başarılı sağlık doğrulamasından sonra trafiği yönlendirmek için sağlık kontrollerini günceller, böylece gecikmenin 100ms eşiğinin altında kalmasını sağlayarak coğrafi olarak yakın yedek bölgeleri önceliklendirir.

Gerçek hayattan bir durum.

Yüksek frekanslı bir ticaret firması, hesaplama maliyetlerini %60 azaltmak için AWS EC2 Spot Örneklerini kullandı. Bir piyasa olağandışı dalgalanma sırasında, AWS birincil us-east-1 erişim bölgesindeki birçok spot kesilme bildirimleri yayınladı. Bu durum, canlı işlemleri sıkı 50ms gecikme gereksinimleri ile yürütürken iki dakika içinde 500 kapsayıcıyı öldürme tehdidi oluşturuyordu ve milyonlarca kaybedilen işlemi riske atıyordu.

Çözüm A: Yerel Kubernetes Kapsayıcı Kesinti Bütçeleri.

Ekip, kapsayıcıları üst düzey düğümlere nazikçe tahliye etmek için standart Kapsayıcı Kesinti Bütçeleri (PDB'ler) ve Küme Otomatik Ölçekleyici ile dayanarak ilerlemeyi düşündü. Bu yaklaşım basitlik sundu ve özel bir kod gerektirmedi. Ancak, 120 saniyelik kesilme penceresi, durumlu risk motorlarının karmaşık bellek içi türev modellerini kalıcı depolamaya serileştirmesi için yetersiz çıktı ve kabul edilemez veri kaybı ve hesaplama boşlukları oluşmasına neden oldu.

Çözüm B: Velero ile Özel Önleyici Düğüm Kontrolörü.

Diğer bir seçenek, kalıcı hacim anlık görüntüleri için Velero ve hızlı düğüm sağlama için Karpenter kullanan özel bir kontrolör dağıtmayı içeriyordu. Karpenter 30 saniye içinde hızlı düğüm başlatma konusunda başarılı olurken, Velero'nun 50GB bellek durumları için anlık görüntü alma ve geri yükleme döngüsü ortalama üç dakika sürdü. Bu gecikme, sıfır kesinti gereksinimini ihlal etti ve sistemin tampon kapasitesinin ötesinde biriken kuyruklu ticaretler sonucunda zincirleme arızalar riski taşıdı.

Çözüm C: Uygulama Düzeyinde Checkpointing ve Çok Bulut Yedekleme.

Seçilen çözüm, her 30 saniyede bir süreç durumlarını Redis Kalıcı kümelerine dondurmak ve serileştirmek için CRIU (Kullanıcı Alanında Checkpoint/Restore) kullanan uygulama farkında checkpointing uyguladı. Mimari, Anthos kullanarak çoklu küme hizmet ağı federasyonu ile GCP Compute Engine'de sıcak bir yedek havuzunu sürdürdü. AWS kesilme sinyalini aldığında, kontrolör hemen Redis'e son delta senkronizasyonunu tetikledi, önceden çekilmiş kapsayıcı görüntülerini kullanarak GCP'de yedek kapsayıcılar oluşturdu ve trafiği kaydırmak için Istio yerellik başarısızlığı kullandı. Bu yaklaşım bazı uygulama karmaşıklıklarından feragat etti ancak sıfır veri kaybı ile 60 saniyenin altında bir failover garantiledi.

Sonuç.

Firma, kütlesel kesilme olayı sırasında iş yüklerinin %98'ini 90 saniye içinde başarılı bir şekilde tahliye etti. Ortalama failover gecikmesi 45ms olarak ölçüldü ve SLO içerisinde kaldı, sistem olay süresince %99.99 çalışma süresini korudu. Uygulama sonrası analiz, yalnızca talebe göre kullanım ile karşılaştırıldığında %55 maliyet azaltımı sağladığını ortaya koydu ve çok bulut spot örnek stratejisinin dayanıklılığını doğruladı.

Adayların genellikle gözden kaçırdığı noktalar.

Ağ kesintisi olduğunda, kesilme sinyali gecikirse veya kaybolursa uç beyin senaryolarını nasıl önlersiniz?

Adaylar genellikle 2 dakikalık uyarının garantili olduğunu varsayıyor. Gerçekte, ağ kesintileri sinyal iletimini geciktirebilir. Çözüm, iş yüklerinin zaman sınırlı kilitler tutacağı Kira mekanizması kullanıyor. Kontrol düzlemi kirayı yenileyemezse, düğümü şüpheli olarak işaretler ve yeni trafiği yönlendirmeyi durdurur. Aynı zamanda, dağıtık bir günlükte bir Tombstone kaydı (örneğin, Apache Kafka) izole örneğin işlemeye devam etse bile sonuçlarının bağlantı kurduğunda bayat olarak reddedilmesini sağlayarak çelişkili durum güncellemelerini önler.

Kontrol noktası esnasında örnek zorla kesilirse, son senkronizasyon sırasında veri tutarlılığını nasıl sağlarsınız?

Birçok kişi basit checkpointing öneriyor ancak "son aşama" tutarlılık sorununu göz ardı ediyor. Doğru yaklaşım, Copy-on-Write (COW) anlamsal ve atomik taahhüt protokollerini kullanır. Son senkronizasyondan önce, uygulama ayırma işlemlerini durdurur (örneğin, GC duraklamaları veya uygulama kancaları aracılığıyla), bir bellek anlık görüntüsü oluşturur (CRIU kullanarak) ve bunu S3'e S3 Güçlü Tutarlılık ile veya Ceph'e atomik RADOS işlemleri ile yazar. Sistem, bir İki Aşamalı Taahhüt (2PC) modeli uygular: checkpoint'i hazırlamak, kontrol uçağına onaylamak ve ancak ondan sonra bağlantıları boşaltmak. Taahhüt aşaması sırasında kesilme meydana gelirse, yedek örnek önceki tutarlı onay noktasına geri döner ve olayları Kafka ofset günlüğünden yeniden oynatır.

Binlerce spot örneğin eşzamanlı kesilme bildirimleri aldığında ve sınırlı yedek kapasiteleri için rekabet ettiğinde sürüklenen sürü problemlerini nasıl hafifletirsiniz?

Adaylar genellikle kitlesel tahliyeler sırasında kaynak çekişmesini gözden kaçırıyor. Çözüm, kontrol düzlemi katmanında bir Token Bucket algoritması uygular, göçleri yedek havuzun emme oranı ile eşleştirerek yavaşlatır. Ayrıca, kritik finansal iş yüklerinin yedek kapasite üzerinde daha az kritik toplu işler üzerinde öncelikli olmalarını sağlamak için Öncelik Sınıfları (PriorityClass olarak Kubernetes'te) kullanır. Geri Basınç mekanizması, API Ağ Geçidi'ne gelen istekleri geçici olarak kuyruğa almak için sinyal gönderir, böylece yeni örnekler, taşınma sonrası trafik dalgaları tarafından hemen aşırı yüklenmez. Son olarak, tahminsel makine öğrenimi modelleri, beklenen kesilme dalgalarından 15 dakika önce yedek kapasiteyi önceden ölçeklendirmek için AWS spot fiyat geçmişlerini analiz eder, böylece geçiş eğrisi yumuşatılır.