Apache Kafka Sunucu Kurulumu ve Mesaj Kuyruğu Yönetimi

Son Güncelleme: Haziran 2026

Apache Kafka, yüksek trafikli uygulamalarda olay akışı (event streaming), mesaj kuyruğu (message queue) ve gerçek zamanlı veri işleme ihtiyaçlarını karşılamak için kullanılan güçlü bir platformdur. Bu rehberde Kafka sunucu kurulumu, temel mimari, güvenlik, performans ayarları, yedekleme yaklaşımı ve VPS/VDS üzerinde pratik kullanım senaryoları detaylı şekilde ele alınmaktadır.

İçindekiler

• Apache Kafka Nedir?
• Kafka Mimarisi ve Temel Kavramlar
• Sunucu Planlama: CPU, RAM, Disk ve Ağ
• Ubuntu Üzerinde Kafka Kurulumu
• Kafka Güvenliği: Kullanıcı, Ağ ve TLS
• Performans Optimizasyonu ve İzleme
• Yedekleme, Saklama Politikası ve Felaket Senaryoları
• Pratik Kullanım Senaryoları
• Sıkça Sorulan Sorular
• Sonuç

Apache Kafka Nedir?

Apache Kafka, uygulamalar arasında yüksek hacimli veriyi güvenilir, ölçeklenebilir ve düşük gecikmeli şekilde taşımak için tasarlanmış dağıtık bir olay akışı platformudur. Geleneksel mesaj kuyruğu sistemlerinden farklı olarak Kafka, mesajları yalnızca alıcıya teslim edip silen bir yapıdan ibaret değildir; verileri belirli bir süre boyunca disk üzerinde tutar, birden fazla tüketicinin aynı veriyi farklı amaçlarla okumasına izin verir ve yatay ölçeklenebilirlik sunar.

Kafka özellikle mikroservis mimarileri, e-ticaret sipariş akışları, log toplama, kullanıcı davranışı analizi, finansal işlem kayıtları, IoT (nesnelerin interneti) verileri ve gerçek zamanlı raporlama sistemlerinde tercih edilir. Örneğin bir alışveriş sitesinde sipariş oluşturulduğunda aynı olay stok servisine, e-posta servisine, fatura servisine ve analitik sistemine gönderilebilir. Kafka bu olayın her servis tarafından bağımsız şekilde tüketilmesini sağlar.

Kafka’nın en önemli avantajlarından biri dayanıklılık ve yüksek işlem hacmi sunmasıdır. Mesajlar topic (konu) adı verilen mantıksal kanallara yazılır, partition (bölüm) yapısı ile paralel işlenir ve replication (çoğaltma) sayesinde bir broker arızalansa bile veri kaybı riski azaltılır. Bu nedenle Kafka, doğru yapılandırılmış bir Türkiye VDS Sunucu veya yüksek trafikli iş yükleri için Kiralık Sunucu üzerinde güvenle çalıştırılabilir.

Kafka Mimarisi ve Temel Kavramlar

Kafka’yı verimli kullanmak için temel kavramları doğru anlamak gerekir. Yanlış tasarlanmış topic, partition veya replication yapısı; performans kaybına, disk tüketiminin hızla artmasına ve tüketici tarafında gecikmelere neden olabilir.

Broker

Broker, Kafka sunucusunun veri kabul eden, saklayan ve tüketicilere sunan bileşenidir. Tek broker ile test veya küçük ölçekli sistemler kurulabilir; ancak üretim ortamında en az üç broker kullanılması önerilir. Broker sayısı arttıkça cluster (küme) daha dayanıklı ve ölçeklenebilir hale gelir.

Topic ve Partition

Topic, mesajların yazıldığı mantıksal kanaldır. Örneğin orders, payments, logs veya user-events birer topic olabilir. Partition ise topic içindeki verilerin parçalara ayrılmasını sağlar. Partition sayısı arttıkça tüketiciler paralel çalışabilir ve daha yüksek veri işleme kapasitesi elde edilir.

Producer ve Consumer

Producer, Kafka’ya mesaj yazan uygulamadır. Consumer ise Kafka’dan mesaj okuyan uygulamadır. Consumer group (tüketici grubu) yapısı sayesinde aynı topic’i birden fazla uygulama grubu bağımsız olarak tüketebilir. Örneğin bir grup veriyi raporlama için okurken başka bir grup bildirim göndermek için okuyabilir.

