Vebende Akademi - kafka-cluster-kurulumu
Uzmanla Konuşun
Blog
MAKALE

Kafka Cluster Kurulumu (Adım Adım)

Dağıtık mesajlaşma ve stream işlem altyapıları için Apache Kafka cluster'larının tasarımı, kurulumu, işletimi ve ölçeklenmesi üzerine kapsamlı rehber.

Kafka Cluster Kurulumu (Adım Adım)

Dağıtık mesajlaşma ve stream işlem altyapıları için Apache Kafka cluster'larının tasarımı, kurulumu, işletimi ve ölçeklenmesi üzerine kapsamlı rehber.

1. Giriş

Gerçek zamanlı veri işleme, event-driven mimariler ve yüksek hacimli mesaj kuyruğu ihtiyaçları modern sistemlerin önemli birer gereksinimi haline geldi. Apache Kafka, yüksek throughput, düşük gecikme ve dayanıklılık sağlayan dağıtık bir publish-subscribe mesajlaşma platformudur. Doğru kurulan bir Kafka cluster, veri boru hatları, stream processing, log toplama ve servis entegrasyonları için güvenilir altyapı sağlar.

Bu makalede Kafka cluster kurulumunu hem pratik hem de mimari bakış açısıyla adım adım ele alacağız: temel kavramlar, bileşenler, single-node geliştirme kurulumundan HA (high-availability) üretim kümelerine, depolama ve retention stratejilerinden, izleme, güvenlik ve ölçekleme ipuçlarına kadar geniş kapsamlı bir rehber sunulacaktır.

Bu neden konuşuluyor?

  • Gerçek zamanlı analitik ve stream processing kullanımının artması.
  • Microservices ve event-driven uygulamaların veri iletişim katmanında güvenilir mesaja ihtiyaç duyması.
  • Bulut ve on-prem hibrit mimarilerde taşınabilir, ölçeklenebilir bir messaging altyapısının önemi.

Kimler için önemli?

Platform mühendisleri, veri mühendisleri, SRE/DevOps ekipleri, backend geliştiriciler ve sistem mimarları için kritik bir konudur.

Hangi problemleri çözüyor?

Yüksek hacimli veri aktarımı, olay temelli entegrasyon, kuyruk tıkanmalarının yönetimi, veri dayanıklılığı ve stream tabanlı iş mantıklarının koordinasyonu gibi problemleri ele alır.

2. Kavramsal Temeller

Kafka'yı verimli kullanmak için temel kavramları netleştirelim.

Kavramlar

  • Broker: Kafka sunucusu; topic partition'larını barındıran node.
  • Topic: Mesaj kategorisi; producerlar veriyi topic'e yazar, consumerlar okur.
  • Partition: Topic'in paralel işlenebilmesini sağlayan sıralı bölümler.
  • Replica: Partition'ın yedek kopyası; dayanıklılık ve availability sağlar.
  • Leader/Follower: Her partition için bir leader ve bir veya daha fazla follower bulunur; yazma/oku işlemleri leader üzerinden yönetilir.
  • Zookeeper/KRaft: Kafka'nın metadata yönetimi için geleneksel olarak ZooKeeper kullanılırdı; yeni sürümlerde KRaft (Kafka Raft) ile ZooKeeper bağımlılığı kaldırılabiliyor.

Mimari

Kafka cluster; birden çok broker, topic partition dağılımı, replication factor ve bir metadata yönetim katmanı (Zookeeper veya KRaft) ile kurulur. Üretim ortamlarında storage (disk) performansı, ağ bant genişliği, JVM ayarları ve retention politikaları mimari kararları doğrudan etkiler.

Terminoloji

  • Replication Factor: Partition başına kopya sayısı; yüksek availability için >1 olmalıdır.
  • ISR (In-Sync Replicas): Leader ile senkron durumda olan follower kümesi.
  • Retention: Kafka'nın mesajları ne kadar süre saklayacağı (time veya size bazlı).

Bileşenler

Brokerlar, controller (Leader broker), ZooKeeper/KRaft, producer, consumer, schema registry (Avro/Protobuf/JSON Schema), connect workers (Kafka Connect) ve stream processing (Kafka Streams, Flink, Spark) tipik bileşenlerdir.

3. Nasıl Çalışır?

Kafka'nın çalışma mantığını ve veri akışını teknik detaylarla inceleyelim.

Sistem Mimarisi

Producer, mesajı topic'e gönderir; Kafka, mesajı ilgili partition'ın liderine yazar. Leader mesajı alır ve follower replika'lara çoğaltır. ISR seti içinde yer alan follower'lar veriyi acknowledged (onay) eder. Consumerlar ise offset takip ederek mesajları okur; consumer group'lar ile paralel tüketim sağlanır.

