Belajar Apache Kafka - Network Configuration & Multi-Datacenter

#Pendahuluan

Kesalahan paling umum dalam setup Kafka bukan di sisi aplikasi, melainkan di jaringan: klien yang tidak bisa terhubung, latensi antar broker yang tinggi, atau komunikasi yang gagal lintas lingkungan. Sebagian besar berasal dari pemahaman yang kurang tentang listener dan advertised listeners.

Di episode 15 ini kalian akan memahami cara Kafka mengonfigurasi titik koneksi, membedakan protokol PLAINTEXT, SSL, dan SASL, mengatur listener internal dan eksternal yang terpisah, serta mengeksplorasi pola deployment multi-datacenter — active-active dan active-passive — beserta pertimbangan latensi dan recovery-nya.

#Konsep Listener

#Listener dan Advertised Listener

Setiap broker membuka satu atau lebih listener: kombinasi host, port, dan protokol tempat broker menerima koneksi. Ketika broker merespons klien, ia tidak menyebut dirinya dengan address yang dipakai klien untuk terhubung, melainkan dengan advertised listener — alamat yang ia umumkan agar klien menghubunginya kembali.

Konfigurasi listener dasar

listeners=PLAINTEXT://:9092
advertised.listeners=PLAINTEXT://kafka-1.internal:9092

Jika advertised.listeners salah, klien berhasil mengirim request metadata pertama tetapi gagal menghubungi broker karena alamat yang diumumkan tidak terjangkau — gejala klasik "koneksi timeout di client, padahal broker sehat".

#Protokol Listener

Protokol menentukan bagaimana koneksi diamankan:

PLAINTEXT: tanpa enkripsi dan autentikasi, hanya untuk development.
SSL: koneksi dienkripsi dengan TLS (detail di episode 18).
SASL_PLAINTEXT: autentikasi SASL tanpa enkripsi.
SASL_SSL: autentikasi SASL plus enkripsi TLS — kombinasi standar produksi.

#Inter-Broker Communication

Komunikasi antar broker diatur dengan inter.broker.listener.name:

Pisahkan listener inter-broker

listeners=INTERNAL://:9093,EXTERNAL://:9094
advertised.listeners=INTERNAL://10.0.1.5:9093,EXTERNAL://kafka.example.com:9094
listener.security.protocol.map=INTERNAL:PLAINTEXT,EXTERNAL:SASL_SSL
inter.broker.listener.name=INTERNAL

inter.broker.listener.name=INTERNAL membuat replikasi antar broker berjalan lewat jaringan internal tanpa melewati internet, sementara klien eksternal memakai listener EXTERNAL yang diamankan SASL_SSL. Nilai listener.security.protocol.map memetakan nama listener ke protokol sebenarnya.

#Multiple Listeners dan Networking

#Internal vs External

Memisahkan listener internal dan eksternal adalah praktik keamanan dasar: klien di dalam VPC memakai alamat privat, klien publik memakai alamat publik yang diamankan, dan keduanya berbagi broker yang sama. Ini menghindari memaparkan seluruh cluster ke internet sekaligus menjaga throughput replikasi tetap di jaringan internal.

#Docker Networking

Dalam Docker, broker sering gagal diakses karena advertised listener memakai nama host yang hanya dikenali di dalam container. Gunakan nama service Compose untuk sesama container dan nama host berbeda untuk klien host:

Listener untuk Docker Compose

KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://kafka:29092,PLAINTEXT_HOST://localhost:9092
KAFKA_LISTENER_SECURITY_PROTOCOL_MAP=PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT

PLAINTEXT://kafka:29092 dipakai sesama container, sementara PLAINTEXT_HOST://localhost:9092 untuk klien dari host. Konfigurasi lengkap akan dibahas di episode 29.

#Cloud Networking

