Bagaimana cara Kafka Streams bermigrasi ke protokol rebalance berbasis broker?

Konteks dan cakupan

Anda mengelola aplikasi Kafka Streams stateful yang menggunakan protokol grup klasik. Setelah melakukan upgrade ke Kafka 4.2, tim ingin beralih ke Streams Rebalance Protocol berbasis broker untuk mengurangi jeda koordinasi global saat instans bergabung, keluar, atau mengalami kegagalan. Pewawancara meminta rencana migrasi, batasan kompatibilitas, dan prosedur rollback.

Asumsikan versi Kafka Streams 4.2.x, topik changelog dan repartition yang sudah ada, serta tidak ada rebuild state penuh yang tidak direncanakan. Panduan resmi menyatakan bahwa protokol baru ini secara kontinu menghitung assignment tugas pada broker dan menggunakan streams group khusus. Kluster Kafka 4.2 baru mengaktifkan fitur ini secara default, tetapi klien tetap harus menyetel group.protocol=streams.

Apa yang dinilai oleh pewawancara

Apakah Anda menjelaskan bagaimana koordinasi berbasis broker menghapus global barrier di sisi klien alih-alih hanya sekadar menghafal pengaturan konfigurasi.
Apakah Anda memisahkan skenario streams group baru, upgrade online dari grup klasik, dan migrasi offline yang didukung.
Apakah Anda memeriksa versi broker dan klien serta risiko KAFKA-20254 pada versi 4.2.0.
Apakah Anda memahami bahwa offset yang sudah di-commit dipertahankan sementara metadata grup lainnya dibangun ulang.
Apakah Anda mengubah ketiadaan static membership, pembaruan topologi, dan dukungan regex menjadi kriteria rilis (release gates).

Jawaban yang lemah akan mengatakan "ubah pengaturannya lalu lakukan rolling update." Jawaban yang kuat akan menginventarisasi kesenjangan versi dan fitur, memilih grup baru atau migrasi pada jendela pemeliharaan (maintenance window), serta mencatat offset, topik changelog, topik repartition, dan target pemulihan (recovery objectives).

Klarifikasi sebelum menjawab

Apakah Kafka dan klien Streams keduanya minimal versi 4.2? Jika tidak, protokol lengkap tidak dapat diaktifkan dengan aman.
Apakah aplikasi bergantung pada static membership, pembaruan topologi online, langganan regex, atau assignment standby/rack-aware? Ketergantungan apa pun dapat menghalangi migrasi.
Bisakah setiap instans dihentikan hingga grup menjadi kosong? Jalur resmi 4.2 hanya mendukung migrasi offline.
Apakah versinya 4.2.0 atau 4.2.1 ke atas? Versi 4.2.0 memiliki bug broker yang diketahui pada migrasi offline, yang telah diperbaiki di 4.2.1.
Bisakah application.id baru digunakan? Grup baru mengisolasi risiko tetapi akan membangun ulang state dan mengubah manajemen offset.

Jawaban-jawaban ini menentukan rencana: jika downtime tidak memungkinkan, jangan mengklaim migrasi online; jika fitur yang belum didukung sangat dibutuhkan, tetaplah gunakan protokol klasik atau lakukan refactoring terlebih dahulu.

Kerangka jawaban 30 detik

"Pertama-tama saya memverifikasi bahwa broker dan klien berada pada versi 4.2.x dan menginventarisasi fitur-fitur yang tidak didukung oleh protokol baru. Streams Rebalance Protocol memindahkan koordinasi tugas ke broker dan menghapus global barrier di sisi klien, tetapi migrasinya bukanlah rolling deployment biasa. Jalur yang terdokumentasi mengharuskan pengosongan grup, menyetel group.protocol=streams, lalu menyalakan instans kembali. Hanya offset yang sudah di-commit yang dipertahankan; topik changelog dan repartition tetap ada, sementara metadata grup lainnya dibangun ulang. Saya akan menghindari 4.2.0 dan menggunakan 4.2.1 atau lebih baru, mencatat offset serta checkpoint state, memverifikasi pemulihan, latensi, dan metrik rebalance, lalu melakukan rollback ke klasik atau membangun ulang dengan application ID baru jika pemeriksaan gagal."