Offset

Offset, partition içindeki her mesajın sıra numarasıdır. Consumer hangi mesaja kadar okuduğunu offset ile takip eder. Bu yapı, servis yeniden başlatıldığında kaldığı yerden devam etmeyi sağlar. Offset yönetimi doğru yapılmazsa aynı mesajın tekrar işlenmesi veya bazı mesajların atlanması gibi sorunlar oluşabilir.

Replication Factor

Replication factor, verinin kaç broker üzerinde kopyalanacağını belirtir. Üretim ortamında genellikle 3 değeri tercih edilir. Böylece bir broker devre dışı kalsa bile veri başka broker üzerinden okunabilir. Tek sunuculu küçük yapılarda replication factor 1 olabilir; ancak bu durumda donanım veya disk arızasına karşı yedekleme stratejisi daha kritik hale gelir.

Sunucu Planlama: CPU, RAM, Disk ve Ağ

Kafka performansı büyük ölçüde disk I/O (girdi/çıktı), ağ kapasitesi ve doğru bellek yönetimine bağlıdır. Kafka mesajları diske sıralı şekilde yazdığı için modern SSD veya NVMe disklerle oldukça yüksek performans sağlar. Ancak disk alanı yalnızca toplam mesaj boyutuna göre değil, saklama süresi, replication factor ve beklenmeyen tüketici gecikmeleri dikkate alınarak hesaplanmalıdır.

CPU Planlama

Kafka yoğun şekilde sıkıştırma, TLS şifreleme, ağ aktarımı ve disk yazma işlemleri yaptığı için CPU önemlidir. Küçük bir test ortamı için 2 vCPU yeterli olabilirken, üretim ortamında broker başına 4 veya 8 vCPU daha sağlıklı sonuç verir. Eğer ssl trafiği, gzip veya zstd sıkıştırma kullanılıyorsa CPU ihtiyacı artacaktır.

RAM Planlama

Kafka, işletim sisteminin sayfa önbelleğinden (page cache) yoğun biçimde yararlanır. Bu nedenle tüm belleği Kafka heap alanına ayırmak doğru değildir. Genellikle broker için 4 GB ile 8 GB arası JVM heap değeri yeterli olur; kalan RAM disk cache için işletim sistemine bırakılır. Örneğin 16 GB RAM bulunan bir sunucuda KAFKA_HEAP_OPTS="-Xms4G -Xmx4G" gibi bir değer başlangıç için uygundur.

Disk Planlama

Kafka disk üzerinde log segmentleri tutar. Disk seçimi yapılırken yalnızca kapasiteye değil, IOPS (saniye başına giriş/çıkış işlemi), gecikme süresi ve dayanıklılığa bakılmalıdır. NVMe diskler düşük gecikme ve yüksek sıralı yazma performansı sunduğu için Kafka iş yüklerinde avantaj sağlar. Ayrıca Kafka veri dizini ile işletim sistemi diskini ayırmak, bakım ve performans açısından iyi bir yaklaşımdır.

Ağ Planlama

Kafka brokerları arasında replication trafiği bulunur. Producer ve consumer trafiğine ek olarak brokerlar arası veri kopyalama da ağ kullanımını artırır. Bu nedenle özellikle çok brokerlı yapılarda düşük gecikmeli ve yüksek bant genişliğine sahip ağ altyapısı tercih edilmelidir. Trafiğin yoğun olduğu yapılarda Kafka’yı aynı veri merkezi veya aynı bölge içinde konumlandırmak gecikmeyi azaltır.

• Küçük test ortamı: 2 vCPU, 4 GB RAM, SSD disk ve tek broker ile başlanabilir.
• Orta ölçekli üretim: 3 broker, broker başına 4 vCPU, 8-16 GB RAM ve NVMe disk önerilir.
• Yüksek trafikli sistem: 3 veya daha fazla broker, özel disk havuzu, izleme sistemi ve ayrı yönetim ağı planlanmalıdır.

Ubuntu Üzerinde Kafka Kurulumu

