Cüzdan Logları için Hata Toleranslı Bir Göç Süreci Oluşturma

Veri migrasyonu bir noktada, kayıtları bir yerden bir yere taşımaktan ibaret olmaktan çıkıyor. Kağıt üzerinde basitlik temiz görünse de, büyük veri setleriyle başa çıkarken hızla kontrol dışı hale gelebilir. Güvenli bir şekilde alma, güvenilir bir şekilde işleme, hatalardan kurtulma ve verileri bozmadan devam etme konularında zorluk yaşamaya başlayabilirsiniz.

Bunu, büyük bir cüzdan log migrasyonu üzerinde çalışırken deneyimledim; defter işlemlerini özel bir çekirdek bankacılık servisine taşıyordum. Hedef sistem, bu logları işlem kayıtları olarak, doğru hesap eşlemeleri, müşteri ilişkileri, bakiyeler, zaman damgaları, metadata ve deterministik referanslarla temsil etmeliydi. Göç, yeniden denemeye uygun olmalı, hatalardan temiz bir şekilde kurtulmalı ve gerçek operasyonel kısıtlamalar altında pratik kalmalıydı. Mevcut implementasyon, her şeyi tek bir kesintisiz akışta ele alıyordu: imleçli sayfalı kayıtları getir, onları satır içi haritalandır ve doğrudan hedef veritabanına yaz. Bu küçük ölçeklerde çalışabilir, ancak 3 milyon kayıt taşıyan dağıtık bir boru hattında işe yaramazdı. Gerçek yükü kaldırabilen, temiz bir şekilde kurtulabilen ve çok daha fazla kontrol ile çalışabilen bir migrasyon boru hattı tasarlamak zorundaydım.

Bu makale için kaynak servise core-service, hedef servise ise core-banking-service olarak atıfta bulunacağız.

Orijinal Yaklaşım ve Başarısız Olma Nedenleri

Orijinal implementasyon, core-banking-service içinde tüm yaşam döngüsünü yöneten tek bir işti. core-service‘den sayfa sayfa imleçli API sayfalarını alıyor, her sayfa için kayıtları dönüştürüyor ve doğrudan ilgili tabloya upser ediyor. Sayfa başına 100 kayıt alıyor ve 500 sayfa fetch için bir limit belirliyordu. Migrasyon, devam işini ele almadığı için güvenlik sınırlamasında duruyordu ve kurtarma, büyük ölçüde Laravel’in yeniden deneme mekanizmasına, kalıcı kontrol noktalarına değil, dayanıyordu.

Yeniden denemeler ve sayfa limitlerine rağmen, bir kontrol döngüsünde ağ IO’su, CPU yoğun haritalama ve DB yazımları birbirine bağlıydı. Bu bağlılık bir operasyonel darboğaz oluşturuyordu. Hacim arttıkça, tek bir hata alanı, geçiş hızını ve kurtarmayı kontrol ediyordu.

3 milyon kayıt için, 500 sayfa yalnızca yaklaşık 50.000 kaydı kapsar. Şans eseri, zaman aşımı ilk olarak işi öldürmediyse bile, tasarımın kalan veriler için gerçek bir devam modeli yoktu. Tasarım küçük işler için çalışabilirdi ancak milyonlarca satırlık ithalatlar için çok sertti.

Gerçek Riskler: Bellek Tükenmesi, Zayıf Kurtarma, Eşzamanlılık

En büyük risk, tasarımın yük altında aşamalı olarak başarısız olmasıydı.

Tek bir iş, binlerce HTTP isteği, tekrar eden dönüşümler, veritabanı sorgulamaları ve upsert işlemlerinden sorumluydu. Bu, zaman aşımı, bellek baskısı ve iş başarısız olursa zayıf kurtarma riski artırıyordu. Güçlü kontrol noktaları olmadan, neyin alınmış, neyin başarılı bir şekilde yazılmış ve neyin tekrar oynatılması gerektiğini söylemek zor oluyordu.

İşlem paralel hale geldiğinde bir eşzamanlılık riski de vardı. Aynı işlem tablosuna upsert eden birden fazla işçi, dizinlerde çatışma yaşayabilir veya deadlock’lara denk gelebilirdi. Bu nedenle, boru hattının parça boyutlarını küçük tutması, deterministik yazım sırasını koruması ve deadlock tekrar denemelerini dayanıklı hale getirmesi gerekiyordu.

