Apache Kafka Hakkında Her şey

Sorunsallar

  • Mikroservis mimarilerinde verilerin nasıl aktarıldığı önemlidir.  Protokol olarak yani (TCP, HTTP, FTP, JDBC, REST, SOAP vb)
  • Veri formatı, verilerin nasıl parse edileceği de önemlidir (JSON, CSV, XML, Avro, Thrift vb).
  • Ayrıca mikroservis üstünde her entegrasyon ek yük olusturur.
mesela yani.

Çözüm

  • LinkedIn dedi ki. Ben birşey yaptım. Apache ile de open source lisansladım. Alın kullanın. dedi. Sonra bir ışık? J
  • Destek işlerine de birçok firma bakmaya başladı ama en başta Confluent çok iyi bir destek mekanizması oluşturdu.
  • Kısaca bu çözümün adı: Kafka idi. artık “Apache Kafka”

Apache Kafkanın Amacı

  • Birlikte çalışan sistemlerin birbirlerine olan bağımlıklıklarını ortadan kaldırarak, üzerlerindeki yüklerini de düşürecek bir yapı inşa edilmesi.
  • Kafka hataya dayanıklı, yatay olarak ölçeklenebilen, esnek bir mimariye sahiptir. Son derece yüksek performans ile bir sistemden diğer sisteme 10 ms’den az bir gecikme(latency) ile neredeyse gerçek zamanlı olarak veri transferini mümkün kılmaktadır. Yani real time bir sistemi amaçlıyor.

Nerelerde Kullanılır?

  • Mesajlaşma sistemlerinde (messaging system),
  • Etkinlik takibinde (activity tracking),
  • Uygulama loglarını toplamada,
  • Sağladığı API ile stream processing ile,
  • Big Data entegrasyonlarıyla
  • Örneğin Fraud sistemleri,
  • Gerçek zamanlı öneriler, kararlar ve bilgiler(insights) oluşturmak için kullanılabilir.

Kavramlar

Bu kısımda aşağıdaki başlıkları inceleyeceğiz.

  • Topic
  • Partitions
  • Offsets.
  • Brokers
  • Topic Replication
  • Producer
  • Consumer
  • Message Delivery Semantics
  • Zookeeper

O zaman,

1. Topics, Partitions, Offsets. Yakından inceleyelim:

  • Topic kullanıcı tanımlı bir kategori ismidir. Yani bir koleksiyondur. Mongo’ cular? This is collections. = topic.
  • Kısaca mesajların tutulduğu yerdir.
  • Veritabınındaki tabloya benzer.
  • Kafka içerisinde birçok topic olabilir, bir isim ile tanımlanırlar.
  • Bir veya birden fazla bölümden(partitions) meydana gelirler.

Her partition’ın 0 dan başlayan numaraları vardır. Resimde bir topic üzerinde 3 partitions (0, 1 ve 2) görüyoruz.

  • Mesajlar partition’lara sıralı olarak ve değiştirilemez olarak eklenirler ve artan şekilde bir kimlik değeri alırlar. Bu değere offset denir.Yani offset aslında bir partitionId ye bağımlı messageId’ dir.
  • Bir mesajın partition ve offset değeri değişmez. Mesaj okuma işleminden sonra kaybolmaz, tekrar erişim mümkündür.
  • Topiclerin bu partition özelliği sayesinde yazma ve okuma işlemleri paralel bir şekilde yapılabilir. Aşağıdaki resimde consumerA 9.offset’ i okurken consumerB’ de 11.offset’ i okuyabilir.
  • Topic’ler oluşturulurken kaç partition olacağı belirlenir, istenirse sonradan da değiştirilebilir. 
  •  Yani partition 0 daki 4 nolu offset değerine sahip bir mesaj, partition 0 daki 5 no lu offset değerine sahip mesajdan önce yazılmıştır ve önce okunacaktır, Kafka bunu garanti eder. 
  • Kafka’ da veriler belirli süre saklanırlar. Default olarak 1 hafta setlenir. Kafka server’ i kurduğumuzda bu yapılandırmaya değineceğiz.
  • Topic’e eklenen yeni mesajlar bir kural (anahtar) belirtilmemişse rastgele bir partition’a atanır, her zaman partition’ın sonuna eklenir ve eklendikçe offset sürekli artmaya devam eder, 0 a hicbir zaman dönmez.

