Kafka’dan OpenSearch’e Veri Aktarımı: Kurumsal Ölçekte Paralel Data Pipeline Mimarisi

Linkedin : Abdurrahman Binici | LinkedIn

Giriş

Modern kurumlarda üretilen log hacmi her geçen gün katlanarak artmaktadır. Uygulamalar, microservice platformları, network cihazları, güvenlik sistemleri ve container tabanlı ortamlar her gün terabaytlarca log data üretmektedir.

Bu verilerin yalnızca depolanması yeterli değildir. Aynı zamanda merkezi bir Observability Platform üzerinde indekslenmesi, analiz edilmesi ve gerçek zamanlı olarak sorgulanabilmesi gerekmektedir.

Çalıştığım kurumda mevcut log management altyapısı Apache Kafka, Logstash ve Elasticsearch teknolojileri üzerine kuruluydu. Ancak zamanla Reporting, Analytics ve Capacity Planning ihtiyaçlarının artmasıyla birlikte OpenSearch platformunu değerlendirmeye başladık.

Bu noktada temel mimari sorumuz şuydu:

“Mevcut Data Pipeline yapısını bozmadan aynı log data’yı ikinci bir Search Platform’a nasıl aktarabiliriz?”

Bu makalede Kafka, Logstash, Kubernetes/OpenShift ve OpenSearch kullanılarak gerçekleştirilen paralel Data Ingestion mimarisini anlatacağım.

Mevcut Mimari

Sistemde uygulamalardan gelen log data ilk olarak Kafka Cluster içerisine gönderiliyordu.

Kafka burada merkezi bir Message Broker görevi üstleniyor ve farklı Producer sistemlerden gelen verileri güvenilir şekilde saklıyordu.

Daha sonra Logstash Consumer’ları ilgili Topic’leri dinleyerek verileri parse ediyor, normalize ediyor ve Elasticsearch Production Cluster’a gönderiyordu.

Bu architecture uzun süre sorunsuz şekilde çalıştı. Ancak zamanla aşağıdaki ihtiyaçlar ortaya çıktı:

• Production sistemlerinden bağımsız bir Reporting Platform oluşturmak
• OpenSearch teknolojisini değerlendirmek
• Analytics workload’larını ayrı bir Cluster üzerinde çalıştırmak
• Gelecekteki migration senaryolarına hazırlık yapmak
• Elasticsearch Cluster üzerindeki sorgu yükünü azaltmak

Bu nedenle mevcut Data Pipeline yapısına ikinci bir target platform eklenmesine karar verildi.

Neden OpenSearch?

OpenSearch son yıllarda özellikle Observability, Log Analytics ve Security Monitoring alanlarında yaygın şekilde kullanılmaya başlanmıştır.

OpenSearch’ün tercih edilmesindeki temel nedenler:

• Açık kaynak yapıya sahip olması
• Elasticsearch mimarisine benzer bir Search Engine sunması
• Güçlü Dashboard ve Visualization yetenekleri
• Büyük ölçekli Cluster mimarilerini desteklemesi
• Horizontal Scalability sağlaması

Ancak burada en kritik gereksinim mevcut Elasticsearch Production Cluster’ını etkilemeden ilerleyebilmekti.

Kafka’nın Sağladığı Avantaj

Bu projedeki en kritik bileşen Apache Kafka oldu.

Kafka sayesinde Producer ve Consumer sistemler birbirinden tamamen bağımsız çalışabilmektedir.

Uygulamalar log üretmeye devam ederken aynı Topic içerisindeki veri birden fazla Consumer Group tarafından tüketilebilmektedir.

Bu sayede:

• Elasticsearch Cluster
• OpenSearch Cluster
• Gelecekte sisteme eklenecek diğer platformlar

aynı veri kaynağını kullanabilmektedir.

Kafka bu mimaride merkezi bir Event Streaming Platform görevi üstlenmektedir.

Logstash Tarafındaki Teknik Zorluklar

İlk aşamada mevcut pipeline’a yalnızca bir OpenSearch Output Plugin eklenmesi yeterli görünüyordu.

Ancak test sürecinde çeşitli sürüm uyumsuzlukları ile karşılaşıldı.

Karşılaşılan hata mesajlarından bazıları:

• Unknown setting ‘ilm_enabled’
• Unknown setting ‘api_version’
• Plugin initialization failed

Yapılan analiz sonucunda kullanılan Logstash sürümü ile OpenSearch Output Plugin sürümü arasında uyumsuzluk olduğu tespit edildi.

Bu nedenle standart container image yerine özel bir Docker Image oluşturulmasına karar verildi.

Özel Docker Image Oluşturulması

OpenSearch Output Plugin içeren yeni bir Logstash image hazırlandı.

