Jepsen: Hasil verifikasi Bufstream 0.1

Pembaruan_2024-11-13

• Dalam laporan awal, disebutkan bahwa konsumer dengan auto-commit aktif dapat menyebabkan kehilangan data karena secara otomatis melakukan commit terhadap offset yang dikembalikan oleh poll terbaru.
• Namun, beberapa pembaca membantah hal itu dan menyatakan bahwa konsumer auto-commit sebenarnya melakukan commit terhadap offset dari poll sebelumnya, bukan poll terbaru.
• Hasil eksperimen dengan klien Java Kafka juga mendukung hal ini, meskipun perilakunya dapat berbeda antar klien.
• Klaim spesifik tentang auto-commit telah dihapus dari laporan, dan penelitian tambahan masih diperlukan.

Latar belakang

• Kafka adalah sistem streaming populer yang menyediakan replikasi, sharding, dan log append-only.
• Bufstream adalah solusi alternatif untuk Kafka yang memprioritaskan tata kelola data dan efisiensi biaya di lingkungan cloud.
• Seperti Kafka, Bufstream menyediakan kumpulan log yang sebagian terurut yang disebut topik, dan setiap topik dibagi menjadi partisi.
• Bufstream kompatibel dengan klien Kafka standar, dan terdiri dari agent tanpa state yang menyediakan API Kafka, object store yang menyimpan data, serta layanan koordinasi.
• Bufstream menekan biaya dengan menulis penyimpanan data langsung ke layanan object storage, dan dapat dijalankan di VM tanpa state yang dapat diskalakan otomatis.

Keamanan klien

• Bufstream dirancang untuk beragam aplikasi streaming, dan menetapkan berbagai opsi konfigurasi klien untuk memastikan perilaku yang aman.
• Seperti Kafka, ia menggunakan acks = all sebagai default, dan menetapkan enable.auto.commit = false untuk mencegah kehilangan data.
• Ia menggunakan auto.offset.reset = earliest agar konsumer dapat mengamati seluruh log.

Transaksi

• Bufstream mendukung sistem transaksi Kafka, dan melalui konfigurasi yang kompleks menyediakan bentuk atomisitas yang lemah.
• Konsumer dapat berjalan pada tingkat isolasi read_uncommitted atau read_committed, dan read_committed mencegah beberapa anomali tertentu (G1a, G1c).
• Pada Kafka, Redpanda, dan Bufstream, anomali G0 tetap terjadi, dan ini tidak selaras dengan tingkat isolasi yang didokumentasikan.

Desain pengujian

• Pengujian dilakukan pada Bufstream 0.1.0 hingga 0.1.3, menggunakan pustaka pengujian Jepsen dan Java Kafka Client.
• Pengujian mengevaluasi keamanan Bufstream dengan menyuntikkan berbagai jenis kegagalan.

Antrean

• Beban kerja antrean yang disesuaikan dengan model data Kafka dirancang dan digunakan pada Bufstream.
• Setiap proses logis menjalankan klien produser, konsumer, dan administrator, lalu mengirim record untuk berbagai key.

Abort

• Berdasarkan hasil yang tidak terduga, dirancang beban kerja yang melakukan abort transaksi dan melacak offset.
• Offset setelah transaksi yang di-abort diklasifikasikan ke dalam empat kategori: maju, mundur, lebih mundur, lainnya.

Hasil Bufstream

