Centralized vs Decentralized Clusters: Menentukan Model Topologi Kluster #

Ketika organisasi kita tumbuh dan mengadopsi arsitektur event-driven secara luas, jumlah aplikasi produser dan konsumen yang berinteraksi dengan Apache Kafka akan meningkat drastis. Di titik ini, kita akan dihadapkan pada dilema tata kelola infrastruktur yang menentukan efisiensi biaya dan kemudahan operasional: “Apakah kita harus membangun satu kluster Kafka terpusat raksasa untuk digunakan bersama oleh seluruh departemen (Centralized Shared Cluster), ataukah menyediakan kluster khusus terpisah untuk setiap tim pengembang (Decentralized Dedicated Clusters)?”

Membuat keputusan ini tanpa analisis matang sering kali berujung pada penyesalan. Memilih model terpusat secara terburu-buru dapat memicu insiden “tetangga bising” (noisy neighbor) di mana satu aplikasi yang bermasalah menghabiskan seluruh bandwidth broker dan merusak performa aplikasi lain. Sebaliknya, memilih model terdesentralisasi secara tidak terkontrol akan memicu lonjakan biaya infrastruktur secara liar, silo data yang sulit disinkronkan, dan beban kerja pemeliharaan yang melelahkan bagi tim SRE kita.

Dalam panduan ini, kita akan membedah keunggulan dan kekurangan model kluster terpusat vs terdesentralisasi, membahas teknik mengelola multi-tenancy aman di kluster terpusat menggunakan kuota klien (Client Quotas) dan ACL, menyusun matriks pengambilan keputusan, serta menyediakan panduan praktis untuk memilih topologi kluster yang tepat.

Pengantar Model Topologi Kluster Kafka #

Untuk meletakkan konteks yang jelas, mari kita definisikan karakteristik dari kedua model topologi kluster berikut:

1. Kluster Terpusat (Centralized Shared Cluster / Multi-Tenant) #

Dalam model ini, hanya ada satu kluster Kafka raksasa (atau beberapa kluster besar yang dibagi berdasarkan klasifikasi lingkungan seperti Dev, Staging, Prod) yang dikelola oleh satu tim platform pusat. Seluruh tim pengembang (tenants) membagikan log data mereka ke dalam kluster yang sama.

2. Kluster Terdesentralisasi (Decentralized Dedicated Clusters) #

Dalam model ini, setiap divisi, tim mikro, atau proyek memiliki kluster Kafka terdedikasi mereka sendiri yang kecil dan independen. Penggunaan data lintas kluster harus dijembatani menggunakan replikator data eksternal.

Keunggulan & Kekurangan Kluster Terpusat (Centralized) #

Model terpusat menawarkan efisiensi maksimal dengan mengorbankan isolasi mutlak.

Keunggulan: #

• Optimalisasi Biaya (CAPEX & OPEX): Kita hanya perlu membayar biaya overhead mesin controller metadata (KRaft/ZooKeeper) untuk satu kluster. Penggunaan resource server broker (CPU/RAM/Storage) juga jauh lebih efisien karena beban kerja yang fluktuatif dari berbagai aplikasi saling menyeimbangkan satu sama lain.
• Kemudahan Tata Kelola Data (Data Governance): Manajemen keamanan (SSL/SASL), kebijakan audit ACL, skema data terpusat (Schema Registry), dan pemantauan metrik operasional terfokus pada satu tempat, memudahkan kepatuhan terhadap regulasi industri.
• Kemudahan Integrasi Data: Karena seluruh topik data berada di satu kluster, proses konsumsi data lintas departemen dapat dilakukan secara instan tanpa perlu membangun pipa replikasi data tambahan.

Kekurangan: #

• Efek Tetangga Bising (Noisy Neighbor Effect): Sebuah aplikasi produser milik tim A yang mengalami bug loop tak terbatas (infinite loop) dapat membombardir broker dengan jutaan pesan per detik, menghabiskan page cache RAM, menyaturasi kartu jaringan broker, dan memperlambat pemrosesan data milik tim B yang tidak bersalah.
• Blast Radius yang Besar: Jika kluster terpusat mengalami mati total (major outage), seluruh aktivitas bisnis perusahaan akan langsung lumpuh total.
• Kesulitan Kustomisasi: Kita tidak dapat melakukan penalaan (performance tuning) spesifik untuk satu aplikasi tertentu (misalnya ukuran segmen log yang berbeda) jika setelan tersebut mengganggu aplikasi tenant lainnya di broker yang sama.

Keunggulan & Kekurangan Kluster Terdesentralisasi (Decentralized) #