Bu bölümde örnek olarak Ubuntu tabanlı bir sunucuda Kafka kurulumu gösterilmektedir. Komutlar üretim öncesi test ortamında denenmeli, sürüm numaraları ve dizin tercihleri kurum standartlarınıza göre uyarlanmalıdır. Kafka, güncel sürümlerde ZooKeeper’sız KRaft (Kafka Raft) modunu desteklediği için yeni kurulumlarda KRaft mimarisi tercih edilebilir.

Sistem Kullanıcısı Oluşturma

Kafka’yı root kullanıcısı ile çalıştırmak güvenlik açısından önerilmez. Öncelikle ayrı bir sistem kullanıcısı oluşturun.

sudo adduser --system --group --home /opt/kafka kafka
sudo mkdir -p /var/lib/kafka /var/log/kafka
sudo chown -R kafka:kafka /var/lib/kafka /var/log/kafka /opt/kafka

Java Kurulumu

Kafka JVM üzerinde çalıştığı için uyumlu bir Java sürümü gerekir. Ubuntu üzerinde OpenJDK kurulumu aşağıdaki gibi yapılabilir.

sudo apt update
sudo apt install -y openjdk-17-jdk wget tar
java -version

Kafka Paketini İndirme ve Hazırlama

Kafka dosyalarını /opt/kafka altında konumlandırmak yönetimi kolaylaştırır. Aşağıdaki örnekte arşiv dosyası indirildikten sonra ilgili dizine çıkarılır.

cd /tmp
wget https://downloads.apache.org/kafka/3.7.0/kafka_2.13-3.7.0.tgz
sudo tar -xzf kafka_2.13-3.7.0.tgz -C /opt/kafka --strip-components=1
sudo chown -R kafka:kafka /opt/kafka

Üretim ortamında indirme adresi ve sürüm numarası kontrol edilmeli, mümkünse dosya imzası doğrulanmalıdır. Ayrıca kurulum dosyalarını doğrudan canlı sistemde değiştirmek yerine yapılandırma yönetimi aracıyla dağıtmak daha güvenli bir pratiktir.

KRaft için Storage ID Oluşturma

KRaft modunda Kafka cluster için benzersiz bir storage ID gerekir. Bu ID, broker meta verisinin ilişkilendirilmesinde kullanılır.

sudo -u kafka /opt/kafka/bin/kafka-storage.sh random-uuid

Komutun ürettiği değeri not alın. Ardından yapılandırma dosyasını düzenleyin. Tek brokerlı basit bir başlangıç için /opt/kafka/config/kraft/server.properties dosyasında aşağıdaki temel ayarlar kullanılabilir.

process.roles=broker,controller
node.id=1
controller.quorum.voters=1@127.0.0.1:9093
listeners=PLAINTEXT://0.0.0.0:9092,CONTROLLER://127.0.0.1:9093
advertised.listeners=PLAINTEXT://SUNUCU_IP_ADRESI:9092
controller.listener.names=CONTROLLER
listener.security.protocol.map=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT
log.dirs=/var/lib/kafka
num.partitions=3
default.replication.factor=1
min.insync.replicas=1
log.retention.hours=168
log.segment.bytes=1073741824

SUNUCU_IP_ADRESI alanı, istemcilerin erişeceği gerçek IP adresi veya özel ağ adresi ile değiştirilmelidir. Kafka’yı internete açık şekilde çalıştırmak yerine güvenlik duvarı, VPN veya özel ağ kullanmak daha doğru bir yaklaşımdır.

Storage Formatlama ve Servis Dosyası

Önce Kafka storage alanını formatlayın. Aşağıdaki komutta UUID_DEGERI yerine az önce üretilen değer yazılmalıdır.

sudo -u kafka /opt/kafka/bin/kafka-storage.sh format -t UUID_DEGERI -c /opt/kafka/config/kraft/server.properties

Daha sonra Kafka’yı systemd servisi olarak tanımlayın.

sudo tee /etc/systemd/system/kafka.service > /dev/null <<'EOF'
[Unit]
Description=Apache Kafka Server
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=kafka
Group=kafka
Environment="KAFKA_HEAP_OPTS=-Xms2G -Xmx2G"
ExecStart=/opt/kafka/bin/kafka-server-start.sh /opt/kafka/config/kraft/server.properties
ExecStop=/opt/kafka/bin/kafka-server-stop.sh
Restart=on-failure
RestartSec=10
LimitNOFILE=100000

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now kafka
sudo systemctl status kafka

