Apache Kafka Nedir ?

Bir çok kaynaktan aynı anda veri gönderilen ve onları birçok hedefin işleyebildiği, bir veri akış mekanizmasıdır. Başlangıçta 2011’de Linkedin tarafından Java ile geliştirilen Kafka daha sonra Apache çatısı altında açık kaynak bir projeye dönüştürülmüştür. Günümüzde Linkedin, Netflix, Uber, Twitter gibi devasa boyutlarda veriye sahip olan birçok firma tarafından kullanılmaktadır.

Pub-sub tabanlı dağıtık bir sistemdir. Verileri sıralı ve kademeli olarak işler. Temel olarak bir üretici(producer) veriyi kafkaya iletir. Kafka bu veriyi depolar. Başka bir tüketici servis(consumer) bu veriyi işler. Dil bağımsızdır. Producer servisi go ile yazılmış, Consumer servisi java ile yazılmış olabilir. Amaç bağımlılıkları kaldırmaktır.(loosely coupling)

Özellikleri

Hızlı

Yüksek trafikte düşük gecikme sağlar.

Güvenilir

Mesajları diskte saklar ve replika ederek veri kaybını önler.

Ölçeklenebilir(Scalable)

Node ve partitions kullanarak yatay ölçeklenebilir.

Yüksek veri hacmi

Büyük hacimli verileri işleyebilir. Big data uygulamaları için elverişlidir.

Dayanıklılık

Veriye sonradan erişebilme(Kaç gün diskte saklamak istediğini veya ne kadar boyuta kadar saklansın belirtebiliriz)

Ne zaman gerek duyulur ?

Kullanıcı tüm işlemlerin sonucunu beklemek zorunda olmadığı durumda,
Mikroservisler arasındaki iletişimde her bir servis için entegrasyon yapılması durumunda,
Mikroservisler arasında hangi formatta veri dolaşacağının(Binary, JSON vs) belli olmadığı durumda,
İletişimin hangi bağlantılarla olacağı(TCP,HTTP,REST,GRPC vs) belli değilse,
Producer hızı ile consumer hızının farklı olması gibi durumlarda kafka kullanılabilir.

Örnek olarak bir servis işine başlar ve bitirir daha sonra kafkaya bitirdiğinin mesajını atar sonrasında onu dinleyen diğer servis işini yapar ve süreç tamamlanır. Servislerin asekron olarak işlerinin yapılması sağlanır. Bu şekilde servislerin birbirine bağımlılığını düşürebiliriz.

Kafka nerelerde kullanılır ?

Mikroservisler arası iletişim

Mikroservislerin sayısı arttıkça aralarındaki bağımlılıkta çok fazla artmaktadır.

Örnek olarak bir satın alma işlemi yapılırken sipariş alınması, ödeme alınması, stoktan düşülmesi, fatura işlemleri, bilgilendirme şeklinde bir akış olabilir. Her bir işlem bittiğinde kafkaya bildirir onu dinleyen servis devam eder.

Log Analizi

Logları inceleyerek uygulamanın nerelerinde ne tür problemler olduğunun takibini yapabilir ve bunlara göre mimari açıdan doğru kararlar alabiliriz.

Etkinlik ve arama takibi

Kullanıcının hangi işlemler ve aramalar yaptığını izleyerek ona özel anlamlı veriler cıkarmak için kullanılır.

Sistem görüntüleme ve Alarmlar

Sistem üzerinde alınan hatalar ve bu hataları kategorize edip ciddi problemlerde alarm kurup hızlı bir şekilde müdahale edilmesinde kullanılabilir.

Veri Tutarlılığı

Bir db’de herhangi bir değişiklik yaptığımızda(Crud) etkilenebilecek yerlerde değişiklik yapmak isteyebiliriz. Örneğin replica db, elastic, redis

Stream Processing İşlemleri

Gerçek zamanlı uygulama geliştirirken kullanılır. Akan veri üzerinde işlem yapmamıza olanak tanır.