Konsumer macet (#1)

• Dari 0.1.0 hingga 0.1.3-rc.8, terjadi masalah di mana panggilan consumer.poll() langsung mengembalikan hasil tanpa record.
• Bufstream menyelesaikan masalah ini di 0.1.3-rc.6 dengan me-refresh cache.

Produser dan konsumer macet (#2)

• Di 0.1.3-rc.6, masih terjadi masalah di mana panggilan InitProducerId gagal atau panggilan listOffsets gagal.
• Bufstream menyelesaikan masalah ini dengan menambahkan logika polling tambahan.

Offset 0 yang salah (#3)

• Dari 0.1.0 hingga 0.1.3-rc.2, terjadi masalah di mana offset 0 yang salah dialokasikan.
• Bufstream menyelesaikan masalah ini di 0.1.3-rc.6.

Kehilangan penulisan transaksi (#4)

• Di 0.1.2, terjadi masalah di mana record dari transaksi yang sudah di-commit menghilang.
• Bufstream menyelesaikan masalah ini di 0.1.3-rc2.

Kehilangan penulisan akibat pemfilteran sisi server (#5)

• Di 0.1.3-rc.8, terjadi kehilangan penulisan sebagai respons terhadap kegagalan ringan.
• Bufstream menyelesaikan masalah ini di 0.1.3-rc.12.

Hasil Kafka

Pesan kesalahan yang menyesatkan (KIP-588)

• Ada masalah di mana ProducerFencedException juga muncul saat terjadi timeout transaksi.
• Tim Kafka direkomendasikan untuk mengubah pesan kesalahan tersebut.

Kemungkinan menunggu tanpa batas saat konsumer ditutup (KAFKA-17734)

• Ada masalah di mana panggilan Consumer.close() dapat menunggu tanpa batas pada network IO.
• Masalah ini dilacak melalui KAFKA-17734.

Offset konsumer yang tidak dapat diprediksi setelah kegagalan transaksi (KAFKA-17582)

• Dokumentasi tentang perilaku yang dimaksud untuk offset konsumer saat transaksi gagal masih kurang.
• Setelah transaksi di-abort, konsumer dapat memundurkan offset atau terus maju.

[GN⁺]

Komentar Hacker News

• Saat menyelidiki masalah yang terjadi di Kafka, ditemukan adanya penulisan yang tak terlihat. Ini memunculkan kemungkinan bahwa pesan Produce yang tertunda ikut masuk ke transaksi di masa depan dan melanggar jaminan transaksi. Ada juga kecurigaan bahwa Kafka Java Client dapat menggunakan kembali nomor urut ketika permintaan mengalami time out. Diperlukan lebih banyak pengujian Kafka

  • Sepertinya Jepsen perlu kembali melakukan investigasi mendalam terhadap Kafka. Investigasi terakhir dilakukan pada 2013, dan ada kemungkinan banyak masalah bisa ditemukan pada Kafka sendiri. Masalah seperti "diam-diam dibuang setelah konfirmasi tulis" terlihat sangat serius

• Setelah melihat halaman produk Bufstream, timbul pertanyaan bagaimana dua pernyataan ini bisa selaras

  • Bufstream berjalan sepenuhnya di dalam AWS atau GCP VPC sehingga Anda dapat mengendalikan data, metadata, dan uptime sepenuhnya. Bufstream tidak pernah berkomunikasi ke luar
  • Harga Bufstream sederhana: $0.002 per GiB tanpa kompresi (sekitar $2 per TiB). Tidak ada biaya per core, agen, atau panggilan
  • Rasanya tidak mungkin seluruh bisnis dijalankan berdasarkan sistem kepercayaan

• Merasa terkejut dengan fitur auto-commit di Kafka

  • Konsumen Kafka dapat secara otomatis meng-commit offset terlepas dari apakah data benar-benar sudah diproses atau belum. Ini berarti jika konsumen melakukan poll pada record, lalu commit, kemudian crash, record tersebut bisa hilang
  • Menurut dokumentasi, jika auto-commit aktif, offset dari pesan yang dikembalikan akan disiapkan untuk di-commit secara otomatis setiap kali metode poll dipanggil. Jika pemrosesan pesan belum selesai, ada risiko progres pesan hilang saat crash
  • Menyesuaikan interval auto-commit membantu untuk pemrosesan duplikat, tetapi tidak membantu terhadap kehilangan pesan

• Protokol transaksi Kafka tampaknya bermasalah secara mendasar dan perlu diperbaiki

  • Investigasi dan penulisannya sangat bagus

• Penasaran apakah Kyle pernah meninjau NATS Jetstream

• Tidak dapat menemukan proyek GitHub bufstream. Penasaran apakah ada petunjuk

• Setelah membaca posting blog dan dokumentasi terkait, Kafka mendefinisikan "exactly-once delivery" sebagai properti dari "operasi baca-proses-tulis". Rasanya akan lebih baik jika ini dijelaskan sebagai transaksi

• Frasa "transaksi dapat diamati sebagian atau seluruhnya" tampaknya seharusnya dibaca sebagai "konsumen dapat mengamati sebagian atau seluruhnya"

• Penasaran perangkat lunak ini digunakan untuk apa. Instrumentasi? Kotak hitam?