Di AWS, broker berada di VPC dengan security group yang hanya mengizinkan port broker dari CIDR tertentu. Untuk klien di luar VPC, gunakan load balancer atau AWS PrivateLink di depan listener. Selalu batasi source IP security group pada jaringan internal dan prinsipal terpercaya.

#DNS Considerations

Advertised listener menggunakan nama host, jadi DNS harus konsisten dari sudut pandang klien dan antar broker. Prinsip penting: nama yang diumumkan broker harus resolve ke alamat yang benar dari tempat klien berada. Jangan memakai alamat IP langsung jika broker bisa dipindah atau diskala, karena IP bisa berubah — pakai nama DNS yang stabil dan biarkan resolver menunjuk ke alamat yang benar.

DNS yang konsisten untuk broker

kafka-1.internal.example.com   -> 10.0.1.5
kafka-2.internal.example.com   -> 10.0.1.6
kafka.example.com              -> load balancer publik

kafka.example.com mengarah ke load balancer untuk klien eksternal, sementara nama kafka-N.internal.example.com dipakai sesama broker dan klien internal. Pastikan juga reverse lookup bekerja jika mutual TLS dan mapping prinsipal berdasarkan hostname dipakai.

#Multi-Datacenter Patterns

#Replication Lintas Datacenter

Kafka tidak mereplikasi data lintas datacenter secara native — replikasi hanya antar broker dalam satu cluster. Untuk multi-datacenter, kalian memakai pola replikasi lintas cluster, terutama MirrorMaker 2.0 yang akan dibahas mendalam di episode 25.

Sebelum memilih pola, tetapkan target bisnis: berapa banyak data yang boleh hilang dan seberapa cepat pemulihan dibutuhkan. Target ini (RPO dan RTO) menentukan seberapa sinkron replikasi harus berjalan dan seberapa otomatis failover-nya.

#Active-Active vs Active-Passive

Active-active: kedua datacenter menerima tulis secara mandiri; data disinkronkan dua arah. Throughput lebih tinggi, tetapi rawan konflik dan perlu offset translation yang hati-hati.
Active-passive: satu datacenter aktif menerima tulis, datacenter lain siaga; replikasi satu arah. Lebih sederhana dan aman, dengan trade-off failover yang harus menunggu sinkronisasi.

#Latency dan Disaster Recovery

Jarak fisik menentukan latensi: replikasi lintas benua bisa menambah ratusan milidetik per round-trip, menurunkan throughput produksi dan memperlambat failover. Untuk RTO (Recovery Time Objective) yang ketat, tempatkan datacenter berjarak rendah, dan rancang failover otomatis dengan checkpoint rutin.

Warning

Jangan memperlakukan dua cluster yang direplikasi sebagai satu cluster. Kafka menjamin consistency di dalam satu cluster; lintas cluster hanya ada perjanjian replikasi (eventually consistent). Tulis aktif di dua tempat bisa menciptakan data divergen yang sulit didamaikan.

#Penutup

Di episode 15 ini kalian sudah memahami perbedaan listener dan advertised listener, empat protokol koneksi, pemisahan listener internal dan eksternal, pertimbangan Docker dan cloud networking, serta pola multi-datacenter active-active dan active-passive.

Inti yang harus dibawa pulang:

Advertised listener adalah alamat yang diumumkan broker; salah konfigurasi membuat klien timeout.
Protokol produksi standar: SASL_SSL untuk autentikasi plus enkripsi.
Pisahkan listener internal untuk replikasi dan eksternal untuk klien.
Di Docker, advertised listener harus berbeda untuk container dan host.
Multi-datacenter memakai replikasi lintas cluster, bukan replikasi dalam satu cluster.
Active-passive lebih aman; active-active lebih cepat tapi rawan konflik.

Di episode 16 selanjutnya kita akan mengamankan akses dengan authentication SASL — PLAIN, SCRAM, GSSAPI, dan OAUTHBEARER. Kalian akan belajar konfigurasi broker dan klien, pembuatan user SCRAM dengan kafka-configs, serta integrasi OAuth 2.0.