Connector Anti-Pattern #

Mengadopsi Apache Kafka Connect sebagai jembatan integrasi data memang menjanjikan kemudahan operasional karena pendekatan yang berbasis konfigurasi deklaratif tanpa penulisan kode. Namun, kemudahan ini sering kali membuat tim pengembang dan administrator sistem lengah terhadap aturan arsitektur terdistribusi yang mendasarinya. Di lingkungan produksi riil, kesalahan konfigurasi kecil atau penyalahgunaan fitur Connect dapat mengakibatkan pemborosan resource CPU/Memory, kebocoran data, downtime pipa data secara masif, hingga rusaknya konsistensi sistem basis data. Untuk menghindarkan kita dari kegagalan operasional tersebut, kita perlu mengenali pola-pola kesalahan umum yang sering terjadi di industri. Artikel ini akan membedah secara kritis sembilan kesalahan fatal (connector anti-patterns) dalam merancang dan mengoperasikan Kafka Connect di lingkungan produksi, memberikan solusi perbaikannya, serta menyajikan checklist kesiapan produksi (production readiness checklist) yang komprehensif.

1. Mengembangkan Producer/Consumer Kustom untuk Skenario Integrasi Standar (Re-inventing the Wheel) #

Banyak organisasi yang baru mengadopsi Apache Kafka terburu-buru menulis aplikasi produser dan konsumen kustom (misalnya menggunakan Java SDK, Go, atau Python) hanya untuk menyalin tabel database PostgreSQL ke Kafka, atau memindahkan event Kafka ke AWS S3.

Mengapa Ini Merupakan Anti-Pattern? Menulis kode kustom untuk kasus integrasi standar berarti kita harus memikirkan sendiri logika pengelolaan offset sumber, penanganan error koneksi jaringan transien, penyeimbangan beban paralel (load balancing), cluster failover, dan instrumentasi metrik. Kode ini rentan terhadap bug, sulit dirawat lintas tim, dan membuang-buang waktu pengembangan yang berharga.
Solusi yang Benar: Selalu periksa direktori Confluent Hub sebelum menulis kode integrasi apa pun. Lebih dari 90% sistem penyimpanan populer (PostgreSQL, MySQL, S3, Elasticsearch, Redis, Snowflake, dll.) sudah memiliki connector siap pakai yang dikembangkan secara profesional dan teruji keandalannya. Manfaatkan framework Kafka Connect untuk menghemat waktu dan menjamin keandalan pipeline data.

2. Menyetel tasks.max Melebihi Jumlah Partisi Input pada Sink Connector (Idle Tasks) #

Dalam upaya meningkatkan kecepatan pemrosesan data (throughput), beberapa administrator kluster secara agresif menyetel nilai "tasks.max" ke angka yang sangat tinggi pada Sink Connector.

// ANTI-PATTERN: Menyetel tasks.max = 10 untuk membaca topik berpartisi 4
{
  "name": "elasticsearch-sink",
  "config": {
    "tasks.max": "10",
    "topics": "orders-topic" // Topik ini hanya memiliki 4 partisi di Kafka
  }
}

Mengapa Ini Merupakan Anti-Pattern? Pada Sink Connector, satu partisi topik Kafka hanya dapat dikonsumsi oleh satu task Connect dalam satu waktu. Jika kita menyetel tasks.max=10 pada topik yang hanya memiliki 4 partisi, kluster Connect akan membuat 10 instansi task thread, namun 6 task di antaranya akan berstatus IDLE (menganggur) secara permanen. Hal ini membuang resource memori heap JVM, mengotori log sistem, dan menambah overhead monitoring kluster tanpa memberikan peningkatan performa sedikit pun.
Solusi yang Benar: Selalu koordinasikan setelan tasks.max dengan jumlah partisi topik Kafka yang dibaca. Jika ingin meningkatkan paralelisme pembacaan Sink Connector, kita harus terlebih dahulu meningkatkan jumlah partisi di sisi broker Kafka (misalnya meningkatkan partisi dari 4 menjadi 12), lalu menyetel tasks.max ke angka 12.

3. Membiarkan Kebijakan Pembersihan Topik Internal Connect Dihapus (connect-configs/offsets/status Cleanup Policy) #