İki Aşamalı Yeniden Tasarım

Yeniden tasarım, migrasyon boru hattını iki ayrı aşamaya ayırdı: önce almaya, sonra işlemeye yöneldi.

Bu ayrım önemlidir çünkü işin iki kısmı farklı kısıtlamalara sahiptir. core-service‘den alma işlemi, API’nın imleçli sayfa düzenini takip etmek zorundaydı, bu nedenle doğal olarak sıralıydı. Ancak kayıtlar veritabanımızda olduğunda, işleme artık kaynak API’ye bağlı değildi. Bu noktada, iş parçaları halinde bölünebilir ve birden fazla kuyruk işçisi tarafından ele alınabilirdi.

Bu nedenle, her şeyi doğrudan veritabanına almak, dönüştürmek ve yazmak yerine, yeni akış şöyle oldu:

• core-service‘den cüzdan loglarını al ve ham yükleri aşama olarak sakla.
• Aşamalı kayıtları oku, dönüştür ve veritabanına paralel olarak upsert et.

Bu, işleme başarısız olursa, aynı veriler için core-service‘e geri dönmem gerekmemesi anlamına gelir. Eğer bir işçi ölürse, aşamalı kayıtlar hala oradadır. Migrasyon daha sonra devam ettirilirse, imleç ve segment durumu, boru hattına nereden kurtulmak üzere bir yer verir.

Yeniden tasarımın temel bir parçası, bir segment fikriydi. Segment, ithalatın sınırlı bir alt kümesidir: sabit sayıda sayfayı fetch et, o kayıtları aşama olarak sakla, bunları paralel çalışan işler ile işle, temizle ve daha fazla veri varsa sıradaki imleçten devam et. Bu, boru hattına tekrarlanabilir bir döngü kazandırıyordu: bir segmenti al, bir segmenti işle, sıradaki segmente geç.

Aşama 1: Ham Kayıtları Al ve Aşama Olarak Sakla

İlk aşama, verileri güvenli bir şekilde core-service‘den almakla sorumludur. Göç başladığında, bir artisan komutu yeni bir oturum ID’si oluşturur ve bir FetchJob gönderir. Bu iş, cüzdan logu dışa aktarma ucu ile sayfa sayfa çağrı yapar, API tarafından döndürülen imleç kullanılarak. Her sayfa sınırlı sayıda kayıt içerir ve bu kayıtlar ham JSON olarak bir aşama tablosuna yazılır. Her segment, tek bir fetch döngüsünün ne kadar veri aşama olarak saklanmasının sınırlıdır.

Her aşamalı satır, bir oturum ve segment ile bağlantılıdır, böylece ithalatı kesintisiz bir çalışmadan ziyade sınırlı partiler halinde işlemenizi sağlar. Fetch aşaması ayrıca bir kontrol noktası tablosuna ilerlemeyi kaydeder; bu da aktif segment, imleç, sayfa ve durumu içerir. Bu, bir zaman aşımından, hatadan veya yeniden denemeden sonra devam edilmesini sağladı.

Aşama 2: Paralel Olarak Dönüştür ve Upsert Et

Bir segment aşamalı hale getirildiğinde, ikinci aşama başlar. Bir BatchJob, o oturum ve segment için aşamalı satırları yükler, bunları küçük ID tabanlı parçalara böler ve Laravel’in batch sistemini kullanarak parça işlerini yönlendirir. Her parça işi yalnızca atanmış aşamalı kayıtları okur, gereken hesap ve müşteri arama haritalarını oluşturur, cüzdan logu yüklerini işlem satırı haline dönüştürür ve onları işlem tablosuna upsert eder.

Upsert, yeniden denemeye uygun olacak şekilde tasarlanmıştır. Her işlem, kararlı kaynak alanlarına dayalı deterministik bir referans alır, böylece bir parça yeniden denendiğinde, aynı işlemi günceller, duplikat oluşturmaz. Birden fazla işçi aynı tabloya aynı anda yazabileceğinden, upsert yolu ayrıca deadlock tekrar deneme işleme içerir.

