Bu senaryoda veri bütünlüğünü sağlamak, sürekli uzlaştırma süreçleri ile bir Değişiklik Veri Yakalama (CDC) mekanizması uygulamayı gerektirir. Göç işlemine başlamadan önce, mevcut durumu belirlemek için checksum doğrulaması ve hash karşılaştırmaları kullanarak bir veri tabanı anlık görüntüsü oluşturmalısınız. Geçiş sürecinde, eski ERP veritabanı işlem günlüklerinden yeni olay odaklı sisteme gerçek zamanlı değişiklikleri akıtmak için Kafka Connect veya Debezium dağıtmalısınız.
Verilerin bozulmadan yönetilmesi için dağıtılmış işlem yönetiminde Saga desenini uygulayın. Son olarak, kaynak ve hedef sistemler arasında geceleyin uzlaştırma yapmak için Apache Spark veya Databricks kullanarak paralel ETL işleri çalıştırın, elden geçirme raporları oluşturarak güven seviyeniz %99.99'a ulaşana kadar manuel inceleme yapın.
Ben, envanter yönetimini 15 yıllık bir Oracle ERP monoliti olan eski sistemden Apache Kafka ve PostgreSQL kullanan bir mikroservis ekosistemine geçiren bir global perakende zinciri ile çalıştım. ERP sistemi, yıllar içinde birden fazla tedarikçi tarafından modifiye edildiğinden, yaklaşık %30'luk tarihi stok hareketlerini etkileyen terkedilmiş kayıtlar ve eksik denetim izleri içeriyordu. İş, zaman dilimlerinde 24/7 çalışıyordu, bu nedenle herhangi bir kesinti, saat başına 2M $ satış kaybına yol açıyordu.
Veri bütünlüğü sorunu ciddiydi çünkü stok seviyelerinin doğru kalması, aşırı satış yapılmasını önlemek için zaruriydi; oysa operasyonları durdurmak için bir temiz kesim yapamaıyorduk.
Çözüm 1: Gerçek zamanlı akış ile Debezium CDC uygulama
Bu yaklaşım, Debezium bağlantılarını Oracle LogMiner'ı izlemek ve her ekleme, güncelleme ve silme işlemini Kafka konularına olay olarak yakalamak üzere yapılandırmayı içeriyordu. Artıları, alt saniye gecikmeyle neredeyse gerçek zamanlı senkronizasyon ve eski veritabanı performansına minimal etki içeriyordu. Ancak, eksileri kayda değerdi: CDC, eksik tarihi denetimlerden kaynaklanan mevcut veri boşluklarını uzlaştıramadı ve eski sistemdeki şema değişiklikleri sürekli bağlantı yapılandırması gerektiriyordu, bu da bakım yükü oluşturuyordu.
Çözüm 2: API kesme ile Strangler Fig desenini dağıtma
Eski ERP ve yeni mikroservisler için yazma işlemlerinin ikisini birden gerçekleştirecek bir soyutlama katmanı oluşturmaya karar verdik, bu sayede okuma trafiğini kademeli olarak geçiştirebildik. Artıları, üretimde yeni sistem doğruluğunu eski sistemle doğrulama fırsatı ve tutarsızlıklar meydana geldiğinde anında geri alma yeteneğiydi. Eksileri, altyapı maliyetlerini iki katına çıkarıyor, yazma işlemlerinin gecikmesine yol açıyor ve iki farklı depolama modelinde (ilişkisel vs olay kaynağı) veri tutarlılığını sağlama karmaşıklığı yaratıyordu.
Çözüm 3: Bakım pencereleriyle toplu ETL yaklaşımı oluşturma
Bu geleneksel yöntem, Apache Airflow kullanarak düşük trafik saatlerinde büyük toplu aktarımları planlamayı öneriyordu, tüm tablo karşılaştırmalarını MD5 hash'leri ile gerçekleştiriyordu. Artıları, her kaydı kapsamlı bir şekilde doğrulama yapma ve toplu işlemler için daha basit hata yönetimi sağlıyordu. Eksileri ise, ERP sisteminin tutarlı anlık görüntüler elde etmek için okuma kilitlerine ihtiyaç duymasıydı, bu da en yüksek uzlaştırma dönemlerinde envanter güncellemelerini 4-6 saat engelleyebilirdi.
Seçilen çözüm ve mantığı
Devam eden senkronizasyon için Çözüm 1 (Debezium CDC) ile tarihsel geri doldurma için değiştirilmiş Çözüm 2'yi birleştiren bir karma yaklaşım seçtik. Gerçek zamanlı değişiklikleri işlemek için Kafka Streams kullandık, aynı zamanda düşük trafik saatlerinde Spark işleri çalıştırarak denetim eksiklikleri olan %30'luk kayıt kısmını geri doldurup doğruladık. Bu seçenek, sürekli operasyon gereği ile tam veri doğruluğu ihtiyacı arasındaki dengeyi sağlamış, daha yüksek altyapı maliyetinin potansiyel kesintiden daha düşük maliyetli olduğunu kabul etmiştir.
Sonuç
Göç, planlanmamış kesinti olmadan altı hafta içinde tamamlandı. Uzlaştırma süreci, müşterileri etkilemeden önce 12,000 envanter tutarsızlığını belirledi ve düzeltti. Prometheus panoları gecikme metriklerini izledi ve CDC gecikmesinin 500 ms altında kalmasını sağladı. Üç ay süresince paralel çalışan sistemler, %99.97 doğruluk gösteren otomatik uzlaştırma ile birlikte, ERP modülünü devre dışı bırakmamıza olanak sağladı ve yıllık olarak şirketi 4M $ lisans ücreti tasarrufu sağlarken envanter doğruluğunu %99.9'un üzerinde sürdürdü.
Olay değiştirmeyen mimarilerde şema evrimi ile başa çıkma yöntemi nedir, olaylar değişmezken ve aşağıdaki tüketiciler belirli alan yapısına bağımlıysa?
Adaylar genellikle olay şemasını basitçe güncellemekten bahseder, ancak bu, olay kaynağına temel olan değişmezlik ilkesini ihlal eder. Doğru yaklaşım, Confluent Şema Kayıt Defteri veya Apicurio'yu kullanarak Şema Kayıt Defteri desenini uygulamaktır. Eski olayları yeni olay modellerine çeviren ve okuyucu sırasında dönüşüm yapan ayrı bir çeviri katmanı uygulamalısınız. Bu, değişmez denetim izini korurken alan modelinin evrim geçirmesine olanak tanır, ancak bu, tüketici mantığına karmaşıklık katmakta ve şema evrimi politikalarının dikkatli bir şekilde yönetilmesini gerektirmektedir.
Sıfır kesinti geöişleri sırasında veri tutarlılığı kararları üzerindeki CAP Teoreminin özel etkileri nelerdir ve trade-off'ları teknik olmayan paydaşlara nasıl iletirsiniz?
Birçok aday CAP Teoremini gündeme getirir ancak göç senaryolarında uygulama zorluğu çeker. Sıfır kesinti göçleri sırasında, Tutarlılık, Erişilebilirlik ve Bölüm toleransı'nı aynı anda garanti edemezsiniz; iki tanesini seçmek zorundasınız. Dağıtılmış göçlerde, genellikle Tutarlılık'tan vazgeçerek Erişilebilirlik ve Bölüm toleransı'nı sağlarsınız ve bunun yerine sonradan tutarlılığı gerçekleştirirsiniz. Bunu iş paydaşlarına iletirken, "CAP" ya da "ACID" gibi teknik terimlerden kaçının; bunun yerine, geçiş sırasında farklı sistemlerin geçici olarak farklı envanter sayıları gösterebileceğini, ancak bunların birkaç dakika içinde uyumlu hale geleceğini açıklayın. Somut örnekler verin: "Bir müşteri, web sitesinde bir ürünün mevcut olduğunu görebilir, ancak sistemler senkronize olurken, ödeme aşamasında yaklaşık 30 saniye boyunca 'stokta yok' mesajı alabilir." Bu, "tutarlılık pencereleri" hakkında gerçekçi beklentiler belirlemenizi sağlar ve paydaşların uzlaştırma süreçlerine neden ihtiyaç duyduğunuzu anlamasına yardımcı olur.
Geçici veri tutarsızlıklarının kabul edilebilir maliyetini, bir göç son tarihini geciktirme maliyeti ile nasıl hesaplıyorsunuz ve hangi metrikler kırılma noktasını tanımlar?
Adaylar sıklıkla göçlerin niceliksel risk analizi yönünü gözden kaçırırlar. Tutarsızlık Maliyeti (COI) hesaplamak için hata oranları ve iş etkisi için geçmiş verileri analiz etmelisiniz: ortalama günlük işlem hacmini, hata olasılığını ve hata başına ortalama maliyeti (müşteri hizmetleri süresi, iadeler ve itibar hasarı dahil) çarparak hesaplayın. Bunu, devam eden eski lisanslamayı, kaçırılan pazar fırsatlarını ve teknik ekip moral/iş gücü kaybı maliyetlerini içeren Gecikme Maliyeti (COD) ile karşılaştırın. Kırılma noktası, COI × göç süresi = COD × gecikme süresi olduğunda ortaya çıkar. Örneğin, veri tutarsızlıklarının günlük 5,000 $ maliyeti olduğu ve gecikme maliyetinin günlük 50,000 $ olduğu durumlarda, uzlaştırma sorunlarını geciktirmekten daha pahalı hale gelmeden önce 10 güne kadar tolere edilebilir. Hizmet Seviye Hedefleri (SLO) belirlemelisiniz; örneğin, "uzlaştırma gecikmesi kayıtların %0.1'inin altında" ve hata oranları, geçmiş kriterlere göre 3 standart sapmadan fazla aşılırsa otomatik geri alma tetikleyicileri tanımlamalısınız.