Bileşenler ve Roller

  • Producer: Mesaj üretip Kafka'ya yazar. Batch ve linger parametreleri throughput'u etkiler.
  • Consumer: Mesajları okuyan uygulama; offset'leri commit ederek ilerler.
  • Kafka Connect: Veri entegrasyonları için source/sink connector'lar sağlar.
  • Schema Registry: Mesaj şemalarını yönetir; veri kalitesini ve evolüsyonunu kolaylaştırır.

Veri Akışı

1) Producer -> Topic partition leader. 2) Leader -> Follower replication. 3) Mesaj local disk'te segment dosyalarına yazılır (log segment). 4) Consumer belirli offset'ten okuyup işleme alır. 5) Log compaction veya retention kuralları gereği eski segmentler cleanup edilir.

Çalışma Mantığı (Örnek Senaryo)

Bir e-ticaret sitesinde sipariş event'leri Kafka'ya publish edilir. Order-service producer, sipariş verisini topic'e yazar. Analitik pipeline (Kafka Connect -> S3 veya stream processor) bu mesajları tüketerek gerçek zamanlı metrikler ve batch ambarına aktarım yapar.

4. Gerçek Dünya Kullanımları

Kafka'nın büyük ölçekli kullanıldığı örnek senaryolar:

Netflix

Event hub olarak Kafka benzeri çözümlerle telemetri, kullanıcı olayları ve pipeline'lar yönetilir; yüksek throughput ve düşük gecikme ön plandadır.

Uber

Gerçek zamanlı konum ve etkinlik stream'leri, yüksek hacimli event akışları hayat kritiktir; Kafka benzeri dağıtık mesajlaşma sistemleri ile çalışılır.

Amazon

Order processing, inventory ve event-driven servis entegrasyonlarında dayanıklı event log yapılarına ihtiyaç vardır.

OpenAI / Büyük Ölçekli ML İş Yükleri

Model eğitim verisinin pipeline'ları, işlenmiş örneklerin kaydı ve telemetry için Kafka kullanılabilir.

Stripe

Ödeme ve finansal event'lerin güvenilir teslimi ve audit için mesaj sırası ve dayanıklılık önemli bir gereksinimdir.

5. Avantajlar ve Sınırlamalar

Avantajlar

  • Yüksek performans: Binlerce partition ve yüksek throughput ile saniyede milyonlarca mesaj işlenebilir.
  • Dayanıklılık: Replication sayesinde veri kaybı riski düşürülür.
  • Esneklik: Stream processing ve connect ekosistemi ile farklı kullanım durumlarına uyum sağlar.

Dezavantajlar

  • Operasyonel karmaşıklık: Zookeeper/KRaft, broker konfigürasyonları, rebalancing ve disk yönetimi uzmanlık gerektirir.
  • Storage yükü: Retention/compaction politikaları yanlış ayarlanırsa disk tüketimi hızla artar.
  • Rebalancing etkileri: Partition reassign veya broker downtime sırasında gecikme/paket kayıpları görülebilir.

6. Alternatifler ve Karşılaştırma

Aşağıdaki tablo Kafka'yı popüler alternatifleriyle karşılaştırır:

TeknolojiAvantajDezavantaj
KafkaYüksek throughput, stream ekosistemi, dayanıklılıkOperasyonel kompleksite, storage yönetimi
RabbitMQDüşük latenceli kuyruğa uygun, routing zenginliğiYüksek hacim ve uzun süreli saklama için maliyetli
PulsarSegment tabanlı storage, multi-tenancy ve geo-replicationDaha yeni, ekosistem Kafka kadar olgun değil
Kinesis (AWS)Managed, AWS entegrasyonuVendor lock-in, maliyet ve throughput sınırlamaları

7. En İyi Pratikler

Kafka cluster kurarken ve işletirken dikkat edilmesi gerekenler:

Production kullanımı

  • Replication factor'ı en az 3 olarak planla; böylece bir broker veya datacenter kaybında veri erişimi sağlanır.
  • Partition count'u dikkatle belirle; paralellik arttıkça yönetim karmaşıklığı ve metadata yükü artar.
  • Zookeeper yerine mümkünse KRaft moduna geçiş planı yap (Kafka sürümüne bağlı olarak).

Performans optimizasyonu

  • Producer batch.size, linger.ms ve compression.type ayarlarını iş yüküne göre optimize et.
  • Broker JVM heap ve GC ayarlarını (G1GC gibi) dikkatle yapılandır; disk I/O için yeterli throughput sağla (NVMe/SSD önerilir).
  • Topic başına partition sayısını iş yükü paralelliğine göre planla; aşırı küçük partition'lar throughput'u sınırlayabilir.

Güvenlik

  • TLS ile broker-client ve inter-broker iletişimini şifrele.
  • SASL (SCRAM/OAUTH) ile kimlik doğrulama ve Kafka ACL ile yetkilendirme uygula.
  • Schema Registry ile veri şemalarını yöneterek backward/forward compatibility'yi güvence altına al.

