Stateful’dan Stateful’a: Huawei Cloud Cloud Container Engine (CCE) Üzerinde Dağıtık Domain Event Yönetimi

Stateful bir domaini buluta taşımak, yalnızca veriyi diske yazmaktan ibaret değildir; gerçeğin zamanını, dilini ve kanıt biçimini yeniden tanımlamaktır. Huawei Cloud’un Cloud Container Engine (CCE) üzerinde çalışan bir ödeme ya da sigorta sistemi düşündüğümüzde, mimariyi güçlü kılan şey “kaç CPU, kaç GB RAM” gibi nicelikler değil; state’in nasıl modellenip çoğaltıldığı, domain event’lerinin nasıl üretildiği ve tekrar oynatıldığında aynı gerçeği kanıtlayıp kanıtlamadığıdır. “Deterministik” kelimesi burada performans ölçütü değil, bir ahitname gibidir: aynı girdiye her zaman aynı çıktıyı üretmek zorunda olan bir sistem, state’i yalnızca saklamaz; onu kanıtlanabilir olaylara ayırır, olayları zamanla ilişkilendirir ve bu ilişkinin bozulmadığını sürdürür. CCE üzerinde kuracağımız mimari, bu nedenle üç eksende ilerler: state’in dağıtık olarak güvenli tutulması, domain event’lerinin nedensel bütünlük içinde üretilmesi ve ihtiyaç hâlinde rehydration yoluyla aynı gerçeğin yeniden kurulabilmesi.

Deterministikliği sağlamak için önce state’in türünü ayırt etmek gerekir. Operasyonel state, işlem anında doğrulanan ve düşük gecikmeyle tutulan bilgidir; sipariş rezervasyonu, poliçe statüsü ya da risk kararı gibi anlık doğrulama gerektiren cümleler bu sınıfa girer. Türev state, operasyonel olaylardan türeyen, okuma ağırlıklı projeksiyonlardır; risk raporları, müşteri 360 görünümü, poliçe portföy skorları böyledir. Kalıcı kanıt state’i ise ledger kayıtları, audit logları ve settlement çıktıları gibi hukuken savunulabilir cümleleri temsil eder. CCE üzerinde bu üç state tipini aynı depoda birleştirir ve tek bir servis tarafından taşınıp çoğaltılır kılarsanız, deterministikliği kağıt üzerinde korurken pratikte hata yüzeyini büyütürsünüz. Doğru yaklaşım, state’i domain diline göre ayırmak ve her bağlamın yalnızca kendi kanıt cümlelerini sakladığı depoları, Kubernetes’in kendisinin değil, bağlamın yönettiği yaşam döngülerine bağlamaktır. Bu, StatefulSet ve PersistentVolume gibi mekanizmaları yalnızca “nasıl” için kullanırken, “ne” ve “neden” sorularını domain seviyesinde çözmek demektir.

CCE tarafında stateful iş yüklerinin yaşam döngüsü, aslında Kubernetes ilkelerine sadık kalmanın ötesinde, yanlış anlamaları bertaraf edecek bir zaman disiplini gerektirir. StatefulSet kullanırken ordinal kimlikler, headless service ve sabit DNS kayıtları yalnızca ulaşılabilirlik için değil, idempotent yan etkiler için de önemlidir. Bir node bakımına girer ya da ölürken PodDisruptionBudget ile eşik belirlemek, Readiness ve Liveness prob’larının gerçekten iş yaptığını kanıtlayacak işaretler üretmesini sağlamak, preStop hook içinde zarif kapanış ve “son görülen olay ofseti” gibi işaretleri yayınlamak, rehydration maliyetini dramatik biçimde düşürür. Anti-affinity ve topology spread kısıtları, kopyaların aynı failure domain içinde birikmesini engellerken, volume sınıfı seçimi deterministikliği doğrudan etkiler: operasyonel state için yüksek IOPS ve düşük latency sunan blok tabanlı bir sınıf, türev state için nesne depolamaya yakın bir strateji, kalıcı kanıt için ise yazma sırasını koruyan, append dostu bir kanal gerekir. Mimar burada depolama motorunu seçmekten önce “zamanı ve sıra kavramını” seçer; çünkü domain event’lerinin kanıt gücü, diskin tipi kadar, o diske yazılan şeyin “hangi saatle ölçüldüğü” ile ilgilidir.

