Apache Kafka, modern veri mühendisliğiyle neredeyse eş anlamlı hale geldi. Mimari diyagramlarda, iş ilanlarında, konferans konuşmalarında var. Olay güdümlü, akış mimarisinin gerekçesi soyut olarak ikna edici: gerçek zamanlı veri akışı, ayrışmış sistemler, olayları tekrarlama ve durumu yeniden inşa etme kapasitesi.
Daha az dikkat çeken soru: Herhangi bir finansal hizmet organizasyonu için, hangi sorunlar gerçekten akışı gerektiriyor ve hangi sorunlar akışın moda olduğu için akış mimarisine zorla uyduruluyorlar?
Kafka Gerçekte Neyi Çözüyor
Kafka belirli bir sorunlar kümesini iyi çözüyor:
Yüksek hacimli, düşük gecikmeli veri taşıma. Sisteminizin saniyede milyonlarca olayı milisaniyenin altında gecikmeyle taşıması gerekiyorsa, Kafka bunun için tasarlandı. Ölçekte işlem işleme, gerçek zamanlı dolandırıcılık tespiti, piyasa verilerini anında işlemesi gereken ticaret sistemleri — Kafka bunlar için inşa edildi.
Ayrışmış olay güdümlü mimari. Birden fazla aşağı akış tüketicisinin olaylara bağımsız olarak tepki vermesi gerektiğinde, Kafka'nın tüketici grup modeli temiz ayrışma sağlıyor. Kaynak sistem olayları yayımlıyor; tüketiciler, kaynağın kimin tükettiğini bilmesine gerek kalmadan kendi tempolerında işliyor.
Olay tekrarı ve yeniden işleme. Olayları tutma ve tekrarlama kapasitesi — ya hatadan sonra durumu yeniden inşa etmek ya da tarihsel veriye karşı yeni tüketiciler eklemek için — toplu sistemlerin temiz sunmadığı gerçek bir mimari avantaj.
Nerede Uymuyor
Çoğu Türk finansal hizmet organizasyonu için dürüst değerlendirme: yasal raporlama Kafka'ya ihtiyaç duymuyor. FATCA bildirimleri aylık gerçekleşiyor. CRS yıllık. HAYMER raporlaması tanımlı döngüleri izliyor. Bu bildirimler için veri kalitesi ve lineage gereksinimleri katı, ama gecikme gereksinimi günlerle ölçülüyor, milisaniyelerle değil.
Bu kullanım durumları için düzenleyici raporlama pipeline'ına Kafka eklemek, gerçek kısıtların hiçbirini ele almadan operasyonel karmaşıklık ekliyor — tüketici grup yönetimi, offset yönetimi, şema kaydı, tam olarak bir kez semantiği. Uyum ekibinin fon yöneticisinin poliçe güncellemesinin bildirim verisinde gerçek zamanlı görünmesine ihtiyacı yok. Bildirim son tarihinden önce, tam lineage ile doğru görünmesine ihtiyaçları var.
Finansal Hizmetlerde Nerede Uyuyor
Akış mimarisinin karmaşıklığını hak ettiği gerçek gerçek zamanlı gereksinimler var:
Dolandırıcılık ve anomali tespiti. İşaretlenmesi gereken bir ödeme, bir sonraki toplu çalışmada değil, kapanmadan önce işaretlenmeli. Gecikme gereksinimi gerçek ve bunu karşılamak için akış altyapısı gerekiyor.
Müşteriye yönelik gerçek zamanlı operasyonlar. Mobil bankacılık uygulamaları, ödeme durumu güncellemeleri, bakiye gösterimleri — müşteriler bunların dünün toplu işlemini değil, mevcut durumu yansıtmasını bekliyor.
Risk izleme. Sigorta ve emeklilikte, belirli risk metrikleri olaylar gerçekleşirken güncellenmeli — toplam risk pozisyonunu etkileyen büyük bir poliçe değişikliği, ay sonunda değil gün sonundan önce risk yönetimine görünür olmalı.
Sistemler arası olay koordinasyonu. Bir sistemdeki ödemenin başka bir sistemde anlık güncelleme tetiklemesi gerektiğinde, toplu entegrasyon operasyonel olarak kabul edilemeyebilecek bir gecikme penceresi oluşturuyor.
Örüntü: gerçek zamanlı, toplu gecikmenin belirli, ölçülebilir bir operasyonel sorun yarattığı zaman haklı. Akışın modern yaklaşım olduğu için değil.
Operasyonel Gerçeklik
Kafka operasyonel olarak önemsiz değil. Güvenilir çalıştırmak için uzmanlık gerektiriyor — broker yapılandırması, replikasyon faktörü, tüketici grup yönetimi, offset commit stratejileri, şema evrimi. Bunu inşa etmeden veya işe almadan benimseyen organizasyonlar, kırılgan, hata ayıklaması zor ve hata modları ekibe yabancı olan akış altyapısıyla sonuçlanıyor.
Gerçek gereksinimlere göre iyi yapılandırılmış PostgreSQL kuyruğunun ya da RabbitMQ gibi bir mesaj aracısının yeterince hizmet edeceği kullanım durumları için Kafka benimseyen ve gerçek gereksinimler tarafından haklılaştırılmayan Kafka karmaşıklığını yönetmek için aylar harcayan organizasyonlar gördüm.
Herhangi bir akış benimsemesinden önce doğru soru: gecikme gereksinimi nedir, verim gereksinimi nedir? Cevap "dakikalar veya saatler" ve "günde binlerce olay" ise, Kafka muhtemelen doğru araç değil. Cevap "milisaniye altı" ve "saatte milyonlarca olay" ise, akış mimarisi karmaşıklığını hak ediyor.
Altyapı Konuşması
Gerçek akış gereksinimleri olan organizasyonlar için, altyapı yatırımı önemli ve planlanmaya değer:
Üreticiler ve tüketiciler arasında olay şemalarını yönetmek için şema kaydı. İşlemede başarısız olan olaylar için ölü mektup kuyruğu. Tüketici gecikmesini, partition sağlığını ve uçtan uca gecikmeyi kapsayan izleme. Yaygın hata senaryoları için çalışma kitapları.
Bunların hiçbiri, denetlenebilirliğin önemli olduğu düzenlenmiş bir ortamda akış altyapısı çalıştırıyorsanız opsiyonel değil. Olay akışı diğerleri gibi bir veri varlığı — gözlemlenebilir olması gerekiyor, şeması belgelenmeli ve hatalar tespit edilebilir ve kurtarılabilir olmalı.
Kafka, doğru sorunlar için güçlü bir araç. Disiplin, hangi sorunların bunlar olduğunu bilmek. Düzenlenmiş finansal hizmetlerde, çoğu organizasyon için dürüst cevap, akış altyapısının bir alt küme kullanım durumuna — gerçek zamanlı olanlara — hizmet ettiği ve iyi inşa edilmiş, düzgün yönetilen toplu altyapının geri kalanına hizmet ettiği. Araçlar konuşması bu değerlendirmeden önce değil, sonra gelmeli.