Apache Kafka Makale Serisi -2

kafka broker ile ilgili görsel sonucu

Büyük verileri etkin bir şekilde kullanmak için bir çok farklı teknoloji karşımıza çıkmaktadır.
Peki bu teknolojilerin ana görevleri nelerdir ?

  • Büyük verileri toplamak
  • Büyük verileri analiz etmek

Büyük veri bloklarını hatasız ve hızlı bir biçimde toplayıp, diğer sistemlere transfer edebilmek için bir mesajlaşma sistemine(queue) ihtiyacımız vardır .
Bu noktada karşımıza Apache Kafka , Rabbit MQ vb. queu sistemleri teknolojileri karşımıza çıkmaktadır.
Burada amaç, akan verileri bir queu (mesaj kuyruğu) içerisine atarak farklı destination lara yollamak (Hadoop,Spark,Elasticsearch,Couchbase,PostgreSQL vb.) hedeflenmektedir.

Bu tarz queu sistemlerin en büyük avantajları ;

  • Birden fazla makinede aralel çalışabilmesi
  • Verileri belirli bir süre saklama özellikleri
  • Verilere anlık erişim sunulması
  • Cluster yapılarından dolayı ne kadar büyük bir yük olursa olsun ona uygun design edilmiş ve sizing yapılmış cluster ile bu yükü cover edebilecek bir yapı kurulabilmesi.

Bu makalemizde biraz Apache Kafka ‘nın Terminolojini anlatacağız.

  • Topic :

Kullanıcı tanımlı kategori isimidir ve mesajların tutulduğu yerdir. Örnek verecek olur isek, veritabanında ki tabloya benzemektedir.
Birden fazla Topic olabilmektedir ve isim ile tanımlanmaktadırlar.
Örneğin , Web sitemizde tıklanmaları tutacağımız click adlı bir topic, aramalarıda tutacağımız search adında topic ler açarak verilerimizi bu şekilde kategorize edebiliriz.

  • Partition-Offset :

Topic içerisinde veriler çeşitli parçalara ayrılabilir.Bu ayrılmaya Partition denilmektedir.
Her partition içerisinde mesajlar tekil (unique) bir Id bilgisine sahiptir.
Her partition ‘ın 0 dan başlayan numaraları vardır. Mesajlar partition ‘lara sıralı ve değiştirilemez olarak eklenirler ve artan şekilde bir kimlik değeri alırlar.
İşte bu değere OFFSET denilmektedir. Bir mesajın partition ve offset değeri değişmez.Mesajlar okuma işleminden sonra kaybolmazlar yani tekrar erişim mümkündür.

Partition işlemlerinden dolayı okuma ve yazma işlemler paralel yapılabilmekte ve buda performansı arttırmaktadır.
Topic ler oluşturulurken veya sonradan kaç partition olacağı belirlenebilir.
Apache Kafka ‘da mesajların sırası partition içinde garanti edilir. Yani Partition 1 de ki 8 no lu offset değerine sahip bir mesaj,
partition 1 de ki 9 no lu offset değerine sahip mesajdan önce yazılmıştır ve önce okunacaktır. Kafka işte bunu garanti ediyor.
Partition 2 deki 5 no lu offset değerine sahip mesaj ise daha önce yazılmış olabilir bu yüzden partition lar arası mesaj sırası için garanti vermez.

  • Broker :

Topic ve Partition ‘ların tutulduğu sunuculardır. Birden fazla broker ile Apache Kafka Cluster oluşmaktadır. Kısaca Kafka Cluster da ki her bir Node ‘a Broker denmektedir.
Bir Broker ‘a bağlantı sağladığınızda tüm cluster lara bağlantı sağlamış oluyorusunuz.Her bir Broker belirli topic partition larını barındırmaktadır.Cluster mimarisi olduğundan Broker tüm veriyi tutmaz yani dağıtık bir yapıdadır.

Örnek ,
5 Broker dan oluşan bir Kafka Cluster ‘ımız olsun. Aynı zamanda click_category adında ve 5 partition dan oluşan bir topic ‘imiz var olsun.
Bu şekilde ki model için her bir Broker bu topic ‘in bir partition ‘ını tutacak şekilde dağılım yapmaktadır. Eğer Partition sayımız 5 değilde 9 olsaydı,
4 Broker iki partition tutup 1 Broker da tek partition tutacak şekilde dağılım olacaktı.

  • Replication Factor :

Bu değer Kafka gibi dağıtık (distrubuted) sistemler için çok önemlidir. Genlede bu değeri 2 veya 3 olarak belirleriz. Bu demek oluyor ki , 1 Broker çöktüğünde veri
kaybı yaşamamamız için bu değer bulunmkatadır. Bildiğiniz üzere Kafka dağıtık bir sistem ve bir Broker çökerse orada ki mesajlar kaybolabilir ve bunun önüne geçmek için bu veirleri
farklı Broker larda da yedeklememiz gerekmekte.İşte tam bu nokta da Replication Factor değerinin önemi ortaya çıkmaktadır.