Bir segmentteki tüm parça işlerinin başarılı bir şekilde tamamlanmasıyla, o segment için aşamalı satırlar silinebilir. Eğer kaynak API başka bir imleç dönerse, bir sonraki fetch segmenti (aşama 1) başlar. Aksi takdirde, ithalat oturumu tamamlandığı olarak işaretlenir.

Neden Aşamalı Tablolar Önemliydi

Aşamalı tablo, core-service ile core-banking-service arasında bir tampondu.

Orijinal yaklaşımda, her API yanıtı fetch edildi, dönüştürüldü ve tek bir geçişte yazıldı. Bu durum, fetch ve işleme işlemlerinin sıkı bir şekilde bağlanmasına neden oluyordu. Eğer iş yarıda başarısız olursa, alınan ile başarıyla yazılan arasındaki ayırımı yapmak zordu.

API yanıtını geçici bir bellek verisi olarak görmek yerine, ithalat önce her ham cüzdan logu yükünü bir aşamalı tabloya kalıcı hale getirdi. Bu, kaynak sistem ile son tablo arasında dayanıklı bir kontrol noktası sağladı. Eğer işleme başarısız olursa, o segment için kayıtlar hala yerel olarak mevcut olur ve sıfırdan başlamadan tekrar denenebilir.

Aşamalı tablolar, çoğaltmayı önlemeye de yardımcı oldu. Her ham kayıt, bir parmak izi aldı ve tablo, bir oturum ve segment içinde benzersizliği zorunlu kıldı. Yeniden denemeler, aynı oturum ve segment için daha önce aşamalı hale getirilmiş kayıtları dikkate almayabilirdi.

Aşamalı tablo, boru hattına daha güvenli bir ritim verdi: sınırlı bir segment al, sakla, işle ve temizle. Tablo, ithalatı kalıcı olarak arşivlemek için değil, sadece geçici bir tampondu, bu da migrasyonu kurtarılabilir hale getirdi.

Parti İşlemenin Oyunu Nasıl Değiştirdiği

Staj alan tabloları, ithalatı kurtarılabilir hale getirirken, parti işlemesi ölçeklenebilir hale getirdi.

core-service ucu, imleçli sayfalama kullandığından, alma işleminin sıralı kalması gerekiyordu. core-banking-service güvenli bir şekilde aynı anda birden fazla sayfa isteyemezdi çünkü API, tam bir dışa aktarım için bağımsız alanlar sunmuyordu.

Ancak, kayıtlar yerel olarak aşamalı hale getirildikten sonra, o sınırlama artık yoktu. Her segment, bağımsız olarak işlenebilecek sabit bir dizi satır içeriyordu.

Burada Laravel batch işleri her şeyi değiştirdi.

Büyük bir veri kümesini dönüştürmek ve upsert etmek yerine, BatchJob birçok daha küçük parça iş oluşturmuştu. Her biri küçük bir aşamalı satır ID setini ele alıyordu, bu da kuyruk işçilerinin daha kolay işleyebileceği, yeniden deneyebileceği ve izleyebileceği bir yük demekti.

Ayrıca, iş geçişini de arttırdı. Daha fazla kuyruk işçisi, kaynak API’yi daha hızlı yapmadı ama dönüşüm ve veritabanı yazımlarını hızlandırdı. Migrasyon artık tüm işi yapan tek bir PHP süreci ile sınırlı değildi.

Bir takas vardı: paralel yazmalar, eşzamanlılık riskleri getirdi. Aynı tabloya upsert eden birden fazla işçi, dizinlerde çatışabilir veya deadlock’lara yakalanabilirdi. Bunu ele almak için, parça boyutları küçük tutuldu, yazmadan önce satırlar sıralandı ve upsert işlemi etrafında deadlock yeniden denemeleri eklendi.

Sonuç, daha iyi bir denge oldu: alma sınırlı ve sıralı, işleme ise paralel ve sınırlı hale geldi. Kırılgan uzun süreli bir iş, ölçeklendirilebilen, yeniden denenebilen ve izlenebilen bir kuyruk destekli iş yüküne dönüştü.

Ne Oldu

Yeniden tasarlanan boru hattı, migrasyonu ortamlarda çalıştırmayı pratik hale getirdi.

Geliştirme aşamasında, hedef doğruluktu. Cüzdan logu yüklerinin yeni işlem şemasına doğru haritalandığını, hesap ve müşteri arama işlemlerinin doğru bir şekilde çözüldüğünü ve yeniden çalıştırmaların duplikat oluşturmadığını doğrulamam gerekiyordu.