Solusi langkah demi langkah

1. Jelaskan apa yang berubah

Grup Streams klasik menghitung assignment tugas anggota pada sisi klien, yang dapat menciptakan titik koordinasi global selama terjadinya perubahan keanggotaan. Protokol baru menyimpan metadata streams-group dan assignment tugas pada broker; aplikasi berkoordinasi melalui heartbeat khusus dan streams group. Panduan resmi mendeskripsikan pendekatan ini sebagai berbasis broker dan menyediakan state streams-group serta Admin API yang terpisah.

2. Inventarisasi kesenjangan kapabilitas

Kafka 4.2 mendokumentasikan batasan yang jelas: static membership belum tersedia; pembaruan topologi yang signifikan memerlukan streams group baru; hanya sticky task assignor yang didukung, sehingga warmup tasks dan rack-aware assignment tidak tersedia; langganan berbasis pattern (regex) tidak didukung; dan migrasi online antara grup klasik dan streams group belum tersedia. Cantumkan hal-hal ini pada checklist rilis sebelum mengubah protokol.

3. Pilih jalur migrasi

Jalur offline yang terdokumentasi adalah: hentikan setiap instans, tunggu hingga session.timeout.ms atau keluar secara eksplisit agar grup menjadi kosong, setel group.protocol=streams, lalu mulai instans kembali. Hanya offset yang telah di-commit yang dipertahankan pada broker. Topik changelog dan repartition tetap menjadi topik internal biasa; metadata grup lainnya dibangun ulang.

text

Stop all instances
      ↓
Confirm an empty streams group and record committed offsets
      ↓
Upgrade brokers and clients to a compatible version
      ↓
Set group.protocol=streams
      ↓
Start instances and observe recovery and rebalance metrics

Jika jendela pemeliharaan tidak dapat diterima, pertahankan protokol klasik atau gunakan application.id baru untuk validasi shadow. Jangan menerapkan asumsi rolling-upgrade dari consumer klasik ke Streams Rebalance Protocol.

4. Tangani risiko versi

Panduan upgrade Kafka memperingatkan bahwa migrasi offline dari klasik ke streams pada versi 4.2.0 terdampak oleh bug broker KAFKA-20254 dan tidak merekomendasikannya. Perbaikannya ada pada 4.2.1. Dalam wawancara, tetapkan 4.2.1 sebagai versi migrasi minimum alih-alih hanya mengatakan bahwa "Kafka 4.2 mendukungnya."

5. Rancang pemeriksaan state dan offset

Sebelum migrasi, catat offset yang telah di-commit untuk setiap topik input, status changelog, dan latensi pemrosesan. Setelah migrasi, verifikasi bahwa grup baru melanjutkan dari offset yang diharapkan, state store berhasil dipulihkan dari changelog, topik repartition masih ada dengan jumlah partisi yang sama, serta duplikasi atau hilangnya record sesuai dengan semantik pemrosesan yang disepakati. Bandingkan dengan baseline sebelum migrasi alih-alih hanya memeriksa apakah proses berhasil menyala.

6. Pantau dan lakukan rollback

Gunakan state streams-group, jumlah/laju rebalance, durasi pemulihan, latensi pemrosesan, dan tingkat kesalahan (error rate) sebagai permukaan observasi. Jika pemulihan mengalami timeout atau pemeriksaan hasil gagal, hentikan grup baru, pertahankan offset dan log, lalu kembalikan konfigurasi ke klasik. Jika grup klasik telah dikosongkan sebelumnya, pemulihan memerlukan cadangan (backup) atau application ID baru; metadata grup tidak akan kembali secara otomatis.

Contoh jawaban berkualitas tinggi

"Saya tidak akan memperlakukan ini sebagai rolling release biasa. Pertama, saya memverifikasi broker dan klien 4.2.x serta memeriksa keberadaan static membership, pembaruan topologi online, langganan regex, warmup, atau rack-aware assignment. Karena jalur resminya adalah offline, saya memilih 4.2.1 atau lebih baru, menghentikan setiap instans dalam jendela pemeliharaan, mengonfirmasi status grup kosong, mencatat offset yang telah di-commit dan checkpoint state-store, lalu menyetel group.protocol=streams.