Topic Oluşturma ve Test

Kurulumdan sonra basit bir topic oluşturup producer ve consumer ile test yapabilirsiniz.

sudo -u kafka /opt/kafka/bin/kafka-topics.sh --create --topic test-events --bootstrap-server 127.0.0.1:9092 --partitions 3 --replication-factor 1
sudo -u kafka /opt/kafka/bin/kafka-topics.sh --list --bootstrap-server 127.0.0.1:9092

Bir terminalde consumer başlatın.

sudo -u kafka /opt/kafka/bin/kafka-console-consumer.sh --topic test-events --from-beginning --bootstrap-server 127.0.0.1:9092

Başka bir terminalde producer ile mesaj gönderin.

sudo -u kafka /opt/kafka/bin/kafka-console-producer.sh --topic test-events --bootstrap-server 127.0.0.1:9092
Merhaba Kafka
Siparis olusturuldu
Odeme basarili

Mesajlar consumer terminalinde görünüyorsa temel Kafka kurulumu başarıyla tamamlanmıştır.

Kafka Güvenliği: Kullanıcı, Ağ ve TLS

Kafka genellikle kritik iş verilerini taşıdığı için güvenlik yapılandırması ihmal edilmemelidir. Varsayılan ve açık bir Kafka portu, yetkisiz erişim, veri sızıntısı ve servis kesintisi riskleri oluşturabilir. Bu nedenle ağ erişimi, kimlik doğrulama, şifreleme ve yetkilendirme birlikte ele alınmalıdır.

Ağ Erişimini Sınırlandırma

Kafka portu olan 9092 yalnızca uygulama sunucularına, özel ağa veya VPN istemcilerine açılmalıdır. İnternete açık Kafka brokerları, bot taramaları ve yetkisiz bağlantılar için hedef haline gelebilir.

sudo ufw allow from UYGULAMA_SUNUCU_IP to any port 9092 proto tcp
sudo ufw deny 9092/tcp
sudo ufw enable
sudo ufw status

Kullanıcı Yetkileri

Kafka dosya dizinleri yalnızca kafka kullanıcısına ait olmalıdır. Log ve veri dizinlerinin yanlış izinlerle bırakılması, hem güvenlik hem de servis sürekliliği açısından sorun oluşturabilir.

sudo chown -R kafka:kafka /opt/kafka /var/lib/kafka /var/log/kafka
sudo chmod 750 /opt/kafka /var/lib/kafka /var/log/kafka

TLS ve Kimlik Doğrulama

Üretim ortamında Kafka istemci trafiği için TLS (taşıma katmanı güvenliği) etkinleştirilmelidir. TLS, istemci ile broker arasındaki verinin şifrelenmesini sağlar. Ayrıca SASL (basit kimlik doğrulama ve güvenlik katmanı) ile kullanıcı adı ve parola tabanlı kimlik doğrulama uygulanabilir. Daha yüksek güvenlik gereken yapılarda karşılıklı TLS kullanılarak hem istemcinin hem de sunucunun sertifika ile doğrulanması tercih edilir.

Güvenlik yapılandırması yapılırken sertifika yenileme, anahtar dosyalarının izinleri, istemci yapılandırmaları ve erişim politikaları bir bütün olarak planlanmalıdır. Web uygulaması, worker servisi ve raporlama sistemi gibi farklı bileşenler için ayrı kullanıcılar tanımlamak, olay takibini kolaylaştırır.

• En az yetki: Her uygulamaya yalnızca ihtiyaç duyduğu topic üzerinde okuma veya yazma izni verilmelidir.
• Şifreli trafik: Veri merkezleri arası veya internet üzerinden geçen bağlantılarda TLS zorunlu olmalıdır.
• Gizli bilgi yönetimi: Parolalar kod deposunda tutulmamalı, güvenli değişken yönetimi veya secret sistemi kullanılmalıdır.
• Audit takibi: Kimlerin hangi topic’e eriştiği düzenli olarak kontrol edilmelidir.

Performans Optimizasyonu ve İzleme