Model terdesentralisasi memprioritaskan keamanan dan kebebasan dengan mengorbankan efisiensi biaya.

Keunggulan: #

• Isolasi Sumber Daya Mutlak: Tidak ada resiko noisy neighbor. Kinerja satu kluster terdedikasi sepenuhnya dikuasai oleh satu aplikasi pemiliknya.
• Blast Radius Minimal: Jika kluster milik tim Payment mati, sistem tracking pengiriman barang milik tim Logistik tetap dapat berjalan $100%$ normal.
• Kebebasan Konfigurasi: Tim pengembang bebas memilih versi Kafka, melakukan upgrade biner secara mandiri, dan menala parameter broker sesuai dengan kebutuhan beban kerja aplikasi mereka sendiri tanpa perlu bernegosiasi dengan tim platform pusat.

Kekurangan: #

• Biaya Infrastruktur Membengkak: Kita harus membayar overhead biaya replikasi dan quorum minimum untuk setiap kluster kecil (ingat batasan $\text{Jumlah Broker} \ge \text{Replication Factor}$). Biaya tagihan server cloud kita akan melambung tinggi.
• Silo Data (Data Silo): Ketika tim Marketing membutuhkan data transaksi dari tim Payment, mereka tidak dapat mengaksesnya secara langsung. Kita harus membangun, memelihara, dan memantau pipa replikasi asinkron (seperti MirrorMaker) lintas kluster, yang menambah kompleksitas arsitektur.
• Beban Operasional Tinggi: Tim SRE harus melakukan pemeliharaan, patching sistem operasi, rotasi sertifikat SSL, dan upgrade versi untuk puluhan kluster independen yang tersebar.

Implementasi Multi-Tenancy Aman di Kluster Terpusat #

Jika kita memutuskan untuk memilih model Kluster Terpusat demi menghemat biaya operasional, kita wajib mengonfigurasi fitur-fitur pengaman multi-tenancy berikut untuk mencegah terjadinya bencana noisy neighbor dan kebocoran data.

1. Standardisasi Penamaan Topik (Namespaces) #

Kita harus melarang pembuatan topik secara acak tanpa aturan. Terapkan konvensi penamaan topik berbasis namespace yang mencerminkan nama departemen atau aplikasi: [departemen].[lingkungan].[nama-aplikasi].[nama-topik]

Contoh: finance.prod.payment-service.orders logistics.staging.tracking.driver-location

Gunakan properti broker auto.create.topics.enable=false untuk mencegah klien membuat topik secara otomatis di luar standar penamaan ini.

2. Penerapan Kuota Klien (Client Quotas) untuk Membatasi Throughput #

Untuk mengisolasi pemakaian kartu jaringan broker dari dominasi satu tenant nakal, kita wajib menyetel Client Quotas. Kuota ini membatasi laju transfer data (dalam satuan byte per detik) untuk setiap Principal (User SSL/SASL) atau Client ID tertentu.

Jalankan perintah CLI berikut untuk membatasi laju tulis produser tim A maksimal sebesar $10 \text{ MB/s}$ dan laju baca konsumen maksimal sebesar $20 \text{ MB/s}$ pada broker:

kafka-configs.sh --bootstrap-server localhost:9092 \
  --command-config /etc/kafka/client.properties \
  --alter \
  --entity-type users \
  --entity-name User:CN=tenant-a-app,O=MyCorp \
  --add-config producer_byte_rate=10485760,consumer_byte_rate=20971520

Cara Kerja Kuota di Kafka: #

Jika produser tim A mencoba mengirim data melebihi $10 \text{ MB/s}$, broker tidak akan menolak koneksi klien secara kasar (reject request). Sebaliknya, broker akan menghitung berapa lama waktu tunda yang dibutuhkan untuk menormalkan laju data kembali ke batas kuota, lalu sengaja menahan respon jabat tangan TCP (injecting delay / throttling) ke produser tersebut sebelum mengirimkan konfirmasi sukses. Teknik penundaan ini secara alami akan memperlambat laju thread produser di aplikasi klien tanpa memicu crash.

Secara teknis, Kafka menggunakan algoritma Sliding Window dengan metrik token bucket untuk menghitung throughput rata-rata dalam jendela waktu tertentu (biasanya disetel via quota.window.num=11 dan quota.window.size.seconds=1). Ketika batas terlampaui, broker akan menahan respons di dalam DelayQueue internal broker selama durasi penalti (misalnya $450 \text{ ms}$) sebelum melepaskannya kembali ke thread network client. Hal ini menaikkan latensi respons di sisi produser secara terukur, memicu mekanisme backpressure alami pada library producer client.

