1. GİRİŞ

Apache Kafka, yüksek hacimli veri akışlarını işlemek ve dağıtmak için endüstri standardı haline gelmiş dağıtık bir event streaming platformudur. Log tabanlı mimarisi, düşük gecikmeli publish/subscribe mekanizması ve yüksek verimlilik sağlayan I/O modellemesi ile gerçek zamanlı veri boru hatlarının (data pipelines), event‑driven sistemlerin ve stream processing uygulamalarının omurgasını oluşturur. Bulut‑native uygulamalar, mikroservis koordinasyonu, telemetri toplama, ETL/ELT iş akışları ve gerçek zamanlı analitik Kafka'nın yaygın kullanım alanlarıdır.

Bu neden bugün konuşuluyor?

Gerçek zamanlı veri işleme ihtiyacı ve mikroservis tabanlı mimarilerin benimsenmesi arttıkça, güvenilir, ölçeklenebilir ve düşük gecikmeli bir messaging/streaming altyapısı hayati önem taşıyor. Kafka, hem veri bütünlüğünü sağlayan bir message broker hem de yüksek-throughput saklama (durable log) çözümü olarak bu ihtiyacı karşılar.

Kimler için önemli?

Platform mühendisleri, veri mühendisleri, SRE'ler, uygulama geliştiriciler ve sistem mimarları Kafka mimarisini anlamalıdır; doğru tasarım hem performans kazanımı sağlar hem de operasyonel riskleri azaltır.

Hangi problemleri çözüyor?

• Yüksek hacimli event ingestion ve gerçek zamanlı veri dağıtımı
• Stream processing ile gerçek zamanlı analitik ve karar mekanizmaları
• Loose coupling: mikroservisler arasında asenkron iletişim
• Event sourcing ve audit loglama için dayanıklı depolama

2. KAVRAMSAL TEMELLER

2.1 Temel kavramlar

• Broker: Kafka sunucusu; topic verilerinin saklandığı ve üreticiler/ tüketiciler ile iletişim kurulan node.
• Topic: Veri akışının kategorize edildiği isimlendirilmiş log.
• Partition: Topic'in yatay olarak bölünmüş alt parçaları; paralel tüketim ve ölçek sağlar.
• Leader & Replica: Her partition için bir leader ve sıfır veya daha fazla follower replica bulunur; leader yazma/okuma isteklerini yönetir, follower replika olarak veri tutar.
• Offset: Partition içindeki her mesajın monoton artan pozisyonu; tüketiciler offset ile okuma konumunu takip eder.
• Producer / Consumer: Üretici uygulamalar veriyi publish eder; tüketiciler subscribe edip okur.
• Consumer Group: Tüketicilerin paralel ve yük paylaşımı ile çalışmasını sağlayan mantıksal grup.

2.2 Zookeeper vs KRaft

Kafka'nın klasik dağıtık koordinasyon katmanı Zookeeper idi; metadata yönetimi ve controller seçiminde Zookeeper kullanıldı. KRaft (Kafka Raft Metadata mode) ile Kafka metadata quorum'unu kendi içinde yönetebiliyor; operasyonel karmaşıklığı azaltıyor ve tek araçla yönetimi kolaylaştırıyor. KRaft, metadata replikasyonu ve controller seçiminde Raft algoritmasını kullanır.

3. NASIL ÇALIŞIR?

3.1 Sistem mimarisi — yüksek seviyede

Kafka, distributed log mimarisine dayanır. Üreticiler veriyi topic'e yazar; her topic bir veya daha fazla partition içerir. Partition'lar cluster üzerindeki broker'lar arasında dağıtılır. Her partition için bir leader seçilir; tüm yazma istekleri leader'a gelir ve leader bu veriyi follower'lara (replica) replikasyon sırasıyla gönderir. Okuma ise consumer group üyeleri arasında partition'ların paylaştırılmasıyla paralel hale gelir. Kafka aynı zamanda durable storage sunar: mesajlar diske append‑only olarak yazılır ve retention policy'leriyle saklanır veya silinir.

3.2 Veri akışı ve garanti modelleri

Kafka'da teslimat garantileri üretici tarafında konfigüre edilir: acks=0/1/all. acks=all (ve ISR kullanımı) strong durability sağlar: leader veriyi commit etmeden önce follower'ların onayını bekler. Consumer tarafında ise at‑least‑once (varsayılan offset commit pattern) veya exactly‑once semantics (EOS) için transactional producer/consumer kombinasyonları kullanılabilir. EOS, idempotent produce ve transactional write ile sağlanır; bu, stream processing job'larında doğru sonuç üretimini garanti eder.

