2020'lerde sürdürülebilir hesaplama ve kurumsal net sıfır taahhütleri için yapılan itici güçle ortaya çıkmıştır. Kuruluşlar, bulut iş yüklerinin, daha düşük karbon yoğunluğuna sahip bölgelere veya zamana kaydırılabileceğini fark etmiştir. Geleneksel planlayıcılar yalnızca maliyet ve performans için optimize edilmiştir, enerji kaynaklarını dikkate almamıştır. Bu soru, heterojen altyapı, tahminsel otomatik ölçekleme ve dağıtılmış sistemlerde çoklu amaçlı optimizasyon anlayışını test etmektedir.
Veri merkezleri, dünya genelindeki elektriğin %1-2'sini tüketmektedir. Fosil yakıtlara dayalı şebekelerde çalışan iş yükleri ile yenilenebilir enerjiye dayalı şebekelerde çalışan iş yükleri arasındaki karbon ayak izi 10 kat kadar farklılık gösterebilir. Ancak, durum bilgisi olan iş yüklerini AWS Spot Instances veya farklı bölgelere taşımak, kesinti ve gecikme cezası riski taşır. Zorluk, gerçek zamanlı karbon yoğunluğu API'lerini kabul eden, iş yükü değişimini tahmin eden ve göç kararlarını karbon azaltımını, mevcudiyet SLO'larıyla dengeleyen bir sistem inşa etmektir; merkezi bir planlayıcının darboğaz haline gelmemesi gerekmektedir.
Özelleştirilmiş Descheduler politikaları ve Cluster Autoscaler entegrasyonları ile Kubernetes kullanan merkeziyetsiz, ajan tabanlı bir planlama ağı. Her düğüm, yerel şebeke yoğunluğunu izleyen bir Karbon Farkındalığı Ajanı çalıştırır. İş yükleri, taşınabilirlik (durumsal vs. durum bilgisi olan) ve kritiklik açısından sınıflandırılır.
Durumsal patlama iş yükleri, düşük karbon yoğunluğuna sahip bölgelerde AWS Spot Instances veya Azure Spot VMs üzerine planlanır; Karpenter veya Cluster API aracılığıyla. Apache Spark yürütücüleri, önceden engelleme durumu ile başa çıkmak için ilerlemeyi Amazon S3'e noktasal olarak kaydeder. Bu yaklaşım, hata toleranslı hesaplamalar için karbon tasarrufunu en üst düzeye çıkarır.
Durum bilgisi olan iş yükleri farklı bir yaklaşım gerektirir. Kritik veritabanları, KubeVirt veya VMware vMotion aracılığıyla canlı göç kullanırken, diğerleri Redis veya PostgreSQL akışıyla ikincil kümelere asenkron replikasyon kullanır. WASM tabanlı bir planlama eklentisi, kenarda çoklu amaçlı optimizasyonu Pekiştirme Öğrenimi ile uygular. Istio, göçler sırasında trafik kaydırmayı yönetir ve etcd, küresel kilitler olmadan dağıtılmış durumu sürdürür.
Küresel bir fintech şirketi, 50.000 çekirdek üzerinden her gece toplu risk hesaplamaları yapmaktadır. Almanya'daki veri merkezi kömür ağırlıklı akşam şebekesi üzerinden çalışırken, Norveç'in hidroelektrik enerjisi sunan bölgesi daha temiz enerji sunmakta fakat aralıklı olarak daha yüksek noktasal fiyatlarla gelmektedir. Mevcut Apache Airflow tabanlı boru hattı, işlerin CET gece yarısı tetiklenmesiyle karbon zirveleri yaratıyordu.
Sürdürülebilirlik ekibi, hesaplama harcamasını artırmadan %40 karbon azaltımı zorunluluğu getirdiğinde sorun ortaya çıktı. Durumsal risk modellerinin tamamlanması 6 saat sürmekteydi, ancak bunları spot örneklere geçirmek, düzenleyici raporlama son tarihlerinin ihlal edilmesine neden olabilecek engellemeler riski taşıyordu. Ayrıca, denetim izleri için PostgreSQL işlem günlükleri AB ekonomik bölgesinden ayrılamazdı, bu da göç stratejilerini karmaşık hale getirdi.
Çözüm A: Statik Zaman Kaydırma, toplu başlangıçları grid karbon yoğunluğu tarihsel ortalamaları baz alarak düştüğünde geciktirmeyi önermiştir. Bu yaklaşım, mevcut Kubernetes kümeleri içinde basit CronJob ayarlamaları gerektirmiştir ve ek altyapı gerektirmemiştir. Ancak, beklenmeyen şebeke stres olayları sırasında başarısız olmuş, enerji piyasalarındaki gerçek zamanlı volatiliteleri göz ardı etmiş ve alt akış Spark analizlerini etkileyen boru hattı gecikmeleri yaratmıştır. Ayrıca, maliyet tasarrufları için spot örnek indirimlerini kullanma fırsatlarını tamamen kaçırmıştır.
Çözüm B: merkezi küresel planlayıcı, her dakika karbon API'lerini sorgulayan ve tüm kümelere iş yüklerini göç ettirme talimatı veren monolitik Go tabanlı bir planlayıcı uygulaması önerirmiştir. Bu tasarım, küresel bir optimizasyon görünümü sağlarken denetimi basit hale getirmiştir, ancak felaket bir tek hata noktası yaratmıştır. Kenar kümelerine yapılan ağ gecikmeleri genellikle 100ms'yi aşmakta, bu da geçerli kararları eski hale getirmekte ve karbon global olarak düştüğünde kalabalık sürü etkisi yaratmaktadır. En kritik olanı, bu tasarımın AB finansal verileri için GDPR veri ikamet gerekliliklerini ihlal etmesidir ve on kadar kümeyi aşan ölçekleme sorunları yaşamaktadır.
Çözüm C: Hiyerarşisel Federasyon Planlama, federatif kontrol için Karmada uygulamasını ve düğüm yerel Karbon Farkındalığı Kubelet eklentilerini uygulamıştır. Her bölgesel küme, yerel şebeke API'lerine MQTT aracılığıyla abone olmuştur; durumsal Spark yürütücüleri düşük karbonlu bölgelerde AWS Spot üzerinde çalışmakta ve S3'e noktasal olarak kaydedilmektedir. Durum bilgisi olan PostgreSQL birincilleri Almanya'da kalmakta ancak pglogical aracılığıyla Norveç'e replikasyon yapılmakta ve sadece aşırı karbon olayları sırasında Patroni felaketi ile terfi etmektedir. Bu yaklaşım, karbonu %45 oranında azaltırken 2 saat altı kurtarma SLA'larını koruyarak veri egemenliğine saygı duymuştur.
Ekip, üretim dışı ortamda pilot uygulama yapıldıktan sonra Çözüm C'yi seçmiştir. Yayılma politikaları için Karmada'yı dağıtmış ve Electricity Maps verilerini okuyan özelleştirilmiş denetleyicileri entegre etmiş, deniz yönetimi için Spot.io'yu da dahil etmiştir. Bu çözüm, karbon azaltımı, maliyet verimliliği ve düzenleyici uyum gibi rekabet eden kısıtlamaları en iyi şekilde dengelemiştir.
Üç ay sonra, karbon emisyonları %47 azalmış, maliyetler agresif spot kullanımı sayesinde %12 düşmüş ve yalnızca %0,3'lük bir iş, engellemeler nedeniyle yeniden hesaplama gerektirmiştir, bu da %1'lik SLA eşiğinin çok altında kalmaktadır. Sistem, manuel müdahale olmaksızın hidro bölgelerine hesaplamaların %80'ini otomatik olarak kaydırarak bir haftalık kömür santrali bakım penceresini başarıyla aşmıştır. Mimari, hem şebeke dalgalılığına hem de bulut sağlayıcılarının spot sona ermesine karşı dayanıklı olduğunu kanıtlamıştır.
Soru 1: Süreç devam eden bir işlem sırasında yüksek karbon alanından düşük karbon bekleme alanına bir PostgreSQL birincil kopya taşırken veri tutarlılığını nasıl sağlarsınız, ACID özelliklerini ihlal etmeden?
Senkron replikasyon ile konsensüs onayı (synchronous_commit = remote_apply) kullanarak, hedef bölgedeki beklemede işlemin uygulanması sağlanır ve ardından birincil onayı alınır. Göçten önce, beklemeyi pg_ctl promote veya Patroni REST API kullanarak terfi ettirin, yalnızca bölgelere geçiş senaryolarını önlemek için synchronous_standby_names'i boş olarak ayarladıktan sonra. Kısa süreli terfi penceresinde, gecikmeyi karşılamak için Redis akışında veya uygulama tarafında yazma önbelleğinde yazmaları kuyruklayın. Terfi tamamlandıktan sonra, uygulama trafiğini Istio sanal hizmet güncellemeleri aracılığıyla yönlendirin ve tutarlılığı pg_dump kontrol toplamları veya pg_dumpall mantıksal çözümleme slot karşılaştırmaları ile doğrulayın. Bu, karbon kaynaklı taşınabilirliğe olanak tanırken sıfır veri kaybını sağlar.
Soru 2: Neden basit bir karbon farkındalığına sahip planlama uygulaması, karbon API'si ile iş yükü planlayıcıları arasında ağ bölünmeleri sırasında genellikle CAP Teoremi'ni ihlal eder?
Planlayıcı, karbon yoğunluğu verilerini zorunlu bir kısıtlama olarak kabul ederse—örneğin, API mevcut değilse planlama yapmaktan kaçınarak—Kullanılabilirlik için Bölüm Toleransı'nı feda eder ve karbon verilerinin tutarlılığını etkiler. Doğru yaklaşım, karbonu yumuşak bir kısıtlama olarak ele alır; geri dönüş heuristikleri ile karbon API çağrıları etrafında bir devre kesici modeli uygular. Bölünmeler sırasında, sistem, önbelleğe alınan karbon yoğunluğu değerleri ile TTL yaşlanma eşikleri kullanarak maliyet veya performans odaklı planlamaya geri döner. Bu, Kullanılabilirlik'i (iş yükleri hala çalışır) korurken, karbon optimizasyonunun geçici Tutarlılık bozulmasını kabul ederek CAP'ye uyarak AP'yi seçmektedir ve karbon metriklerinde nihai tutarlılık sağlamaktadır.
Soru 3: Aynı bölgede on binlerce küme aynı anda düşük karbon yoğunluğu olayını tespit ettiğinde ve iş yüklerini taşımaya çalıştığında thundering herd problemini nasıl önlersiniz?
Göç karar mantığında, yıldızsız üssel geri çekilme uygulayarak kümeler arası eylemleri senkronize etmeme sağlamak amacıyla cluster ID'ye göre 0 ile 300 saniye arasında rastgele gecikmeler kullanın. Dağıtılmış bir semaphore veya leasing mekanizması kullanarak, varış bölgesinde eş zamanlı göçleri sınırlayarak maksimum bir kota uygulayın. Ayrıca, Prophet veya tarihsel ağ verileri üzerinde eğitilmiş LSTM modellerini kullanarak karbon düşüşlerini tahmin ederek reaktif göç yerine öngörücü ölçekleme uygulayın. Bu, düşük karbon penceresi açılmadan önce iş yüklerinin aşamalı olarak önceden konumlandırılmasına izin verir, talep zirvelerini yumuşatır ve yeşil bölgede kaynak tüketimini önleyerek planlayıcı merkeziyetçiliğini korur.