Domain event üretimi, CCE’nin “sinyal ve kuyruk” dünyasıyla birlikte düşünülmelidir. Outbox yaklaşımını yalnızca bir entegrasyon paterni olarak yorumlamak, deterministikliği ıskalar. Outbox, bir servis içinde kanıt cümlelerinin ilan edildiği tek yer olmalıdır; yani servisin yazma işlemi, hem kendi state’ini hem de o state’in kanıt cümlesini aynı nedensel bağ içinde üretmelidir. Burada kilit nokta “fencing” ve tek yazar disiplinidir: lider seçimi yapılan replikalarda fencing token olmadan eşzamanlı yazma denemelerini kati surette reddetmek, event ID’lerinin zaman damgası değil, bağlamca üretilen monoton bir sıra üzerinde yükselmesi, idempotent tüketimin gerçekten idempotent olması için gereklidir. Kubernetes lider seçimini bir sidecar ya da koordinasyon kütüphanesiyle çözebilirsiniz; ama asıl lider seçimidir: kimin cümle kurma yetkisi olduğudur. Bu yetki, Pod’un çalıştığı node’un kaderine değil, bağlamın “tek-gerçek” tanımına bağlanır.

Eventual consistency, CCE üzerinde bir slogan değil, görünür bir takvime dönüştürülmelidir. Sipariş bağlamı, ödeme bağlamından aldığı PaymentPromiseReceived sonrasında en geç N saniye içinde ya OrderCommitted üretir ya da OrderCancelled ilan eder. Bu sözleşme, kuyruk gecikmesi ve tüketici ölçeklenmesi gibi operasyonel parametrelerin arkasına saklanmaz; aksine, Readiness prob’ları ve HPA (horizontal pod autoscaler) sinyalleri doğrudan bu takvimle ilişkilendirilir. HPA politika değişimi yalnızca CPU/latency eşiğiyle değil, “kanıt üretme süresi” ile tetiklenir. Böylece ölçeklenme, hız uğruna gerçeğin ertelenmesi anlamına gelmez; gerçeğin zamanında ilan edilmesi için kaynak tahsisine dönüşür. Burada izlenebilirlik kritik rol oynar: correlation-id, causation-id ve event-ofsetleri, uygulama log’larından bağımsız bir izlekle, domain akışına özgü bir zaman çizgisi üzerinde tutulmalıdır. Bu çizgi, Pod’lar yeniden planlandığında kaybolmamalı; sistemin kendi hafızası olarak dışarıda bir yerde saklanmalıdır.

Rehydration, deterministikliğin hakiki sınavıdır. Bir stateful servis düştüğünde veya yeni bir replika katıldığında, domain event logundan replay ile state’i yeniden kurmak kulağa basit gelir; pratikte neyin yeniden kurulduğunu, neyin yalnızca projeksiyon olarak güncellendiğini ayırmak gerekir. Operasyonel state’i her seferinde sıfırdan replay etmek yerine, snapshot stratejisiyle belirli aralıklarla sabitlenmiş, bağlamsal olarak imzalanmış anlar üretmek, rehydration süresini dakikalardan saniyelere indirir. Snapshot tutmak tek başına yeterli değildir; snapshot’ın hangi zaman sözleşmesine göre alınmış olduğu, sonraki replay’in hangi saatten devam edeceği, event akışında boşluk olup olmadığına dair kanıt cümleleri üretilmelidir. CCE üzerinde bu sürecin güvenliği, yalnızca dosya kilitlemekle değil, snapshot’ı alan Pod’un o anda gerçekten yazma yetkisine sahip olduğunun kriptografik veya en azından fencing temelli kanıtıyla sağlanmalıdır. Aksi takdirde hızlı bir rehydration, yanlış bir gerçeğin hızlı inşasına dönüşür.

Çoğaltma topolojisini belirlerken “Stateful’dan Stateful’a” ilkesini unutmamak gerekir. Çoğu ekip, stateful bir çekirdek üzerine stateless okuyucular yığarak rahatlar; fakat türev state’in de aslında başka bir bağlamda stateful olduğu gerçeği gözden kaçar. Bir risk projeksiyonu, tek satır SQL’den ibaret değil, farklı bağlamların zamansal ilişkisidir; bu nedenle yalnızca cache katmanıyla hızlandırılamaz. Türev state’i yöneten servis, orijinal olayların nedensel sırasını bilmek zorundadır. Olayların bir bağlamda “aynı ana” düştüğü durumlarda, deterministik bağlayıcı kurallar koymak – örneğin aynı milisaniyede gelen iki olayı bağlamsal bir öncelik fonksiyonuyla sıralamak – ileride tekrarlanabilir bir gerçek üretir. Kubernetes node saatlerinin sapması bu yüzden operasyonel değil, mimari bir konudur. Zaman senkronizasyonunun disiplini, PTP/NTP ayarlarından önce “hangi bağlamın saatinin hangi kararı belirlediği” sorusuna verilmiş cevapla başlar.