3.3 Partitioning ve veri yerleşimi

Partition key seçimi throughput ve veri lokalitesi açısından kritiktir. Tek bir partition'a yoğunlaşma (hot partition) performans darboğazı yaratır; hash veya custom partitioner ile veriyi dengeli dağıtmak gerekir. Ayrıca partition sayısı artarsa paralellik artar ama yönetimsel overhead (reassignment, rebalancing) de yükselir.

3.4 Replication, ISR ve failover

ISR (In‑Sync Replicas) liderin takipçisi olarak güncel kalan replika setidir. Eğer leader düşerse, kontrolör yeni bir leader'ı ISR içinden seçer; bu süreç minimum downtime hedefler. Replica lag monitoring ve replica.fetch.max.bytes gibi parametreler replika sağlığını etkiler ve SRE'lerin izleme listesinde olmalıdır.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Netflix — telemetri ve event streaming

Netflix ölçekli telemetri toplama ve real‑time decision sistemleri için Kafka'yı kullanır. Yüksek hacimli event ingestion, kullanıcı etkileşimleri ve altyapı telemetrisi Kafka topic'lerine gelir; downstream stream processing sistemleri (Flink/Samza/Spark Streaming) bu topic'leri tüketip anlık iç görüler üretir.

4.2 Uber — yüksek paralellik ve düşük gecikme

Uber benzeri platformlar, geçerli konum ve talep verisini gerçek zamanlı paylaşmak için Kafka benzeri stream altyapılarına güvenir. Bu sistemlerde partitioning, locality ve ordering garantileri iş mantığı için hayati önem taşır.

4.3 Finans ve ödeme sistemleri — kesinlik ve audit

Fintech uygulamalarında Kafka event sourcing ve immutable log mekanizmasıyla transaction auditing ve reconciliation için kullanılır. Exactly‑once processing ve transactional write özellikleri finansal doğruluk sağlar.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Yüksek throughput: Disk append‑only ve zero‑copy optimizasyonları sayesinde yüksek veri aktarımı sağlar.
• Dayanıklılık: Replication ve disk tabanlı log retention ile veri kaybı riskini azaltır.
• Ölçeklenebilirlik: Partitionlar ile yatay ölçekleme mümkündür.
• Ekosistem: Connectors, Stream processing API'leri ve ekosistemle entegrasyon zenginliği.

Sınırlamalar

• Operasyonel karmaşıklık: Broker, controller, Zookeeper/KRaft, partition reassignment yönetimi deneyim gerektirir.
• Hot partition riski: Yanlış partition key tasarımı performans darboğazı yaratır.
• Retention ve storage maliyeti: Uzun retention süresi disk maliyetini artırır.
• Ordering sınırları: Ordering garantisi yalnızca partition seviyesinde sağlanır; cross‑partition ordering zordur.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

Aşağıdaki tablo Kafka ile diğer yaklaşım ve ürünleri karşılaştırır:

7. EN İYİ PRATİKLER

Production kullanımı

• Partition key tasarımına yatırım yapın: sorgu ve tüketim paterniyle uyumlu, hotspot'ları engelleyen anahtarlar seçin.
• Replication factor'ı ve ISR politikalarını iş kritikliğiyle hizalayın (örn. RF=3 genelde iyi bir dengedir).
• Monitoring: broker metrics, under‑replicated partitions, consumer lag, GC ve disk usage izlenmelidir.
• Graceful rolling upgrades: controller leadership, preferred leader election ve rebalancing stratejileri planlanmalı.

Performans optimizasyonu

• Producer batching ve linger.ms ayarları ile throughput artırılabilir.
• Compression (snappy, lz4) ile I/O azaltımı sağlanır; ancak CPU trade‑off'u değerlendirin.
• IO sıralama ve disk yapısını optimize edin: SSD, partition log segment boyutları ve flush davranışlarını tuning yapın.

Güvenlik

• Encryption in transit (TLS) ve encryption at rest uygulayın.
• SASL/Kerberos veya OAuth ile authentication; ACL'ler ile authorization yönetin.
• Network segmentation ve VPC/peering ile erişimi sınırlandırın.

Ölçeklenebilirlik ve operasyon

