Wawancara Backend: Bagaimana Anda Menggunakan Kafka Static Membership untuk Rolling Restart?

Pertanyaan dan Kapan Ini Berlaku

Consumer group berjalan pada instance yang dapat diganti. Restart atau gangguan jaringan singkat memicu penugasan ulang partisi, yang menyebabkan jeda dan lonjakan latensi. Jelaskan identitas anggota statis, perilaku koordinator, urutan deployment, batas waktu (timeout), dan batasan kegagalan daripada sekadar menyebutkan satu konfigurasi.

Hal yang Dievaluasi Pewawancara

Membedakan anggota dinamis, anggota statis, dan partition assignor.
Menjelaskan keunikan group.instance.id, session timeout, dan risiko fencing akibat ID duplikat.
Menghubungkan pengaturan consumer dengan rolling deployment, graceful shutdown, dan pemantauan.
Menyatakan kapan static membership masih melakukan rebalance karena topologi, timeout, atau kegagalan nyata.

Pertanyaan Klarifikasi Sebelum Anda Menjawab

Apakah setiap instance memiliki identitas unik yang stabil, atau diganti secara acak?
Berapa lama waktu yang dibutuhkan untuk restart, dan berapa session.timeout.ms serta batas broker?
Apakah grup menggunakan penugasan eager atau cooperative, dan apakah migrasi tersebut juga harus dilakukan?
Berapa waktu jeda dan pemulihan lag maksimum yang dapat diterima?
Bagaimana deployment memastikan instance lama keluar sebelum menggunakan kembali ID-nya?

Kerangka Jawaban 30 Detik

Saya akan menetapkan group.instance.id yang stabil dan unik untuk setiap consumer, memungkinkan restart singkat dalam batas session timeout untuk mempertahankan keanggotaan alih-alih memicu penugasan ulang penuh untuk ID anggota acak yang baru. Deployment mengganti satu slot pada satu waktu dan tidak pernah menggunakan kembali ID secara bersamaan. Static membership tidak menggantikan migrasi assignor atau menyembunyikan kegagalan yang lama, jadi saya akan memvalidasi jumlah rebalance, waktu partisi tidak tersedia, latensi consumer, dan error ID duplikat.

Pembahasan Mendalam Langkah demi Langkah

Langkah 1: Konfirmasikan model identitas anggota

Anggota dinamis biasanya bergabung dengan ID anggota yang di-generate yang berubah setelah suatu proses keluar. Anggota statis diidentifikasi oleh group.instance.id, yang harus unik di dalam grup dan tetap bertahan setelah restart. Dapatkan ID ini dari ordinal StatefulSet, slot mesin, atau lease yang terkontrol, bukan UUID acak yang di-generate pada setiap start.

Langkah 2: Pahami batasan session-timeout

Setelah heartbeat berhenti, koordinator tidak langsung menganggap anggota statis telah keluar secara permanen; koordinator menyatakan anggota tersebut gagal setelah session timeout. Timeout yang terlalu singkat membuat deploy normal memicu rebalance; timeout yang terlalu lama menunda pengambilalihan setelah kegagalan nyata. Atur nilai ini berdasarkan waktu startup, jitter jaringan, dan anggaran jeda bisnis dalam batas broker.

Langkah 3: Cegah ID duplikat

Dua instance aktif dalam satu grup tidak boleh berbagi group.instance.id yang sama. Orkestrasi harus melepaskan identitas lama sebelum memulai penggantinya. Jika keduanya berjalan, koordinator dapat menolak atau melakukan fencing pada salah satu anggota. Perlakukan error ID duplikat sebagai sinyal pemblokir deployment alih-alih menutupinya dengan retry.

Langkah 4: Koordinasikan assignor dan graceful shutdown

Static membership mengurangi churn identitas; assignor menentukan pergerakan partisi. Meng-upgrade assignor atau mengaktifkan mode kooperatif memerlukan pemeriksaan kompatibilitas tersendiri. Pada shutdown normal, hentikan polling, commit offset yang aman, tinggalkan grup, dan tutup koneksi. Penghentian abnormal bergantung pada pengambilalihan oleh session-timeout.

Langkah 5: Rancang rolling deployment

Ganti satu instance pada satu waktu, dan tunggu hingga anggota baru bergabung, partisi stabil, dan latensi pulih. Catat pemetaan instance-ke-partisi sebelum deployment, amati log koordinator dan consumer lag, serta jeda batch jika terjadi kegagalan sambil mempertahankan versi lama. Static membership bukanlah izin untuk restart paralel tanpa batas.

Langkah 6: Identifikasi kasus yang masih memicu rebalance

