Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Araştırmalar sonucunda verien karar, KAFKA ve kullanlacak bir NoSql DB ( Amazon DynamoDB ) kullanılarak oluşturularak bir audit log sistemi yapılacaktır.

Neden KAFKA?

KAFKA kullanma sebebimiz, her request esnasında oluşturulacak bir record ve bu recordun update işlemi göz önüne alındığında minimum oluşturulacak veri tabanı işlemleri en az 3 adet ( audit create, audit update, ve request için kendi sorumluluğu olan veritabanı query) olacaktır. Bu yüzden KAFKA servisi kullanarak aslında bir even-bus sistemi kurmayı planladık.

Neden NoSQL?

NoSQL Database performans olarak daha hızlı olduğu kanıtlamıştır. Normal veri tabanımızdan ayırmamızın sebebi ise yukarıda bahsettiğimiz 2+query problemidir.

...

Akışımız

Her istek atıldığında api tarafında Idenity request based (istek bazlı) oluşturulduğu için Identity içinde bir request id oluşturulduktan sonra bunların üzerinden veri tabanı kaydı gerçekleştirilip HttpServletRequeste requestTime setlenecek , gerçekleştirilen kayıtların ardından gelen cevaplar ve hatalara göre veri tabanımızdaki kayıtlar güncellenecektirhttp filter ile veri tabanımıza kayıt atılacaktır.

Not: HttpServletRequeste requestTime setlenen requestTime Burada get edilip db ye yazılacaktır.

Note

Request veya response’daki hassas bilgiler için maskeleme işlemi uygulanacaktır.

...

Info

Burdan ilgili veri modeli analizine gidebilirsiniz.

...

Araştırma

Audit loglar, sistemdeki önemli olayların ve işlemlerin izlenmesi ve kayıt altına alınması amacı ile sistem için hayati veriler sunarlar. Bu yazıda, audit log’ların nasıl yönetileceği konusunda farklı yaklaşımları ve her birinin avantajları ile dezavantajlarını derledim. En yaygın seçenekler; doğrudan veritabanına kaydetmek ve AWS S3'e kaydetmektir.

1- Doğrudan Veritabanında Audit Log Depolama

Doğrudan veritabanında saklamak, daha güvenilir ve merkezi bir kayıt tutma yöntemi olup; mevcut veritabanı altyapısıyla daha kolay entegre olabilir ve daha güçlü sorgulama seçenekleri sunar(her ne kadar sorgu atmayacak olsak bile).