Bu image kurum içi Container Registry ortamına yüklenerek Kubernetes deployment’larında kullanılmaya başlandı.

Bu yaklaşım aşağıdaki avantajları sağladı:

• Standardizasyon
• Tekrarlanabilir kurulum
• Kolay rollback imkanı
• Merkezi sürüm yönetimi
• Daha kolay operasyonel bakım

Özellikle Kubernetes tabanlı ortamlarda özel image kullanımı deployment süreçlerini önemli ölçüde kolaylaştırmaktadır.

Kubernetes/OpenShift Deployment

Sistem Kubernetes platformu üzerinde çalıştırıldı.

Hazırlanan özel Logstash image’ı Container Registry ortamına yüklendikten sonra yeni Deployment oluşturuldu.

Logstash Pod’ları Kafka Topic’lerini dinleyerek verileri OpenSearch Cluster’a göndermeye başladı.

Deployment sırasında aşağıdaki konulara özellikle dikkat edildi:

• TLS/SSL sertifika yönetimi
• Secret Volume entegrasyonu
• Network erişimleri
• Resource Limit ve Request değerleri
• Consumer Group yapılandırması
• Health Check ve Liveness Probe ayarları
• Pod restart senaryoları

Özellikle TLS sertifikalarının Kubernetes Secret olarak yönetilmesi sayesinde OpenSearch Cluster ile güvenli HTTPS bağlantısı sağlandı.

Consumer Group yapılandırması sayesinde Kafka üzerindeki offset yönetimi kontrol altında tutuldu ve veri kaybı yaşanmadı.

Karşılaşılan Operasyonel Sorun

İlk testlerde bazı Logstash Pod’larının sürekli restart ettiği gözlemlendi.

Yapılan incelemelerde Kubernetes Event kayıtları ve Pod logları analiz edildi.

Analiz sonucunda Resource Limit değerlerinin yetersiz olduğu ve Logstash JVM belleğinin yoğun veri akışı altında sınır değerlere ulaştığı tespit edildi.

Bu nedenle:

• CPU Limit değerleri artırıldı
• Memory Limit değerleri güncellendi
• JVM Heap ayarları optimize edildi
• Pipeline Worker sayıları yeniden düzenlendi

Yapılan optimizasyonların ardından Pod’lar kararlı şekilde çalışmaya başladı ve Kafka üzerinden gelen veri başarıyla OpenSearch Cluster’a aktarılmaya devam etti.

Bu süreç bir kez daha gösterdi ki başarılı bir deployment yalnızca uygulamanın çalışması değil, aynı zamanda kaynak kullanımının doğru planlanması ile mümkündür.

Veri Doğrulama Süreci

Kurulum tamamlandıktan sonra Data Validation süreci başlatıldı.

Bu kapsamda aşağıdaki kontroller gerçekleştirildi:

• Kafka Consumer Lag analizi
• Logstash Pipeline loglarının incelenmesi
• OpenSearch Index kontrolleri
• Document Count karşılaştırmaları
• Search performans testleri

Gerçekleştirilen testler sonucunda veri kaybı yaşanmadığı doğrulandı.

Elde Edilen Sonuçlar

Proje sonunda aşağıdaki hedefler başarıyla gerçekleştirildi:

✓ Kafka Data Pipeline kesintisiz şekilde çalışmaya devam etti.

✓ Elasticsearch Production Cluster etkilenmedi.

✓ OpenSearch Cluster üzerinde yeni index yapıları oluşturuldu.

✓ Veri kaybı yaşanmadı.

✓ Reporting ve Analytics workload’ları ayrı bir platforma taşındı.

✓ Gelecekteki OpenSearch projeleri için temel oluşturuldu.

Çıkarımlar

Bu proje bir kez daha gösterdi ki başarılı bir platform mimarisi yalnızca kullanılan teknolojilerden ibaret değildir.

Doğru Architecture kararları almak, sistemleri birbirinden izole etmek ve ölçeklenebilir çözümler tasarlamak en az teknolojilerin kendisi kadar önemlidir.

Kafka’nın sunduğu Event Streaming mimarisi sayesinde mevcut Production sistemlerini riske atmadan yeni platformları devreye almak mümkün hale gelmiştir.

Sonuç

Kafka, Logstash ve OpenSearch kombinasyonu büyük ölçekli Log Management ve Observability platformları için oldukça güçlü bir çözüm sunmaktadır.

Doğru planlanmış bir Data Pipeline mimarisi ile mevcut sistemleri koruyarak yeni platformları devreye almak mümkündür.

Kurumsal ortamlarda gerçekleştirilen bu tür çalışmalar yalnızca teknik bir dönüşüm değil, aynı zamanda gelecekteki platform ihtiyaçlarına yapılan stratejik bir yatırım niteliği taşımaktadır.