2. Brokers

  • Broker, topic ve partition’ları tutan sunuculardır. 
  • Birçok broker bir araya gelince kafka cluster’ı oluşturur. 
  • Bir broker’a bağlandığınızda, buna “bootstrap broker” /”bootstrap server” denir ve tüm cluster’a bağlanmış olursunuz.
  • Her broker sadece belirli topic partitionlarını içerir. Yani tüm veriyi tutmaz çünkü Kafka dağıtık bir yapıdadır. 
  • Yani ne imiş:  Cluster içerisindeki her Kafka broker aslında bir “Bootstrap Server” mış.
  • X Broker’ ı, topic ve partition bilgilerini bilir ve bir consumer veya producer kendisine bağlandığında bu bilgileri paylaşır. Bu bilgiler metadata olarak adlandırılır.
  • Bir Kafka broker’a bağlanmak tüm Kafka cluster’ına bağlanmaktır J Uygulama esnasında göreceğiz bunu.

3. Topic Replication

  • Kafka dağıtık(distrubuted) bir sistemdir, bir broker çökse bile veri kaybı olmaması ve işlemlerin devam ediyor olması gereklidir. (Bu konuya kafka hazırlık yazısında değinmiştim.)
  • Replikasyon bu işi yapar. Kelime anlamı zaten replike etmek-kopya oluşturmaktır. (bkz replike iPhone)
  • Replication Factor genellikle 2 yada 3 olarak belirlenir, 2 olarak belirlenmesi biraz risklidir. 

Örnek:

  •  3 broker dan oluşan bir kafka cluster yapımız olduğunu düşünelim. Id leri ile tanıyacak olursak broker.id=0 olan 1.Broker’ imiz, broker.id=1 olan 2.brokerimiz ve broker.id=2 olan da 3.Broker olsun.
  • 2 adet partition oluşturduk diyelim.
  • Yani replication factor sayımız 2 oldu. Aşağıya bakacak olursak:
  • Replication factor 2 olarak set edildiği için partition’ların birer kopyası farklı bir broker üzerinde daha tutulacaktır.
  •  broker.id=1’ i kaybettiğimizi düşünelim, bu durumda veriler broker.id=0 ve broker.id=2 de olduğu için kayıp olmayacak, işlemler devam edecektir.
  • 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 (ISR). 
  • Yani her partition için bir lider, birçok ISR(in-sync replica) olur.
  • Lider ve ISR’lara karar veren Zookeeper’dir.

4. Producer

  • Producer: Topic’lere veriyi yazanlara verilen niteliktir.
  • Cluster içerisindeki bir brokere bağlanarak hangi broker ve partitiona yazacağını bilirler. (–bootstrap-server değeri verilmeden yazma ve okuma gerçekleşmez! gerçekleşemez. Bu konuya geleceğiz.*)
  • Broker çökse bile otomatik olarak recover olacağını söylemiştik.
  • Mesaj anahtarı (message key) belirtilmişse, partition’a yazma işlemi anahtar değerine göre yapılır.
  • Aynı anahtar değerine sahip mesajlar, aynı partition’a yazılır. 
  • Kafka partition bazında yazma ve okuma işlemini garanti ettiği için, sıranın önemli olduğu durumlarda kullanılabilir.
  • Mesaj anahtarı belirtilmediği durumlarda partition’lara yükü dengelemek için round robin ile yazacaktır.

Mesela producer’ in kafka ya yazmak istediği bir json veri düşünelim.

			{merchantId: abcdf-1-1-2,date: 20200517,category: xyz,phoneNumber: 555-555-5555}

Yazma işleminde message key’ e karışmazsak roundrobin yöntemiyle identity olarak offset’ lemeye devam edecek. Yazma işlemini merchantId ye göre veya category’ e göre yaparak verileri ayrıştırmada da kullanabiliriz. Dolayısıyla önem arz ediyor message keys bilgisi.

  • Acks adında bir parameter var.
  • Bu aslında producer’ in onayı anlamına geliyor.
  • Producer acknowledgment (acks=x)
  • Acks=0

         Kafkaya mesajı gönder cevabı bekleme dümdüz devam et.

         Dezavantaj: very kaybolabilir, risk yüksek.

  • Acks=1

         Kafkaya mesajı gönder ve sadece leader yazana kadar bekle.

         Orta derece hız ve performans. risk az.

  • Acks=all,-1

         Kafkaya mesajı gönder, leader ve isr lerin yazılmasını sonuna kadar bekle.

         En yavaş ve en güvenilir yöntem. Mesajın kaybolma ihtimali yok. Risk 0.00000….9