Kafka yüksek performanslı bir sistemdir; ancak yanlış yapılandırma ile gecikme, consumer lag, disk doluluğu veya broker dengesizliği oluşabilir. Performans optimizasyonu yalnızca tek bir ayarı değiştirmekten ibaret değildir. Producer, broker, consumer, disk, ağ ve uygulama mantığı birlikte değerlendirilmelidir.

Producer Ayarları

Producer tarafında acks, batch.size, linger.ms ve compression.type ayarları önemlidir. acks=all daha güvenli teslimat sağlarken gecikmeyi artırabilir. linger.ms küçük bir bekleme süresi ekleyerek daha büyük batch oluşmasını sağlar ve throughput (iş hacmi) değerini artırabilir. Sıkıştırma için lz4 veya zstd çoğu senaryoda iyi sonuç verir.

Consumer Lag Takibi

Consumer lag, tüketicinin Kafka’daki son mesaja göre ne kadar geride olduğunu gösterir. Lag sürekli artıyorsa consumer sayısı yetersiz olabilir, işleme süresi yüksek olabilir veya partition sayısı paralellik için yeterli olmayabilir.

sudo -u kafka /opt/kafka/bin/kafka-consumer-groups.sh --bootstrap-server 127.0.0.1:9092 --describe --all-groups

Broker ve Topic Ayarları

Topic oluştururken partition sayısı rastgele seçilmemelidir. Çok az partition paralelliği sınırlar, çok fazla partition ise broker üzerinde dosya tanıtıcıları, bellek ve metadata yükünü artırır. Başlangıçta orta ölçekli bir topic için 3, 6 veya 12 partition tercih edilebilir; ancak karar mesaj hacmine, consumer sayısına ve büyüme beklentisine göre verilmelidir.

İzleme Metrikleri

Kafka izleme için JMX (Java Management Extensions) metrikleri kullanılabilir. İzlenmesi gereken temel metrikler disk kullanımı, broker CPU, ağ trafiği, under-replicated partition, offline partition, request latency, log flush süresi ve consumer lag değerleridir. Bu metrikler düzenli takip edilmezse sorunlar genellikle kullanıcı şikayeti veya servis kesintisi ile fark edilir.

Yedekleme, Saklama Politikası ve Felaket Senaryoları

Kafka, verileri replication ile koruyabilir; ancak replication tek başına yedekleme değildir. Yanlışlıkla silinen topic, hatalı retention ayarı, uygulama kaynaklı bozuk veri üretimi veya tüm cluster seviyesinde yaşanan problem için ayrıca yedekleme ve felaket kurtarma planı gerekir. Bu noktada Corelux Yedekleme Hizmeti gibi düzenli ve planlı çözümler, operasyonel riski azaltmaya yardımcı olur.

Retention Politikası

Retention, Kafka’nın mesajları ne kadar süre veya ne kadar disk boyutuna kadar saklayacağını belirler. Örneğin log ve analitik veriler 7 gün saklanabilirken, finansal olayların daha uzun süre tutulması gerekebilir. Ancak Kafka’yı sınırsız arşiv sistemi gibi kullanmak genellikle doğru değildir. Uzun süreli saklama için object storage, veri ambarı veya arşiv veritabanı daha uygun olabilir.

sudo -u kafka /opt/kafka/bin/kafka-configs.sh --bootstrap-server 127.0.0.1:9092 --entity-type topics --entity-name test-events --alter --add-config retention.ms=604800000

Topic Konfigürasyonlarını Yedekleme

Kafka verisinin yanında topic ayarları, ACL kuralları, servis dosyaları ve uygulama yapılandırmaları da yedeklenmelidir. Sadece veri dizinini kopyalamak çoğu zaman yeterli değildir. Aşağıdaki örnek, topic listesini dışa aktarmak için kullanılabilir.

sudo -u kafka /opt/kafka/bin/kafka-topics.sh --bootstrap-server 127.0.0.1:9092 --describe > /root/kafka-topics-backup.txt

Felaket Kurtarma Yaklaşımı

Felaket kurtarma planında RPO (kabul edilebilir veri kaybı süresi) ve RTO (kabul edilebilir geri dönüş süresi) net tanımlanmalıdır. Kritik finansal işlemlerde RPO birkaç saniye olabilirken, log analiz sistemlerinde birkaç dakikalık kayıp kabul edilebilir. Bu değerler, replication, snapshot, uzak lokasyon yedeği ve uygulama tarafı tekrar üretim stratejisini belirler.