Kurtarma ve gözetim aşamalarında “otomatik düzeltme” yerine “yeniden cümle kurdurma” yaklaşımı tercih edilmelidir. Reconciliation servisi dış dosyaları alır, ledger bağlamının cümleleriyle karşılaştırır; uyuşmazlık bulduğunda, bir “repair script” çağırmak yerine sorumlu bağlamı yeniden cümle kurmaya zorlar. Bu tasarım, Kubernetes Job veya CronJob kaynaklarıyla entegre şekilde, fakat asıl olarak domain sözleşmesiyle yönetilir. Böylece düzeltme, veritabanı seviyesinde sütun güncellemekten ibaret bir operasyon değildir; kanıtın yeniden üretilmesidir. CCE ölçeğinde bu yaklaşım, izlenebilirliği operasyon loglarından domain event haritasına taşır; postmortem tartışmalar “hangi pod öldü?”den “hangi bağlam geç konuştu ya da yanlış cümle kurdu?”ya evrilir.

Takım topolojisi, mimarinin sessiz kanunudur. CCE üzerinde sorunsuz deploy edilen on servis, tek bir kelimenin farklı anlamlarda kullanıldığı bir organizasyonda yalnızca “on farklı hız” üretir; doğruluk üretmez. Authorization ekibi “onay” cümlelerini, Order ekibi “taahhüt” cümlelerini, Ledger ekibi “mali gerçek” cümlelerini kanıtlamakla yükümlüdür. Bu yükümlülük, yalnızca kod sahipliği değil, zaman sözleşmesi ve olay sözleşmesi sahipliğidir. OKR’lar, pod sayısı veya CPU maliyeti değil, bağlam cümlelerinin zamanında ve tutarlı ilan edilmesi üzerine yazılmalıdır. Kubernetes, bu disiplinin yürütme motorudur; disiplini kendisi yaratmaz. Disiplini yaratan, bağlamın cümle kurma yetkisinin kimde olduğuna dair net ve savunulabilir bir karardır.

Bütün bu bileşenleri bir araya getirdiğimizde, CCE üzerinde deterministik bir stateful mimarinin ana hatları netleşir. Tek-yazar ilkesi ve fencing ile korunan operasyonel state, outbox aracılığıyla bağlam cümlelerini ilan eder; bu cümleler, olay sırasını koruyan kuyruklar üzerinden ilgili bağlamlara taşınır; türev state, replay ve snapshot stratejilerinin birlikte kullanımıyla rehydrate edilir; reconciliation, hatayı “yeniden cümle kurdurarak” giderir; izlenebilirlik, metriklerden önce nedenselliği ve zamanı görünür kılar. Ölçeklenme politikaları, hız talebine değil, kanıt üretme takvimine bağlıdır. Depolama sınıfı ve topoloji tercihleri, IOPS’tan önce olay sırası ve nedensellik dayanıklılığına göre yapılır. Ve en önemlisi, her bağlam kendi saatini ilan eder; mikroservislerin bağımsızlığı veri paylaşmamakla değil, başkasının saatine esir olmamakla sağlanır.

Sonuçta “Stateful’dan Stateful’a” demek, state’i yalnızca ayakta tutmak değil, onu her seferinde aynı gerçeği kuracak şekilde konuşturmak demektir. Huawei Cloud CCE, bu disiplin için güçlü bir yürütme ortamı sağlar; fakat gerçeğin deterministik olup olmadığına CCE karar vermez. Kararı, siz bağlam çizerek, cümle kurma yetkisini tekilleyerek ve zamanı bir sözleşme hâline getirerek verirsiniz. Doğruluğu böyle inşa ettiğinizde, hız artık bir hak değil, kazanılmış bir yan üründür; cache, gerçeğin yerine geçmez; outbox, entegrasyon değil, kanıtın ilanıdır; rehydration, kurtarma değil, gerçeğin yeniden yazılmasıdır. Bu nedenle mimariyi bir diyagramla değil, bir ilkeyle bitirmek yerinde olur: Zaman deterministik değilse, zeka asla güvenli değildir.

HuaweiCloud #CloudArchitecture #StatefulSystems #Microservices #DomainDrivenDesign