Ölçeklenebilirlik

  • Broker sayısını yatay olarak arttırarak kapasiteyi yükselt; partition yeniden dağıtımlarını kontrollü yap.
  • Disk ve ağ I/O sınırlarını izleyerek hotspot oluşumunu engelle.
  • Cross-datacenter replication (MirrorMaker/Confluent Replicator veya Pulsar geo-replication benzeri) stratejilerini planla.

8. Sık Yapılan Hatalar

  • Retention politikalarını yanlış ayarlamak — gereksiz disk tüketimi veya veri kaybı.
  • Replication factor'ı düşük tutmak — broker kaybında veri kaybı riski artar.
  • Partition sayısını sonradan düzensiz artırmak — rebalancing maliyetleri ve kesintiler.
  • Monitoring ve alert eksikliği — ISR dışına çıkan replika veya disk dolulukları gözden kaçar.
  • Schema evrimini yönetmemek — tüketicilerle uyuşmazlık ve data corrupt riskleri.

9. Gelecek Trendler

  • Cloud-native stream platformları: Managed Kafka hizmetleri (MSK, Confluent Cloud) ve serverless stream çözümleri yaygınlaşacak.
  • Tiered storage: Uzun dönem veriler için katmanlı storage (hot/warm/cold) daha verimli maliyet yönetimi sağlar.
  • Event mesh ve global replication: Multi-region replikasyon ve global event routing önem kazanacak.
  • Veri contract-first yaklaşımlar: Schema, semantic ve contract yönetimi üretim güvenliğini artıracak.

Ek Bölümler

Sık Sorulan Sorular (FAQ)

  1. S: Kafka'yı küçük bir uygulama için kullanmalı mıyım?

    C: Küçük uygulamalar için Kafka yönetim maliyeti fazla olabilir; geliştirme sürecinde embedded/kafka lokal veya managed çözümler tercih edilebilir.

  2. S: Replication factor ne olmalı?

    C: Üretimde en az 3 önerilir — bu sayede tek broker kaybında quorum korunur.

  3. S: ZooKeeper gerekli mi?

    C: Yeni Kafka sürümlerinde KRaft ile ZooKeeper bağımlılığı azaltılıyor; ancak mevcut dağıtımlarda ZooKeeper hâlâ metadata yönetimi için kullanılıyor.

  4. S: Disk tipi ne olmalı?

    C: Yüksek I/O için NVMe/SSD önerilir; disk throughput, retention ve segment flush performansını doğrudan etkiler.

  5. S: Topic partition sayısı nasıl belirlenir?

    C: Paralellik ve consumer group sayısına göre belirlenir. Her consumer thread en fazla bir partition okuyabileceği için paralel tüketim hedefleniyorsa partition sayısını arttırın.

  6. S: Rebalancing nasıl minimize edilir?

    C: Statically assign edilen partition'lar, prefered leader election ve kontrollü reassign işlemleri ile rebalancing etkileri azaltılabilir.

  7. S: Schema evolution nasıl yönetilir?

    C: Avro/Protobuf ve Schema Registry kullanarak backward/forward kompatibilite kurallarını uygulayın.

  8. S: Monitoring için hangi metrikler kritiktir?

    C: ISR size, under-replicated partitions, broker throughput, disk utilization, GC pauses, network latency ve consumer lag temel metriklerdir.

Anahtar Kavramlar

Partition
Topic'in paralel işlenmesini sağlayan bölüm.
Replication Factor
Partition başına kopya sayısı; dayanıklılığı belirler.
ISR
Leader ile senkron durumda olan replika kümesi.
Retention
Mesajların saklanma süresi veya boyutuna göre konfigürasyon.

Öğrenme Yol Haritası

Aşağıdaki adımlar Kafka uzmanlığına ulaşmak isteyenler için önerilen sıra ve süre tahminlerini içerir:

  1. Temel Kavramlar (1-2 hafta): Topic, partition, producer/consumer, offset ve basic client API'leri öğrenin.
  2. Geliştirme ve Lokal Deneyim (2-3 hafta): Local Kafka cluster (docker-compose/kind) ile producer/consumer uygulamaları yazın.
  3. Connect & Schema (2-3 hafta): Kafka Connect ile entegrasyonlar, Schema Registry ve format yönetimi.
  4. Operasyon & Monitoring (3-4 hafta): Broker yönetimi, rebalancing, metrics, logging ve alerting konularında deneyim kazanın.
  5. Production Readiness (sürekli): HA topolojileri, disaster recovery, capacity planning ve security best practices üzerinde çalışın.

Pratik alıştırmalar: küçük bir event-driven uygulama tasarlayın, Kafka Connect ile veriyi bir veritabanından okuyup S3'e yazdırın, ardından consumer lag ve rebalancing senaryolarını test edin.