• Topic ayarlarını belgeleyin: Partition, retention, replication ve ACL bilgileri düzenli kayıt altına alınmalıdır.
• Uzak lokasyon düşünün: Aynı fiziksel ortamda tutulan yedekler büyük afet senaryolarında yeterli olmayabilir.
• Geri dönüş testi yapın: Yedeğin çalıştığı, yalnızca felaket anında değil düzenli testlerle doğrulanmalıdır.

Pratik Kullanım Senaryoları

Kafka yalnızca büyük ölçekli teknoloji şirketleri için değil, büyüyen web projeleri, SaaS platformları ve kurumsal uygulamalar için de güçlü bir altyapı bileşenidir. Özellikle yoğun trafikli uygulamalarda senkron işlemleri azaltarak kullanıcı deneyimini iyileştirebilir.

E-ticaret Sipariş Akışı

Bir e-ticaret sisteminde kullanıcı ödeme yaptığında sipariş oluşturma, stok düşme, fatura kesme, kargo bildirimi ve e-posta gönderimi aynı anda tetiklenebilir. Tüm bu işlemleri tek web isteği içinde yapmak gecikmeyi artırır. Bunun yerine uygulama order-created topic’ine olay yazar, ilgili servisler bu olayı kendi hızında tüketir. Böylece web uygulaması daha hızlı yanıt verir.

Log Toplama ve Analiz

Birden fazla web sunucusu, uygulama sunucusu ve arka plan servisi olan yapılarda logları merkezi olarak toplamak önemlidir. Kafka, logları geçici ve dayanıklı bir akış katmanı olarak taşıyabilir. Daha sonra bu veriler arama motoruna, veri ambarına veya alarm sistemine aktarılabilir.

Bildirim Sistemi

Kullanıcıya e-posta, SMS veya uygulama içi bildirim göndermek için Kafka kullanılabilir. Uygulama, notification-requested topic’ine mesaj yazar. Bildirim worker’ları mesajları tüketir ve dış servislerle iletişim kurar. Dış servis yavaşlasa bile ana uygulama doğrudan etkilenmez.

IoT ve Sensör Verileri

IoT cihazlarından gelen sıcaklık, konum, hareket veya durum verileri Kafka ile gerçek zamanlı olarak işlenebilir. Partition yapısı cihaz ID’sine göre tasarlanırsa aynı cihaza ait olayların sırası korunabilir. Bu özellik, zaman sıralı analizlerde önemlidir.

Uygulama Altyapısı Seçimi

Küçük ve orta ölçekli projelerde Kafka için güçlü bir Sanal Sunucu başlangıç noktası olabilir. Daha yoğun trafik, yüksek disk I/O ve çok brokerlı cluster ihtiyaçlarında ise özel kaynaklara sahip Kiralık Sunucu tercih edilerek daha kararlı performans elde edilebilir.

Sıkça Sorulan Sorular

Sonuç

Apache Kafka, modern web uygulamalarında olay akışı, mesaj kuyruğu, gerçek zamanlı veri işleme ve servisler arası gevşek bağlı iletişim için güçlü bir çözümdür. Ancak Kafka’dan verimli sonuç almak için yalnızca kurulum yapmak yeterli değildir; topic tasarımı, partition planı, disk kapasitesi, güvenlik, izleme, retention politikası ve yedekleme stratejisi birlikte değerlendirilmelidir.

Küçük projelerde tek brokerlı Kafka kurulumu öğrenme ve geliştirme için uygun olabilir. Kritik üretim ortamlarında ise çok brokerlı yapı, güvenli ağ mimarisi, düzenli izleme ve felaket kurtarma planı şarttır. Corelux altyapısında ihtiyaçlarınıza göre Sanal Sunucu, yüksek performans gerektiren iş yükleri için Kiralık Sunucu ve veri güvenliği için Yedekleme Hizmeti seçeneklerini değerlendirerek Kafka tabanlı sistemlerinizi daha güvenli, ölçeklenebilir ve sürdürülebilir hale getirebilirsiniz.