Secara default, saat pertama kali distributed worker Connect menyala, worker akan mencoba membuat tiga topik internal: connect-configs, connect-offsets, dan connect-status. Namun, terkadang kebijakan pembuatan otomatis ini dimatikan, dan administrator membuat topik tersebut secara manual dengan konfigurasi default broker.

Mengapa Ini Merupakan Anti-Pattern? Jika topik internal dibuat dengan konfigurasi default broker yang memiliki kebijakan pembersihan berbasis waktu (cleanup.policy=delete dengan retensi 7 hari), maka Kafka akan secara otomatis menghapus pesan-pesan lama setelah lewat 7 hari. Ketika data konfigurasi connector di connect-configs terhapus, kluster Connect akan kehilangan seluruh informasi connector terdaftar. Ketika data offset di connect-offsets terhapus, seluruh Source Connector akan mulai membaca data sistem sumber dari awal lagi (data duplication).
Solusi yang Benar: Ketiga topik internal Kafka Connect wajib dibuat dengan kebijakan pembersihan berbasis kompresi log (cleanup.policy=compact). Hal ini menjamin bahwa Kafka tidak akan pernah menghapus data status dan koordinat offset terakhir, melainkan hanya memadatkan log untuk mempertahankan record terbaru per kunci.

4. Melakukan Pemrosesan Data Berat di Single Message Transforms (SMT) (Heavy ETL inside SMT) #

Single Message Transforms (SMT) adalah fitur yang sangat praktis untuk mengubah bentuk data secara cepat saat transit di memori worker. Namun, kemudahan ini sering disalahgunakan untuk melakukan manipulasi data yang kompleks.

Mengapa Ini Merupakan Anti-Pattern? SMT dijalankan secara sinkron di dalam utas tunggal (single thread) eksekusi task. Jika kita menggunakan SMT untuk menjalankan query SQL tambahan ke database eksternal untuk memperkaya data (data enrichment), melakukan enkripsi kriptografi tingkat tinggi, atau melakukan panggilan REST API eksternal, latensi per pesan akan melonjak. Pipa data akan mengalami kemacetan parah, memicu detak jantung task terlambat (heartbeat timeout), dan menyebabkan instansi worker Connect terus-menerus mengalami crash dan rebalancing.
Solusi yang Benar: Gunakan SMT hanya untuk modifikasi ringan baris-tunggal yang bersifat stateless (seperti me-rename field, menyembunyikan kolom, atau menyisipkan metadata timestamp). Jika kita membutuhkan operasi penggabungan data (join), kueri eksternal, atau kalkulasi bisnis yang berat, lakukan hal tersebut di layer pemrosesan aliran data terpisah menggunakan Kafka Streams atau Apache Flink setelah data mendarat di Kafka.

5. Menjalankan Mode Standalone di Lingkungan Produksi Kritis (Standalone Mode in Production) #

Beberapa tim pengembang tetap mempertahankan deployment Standalone Mode yang mereka gunakan selama masa pengembangan lokal ketika sistem dipindahkan ke lingkungan produksi utama.

Mengapa Ini Merupakan Anti-Pattern? Standalone Mode berjalan di dalam satu proses JVM tunggal. Mode ini tidak memiliki High Availability (HA) dan kemampuan failover otomatis. Jika VM tempat standalone worker Connect berjalan mati atau mengalami error JVM, seluruh aliran data integrasi akan lumpuh total sampai ada administrator yang masuk secara manual ke server untuk menyalakan ulang service.
Solusi yang Benar: Selalu gunakan Distributed Mode untuk lingkungan produksi, dengan mendeploy minimal 2 atau 3 worker node yang tersebar di beberapa Availability Zone berbeda. Hal ini menjamin ketersediaan tinggi di mana tugas-tugas dapat berpindah secara otomatis jika ada salah satu node yang mengalami crash.

6. Mengabaikan Setelan Kompatibilitas Skema (Schema Incompatibility) #

Ketika menggunakan Schema Registry untuk mengelola validasi tipe data biner, pengembang sering kali langsung mengubah tipe data kolom di database sumber (misalnya dari INT menjadi VARCHAR) tanpa memikirkan dampaknya terhadap konsumen hilir.