Staging aşamasında, yük altında davranışa odaklanıldı. Fetch işleri zaman aşımı limitleri içinde kalmalı, işleme işleri yönetilebilir parçalar halinde çalışmalı ve hataların ilerlemeyi kaybetmeden yeniden denenebilir olması gerekiyordu.

Üretim benzeri ortamda migrasyon çalıştırıldığında, boru hattı artık sınırlı fetch segmentleri ve paralel işlem batch’leri dizisi olarak şekillenir. Her segment fetch edilir, aşamalı hale getirilir, işlenir, temizlenir ve sıradaki imleçten devam edilebilir.

Sonuç, milyonlarca cüzdan log kaydını çok daha iyi kontrol ile taşıyabilen bir migrasyon boru hattıydı.

• Toplam taşınan kayıt: ~4 milyon kayıt tüm hedef ortamlarda
• Ortam ithalat çalışmaları: Geliştirme (~33k), staging (~1 milyon), üretim benzeri (~3 milyon)
• Başarısız/yeniden denenen işler: Bazı parça işleri yürütme sırasında yeniden denendi, ancak boru hattı sıfırdan başlatmadan tamamlandı
• Sonuç: Tüm hedef ortamlarda başarıyla tamamlandı

Takaslar ve İyileştirmeler

İki aşamalı tasarım iyi çalıştı. Alma ve işleme aşamalarının ayrılması, boru hattını daha kolay anlamak ve kurtarmak açısından kolaylaştırdı, ayrıca kuyruk partileri ağır yazım aşamasını işçilerin arasında paylaştırdı.

İdempotans modeli, duplikat kayıtları önlemede etkili oldu. Deterministik işlem referansları ve ham kayıt parmak izi, mali kayıtları taşırken yeniden denemeleri daha güvenli hale getirdi ki bu kritik bir konuydu.

Temel zayıflıklardan biri şeffaflıktı. İlerleme tablosu bir kontrol noktası olarak çalıştı ama tam bir denetim izi sağlamadı. Daha iyi bir versiyon, her segment için ithalat tarihçesi ekleyecektir: aşamalı, işlenmiş, atlanmış, yeniden denenen ve temizlenen.

Ayrıca, performans metriklerini daha erken eklemeyi de düşünürdüm. Sayfa başına fetch süresi, parça başına işleme süresi, deadlock sıklığı ve dakikada işlenen kayıtlarla ilgili metrikler, ortak çalışma ortamları arasında ince ayar yapmayı kolaylaştırırdı.

Son olarak, imleçli sayfalama, doğru fetch etmeyi sağlarken sınırlı paralellik sağladı. Eğer bu migrasyon kalıbı tekrarlayıcı hale gelirse, daha güvenli paralel alma işlemleri desteklemek için kaynak API’sini genişletmeyi düşünürdüm.

Sonuç

Bu migrasyonun en büyük dersi, ölçeğin problemin doğasını değiştirdiğiydi. Hacim bir kez arttığında, zorluk sadece verileri taşımak değil, kontrol olmaya başlar: duraklatma, yeniden deneme, devam etme ve ilerlemeyi doğrulama konularında mali verileri bozmadan nasıl hareket edileceği. Basit bir fetch ve sakla işi, veri kümesi büyüdüğünde, kaynak başka bir hizmet olduğunda ve yeniden denemelerin güvenli olması gerektiğinde hızla kırılgan hale gelebilir.

İki aşamalı boru hattı, bu gerçekleri dikkate alarak işledi. Alma işlemi kontrol altında kaldı, işleme paralel hale geldi ve hata yaşandığında sıfırdan başlamayı gerektirmedi.

Önemli değişim sadece teknik değil, aynı zamanda bir zihniyet değişimiydi. Tek bir büyük işin hayatta kalmasını sağlamaya çalışmaktan vazgeçtim ve bir başarısızlığı bekleyen, ondan kurtulabilen ve ilerlemeye devam eden bir boru hattı tasarlamaya başladım. Bu noktada, çalışma artık sadece cüzdan log kayıtlarını taşımak değil; aynı zamanda gerçek yükü kaldırabilen ve hâlâ güvenilir olabilen bir migrasyon boru hattı inşa etmekti.