Menambahkan anggota, melebihi session timeout, mengubah jumlah partisi atau langganan topik, mengubah assignor, dan perpindahan koordinator semuanya dapat memicu penugasan ulang. Static membership mengurangi churn dari ketidakhadiran dan kembalinya anggota dalam waktu singkat; ini tidak menghilangkan koordinasi yang disebabkan oleh perubahan topologi atau kapasitas.

Langkah 7: Validasi manfaat dan risiko dengan metrik

Catat jumlah rebalance, waktu partisi tidak tersedia, latensi consumer p99, lag maksimum, error ID duplikat, session timeout, dan waktu pemulihan per deployment. Injeksikan restart singkat, startup yang lambat, partisi jaringan, tabrakan ID, dan perubahan broker. Tetapkan ambang batas jeda dan rollback otomatis.

Contoh Jawaban Berkualitas Tinggi

Saya akan menetapkan group.instance.id yang stabil dan unik untuk setiap slot consumer yang di-generate dari ordinal deployment atau lease yang terkontrol. Rolling deploy mengganti satu slot pada satu waktu: anggota lama berhenti melakukan polling dan keluar secara graceful, kemudian proses baru bergabung dengan ID yang sama. Jika restart selesai dalam batas session timeout, grup menghindari churn yang disebabkan oleh perubahan ID anggota acak. Saya akan menentukan session.timeout.ms dari startup normal maksimum, jitter jaringan, dan jeda yang diizinkan, bukan sekadar menaikkannya. Orkestrasi akan memblokir penggunaan kembali ID secara bersamaan; error ID duplikat atau fencing akan menghentikan rollout. Static membership tetap tidak menangani ekspansi partisi, perubahan langganan, atau timeout nyata, jadi saya akan memantau rebalance, latensi p99, lag, waktu tidak tersedia, dan pemulihan, dengan pengujian rollback melalui fault-injection.

Kesalahan Umum

Men-generate group.instance.id acak baru pada setiap start.
Menaikkan session timeout tanpa memperkirakan waktu pengambilalihan saat kegagalan.
Menjalankan dua proses secara bersamaan dengan ID instance yang sama.
Mengasumsikan static membership menghilangkan setiap rebalance dan mengabaikan perubahan topik, partisi, atau langganan.
Mengubah konfigurasi tanpa memvalidasi kompatibilitas assignor dan graceful shutdown.
Hanya melihat lag rata-rata dan melewatkan waktu tidak tersedia serta latensi p99 selama deployment.

Pertanyaan Lanjutan dan Tanggapan

Pertanyaan lanjutan 1: Seberapa cepat partisi dari instance yang mengalami crash diambil alih?

Biasanya setelah koordinator menentukan bahwa sesi telah timeout; heartbeat, kondisi jaringan, dan status koordinator juga berpengaruh. Bekerjalah mundur dari target pemulihan dan ukur dengan fault injection alih-alih mengutip nilai default.

Pertanyaan lanjutan 2: Apakah static membership dan cooperative sticky assignor adalah hal yang sama?

Tidak. Static membership menstabilkan identitas anggota dan mengurangi churn akibat ketidakhadiran singkat. Cooperative assignor mengontrol cara perpindahan partisi dan mengurangi jeda migrasi. Keduanya dapat digabungkan tetapi harus divalidasi secara terpisah.

Pertanyaan lanjutan 3: Mengapa memblokir deployment jika terjadi ID duplikat?

Dua proses yang bersaing untuk satu identitas dapat menyebabkan fencing, churn partisi, dan kepemilikan yang tidak dapat diprediksi. Retry dapat memperparah tabrakan tersebut, sehingga deployment harus memperbaiki alokasi identitas terlebih dahulu.

Pertanyaan lanjutan 4: Bisakah session timeout diatur hingga beberapa jam?

Hanya jika bisnis dapat menerima partisi menunggu selama itu setelah terjadi kegagalan dan batas broker mengizinkannya. Sebagian besar sistem memodelkan jeda deploy dan pemulihan kegagalan secara terpisah alih-alih menyembunyikan startup yang lambat di balik timeout yang ekstrem.

Pertanyaan lanjutan 5: Apakah scaling consumer tetap memicu rebalance?

Ya. Anggota baru mengubah kepemilikan partisi; identitas statis tidak dapat mencegah perubahan topologi. Lakukan scaling pada jendela waktu yang lebih tenang, amati migrasi dan lag, serta jaga strategi assignor dan versi tetap kompatibel.

Pertanyaan lanjutan 6: Bagaimana Anda me-rollback deployment yang gagal?

Jeda penggantian lebih lanjut, pertahankan instance yang belum diubah, dan verifikasi bahwa versi lama dapat bergabung kembali dengan ID aslinya serta melanjutkan konsumsi data. Periksa ID duplikat, offset yang di-commit, lag, dan log koordinator sebelum memutuskan apakah akan melanjutkan atau memperluas respons insiden.