5. Consumer

  • Consumer: Topic’lerden veriyi okurlar.
  • Hangi broker’dan okuyacağını bilir(–bootstrap-server), broker çökse bile otomatik recover olur.
  • Okuma işlemi aynı Partition içerisinde sıralı bir şekilde olur.
  • Consumer birden fazla partition’dan mesaj okuyabilir.
  • Her bir consumer, bir consumer grup oluşturur.
  • Bir partition’ı bir consumer group içerisinde sadece bir consumer okuyabilir.
  • Consumer offset bilgilerini okuması ile ilgili kafka’ nın bir yaklaşımı var. 
    • Kafka, consumer offset bilgilerini “__consumer_offsets” topic içerisinde tutar.
    • Consumer, Kafka topic’ten mesajı okur, mesajı işler ve mesajın offset değerini “__consumer_offsets” topic’ine yazar.
    • Offset bilgilerininin topic’e yazılma işlemi consumer tarafından otomatik yapılır yada programlanabilir.
    • Bir consumer kaybedildi
      • Tekrar ayağa kalktı ve “__consumer_offsets” içerisinde en son hangi mesajı okuduğu kayıtlı olduğu için kaldığı yerden devam edebilir.

6. Message Delivery Semantics

  • Consumer’ların offset bilgilerinin “__consumer_offsets” topicinde ne zaman yazacağına göre değişen “__consumer_offsets”  topicine karşı bazı teslimat yöntemleri vardır.
    • At most once
      • Offset bilgisi mesaj alınır alınmaz yazılır.
      •  Mesaj, işlenmesi sırasında bir hata oluşursa kaybedilir.
      • En performanslı yöntemdir
      • Dez avantajı: Mesaj kaybı söz konusu.
      • Okunan mesaj bilgilerin çok önemli olduğu sistemlerde önerilmez!
    • At least once
      • Offset bilgisi mesaj işlendikten sonra yazılır.
      • Mesaj, işlenmesi sırasında bir hata oluşursa tekrar okunur.
      • Mesaj kaybı oluşmaz ama birden fazla mesajları okuma olasılığı vardır.
      • Dolayısıyla “__consumer_offsets”  topicinde mesaj okuma bilgisi dublike olabilir. Kurulu olan sisteminiz bundan etkilenmemelidir?
      • Etkilenirse de etkilenmemesi sağlanmalıdır bu yöntem en çok tercih edilen yöntemdir J
    • Exactly once
      • Kafka – Kafka arasındaki iş akışlarında Kafka Streams API ile sağlanıyor.
      • Mesaj, Kafka topic’ler arasında transfer olurken ve işlenirken transactional producer ve consumer kullanılıyor.

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

8. Sonuç

  • Uygulamalarınızı yüksek ölçeklenebilir, elastik, dağıtılmış, hataya dayanıklı hale getirir
  • Exactly Once Processing (tam olarak bir kez işleme) semantiğini destekler
  • Stateful processing (window, aggregation işlemleri vs) ve stateless processing (veriyi zenginleştirme, veri transformasyonu vs)
  • Windowing, joins, aggregations ile event-time processing
  • Streams ve veritabanlarının dünyalarını birleştirmek için Interactive Queries (Etkileşimli Sorguları) destekler
  • Basit declarative functional API yada alt seviye imperative API
  • Milisaniye işleme gecikmesi
  • Her seferinde bir kayıt işleme (mikro batching yok)
  • Geç gelen ve sırası dışındaki verileri sorunsuz bir şekilde işler
  • Aktarılan verilerin şifrelenmesini destekler
  • Kimlik doğrulama ve yetkilendirmeyi destekler
  • Özetle, Kafka Streams API aşağıdaki durumlarda alternatiflerine (Spark, Storm vs) göre ideal çözüm olarak düşünülebilir.
  • Stream processing uygulamamız kafka’dan kafka’ya pipeline oluşturuyorsa
  • Stream processing amacıyla ayrıca cluster yapılar kurmak istenmiyorsa
  • Akan veri üzerinde filtreleme, joins, aggregations, veri zenginleştirme gibi basit stream processing fonksiyonları gerçekleştirilmek isteniyorsa
  • Hedef kullanıcılar java developerlar ise,

Kaynak

https://kafka.apache.org/

Bilgi

Bu yazı 3 aşamadan oluşmaktadır.

1.yazı genel mimari yapıları anlatır.

2.yazı bu yazıdır. Apache Kafka Hakkında her detaya yer verilir.

3.yazı ise uygulama aşamasıdır.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir