Kafka ile Audit Log Yönetimi

Sonuç

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, gerçekleştirilen kayıtların ardından gelen cevaplar ve hatalara göre veri tabanımızdaki kayıtlar güncellenecektir.

Saklanacak Veriler

• IP : İstek atan ip adresi

  • 192.168.0.1

• User ID : Eğer kullanıcımız var ise kullanıcı id’sini tutmak

  • 1c911d7d-dd0c-4b11-a067-d49c963e3a5e

• Origin: isteğin geldiği origin

  • https://example-ui.com

• Path : Path’i tutacak alandır

  • /user/login

• Http Method : Http method’u tutacak alandır

  • GET | POST | PUT | PATCH | DELETE

• User Agent : İstek atan cihaz/tarayıcı bilgileri

  • Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36

• Request Header : İstekle ilgili başlık bilgilerini tutan bir alandır

  • { "host": "localhost:8080", "user-agent": "PostmanRuntime/7.26.10", "accept": "/", "cache-control": "no-cache", "postman-token": "1234abcd", "accept-encoding": "gzip, deflate, br", "connection": "keep-alive" }

• Request Body : İstekle ilgili başlık bilgilerini tutan bir alandır

  • { "name": "John", "age": 30, "email": "john@example.com" }

• Response Status Code : HTTP durum kodu

  • AUTH_EROR

• Response Code : Her isteğin döndürdüğü unique code

  • 123e4567-e89b-12d3-a456-426614174000

• Response Body : API'nin döndüğü yanıt eğer varsa

  • { "time": "2024-07-01T21:21:21.879518571", "isSuccess": true, "response": { "createdUser": "agitrubard", "createdAt": "2024-06-24T13:32:49", "updatedUser": "AYS", "updatedAt": "2024-07-01T21:20:41", "id": "4eb44207-b6a8-4d9c-82c2-292840e4f897", "reason": "Mo Alam için oluşturuldu.", "rejectReason": null, "status": "COMPLETED", "institution": { "id": "d95b59c7-9ac1-4be3-a981-33af1d3f8386", "name": "Disaster Foundation" }, "user": { "id": "828198fd-70b7-4037-9ece-b94274e72524", "firstName": "Buğra", "lastName": "Ercan", "city": "İstanbul", "emailAddress": "bugra.ercan@afetyonetimsistemi.org", "phoneNumber": { "countryCode": "90", "lineNumber": "5051237891" } } } }

• Error : Eğer bir hatamız varsa onu tutan alandır

• Created At : Verinin oluşturulma tarihi

  • 2024-10-06T12:30:45

• Updated At : Verinin güncellenme tarihi

  • 2024-10-06T12:30:45

Open

Powered by @Sinan ARTUN

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. (Javers Vs Envers Comparision — JaVers Blog )

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

• Sorgulama :
  Veritabanındaki kadar güçlü sorgulama yeteneklerine sahip değillerdir.

• 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 kullanımında event listenerlarda yararlanarak bir audit log sistemi kurulabilir. Özelleştirilebilir olması ( @PrePersist, @PreUpdate and @PreRemove ) ve bize her adımda detaylı bir şekilde kendi isteklerimize göre dizayn etme fırsatından dolayı bir iki adım öne geçirebilir.

• 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.

• İsteklerin dosya sisteminde loglanması durumunda isteğe verilen cevap ve bu cevabın update edilebilir olma sürecinde tek bir veri üzerinde bunu yapmak istediğimizde dosyada tutmak bizlere zorluklar çıkarabilir.

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

• Auditing with JPA, Hibernate, and Spring Data JPA | Baeldung

• How to Create an Audit Trail in Spring Boot Applications

• What is the best way to handle audits in Spring Boot?

• Spring Boot REST API: Implementing Custom Audit Logging