Mikroservis Mimarisinde Raporlama İşlemleri
Bir uygulamayı daha küçük parçalara bölerken, potansiyel olarak verilerin nasıl ve nerede saklandığını yani veritabanlarını da ayırmamız gerekir. Ancak bu, yaygın bir kullanım durumu söz konusu olduğunda sorun yaratır: raporlama.
Raporlamanın yararlı çıktılar üretebilmesi için genellikle birden çok domain verilerini bir araya getirmesi gerekir. Örneğin, şunları yapmak isteyebiliriz. Order verilerini, satılanların kataloglarından aldığımız açıklamalarıyla zenginleştirmek isteyebiliriz. Veya satın alma geçmişlerinden ve müşteri profillerinden bilgi gerektirebilecek belirli, yüksek değerli müşterilerin alışveriş davranışlarına bakmak isteyebiliriz.
Standart, monolit bir mimaride tüm verilerimiz büyük tek bir veri tabanında depolanır. Bu, tüm verilerin tek bir yerde olduğu anlamına gelir; dolayısıyla tüm bilgileri raporlamak aslında oldukça kolaydır, çünkü verileri SQL sorguları yoluyla kolayca birleştirebiliriz. Sorgularımızın oluşturduğu yükün ana sistemin performansını etkilemesinden korktuğumuz için genellikle bu raporları ana veritabanında çalıştırmayız; dolayısıyla bu raporlama sistemleri sıklıkla bir okuma kopyasına yönelir.
Dağıtık mimarilerde raporlama sistemi kurmanın farklı yaklaşımları ve bu yaklaşımların her birinin artı ve eksileri mevcuttur. Sırasıyla bu yaklaşımlara bir bakalım
1. Servis Çağrıları Yoluyla Veri Alma
Bu modelin pek çok çeşidi vardır, ancak hepsi gerekli verilerin kaynak sistemlerden API çağrıları yoluyla çekilmesine dayanır. Son 15 dakika içinde verilen siparişlerin sayısını göstermek isteyebilecek bir kontrol paneli gibi çok basit bir raporlama sistemi için bu iyi olabilir. İki veya daha fazla sistemden gelen veriler arasında raporlama yapmak için bu verileri bir araya getirmek üzere birden fazla call yapmanız gerekir.
Ancak bu yaklaşım, daha büyük miktarda veri gerektiren kullanım durumlarıyla hızla bozulur. Müşteri davranışındaki çeşitli trendlere ve bunun geliri nasıl etkilediğine bakarak, son 24 aydaki müzik mağazamız için müşteri satın alma davranışı hakkında rapor vermek istediğimiz bir kullanım senaryosu hayal edin. En azından müşteri ve finans sistemlerinden büyük miktarda veri çekmemiz gerekiyor. Bu verilerin yerel bir kopyasını raporlama sisteminde tutmak tehlikelidir, çünkü değişip değişmediğini bilemeyebiliriz (geçmişsel veriler bile eventten sonra değiştirilebilir), dolayısıyla doğru bir rapor oluşturmak için tüm finansmana ve son iki yılın müşteri kayıtlarına ihtiyaç vardır. Mütevazı sayıda müşteriyle bile bunun hızla çok yavaş bir operasyona dönüşeceğini görebilirsiniz.
Servisin sunduğu kaynaklara önbellek başlıkları ekleyerek bazı veri alımını hızlandırabiliriz, ancak raporlamanın doğası gereği genellikle verilerin uzun kuyruğuna erişiriz. Bu, daha önce hiç kimsenin talep etmediği (veya en azından yeterince uzun bir süre boyunca talep etmediği) kaynakları talep edebileceğimiz anlamına gelir, bu da potansiyel olarak pahalı bir önbellek kaybına yol açabilir.
2. Data Pumps
Raporlama sisteminin verileri çekmesi yerine, verilerin raporlama sistemine aktarılmasını da sağlayabiliriz. Verileri standart HTTP callarıyla almanın dezavantajlarından biri, çok sayıda call yaptığımızda HTTP’nin ek yükü ve yalnızca raporlama amacıyla mevcut olabilecek API’ler oluşturma zorunluluğunun getirdiği ek yüktür. Alternatif bir seçenek, veri kaynağı olan servisin veritabanına doğrudan erişen ve onu bir raporlama veritabanına pompalayan bağımsız bir programa sahip olmaktır. Ancak mikroservis mimaride bir servisin birden fazla database’e dokunmaması gerekir’i daha önce söylemiştik. Raporlama yapısı doğru şekilde implemente edildiğinde bunun istisnasıdır.
Başlangıç olarak raporlama için veri pompasının, servisi yöneten ekip tarafından oluşturulup yönetilmesi gerekir. Bu, Cron aracılığıyla tetiklenen bir komut satırı programı kadar basit bir şey olabilir. Bu programın hem servisin kendi veri tabanı hem de raporlama şeması hakkında detaylı bilgiye sahip olması gerekir. Pompanın görevi birini diğerinden haritalamaktır. Servisi yöneten ekibin aynı zamanda pompayı da yönetmesini sağlayarak, servis şemasına bağlanmayla ilgili sorunları azaltmaya çalışıyoruz
Veri pompalarının genel olarak mantıklı ve uygulanabilir bir öneri olduğunu düşünsem de, özellikle veri tabanındaki değişimi yönetmedeki zorluklar göz önüne alınmalı.
3. Event Data Pumps
Mikroservisler yönettikleri entitylerin durum değişikliklerine dayalı olarak eventler fırlatabilir. Örneğin, müşteri servislerimiz belirli bir müşteri oluşturulduğunda, güncellendiğinde veya silindiğinde bir event fırlatabilir. Bu tür event fırlatan mikroservisler için, verileri raporlama veritabanına pompalayan kendi event consumerını yazma seçeneğimiz de vardır.
Bu yaklaşımla kaynak mikroservisin database’ine olan couplingin önüne geçilmiştir. Bunun yerine servis tarafından yayılacak eventlere bağlanılmıştır. Ayrıca, hangi eventlerin hali hazırda işlenmiş olduğunu saklarsak, eski eventlerin zaten raporlama sistemine eşlendiğini varsayarak yeni eventler geldikleri anda işleyebiliriz. Bu, yalnızca delta göndermemiz gerektiğinden yerleştirmemizin daha verimli olacağı anlamına gelir. Benzer şeyleri bir veri pompasıyla yapabiliriz, ancak bunu kendimiz yönetmeliyiz, oysa event akışının temelde zamansal doğası bize büyük ölçüde yardımcı olur.
Event veri pompamız servisin iç kısımlarına daha az bağlı olduğundan, bunun mikro servisle ilgilenen ekipten ayrı bir grup tarafından yönetildiğini düşünmek de daha kolaydır. Event akışımızın doğası, subscribe’ları servisteki değişikliklere aşırı derecede bağlamadığı sürece, bu event eşleyici, subscribe olduğu servisten bağımsız olarak gelişebilir.
Bu yaklaşımın ana dezavantajları, gerekli tüm bilgilerin event olarak yayınlanmasının gerekmesi ve doğrudan veritabanı düzeyinde çalışma avantajına sahip daha büyük veri hacimleri için bir veri pompası kadar iyi ölçeklenemeyebilmesidir. Bununla birlikte, böyle bir yaklaşımla elde edilen daha gevşek bağlantı ve daha yeni veriler, uygun eventleri hali hazırda açığa çıkarıyorsanız, bunu dikkate almaya değer kılar.