Kafka Temel Bileşenler

Topic

Veritabanındaki tablolara benzetebiliriz. Belirli bir veri akışı depolar. Mesajları düzenlemek ve bölümlendirmek için kullanılır. Topiclere isim verilebilir. Örnek olarak log bilgilerini tutan “logs” isimli bir topic olabilir. Bir producer topiğe veri yazarken bir consumer tarafından da o topicte yazılanlar işlenir. iki tür mesajlaşma modeli vardır. Biri sıraya alma diğeri publish-subscribe birinde topiğe veri yazılır. Bir servis tarafından sırayla consume edilir. Diğeri bir topiğe birden fazla servis veri ekleyebilir. Birden fazla sevis de dinleyip işleyebilir. Brokerların içerisinde bulunur. Topicteki verilen varsayılan olarak 1 hafta sonra silinir. Bu süreyi “message retention period” değeri ile değiştirebiliriz.

Partitions

Topiclerin içerisinde partitions adını verdiğimiz bölümler bulunmaktadır. Topic oluşturulurken içerisindeki partitions sayısı belirtilmelidir. Her bir mesajın offset olarak adlandırılan artan şekilde bir id değeri mevcuttur. Bir partitiona yazılan veriler değiştirilemez. Kafka topicleri immutable yani değişmezdir. Her bir veri okunduğunda offset artarak ilerler. Offset bir pointer görevi görür. Her partitionın kendine ait offset değeri vardır.

Broker

Kafka Cluster, bir yada daha fazla broker dediğimiz sunuculardan oluşmaktadır. Her bir brokerda farklı topicler olabileceği gibi bir brokerın bozulması durumu için birbirinin replikalarını da saklayabilir.

Topic Replication

Brokerların bozulması durumu için birden fazla broker içerisinde topic replikalarını(kopyalarını) saklarız. Bir broker düştüğünde diğeri ile devam eder. Asıl işlemlerin yapıldığı topiğe lider(leader) diğerlerine de takipçi(follower) denir. Her bir topic farklı brokerlara dağıtılır. Bu şekilde birine birşey olduğunda diğerleri ile işler devam eder.

Replication Factor, producer tarafından belirtilen bu değer bize bu mesajı en az kaç tane brokerda bulundurmamız gerektiğini verir.

Diyelim 15 adet farklı data centerlarda brokerımız olsun. Replication factor değeride 4 olsun. Bu demek oluyor ki bu mesajı 15 broker içerisinde en az 4 farklı brokerda bulunduracak.

Min-isr, değeri ise en az bu değer kadar brokerda mesajın bulunduğuna emin olduktan sonra onay ver anlamına geliyor.

min-isr değerini 2 olduğunu varsayalım yukarıdaki örneğe göre 2 brokerda bu mesajın bulunduğu kesin olmadan onay verilmez.

Aşağıdaki örnek replication factor 3 olduğu durum içindir.

Producer

Topic içerisine veri yazar. Mesaj anahtarları(Message Keys) ile sadece belirli partition içerisine veri gönderebilirken bunun yanında key belirtmeden tüm partitionlara da veri gönderebilir. Bir partitiondaki verileri okurken sıranın önemi var ise key ile gönderme tercih edilir. Mesaj anahtarsız gönderilirse iş yüküne göre(round robin) partitionlara dağıtılır.(load balancing).

Kafka Acknowledgement

Bu özellik ile yazılan verilerin ne durumda olduğunun bilgisini producera verebilir.

NONE

Producer brokere veriyi gönderir ama onayını beklemez ve akışına devam eder. Broker çalışır durumda mı veriyi başarılı bir şekilde gönderdi mi diye bakmaz. Bu durumda gecikme çok düşük verimlilik yüksek olsa da devamlılık ve veri kaybının ihtimali vardır.

LEADER_ONLY