Avantajlar

  • Sorgulama ve Raporlama :
    SQL ile karmaşık sorgular oluşturabilme yeteneği, bize ileriki zamanlarda log’ları raporlamak istersek büyük avantaj sağlayabilir.

  • Hazırda var olan Tech Stack ile olan uyumu :
    MySQL ve Spring Data JPA halihazırda kullanıldığından dolayı, audit log’ları mevcut veritabanımıza entegre etmemiz çok kolay olacak ve bu sayede entegre ederken karşılaşabileceğimiz karmaşanın önüne geçmiş olacağız. Daha hızlı, sorunsuz ve basit bir entegrasyon süreci sağlar bize.

  • Merkezi Olması :
    Log’ların verilerle birlikte aynı veritabanında tutulması, veri yönetimi ve bu verilerin yedeklenmesi açısından oldukça avantajlı olabilir. Bu da hızlı erişim ve yedekleme gereken durumlarda işimizi kolaylaştırabilir.

  • Farklı toollar ile gerçekleştirilebilir :
    Çok bilinen JAVERS ve ENVERS toolları ile gerçekleştirebiliyor olmamız hem kolaylık hem esneklik sağlar. Fakat ENVERS noSQL veritabanı ile çalışamıyor dolayısıyla projeye ileriki aşamada noSQL veritabanı entegre edilecekse ENVERS bizim için bir opsiyon olamaz. (https://javers.org/blog/2017/12/javers-vs-envers-comparision.html )

Dezavantajlar

  • Performans :
    Yoğun kullanımda performansı kötü etkileyebilir.

  • Bakım :
    Düzenli olarak eski logların temizlenmesi gerekebilir.

2- AWS S3

AWS S3, büyük ölçekli ve uzun süreli depolama ihtiyaçlarını karşılamak için kullanılan, yüksek dayanıklılık ve erişilebilirlik sunan bir depolama hizmetidir.

Avantajlar

  • Ölçeklenebilirlik :
    AWS S3 çok büyük miktarda veriyi yönetebilecek şekilde tasarlanmıştır ve eğer büyük bir veri saklayacaksak ideal olan çözümdür.

  • Dayanıklılık ve Erişilebilirlik :
    S3, bir hayli yüksek dayanıklılık ve erişilebilirlik sağlar. Bu da verilerimizin güvenli ve erişilebilir olmasını garanti eder. Veri kaybı riski oldukça azdır.

  • Entegrasyon ve Güvenlik :
    AWS servisleri sayesinde güvenlik bakımından güçlü, entegrasyon bakımından görece kolay bir yapı sunmaktadır.

  • Asenkron Veri İşleme :
    Log’lar S3’e asenkron olarak yüklenir. Dolayısıyla bu durum uygulama performansına olumlu bir etki bırakır.

Dezavantajlar

...

Gecikme :
Veri üzerinde yapılacak işlemler, doğrudan veritabanı erişiminden daha fazla gecikmeye sebep olabilir.

...

Kullanım Karmaşıklığı :
Kullanımı ve bakımı uzmanlık gerektirebilir.

...

Ücretlendirme Politikası :
En önemli dezavantajı ücretlendirme politikasıdır. Çünkü öngörülemeyen giderlere sebebiyet verebilir.

3- Yöntemler

  • Hibernate Envers :

Hibernate’in modelleri takip etme özelliğinin olmasından dolayı burada kullanılabilir. Ancak bizim projemizde hibernate bağımlılığı yoktur. Bu durum bazı komplikasyonlara sebebiyet verebilir.

  • Spring Boot JPA Audit :

...

  • Spring Data JPA Audit :

Bu yapıya benzer bir yapının AYS’de hali hazır olmasından kaynaklı bunun projemizle uyumlu olabileceği konusunda soru işaretlerine sahibim.

  • Aspect-Oriented Programming (AOP) :

Aspect oriented programming ile audit logging yapılacak işlemi seçebilir ve isteklerimize göre yönetebiliriz. Ancak bunun getirebileceği bazı negatif efektler de olabilir. Örneğin loglanması için bunun her yerde belirtilmesi ve kullanılması. Bunun yanı sıra bize hangi durumlarda audit log düşmek istediğimizi de belirleyebileceğimiz için bize farklı bir fleksibilite sağlamaktadır.

  • Intercepters :

Bunlardan ayrı olarak intercepters tanımlanarak, her adımların ve her endpointlerin audit loglanması sağlanabilir. Ancak bu sistem database tercihi yapıldığında veri tabanımızı şişirebilir ve gereksiz yerlerin audit logunu veri tabanımızda tutuyor olabiliriz.

  • Event Listener:

Yukarıdaki adımlar daha da özel bir yapı tercih edilmesi isteniyor ise event-listener mantığı tercih edilebilir.

4- Karışılaşılabilecek problemler

...

Her istek veri tabanına kayıt edilmesi halinde karşılaşılacak iş yükünün çok olması ve bu problemi takip eden API yavaşlıkları gibi durumlar mevcut.

...

.

...

Info

Örn: id:9473-1431-3256-5434, request:/auth/login, response: {status: 202, …}, …

Sonuç olarak, aşırı büyük bir veri ile uğraşmayacaksak, hem maddi açıdan hem de sunduğu avantajlar bakımından en doğrusu, doğrudan veritabanına kaydetmek ve bunu yaparken en uygun tool’un bize sağladıklarından dolayı custom ( interceptors/AOP ) bir servisinin/yapısının tercih edilmesi olduğunu düşünmekteyim.

Yardımcı Linkler

...

https://www.baeldung.com/database-auditing-jpa#2-implementing-the-callback-methods

...

https://medium.com/@AlexanderObregon/how-to-create-an-audit-trail-in-spring-boot-applications-3ecacd362825

...

https://stackoverflow.com/questions/68938237/what-is-the-best-way-to-handle-audits-in-spring-boot

...