Telafi İşlemleri (Compensating Transactions) Tasarımı
Mikroservis mimarisinde her servis kendi veritabanına sahip olduğu için veri bütünlüğü sorunları kaçınılmaz hale gelir. Çok servisli işlem yönetimi bu noktada kritik bir gereksinim olarak öne çıkar. Saga deseni, uzun süren işlemleri yerel transaction'lara bölerek ardışık biçimde çalıştırır. Her adım başarılı olursa akış tamamlanır. Bir adım başarısız olursa tamamlanan işlemler telafi işlemleriyle düzeltilir. Koreografi tabanlı saga'larda servisler birbirini olaylar üzerinden haberdar eder. Merkezi kontrol tabanlı yaklaşımda ise merkezi bir bileşen adımların sırasını belirler. Her iki yöntemin de kendine özgü avantajları ve zorlukları vardır. Telafi işlemlerinin tekrarlanabilir tasarlanması vazgeçilmezdir. Ağ gecikmeleri nedeniyle mesajlar birden fazla defa işlenebilir. Bu nedenle her işlem için eşsiz bir kimlik tutulmalı. Saga'nın izlenmesi de ek bir özen gerektirir. Dağıtık izleme araçları bu akışı görünür kılar.
Event odaklı veri senkronizasyonu, servisler arasında zayıf bağlılığı sağlayarak veri akışını mümkün kılar. Bir servis verisini değiştirdiğinde bir olay yayınlar. Diğer servisler bu olayı dinleyerek kendi lokal kopyalarını yeniler. Mesaj aracıları bu dağıtımı güvenilir biçimde sağlar. Apache Kafka gibi platformlar olayları kalıcı olarak saklayarak yeniden işlemeye izin verir. Bu özellik, yeni bir servis eklendiğinde geçmiş verinin aktarılmasını kolaylaştırır. Olay sırası ise özel bir mesele olarak ele alınmalıdır. Aynı kayda ait olaylar yanlış düzende işlenirse hatalı durumlar ortaya çıkar. Bu nedenle bölüm anahtarları dikkatli seçilmelidir. Ölü harf kuyrukları işlenemeyen mesajları izole ederek sistemin akışını korur. Yeniden deneme politikaları kademeli geri çekilme birlikte uygulanmalıdır. İşletimsel olarak olay gecikmelerinin izlenmesi gereklidir.
Eventual consistency kavramı, güncellemelerin bütün kopyalara sınırlı bir süre içinde yayılacağını garanti eder. Hemen tutarlılığın feda edildiği bu yaklaşım yüksek kullanılabilirlik sağlar. Kullanıcılar bazen güncel olmayan veri görebilir. Bu durum birçok senaryo için kabul edilebilirdir. Bankacılık gibi alanlarda ise katı garantiler şart olabilir. Okuma sırasında tutarsızlığı azaltmak için okuma onarımı teknikleri kullanılabilir. Arka planda çalışan süreçler de farklılıkları zamanla giderir. Vektör saatleri çakışmaları belirlemek için kullanılır. Son yazan kazanır gibi basit çözüm yaklaşımları her durumda uygun değildir. Domain kuralına dayalı birleştirme daha doğru sonuçlar verir. Ekip takımları bu modeli ürün deneyimiyle birlikte tasarlamalıdır.
İki aşamalı commit protokolü, çok düğümlü işlemlerde bütünlüğü sağlamak için geleneksel bir çözümdür. Yönetici düğüm önce bütün düğümlere hazır olup olmadıklarını sorar. Katılımcılar hazırsa kilitleri tutarak onay verir. Merkezi bileşen hepsinden pozitif yanıt alırsa commit komutunu gönderir. Fakat koordinatör çöktüğünde bağlı servisler uzun süre bloke kalabilir. Bu durum sistemde önemli bir darboğaz yaratır. Ağ bölünmeleri da protokolün güvenilirliğini zayıflatır. Büyüme kapasitesi açısından bu model sınırlı kalır. Gecikmeye duyarlı ortamlarda performans ciddi ölçüde düşer. Dolayısıyla modern mikroservis sistemlerinde genellikle daha esnek desenler seçilir edilir. Buna rağmen bazı sınırlı durumlarda protokol hâlâ faydalıdır.
Servisler arası veri paylaşımı, servis tabanlı sistemlerin en çok konuşulan konularından biridir. Senkron API çağrıları kolay görünse de art arda bağımlılıklar yaratabilir. Tek bir modül yavaşladığında tüm zincir etkilenir. Eşzamansız mesajlaşma bu tehlikeyi azaltır. Veri çoğaltma ile servisler ihtiyaç duydukları verileri yerel olarak tutar. Fakat bu durumda tutarlılık yükü artar. Ortak veritabanı yaklaşımı hızlı geliştirme sağlar. Lakin servisler arasında güçlü bağ oluşturur. Bu da bağımsız dağıtımı zorlaştırır. Ön yüze özel arka uç gibi katmanlar farklı istemcilerin gereksinimlerini karşılar. Kontrat odaklı geliştirme ile API değişiklikleri planlı şekilde ilerler. Doğru strateji, ürün gereksinimlerine ve ekip yapısına bağlı seçilmelidir.
Idempotent mesaj işleme teknikleri, mikroservislerde aynı olayın birden fazla kez teslim edilmesi durumunda veri tutarlılığını koruyabilmek için vazgeçilmez bir yaklaşımdır. Ağ kesintileri, yeniden deneme mekanizmaları ve broker kaynaklı tekrar teslimler sıkça yaşanan olaylardır. Bu nedenle her mesajın benzersiz bir tanımlayıcı ile işaretlenmesi ve işlenmiş mesajların bir tabloda kaydedilmesi önerilir. Tüketici servis, yeni bir mesaj geldiğinde önce bu kayda göz atarak daha önce işlenip işlenmediğini kontrol eder. Böylece aynı iş mantığı tekrar çalıştırılmaz. Doğal kontrol ilkesi olan koşullu güncellemeler de bu hedefe güçlü biçimde destek olur. Örneğin bir sipariş durumunu güncellerken mevcut sürüm numarasının eşleşmesi şartı aranabilir. Mesaj işleme ile kayıt güncellemesinin aynı yerel işlem içinde gerçekleşmesi ise atomikliği güvence altına alır. Idempotency anahtarları belirli bir pencere sonra temizlenebilir, ancak bu süre yeniden teslim olasılığına göre belirlenmelidir. Test aşamasında aynı mesajın birden fazla kez gönderildiği senaryolar mutlaka denenmeli edilmelidir. Bu sayede beklenmeyen yan etkilerin üretim ortamına geçmesi engellenir. Sonuç olarak idempotent tüketiciler, dağıtık sistemlerde sağlamlığı artıran temel bir yapı taşıdır.
Outbox deseni ile güvenilir olay yayını, bir servisin veritabanı değişikliği ile olay yayınlama işlemini tek bir işlem içinde gerçekleştirmesini sağlayan etkili bir yöntemdir. Klasik yaklaşımda veritabanına yazma ve mesaj broker'ına gönderme ayrı işlemler olduğundan, biri başarısız olduğunda sistem tutarsız konuma düşebilir. Outbox tablosu bu sorunu, olayın aynı transaction içinde iş verisiyle birlikte saklanması ile çözer. Ayrı bir yayıncı süreç ya da CDC tabanlı araç bu tablodaki kayıtları okuyup broker'a gönderir. Yayın başarıyla tamamlandığında ilgili kayıt işaretlenir ya da silinir. Bu yaklaşım at-least-once teslim güvencesi sunduğundan tüketici tarafında idempotency zorunlu hale gelir. Olay sıralamasının korunması için aynı varlığa ait olayların aynı partisyon anahtarıyla gönderilmesi önemlidir. Outbox tablosunun büyümesi performans sorunlarına yol açabileceğinden düzenli temizlik planı tanımlanmalıdır. Zaman damgası, olay türü ve yük alanlarının tutarlı bir şemayla tutulması izleme açısından faydalıdır. Ayrıca yayınlayıcının kesintiye uğraması durumunda kayıtların kaybolmadan işlenmeye devam etmesi sağlanmalıdır. Bu desen, özellikle stok gibi kritik alanlarda güvenilir entegrasyonun çekirdeğini oluşturur.
Dağıtık kilitleme ve eşzamanlılık kontrolü, birden fazla servis örneğinin aynı kaynağa paralel biçimde erişmesinden doğabilecek çakışmaları önlemek için gereklidir. Redis tabanlı kilitler, ZooKeeper veya etcd gibi koordinasyon servisleri bu amaçla sıkça başvurulan araçlardır. Kilit ömrü tanımlanırken işlemin en uzun makul tahmini göz önünde bulundurulmalıdır. Aksi halde kilit sahibi çökerse kaynak bir müddet kilitli kalabilir. Fencing token kullanımı, süresi dolmuş bir kilit sahibinin bayat istek göndermesini engellemek için önemli bir yöntemdir. İyimser eşzamanlılık kontrolü ise sürüm numarası ya da zaman damgası denetleyerek çakışmaları yalnızca güncelleme anında yakalar. Çekişmenin düşük olduğu senaryolarda bu yaklaşım kilitlemeye göre daha performanslı çalışır. Yüksek çekişmeli kaynaklarda ise pesimistik kilitleme daha güvenilir sonuçlar verebilir. Kilit kullanımı sistemin genel performansını artırabileceğinden her kaynak için dikkatli seçim yapılmalıdır. Hata durumlarında kilitlerin düzgün biçimde serbest bırakılması ve izlenmesi operasyonel sağlık için gereklidir.
Veri çoğaltma ve tutarlılık modelleri, dağıtık veritabanlarında verinin farklı düğümler arasında nasıl senkronize edileceğini belirleyen önemli kavramlardır. Senkron çoğaltmada yazma işlemi tüm replikalar kabul edilene kadar bekler, bu da tutarlılığı güçlendirirken gecikmeyi yükseltir. Asenkron çoğaltmada ise birincil düğüm yazmayı hemen onaylar, replikalar daha sonra senkronize olur. Bu model daha yüksek kullanılabilirlik sunsa da replika gecikmesi nedeniyle eski veri okunabilir. Güçlü tutarlılık, her okumanın en son yazılan değeri döndürmesini hedefler. Nihai tutarlılık ise sistemin belirli bir süre sonunda tüm düğümlerin aynı duruma ulaşacağını vaat eder. CAP teoremi, ağ bölünmesi anında tutarlılık ile erişilebilirlik arasında bir tercih yapılması gerektiğini belirtir. Servis sınırlarını aşan verilerde genellikle nihai tutarlılık uygun bulunur. Okuma-yazma kuorumları ve vektör saatleri gibi mekanizmalar çakışan güncellemelerin çözümünde yardımcı olur. Hangi modelin benimseneceği iş gereksinimlerine ve kabul edilebilir gecikme toleranslarına göre değerlendirilmelidir.
Hata telafisi ve kompanzasyon işlemleri, dağıtık işlemlerde bir adım başarısız olduğunda önceki adımların etkisini geri almak için tasarlanmış çözümlerdir. Klasik iki aşamalı işlem protokolleri mikroservislerde esneklik açısından sınırlayıcı olabildiğinden Saga deseni tercih edilen bir alternatiftir. Saga, her yerel işlemi bir kompanzasyon işlemiyle eşleştirerek ilerler. Koreografi tabanlı sagalarda servisler birbirlerinin olaylarını dinleyerek sürecin sonraki adımına geçer. Orkestrasyon tabanlı sagalarda ise merkezi bir orkestratör adımların sırasını belirler. Kompanzasyon işlemleri tam anlamda geri alma değildir; örneğin gönderilmiş bir e-posta geri çekilemez, yalnızca düzeltici bir bildirim iletilebilir. Her kompanzasyonun da idempotent yazılması gerekir, çünkü kendisi de yeniden çalıştırılabilir. Zaman aşımı, yeniden deneme sınırları ve ölü harf kuyrukları başarısız adımların izlenmesi için gerekli bileşenlerdir. İşlem durumunun kalıcı olarak tutulması sistemin çökme sonrasında kaldığı yerden devam etmesini sağlar. Sonuçta iyi tasarlanmış kompanzasyon mekanizmaları, dağıtık sistemlerde iş tutarlılığını korumanın en güvenilir yollarından biridir.
Mikroservislerde Veri Yönetiminin Temel İlkeleri
Mikroservislerde her servis çoğunlukla kendi veri deposuna sahip olur, bu tasarım servislerin bağımsız ölçeklenmesine olanak tanır. Ancak dağıtık veri ortamında bir işlemin birden fazla servise yayılması, tutarlılığın korunmasını zorlaştırır. Katı transaction modeli yerine çoğu zaman eventual consistency modeli alır. Bu model, bir süre farklı veri görünümlerinin normal kabul edildiğini öngörür. Tasarım sürecinde bu uzlaşının dikkatle belirlenmesi şarttır. Ekipler, hangi verinin anlık, hangi verinin gecikmeli tutarlı olması gerektiğini net biçimde belirlemelidir. İş mantığı ile mimari kısıtların hizalanması, uzun ömürlü çözümler üretir. Bu bölümde temel kavramları ve sorunun kökenini inceleyeceğiz.
Veri Tutarlılığında Sık Yapılan Hatalar
Ekipler sıklıkla servisler arasında senkron çağrı zincirleri kurarak işe başlar, bu tercih, bir noktadaki gecikmenin kaskad hatalara dönüşmesine sebep olabilir. Sık görülen başka bir yanlış, her senaryo için two-phase commit kullanmaya kalkmaktır, ancak bu mekanizma, ağ bölünmelerinde sistemi kilitleyebilir. Yinelenen mesajların yönetilmemesi ile idempotent tasarımın ihmal edilmesi sık görülür. Olay yayınlama ile veritabanı güncellemesinin ayrı transaction'larda yapılması, veri kaybına veya uyumsuzluğa neden olabilir. Bu tür aksaklıkların kökeni çoğunlukla kısa vadeli ve basit görünen kararlara dayanır.
Tutarlılık İçin Profesyonel Yaklaşımlar
Deneyimli mimarlar, Saga deseninin çoğu senaryoda en pratik çözüm olduğunu belirtir, zira her servis kendi işlemini yürütür ve hata durumunda telafi eylemi tanımlanır. Outbox yaklaşımı, veri ve olay tutarlılığını sağlamak için güçlü bir yöntem olarak öne çıkar. Olay tüketicilerinin mükerrer mesajlara dayanıklı olması, uzmanlarca temel bir gereklilik olarak görülür. İzleme altyapısının güçlü kurulması, olası sapmaların geç kalmadan görülmesine yardımcı olur. Gereksinimlerin baştan doğru tanımlanması, uzun vadede önemli maliyet tasarrufu sağlar.
Tutarlılığın Finansal Yönleri
Harcamalar, tercih edilen yaklaşıma ve geliştirici birikimine göre önemli ölçüde değişir, event broker ve izleme araçları, işletim giderlerini kalıcı olarak artırır. Veri hatalarının maliyeti, önleyici altyapı yatırımından çoğu zaman çok daha fazla olabilir. Maliyet kontrolü açısından, tüm sistemi aynı sıkılıkta korumak yerine kritik akışlara öncelik verilmesi tavsiye edilir. Bulut sağlayıcılarının sunduğu hazır servisler, kurulum süresini ve harcamayı kısaltabilir. Yine de uzun vadeli bakım ve ekip eğitimi kalemlerinin de bütçeye dahil edilmesi gerekir.
Geçiş Döneminde Zamanlama Stratejileri
Mimari değişikliklerin düşük trafikli dönemlere yerleştirilmesi, kesinti etkisini belirgin biçimde azaltır, çünkü eski ve yeni sistemin birlikte çalıştığı dönemde uyumsuzluk yaşanabilir. Büyük değişiklikler öncesinde, staging ortamında kapsamlı yük ve tutarlılık testleri yapılması önerilir. Ayrıca kademeli geçiş (canary veya blue-green) stratejileri, riskin kontrollü biçimde yönetilmesini sağlar. Ekiplerin nöbet ve destek planlarını, kritik zaman dilimlerini kapsayacak biçimde hazırlaması da önemlidir. Bakım pencereleri de iyi duyurulmalı ve paydaşlarla önceden koordine edilmelidir.
Uzmanlara Yöneltilen Yaygın Sorular
Eventual consistency her durumda uygun bir seçenek midir, hayır, her iş kuralı için aynı esneklik kabul edilemez ve bazı alanlar sıkı kontrol gerektirir. Bir diğer sık soru, dağıtık transaction ile Saga arasındaki farkın ne olduğudur, Saga her servisin yerel işlemini yürütüp hata halinde telafi eder, klasik model ise tüm katılımcıları eş zamanlı koordine eder. Event sırası sorununun nasıl çözüleceği, geliştiricilerin en çok merak ettiği noktalardan biridir, anahtar bazlı bölümleme ile aynı varlığa ait olayların sırayla işlenmesi sağlanabilir. Son olarak, tutarsızlık tespit edildiğinde ne yapılması gerektiği de önemli bir sorudur, önce kök nedenin analiz edilmesi, ardından telafi veya mutabakat (reconciliation) süreçlerinin çalıştırılması önerilir.