Mengapa Ini Merupakan Anti-Pattern? Modifikasi kolom secara langsung tanpa aturan kompatibilitas skema yang ketat akan membuat Debezium CDC Connector mengirimkan skema baru yang melanggar aturan kompatibilitas di Schema Registry. Akibatnya, registrasi skema ditolak, dan task Connect akan langsung masuk ke status FAILED secara permanen, menghentikan seluruh pipa data.
Solusi yang Benar: Terapkan aturan kompatibilitas skema BACKWARD atau FULL pada Schema Registry. Jika ingin mengubah tipe data kolom database secara drastis, lakukan proses migrasi bertahap (tambahkan kolom baru, migrasikan data secara perlahan, lalu hapus kolom lama secara aman setelah konsumen di-upgrade).

7. Tidak Mengaktifkan Dead Letter Queue (DLQ) pada Sink Connector (DLQ Negligence) #

Mencegah task Sink agar tidak mudah crash saat menjumpai pesan rusak sering kali dilakukan dengan menyetel properti errors.tolerance=all.

Mengapa Ini Merupakan Anti-Pattern? Penyetelan errors.tolerance=all tanpa mendefinisikan topik Dead Letter Queue (DLQ) akan membuat worker Connect membuang pesan rusak tersebut ke tempat sampah secara diam-diam. Kita tidak akan pernah tahu bahwa ada pesan yang hilang dari pipeline, yang baru disadari berbulan-bulan kemudian saat audit data lake menunjukkan ketidakcocokan angka laporan transaksi.
Solusi yang Benar: Selalu kombinasikan "errors.tolerance": "all" dengan mendefinisikan topik DLQ melalui properti "errors.deadletterqueue.topic.name". Aktifkan juga header context agar penyebab kesalahan tercatat rapi untuk kebutuhan debugging.

8. Menghapus Data CDC (Hard-Delete) Tanpa Mengirimkan Tombstone Record #

Saat mengoperasikan Source CDC (Debezium), kita sering melakukan pembersihan data lama di database sumber menggunakan perintah SQL DELETE.

Mengapa Ini Merupakan Anti-Pattern? Secara default, jika terjadi penghapusan baris data di RDBMS, Debezium akan memancarkan sebuah record ke Kafka dengan nilai metadata op: d. Tepat setelah record tersebut, Debezium memancarkan pesan kosong kedua bernilai null dengan key yang sama. Pesan null kedua ini disebut Tombstone Record. Tombstone sangat penting bagi konsumen hilir (seperti topik Kafka dengan cleanup policy compact, atau database target yang terkompresi) sebagai sinyal untuk menghapus kunci tersebut dari memori fisik. Jika kita menonaktifkan tombstone (tombstones.on.delete=false), ruang disk di sistem hilir akan terus membengkak karena data lama yang sudah terhapus di database utama tidak pernah dibersihkan di Kafka.
Solusi yang Benar: Selalu biarkan setelan default "tombstones.on.delete": "true" aktif pada konfigurasi Debezium. Pastikan juga sistem konsumen hilir kita dirancang untuk menangani pesan bernilai null tanpa memicu NullPointerException.

9. Menempatkan File JAR Plugin di dalam Java Classpath Global (Dependency Hell) #

Saat menginstal custom connector baru di server Connect, beberapa administrator meletakkan file JAR plugin di folder library bawaan instalasi Kafka (/opt/kafka/libs/) atau menggabungkannya ke dalam variabel lingkungan CLASSPATH sistem global.

Mengapa Ini Merupakan Anti-Pattern? Menaruh semua file JAR connector di classpath global JVM akan memicu Dependency Hell (Tabrakan Library). Dua connector yang berbeda sering kali membutuhkan versi pustaka pihak ketiga yang berbeda (misalnya, Connector A butuh guava-20.0.jar sedangkan Connector B butuh guava-32.0.jar). Ketika ditaruh di classpath global, JVM hanya akan memuat salah satu versi, menyebabkan salah satu connector crash saat runtime karena kegagalan pemanggilan metode (java.lang.NoSuchMethodError).
Solusi yang Benar: Manfaatkan fitur isolasi classloader bawaan Kafka Connect menggunakan parameter plugin.path. Kita harus menempatkan setiap connector di dalam folder subdirektori tersendiri yang terisolasi di bawah path plugin:

/opt/connectors/
  ├── debezium-connector-postgres/
  │     ├── debezium-core-2.1.jar
  │     └── postgresql-42.5.jar
  └── confluent-connector-s3/
        ├── connect-s3-10.3.jar
        └── aws-java-sdk-s3-1.12.jar

Di properti worker, kita cukup mendefinisikan folder induknya: plugin.path=/opt/connectors

Setiap connector akan dimuat di dalam Classloader-nya sendiri secara terisolasi tanpa ada risiko tabrakan library.

Checklist Review Kesiapan Produksi (Production Readiness Checklist) #

Sebelum mendeploy connector baru ke lingkungan produksi utama, gunakan checklist di bawah ini untuk memverifikasi keamanan dan keandalannya:

Kategori 1: Infrastruktur & Cluster Worker #

Worker Connect dideploy dalam Distributed Mode dengan minimal 2 instance di Availability Zone berbeda.
Alokasi Heap Memory worker JVM disetel minimal 4 GB dengan opsi -XX:+UseG1GC aktif.
Subnet kluster Connect diisolasi dan port HTTP REST API 8083 diamankan dari akses publik luar.
Worker disetel pada AZ yang sama dengan database sumber untuk meminimalkan biaya Cross-AZ egress.

Kategori 2: Konfigurasi Connector #

Parameter tasks.max untuk Sink Connector disetel sesuai dengan jumlah partisi topik Kafka.
Connector Source CDC (Debezium) disetel dengan tasks.max=1 secara eksplisit untuk mencegah overhead.
Seluruh password database dan API Key dienkripsi dan dipanggil menggunakan placeholder Config Providers (seperti FileConfigProvider atau Vault).
SMT hanya melakukan operasi stateless ringan; tidak ada panggilan I/O jaringan di dalam transformasi.

Kategori 3: Topik Internal & Validasi Skema #

Ketiga topik internal (connect-configs, connect-offsets, connect-status) dibuat dengan replication.factor=3 dan min.insync.replicas=2.
Topik internal connect-configs dikonfigurasi dengan tepat 1 partisi.
Ketiga topik internal menggunakan kebijakan pembersihan cleanup.policy=compact.
Validasi data menggunakan Avro/Protobuf dengan Schema Registry aktif menggunakan kompatibilitas BACKWARD.

Kategori 4: Error Handling & Observability #

Sink Connector dikonfigurasi dengan Dead Letter Queue (DLQ) dan properti context.headers.enable=true aktif.
Setelan errors.retry.timeout disetel minimal 3-5 menit untuk menangani kegagalan jaringan transien.
Pemantauan metrik JMX put-batch-time-ms, poll-batch-time-ms, dan total-record-errors telah terhubung ke Prometheus/Grafana.
Script auto-recovery aktif untuk menyalakan ulang task failed secara otomatis jika terjadi error jaringan singkat.

Ringkasan #

Re-inventing the Wheel — Selalu gunakan connector standar industri yang tertera di Confluent Hub dibanding menulis kode produser/konsumen kustom untuk kasus integrasi database/storage standar.

Tuning tasks.max — Jumlah Sink task yang aktif dibatasi secara fisik oleh jumlah partisi topik Kafka. Menyetel tasks.max melebihi partisi hanya akan membuang memori JVM secara sia-sia.

Topik Internal Compacted — Pastikan tiga topik internal distributed Connect (configs, offsets, status) menggunakan kebijakan cleanup.policy=compact agar data konfigurasi tidak hilang setelah lewat masa retensi default.

Isolasi Classloader — Gunakan setelan plugin.path dengan menempatkan setiap connector di subdirektori tersendiri untuk mencegah tabrakan versi library (dependency hell) pada JVM.

Isolasi Cluster — Hindari menyatukan seluruh connector ke dalam satu cluster Connect raksasa. Isolasi kluster berdasarkan karakteristik workload (CDC Source vs Bulk Sink) untuk mencegah rebalance storm.

← Sebelumnya: Error Handling & DLQ Berikutnya: What is Kafka Streams →