Örnek,

3 adet Broker dan oluşan bir Kafka Cluster ‘ımız olsun ve 1 topic 2 partition ‘ımız olsun ve Replication factor değerimizde 2 olsun. Broker 1 de bir partition broker 2 de de 2. partition tutulmaktadır.
Replication factor değerimiz 2 olduğundan partition ların birer kopyası farklı bir broker üzerinde daha tutulacaktır. Bu şekilde 1.broker gittiğinde mesajlarımızı kaybetmemiş olacağız.

Kafka’da belirli bir zamanda bir partition için sadece bir lider(Leader) kavramı vardır. Lider olan broker veriyi alır ve sunar, diğer brokerlar pasif kopyalar olur, sadece verileri senkronize ederler.
Yani her partition için bir lider, birçok ISR(in-sync replica) olur. Lider ve ISR’lara karar veren Zookeeper’ dir.

  • Producer :

Mesajları birden fazla Kafka Topic ‘e gönderen bileşenlerdir. Topic lere veri yazan kısımdır. Broker çökse bile otomatik recover olur.

  • Consumer :

Bir ya da birden fazla Topic ‘i dinleyerek mesajları broker üzerinden çeken bileşenlerdir.

kafka broker ile ilgili görsel sonucu
  • Consumer Offset :

Apache Kafka , offset bilgilerini topic içerisinde tutmaktadır. Consumer , Topic ten veriyi okur ve mesajı işler daha sonra ise mesajın offset değerini ilgili topic ‘e yazar.
Offset bilgilerinin topic ‘e yazılma işlemi consumer tarafından otomatik olarak yapılır yada programlanabilir.Buun yöntemlerini aşağıda Message Delivery Semantics
bölümünde aktaracağım. Bu sayede bir consumer tekrar ayağa kalktığında o topic içerisinde hangi offset de olduğu bilgisini bildiği için kaldığı yerden devam etmektedir.

  • Message Delivery Semantics :

Consumer ‘ların mesajlarını ne zaman yazacağına göre değişiklik gösteren 3 farklı mesaj teslim garantisi bulunmaktadır. Yöntemleri anlatırken en çok tercih edilen ile başlayacağım.

  • At Least Once :
    Offset bilgisi mesaj işlendikten sonra yazılır.İşlenme sırasında bir hata oluşursa mesaj tekrar okunur ve bu durumda mesaj kaybı yaşanmaz ama birden fazla mesajları okuma olsalığı ortaya çıkmaktadır.En çok tercih edilen modeldir. Fakat bu modelde mesaj işleme sürecimiz idempotent olmalıdır yani duplicate durumlarında sistemlerimiz etkilenmemektedir.
  • At Most Once :
    Offset bilgisini mesaj alındığı gibi yazıldığı modeldir. Bu yüzden işleme sırasında bir hata ile karşılaşıldığında mesaj kaybedilir. Bu sebepten ötürü pek tercih edilmeyen bir modeldir. En performanslı ama mesaj kaybı riski yüksek olduğundan tercih edilmiyor.
  • Exactly Once :
    Sadece Kafka ile Kafka arasında ki mesajlama için kullanılabilen bir modeldir. Kafka Stream API ile akışlar sağlanmaktadır. Mesaj, Kafka topic’ ler arasında transfer olurken ve
    işlenirken transactional producer ve consumer kullanılıyor.
  • Zookeeper
    Kafka broker’ larını yönetir. Topic partition’ ları için broker lider seçiminine yardımcı olur. Yeni bir broker ayağa kalktığında veya düştüğünde, topic
    oluşturulduğunda veya silindiğinde, Zookeeper Kafka broker’ lara bildirim gönderir. Kafka, ayağa kalkmak için Zookeeper’a ihtiyaç duyar. Bu nedenle önce
    Zookeeper, sonra Kafka broker ayağa kaldırılır. Kural olarak cluster içerisindeki Zookeeper sayısı tek sayı olmalıdır. Bir lider ve takipçileri vardır. Kafka,
    cluster içerisindeki herhangi bir Zookeeper’a bağlanması yeterlidir.
  • Kafka Broker Discovery
    Cluster içerisindeki her Kafka broker aslında bir “Bootstrap Server” dır. Diğer broker, topic ve partition bilgilerini bilir ve bir consumer veya producer kendisine bağlandığında bu bilgileri paylaşır. Bu bilgiler meta-data olarak adlandırılır. Yani, bir Kafka broker’a bağlanmak tüm Kafka cluster’ ına bağlanmak
    anlamına gelir.
    NOT : Producer ve Consumer’ lar için cluster içerisindeki hangi broker’a yazacağını veya hangi broker’ dan okuyucağını bilirler.

Leave a Reply

Your email address will not be published. Required fields are marked *