3. Kuota Komputasi dan Jaringan Tingkat Lanjut #

Selain batasan byte rate, kluster terpusat skala besar juga harus menerapkan kuota komputasi dan batas pembuatan koneksi untuk mengantisipasi serangan denial-of-service (DoS) tidak sengaja:

• request_percentage: Batasan persentase waktu thread I/O (num.io.threads) dan thread network (num.network.threads) yang boleh dikonsumsi oleh satu user (misalnya disetel request_percentage=20). Ini mencegah klien mengirim kueri metadata dalam loop cepat yang dapat memacetkan request handler.
• connection_creation_rate: Membatasi jumlah pembuatan koneksi TCP baru per detik dari satu alamat IP tertentu (misalnya disetel maksimal 50 koneksi per detik) untuk mengamankan broker dari kehabisan file descriptor akibat serangan botnet atau bug rekoneksi aplikasi klien.

# Batasi laju pembuatan koneksi TCP dari IP tertentu secara dinamis
kafka-configs.sh --bootstrap-server localhost:9092 \
  --command-config /etc/kafka/client.properties \
  --alter \
  --entity-type ips \
  --entity-name 10.120.4.52 \
  --add-config connection_creation_rate=50

4. Penegakan Kepatuhan Skema (Schema Registry Governance) #

Pada kluster terpusat, jika satu produser mengubah struktur data payload tanpa berkoordinasi, seluruh aplikasi konsumen milik tenant lain yang membaca topik tersebut akan mengalami crash akibat kesalahan parsing (deserialization errors).

• Tindakan: Wajib integrasikan Schema Registry (seperti Confluent Schema Registry).
• Kebijakan Kompatibilitas: Setel tingkat kompatibilitas ke BACKWARD atau FULL. Ini memastikan produser hanya dapat mendaftarkan skema versi baru jika skema tersebut aman dibaca oleh konsumen yang masih menggunakan kode versi lama, menjaga kelancaran operasi data terpusat.

Berikut adalah tabel matriks kompatibilitas Schema Registry yang wajib dipahami oleh tim platform kita untuk menentukan aturan evolusi skema:

5. Pengamanan Hak Akses Menggunakan ACL Ketat dan Autentikasi SASL #

Jangan biarkan satu tenant membaca data dari topik tenant lain secara bebas. Terapkan arsitektur keamanan Zero-Trust dengan membatasi hak akses tulis (Write) dan baca (Read) menggunakan kebijakan ACL Kafka berbasis sertifikat SSL (SSL Principal) atau akun SASL/SCRAM.

Pertama, kita harus mengonfigurasi autentikasi JAAS untuk pengguna SASL/SCRAM di broker. Tambahkan baris berikut ke file konfigurasi JAAS broker (/etc/kafka/kafka_server_jaas.conf):

KafkaServer {
    org.apache.kafka.common.security.scram.ScramLoginModule required
    username="admin"
    password="admin-secret-password"
    user_admin="admin-secret-password"
    user_tenant_a="tenant-a-secret-pass"
    user_tenant_b="tenant-b-secret-pass";
};

Selanjutnya, jalankan perintah CLI berikut untuk mengaktifkan ACL yang membatasi hak akses baca/tulis topik antar tenant:

# Berikan akses Tulis hanya untuk produser Finance ke topiknya sendiri
kafka-acls.sh --bootstrap-server localhost:9092 \
  --command-config /etc/kafka/client.properties \
  --add \
  --allow-principal User:tenant_a \
  --operation Write \
  --topic finance.prod.

Untuk melengkapi pengamanan, kita juga wajib mengaktifkan parameter authorizer.class.name=kafka.security.authorizer.AclAuthorizer di dalam file server.properties masing-masing broker. Secara default, jika parameter ini aktif, broker akan menolak semua akses dari klien (deny by default) kecuali jika akses tersebut telah diizinkan secara eksplisit melalui ACL.

Metrik Pemantauan Utama dalam Multi-Tenancy #

Saat mengelola kluster terpusat yang dihuni oleh banyak tenant, mendeteksi tenant mana yang membebani sistem secara berlebih adalah kunci utama untuk menjaga stabilitas operasional. Kita wajib mengumpulkan metrik JMX berikut melalui agen Prometheus/Jolokia di broker kita:

1. Metrik Throttling Kuota (Client Throttle Time) #

Metrik ini menunjukkan durasi penalti (dalam milidetik) yang diberikan broker kepada klien karena melanggar batas byte rate.