• Cluster capacity planning: throughput ve retention gereksinimlerine göre disk ve network planlayın.
• Topic lifecycle: retention, compaction ve cleanup policy'lerini iş gereksinimiyle hizalayın.
• Disaster recovery: cross‑region replication (MirrorMaker 2, Replication) ve DR planları hazırlayın.

8. SIK YAPILAN HATALAR

• Tek partition'a aşırı yönlendirme yaparak hot‑spot yaratmak.
• Yetersiz monitoring — consumer lag'ı ve under‑replicated partition'ları izlememek.
• Retention'ı gereksiz uzun tutmak; disk maliyetlerini göz ardı etmek.
• Transactional veya EOS gerektiren iş yüklerinde konfigürasyon hataları yapmak.
• Zookeeper/KRaft geçişini plansız yapmak; metadata quorum problemlerine yol açmak.

9. GELECEK TRENDLER

9.1 KRaft ve metadata kolaylaştırma

KRaft'ın benimsenmesiyle Kafka yönetimi daha sadeleşecek; Zookeeper bağımlılığı azalacak ve metadata yönetimi daha entegre hale gelecek.

9.2 Tiered / cold storage ve cost optimization

Tiered storage, uzun retention ile maliyet yönetimini kolaylaştıracak; sıcak verilere hızlı erişim, soğuk veriler için ekonomik depolama birlikte kullanılacak.

9.3 Serverless ve managed Kafka

Serverless Kafka çözümleri (autoscaling, serverless brokers) operasyonel yükü azaltacak; managed hizmetlerin yaygınlaşması operasyonel bariyerleri düşürecek.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. Kafka hangi durumlarda RabbitMQ'dan daha uygundur?

   Yüksek throughput, log‑oriented storage ve stream processing ihtiyaçları varsa Kafka daha uygundur; RabbitMQ routing ve düşük gecikme senaryolarında tercih edilir.

2. KRaft'a geçiş ne zaman mantıklıdır?

   Küçük yeni deployment'larda veya metadata yönetimini sadeleştirmek isteyen kuruluşlarda KRaft tercih edilebilir; geçiş planı ve test önemlidir.

3. Hot partition nasıl önlenir?

   Partition key tasarımını gözden geçirerek, hash tabanlı partitioner veya artan cardinality'ye sahip anahtarlar kullanarak hotspot'ları azaltın.

4. Exactly‑once semantics her yerde gerekli mi?

   Her iş yükü için gerekmeyebilir; finansal veya kritik data pipeline'larında EOS gereklidir, aksi halde at‑least‑once ile idempotent tüketim tercih edilebilir.

5. Retention için en iyi strateji nedir?

   İş gereksinimine göre: event sourcing için uzun retention veya compaction; analytics için ihtiyaç duyulan süre kadar saklama. Tiered storage ile maliyeti optimize edin.

6. Monitoring için hangi metrikler kritik?

   Broker disk usage, network throughput, under‑replicated partitions, consumer lag, GC pauses, request latency ve ISR boyutu takip edilmelidir.

7. Partition sayısını nasıl seçmeliyim?

   Paralellik ihtiyacı ve tüketici sayısı ile uyumlu, ancak çok yüksek partition sayısı yönetimsel yük getirir; test ve kapasite planlama ile belirleyin.

8. Kafka güvenliğini nasıl sağlarım?

   TLS, SASL/OAuth, ACL'ler ve network segmentation ile erişimi kısıtlayın; ayrıca audit log ve key management uygulayın.

Anahtar Kavramlar

Partition

Topic içinde paralel okuma ve yazma sağlayan alt birimler.

ISR (In‑Sync Replicas)

Leader ile senkron kalan replika seti; failover için kaynak sağlar.

Leader Election

Partition leader'ının seçilme süreci; controller tarafından yönetilir.

Compaction

Topic'te en son anahtar değeri korunarak eski kayıtların temizlenmesi yöntemi.

Öğrenme Yol Haritası

1. 0–1 ay: Kafka temel kavramları, producer/consumer API'leri ve local setup (single broker) ile başlayın.
2. 1–3 ay: Multi‑broker cluster, partitioning, replication ve temel konfigürasyon ile deneyim kazanın.
3. 3–6 ay: Performance tuning (producer batching, compression), monitoring (Prometheus/Grafana) ve rebalancing testleri yapın.
4. 6–12 ay: KRaft, tiered storage, cross‑region replication ve transactional/EOS konularında uzmanlaşın.
5. 12+ ay: Büyük ölçekli streaming mimarileri, disaster recovery planları ve ekonomi/ops optimizasyonları üzerine derinleşin.