"Setelah perubahan, saya memverifikasi bahwa offset berlanjut, changelog memulihkan state store, topik repartition tetap ada, serta state streams-group, metrik rebalance, waktu pemulihan, dan latensi bisnis dalam kondisi sehat. Hanya offset yang telah di-commit yang dipertahankan; metadata grup lainnya dibangun ulang. Versi 4.2.0 membawa risiko KAFKA-20254, sehingga saya tidak menganggapnya sebagai versi migrasi yang aman. Jika validasi gagal, saya menghentikan grup baru, kembali ke klasik, atau membangun ulang dengan application ID baru dan menyimpan bukti log untuk evaluasi."

Kesalahan umum

Kesalahan: memperlakukan group.protocol=streams sebagai peralihan bertahap (rolling switch) → Penyebab kegagalan: migrasi online tidak didukung → Solusi: jadwalkan jendela pemeliharaan dengan kondisi grup kosong.
Kesalahan: melakukan migrasi pada 4.2.0 → Penyebab kegagalan: panduan upgrade resmi mencatat KAFKA-20254 → Solusi: gunakan 4.2.1 atau lebih baru yang telah menyertakan perbaikan.
Kesalahan: menjanjikan bahwa setiap state grup akan dipertahankan → Penyebab kegagalan: hanya offset yang telah di-commit yang tersisa dan metadata lainnya dibangun ulang → Solusi: buat prosedur terpisah untuk memeriksa offset, state-store, dan topik.
Kesalahan: mengabaikan static membership atau pembaruan topologi → Penyebab kegagalan: protokol baru belum mendukungnya → Solusi: inventarisasi fitur dan tetap gunakan protokol klasik jika diperlukan.

Pertanyaan lanjutan dan tanggapan

Bisnis tidak boleh berhenti. Bisakah dua batch instans beralih secara bertahap?

Jangan mendeskripsikan skenario tersebut sebagai migrasi Streams yang terdokumentasi. Jika downtime tidak memungkinkan, tetap gunakan klasik atau buat application ID baru untuk validasi shadow, lalu biarkan lapisan bisnis menanggung beban pembuatan ulang state saat proses cutover.

Mengapa harus memvalidasi state store jika offset yang di-commit tetap bertahan?

Offset hanya menunjukkan di mana pembacaan berikutnya dimulai, bukan memastikan bahwa state lokal sudah lengkap. Pemutaran ulang changelog, ketidakcocokan, atau kegagalan pemrosesan dapat membuat state store tidak konsisten dengan offset, sehingga validasi state dan hasil bisnis tetap wajib dilakukan.

Versi 4.2.0 sudah berstatus GA. Mengapa harus dihindari?

Status GA menandakan bahwa fitur telah dirilis secara umum, bukan berarti setiap jalur migrasi bebas dari cacat yang diketahui. Panduan resmi mengidentifikasi KAFKA-20254 pada migrasi offline dan menyebutkan bahwa masalah tersebut telah diperbaiki di 4.2.1; pilihlah versi yang sudah diperbaiki, bukan sekadar label GA-nya.

Aplikasi menggunakan langganan regex. Apa yang harus dilakukan?

Protokol streams yang baru tidak mendukung langganan topik berbasis pola/pattern. Tetaplah pada protokol klasik atau ubah metode discovery menjadi daftar topik yang eksplisit sebelum mempertimbangkan migrasi; mengubah protokol grup saja tidak cukup.

Bagaimana Anda memutuskan apakah perlu menggunakan application ID baru?

Gunakan application ID baru saat validasi paralel diperlukan, grup lama tidak dapat dikosongkan dengan aman, atau risiko pemulihan state harus diisolasi. Konsekuensinya adalah pemrosesan ulang, rebuild state-store, dan kebutuhan resource tambahan, jadi perkirakan waktu pemulihan dan kapasitas penyimpanan terlebih dahulu.

Referensi

Panduan pengembang Apache Kafka Streams Rebalance Protocol.
Panduan Upgrade Apache Kafka 4.2 Streams.
Pengumuman Rilis Apache Kafka 4.2.0.