• Nama MBean (Producer): kafka.server:type=Produce,user={user},client-id={client-id}
• Atribut: throttle-time-average dan throttle-time-max
• Tindakan Alert: Jika nilai rata-rata throttle-time di atas $0 \text{ ms}$, tenant tersebut secara aktif dibatasi. SRE harus bersiap jika pengembang mengeluhkan kenaikan latensi aplikasi mereka.

2. Metrik Penggunaan CPU Thread (Request Percentage Quota) #

Menunjukkan persentase waktu thread I/O broker yang dihabiskan untuk melayani permintaan dari pengguna tertentu.

• Nama MBean: kafka.server:type=Request,user={user},client-id={client-id}
• Atribut: request-time-fraction
• Tindakan Alert: Jika sebuah user mengonsumsi request-time-fraction lebih dari $0.20$ ($20%$), batasi aktivitas user tersebut atau minta mereka mengoptimalkan pengiriman batching (misalnya menaikkan batch.size dan linger.ms pada producer).

3. Metrik Pembuatan Koneksi (Connection Creation Rate) #

Memonitor laju koneksi TCP baru per detik yang dibuat oleh klien untuk mendeteksi bug koneksi bocor (connection leak).

• Nama MBean: kafka.server:type=SocketServer,name=ConnectionCreationRate
• Atribut: MeanRate dan OneMinuteRate
• Tindakan Alert: Kenaikan tajam di atas 100 koneksi baru per detik pada satu broker menunjukkan aplikasi klien mengalami loop gagal-koneksi dan terus mencoba membuat socket TCP baru, yang berisiko menghabiskan kapasitas file descriptor server OS broker.

Perbandingan Topologi Logis Centralized vs Decentralized #

Berikut adalah visualisasi perbedaan antara struktur data dan akses pada model kluster terpusat berbagi vs kluster terdesentralisasi terdedikasi:

flowchart TD
    subgraph Centralized ["MODEL KLUSTER TERPUSAT (Multi-Tenant)"]
        direction TB
        subgraph SharedCluster ["Kluster Kafka Terpusat Raksasa"]
            TopicA["Topik: tenant-a.orders"]
            TopicB["Topik: tenant-b.orders"]
        end
        ClientA1["Produser A"] -->|Quota Tulis 10MB/s| TopicA
        ClientB1["Produser B"] -->|Quota Tulis 5MB/s| TopicB
        ClientA2["Konsumen A"] -->|Akses Terbatas ACL| TopicA
        ClientB2["Konsumen B"] -->|Akses Terbatas ACL| TopicB
    end

    subgraph Decentralized ["MODEL KLUSTER TERDESENTRALISASI (Dedicated)"]
        direction TB
        subgraph ClusterA ["Kluster Kafka A (Divisi A)"]
            TopicA_Ded["Topik: orders"]
        end
        subgraph ClusterB ["Kluster Kafka B (Divisi B)"]
            TopicB_Ded["Topik: orders"]
        end
        ClientA_Ded["Produser & Konsumen A"] <--> ClusterA
        ClientB_Ded["Produser & Konsumen B"] <--> ClusterB
        
        ClusterA -.->|"Pipa Replikasi Data (MirrorMaker 2.0)"| ClusterB
    end

Matriks Pengambilan Keputusan: Memilih yang Tepat #

Gunakan tabel matriks evaluasi di bawah ini untuk memandu organisasi kita dalam memilih model topologi kluster yang paling cocok dengan kondisi riil bisnis:

Checklist Audit Pemilihan Model Topologi Kluster #

Lakukan langkah audit berikut untuk memverifikasi bahwa model kluster yang kita jalankan saat ini telah dilengkapi dengan instrumen tata kelola yang memadai:

Ringkasan #

• Bagi Beban dengan Terpusat — Pilih model kluster terpusat jika prioritas utama organisasi adalah efisiensi biaya infrastruktur dan kemudahan tata kelola data satu pintu.
• Isolasi dengan Terdesentralisasi — Pilih model kluster terdesentralisasi terdedikasi untuk kebutuhan sistem dengan tingkat kepatuhan keamanan tinggi (seperti regulasi bank) atau blast radius kritis.
• Terapkan Kuota Klien — Cegah bencana noisy neighbor pada kluster terpusat dengan mengonfigurasi batasan producer_byte_rate dan consumer_byte_rate untuk setiap tenant.
• Kunci Akses via ACL — Terapkan arsitektur keamanan zero-trust menggunakan otorisasi ACL yang ketat untuk mengisolasi hak akses baca-tulis topik antar departemen.

← Sebelumnya: Rolling Upgrade & Maintenance   Berikutnya: Multi-Cluster Strategy & MirrorMaker →