Producer brokere verileri gönderdiğinde lider topiğin onayını bekler ama followerların onayını beklemez. Kısmen veri kaybı ihtimali olsa da NONE durumu gibi değildir.

ACK_ALL

Producer brokera veri gönderdiğinde hem liderin hemde followerların onayını bekler. Bu şekilde veri kaybı çok düşüktür ancak gecikme yüksek verimlilik düşük olabilir. Hangisinin seçileceği iş akışına ve oluşabilecek risklere göre değişebilir.

Consumer ve Consumer Groups

Topic üzerindeki verileri okur. Hangi brokerlardan veri okuması gerektiğini bilir ve aynı anda birden fazla brokerdan okuyabilir. Her bir consumerın bir grubu vardır. Grup halinde veri okurlar. Her grubun bir id si vardır. Load balancing ve yatay ölçeklenebilirlik için önemlidir.

Örneğin 20 tane partitiona sahip bir topic olsun eğer aynı grup id ye sahip 2 consumer var ise biri 10 partitonu diğeri 10 partitionu okuyacaktır. Ama 2 farklı grup id ye sahip 2 consumer olsaydı biri 20 partition diğeri 20 partition okuyacaktı. Kaç partition var ise aynı grup id ye sahip o kadar consumer olması tercih edilir. Eğer bir partition kapatılırsa consumer idle duruma yani pasif duruma geçebilir.

Kafka consumerlar bir pull model olarak çalışmaktadır. Kafka, consumerlara veri göndermez consumerler kafkadan veri ister. Bu şekilde okuma hızını consumerlar belirler.

Okuma sırası partition içerisinde garanti verilse de partitionlar arasında okunma sırası garanti edilmez.

Delivery Semantics

Producer ve broker arasında 3 farklı teslimat bulunmaktadır.

At most once

Offset, mesaj iletildiği gibi ilerletilir. Başarılı bir şekilde iletilip iletilmediğine bakılmaz. Hata olması durumunda veri kaybolur. Veri kaybını önemsemez. Düşük gecikme, yüksek verim beklenir.

At least once

Offset, mesaj iletildikten sonra commitlenir.

Eğer bir hata cıkması durumunda tekrar okunabilir. Bu işlem yinelenerek tekrar etmesine neden olabilir. Bundan dolayı tekrar tekrar işlenmesinin bir hataya neden olmayacağı durumlarda kullanılır. Orta düzey bir verim ve gecikme beklenir.

Exactly Once

Sadece bir kere iletilir. Verinin kaybolmaması hedeflenir. Düşük verim yüksek gecikme beklenir ama veri kaybı olmaz.

Zookepper

Brokerlar arasındaki haberleşmeyi, replikalar arasında sync işlemleri yapar. Eski kafka sürümde kafka ayrı zookeper ayrı olarak ayağa kaldırılıyordu. Kafka yeni versiyonlarda içerisinde onuda dahil etti.

Kafka Connect

Popüler sistemleri kafka ile entegre etmemizi sağlayan bir araçtır. Verileri kafkaya yazmak ve kafkadan diğer veri depolarına veri aktarmak için kullanılabilir.

Kafka Source connector(Producer) -> kafka -> Sink Connector(consumer)

Mysql -> source connector -> kafka -> sink connector -> Amazon S3

Oluşabilecek Senaryolar

Bir topicden create işlemi okuduğumuzda aynı anda başka bir partition içerisinde de bu işlemin cancel işlemi okunduğunu varsayalım. Create işleminde de bir hata oluşmuş olduğunu düşünelim cancel iptal edilecek bir işlem bulamadığından o da hata verecek bu durumda ne yapılabilir ?

Bu durumlar için bir retry ve error topiği oluşturabiliriz. Hata verme durumunda retry içerisinde atıp bu işlemin tekrardan denenmesi sağlanabilir. Bu şekilde sistemdeki hatanın çözülmesi veya sistemin toparlanması için zaman kazanmış oluruz. Yine hata verirse bu kez error topiğine alabiliriz.