Bermigrasi dari Kafka ke Pub/Sub

Dokumen ini berguna jika Anda mempertimbangkan untuk bermigrasi dari Apache Kafka yang dikelola sendiri ke Pub/Sub, karena dapat membantu Anda meninjau dan mempertimbangkan fitur, harga, dan kasus penggunaan. Setiap bagian mengidentifikasi kasus penggunaan Kafka umum dan menawarkan panduan praktis untuk mencapai kemampuan yang sama di Pub/Sub.

Ringkasan Pub/Sub

Pub/Sub adalah layanan pesan asinkron. Pub/Sub memisahkan layanan yang menghasilkan peristiwa dari layanan yang memproses peristiwa. Anda dapat menggunakan Pub/Sub sebagai middleware berorientasi pesan atau penyerapan dan penayangan peristiwa untuk pipeline analisis streaming. Dalam kedua skenario tersebut, aplikasi penayang membuat dan mengirim pesan ke topik. Aplikasi pelanggan membuat langganan ke topik untuk menerima pesan dari topik tersebut. Langganan adalah entitas bernama yang mewakili minat dalam menerima pesan tentang topik tertentu.

Pub/Sub berjalan di semua region Google Cloud. Pub/Sub mengarahkan traffic penayang ke pusat data Google Cloud terdekat tempat penyimpanan data diizinkan, seperti yang ditentukan dalam kebijakan pembatasan lokasi resource.

Pub/Sub dapat berintegrasi dengan banyak layanan Google Cloud seperti Dataflow, Cloud Storage, dan Cloud Run. Anda dapat mengonfigurasi layanan ini untuk berfungsi sebagai sumber data yang dapat memublikasikan pesan ke Pub/Sub, atau sebagai sink data yang dapat menerima pesan dari Pub/Sub.

Ringkasan Kafka

Apache Kafka adalah platform streaming peristiwa open source yang terdistribusi, dan memungkinkan aplikasi memublikasikan, berlangganan, menyimpan, dan memproses streaming peristiwa. Server Kafka dijalankan sebagai cluster mesin yang berinteraksi dengan aplikasi klien untuk membaca, menulis, dan memproses peristiwa. Anda dapat menggunakan Kafka untuk memisahkan aplikasi, mengirim dan menerima pesan, melacak aktivitas, menggabungkan data log, dan memproses streaming.

Dalam cluster Kafka, beberapa node dalam cluster ditetapkan sebagai broker. Broker menerima pesan dari produsen dan menyimpannya di disk. Pesan yang disimpan diatur menurut topik dan dipartisi di beberapa broker yang berbeda dalam cluster. Peristiwa baru yang dipublikasikan ke topik ditambahkan ke akhir salah satu partisi topik. Konsumen kemudian dapat mengambil pesan dari broker, yang dibaca dari disk dan dikirim ke konsumen.

Memahami perbedaan antara Kafka dan Pub/Sub

Diagram berikut menunjukkan perbedaan strategi penskalaan antara Kafka dan Pub/Sub:

Strategi penskalaan dengan partisi untuk Kafka dan tanpa partisi untuk Pub/Sub.

Dalam diagram sebelumnya, setiap M mewakili pesan. Broker Kafka mengelola beberapa partisi pesan yang diurutkan, yang diwakili oleh baris horizontal pesan. Konsumen membaca pesan dari partisi tertentu yang memiliki kapasitas berdasarkan mesin yang menghosting partisi tersebut. Pub/Sub tidak memiliki partisi, dan konsumen membaca dari topik yang diskalakan secara otomatis sesuai permintaan. Anda mengonfigurasi setiap topik Kafka dengan jumlah partisi yang diperlukan untuk menangani beban konsumen yang diharapkan. Pub/Sub diskalakan secara otomatis berdasarkan permintaan.

Membandingkan fitur

Tabel berikut membandingkan fitur Apache Kafka dengan fitur Pub/Sub:

Apache Kafka Pub/Sub
Pengurutan pesan Ya, dalam partisi Ya dalam topik
Penghapusan duplikat pesan Ya Ya, menggunakan Dataflow
Langganan push Tidak Ya
Antrean pesan yang dihentikan pengirimannya
(antrean pesan yang tidak dapat diproses)		 Mulai versi 2.0 Ya
Transaksi Ya Tidak
Penyimpanan pesan Hanya dibatasi oleh penyimpanan mesin yang tersedia 31 hari.
Topik dapat menyimpan pesan yang dipublikasikan, termasuk pesan yang dikonfirmasi, selama maksimum 31 hari. Hal ini dapat dikonfigurasi oleh properti `message_retention_duration` dari topik.
Putar ulang pesan Ya Ya
Locality Cluster lokal dapat direplikasi menggunakan MirrorMaker Layanan terdistribusi global dengan lokasi penyimpanan pesan yang dapat dikonfigurasi
Logging dan pemantauan Dikelola sendiri Otomatis dengan Cloud Logging dan Cloud Monitoring
Stream processing Ya, dengan KSQL Ya, dengan Dataflow

Memahami penyimpanan dan pemutaran ulang pesan Pub/Sub

Secara default, Pub/Sub menyimpan pesan yang tidak dikonfirmasi hingga 7 hari, tetapi Anda juga dapat mengonfigurasi langganan Pub/Sub untuk menyimpan pesan yang dikonfirmasi hingga 7 hari, bergantung pada usia pesan terlama (dikonfirmasi atau tidak dikonfirmasi) dalam langganan. Dengan mempertahankan pesan yang direspons, Anda dapat memutar ulang beberapa atau semua pesan tersebut berdasarkan stempel waktu. Saat Anda memutar ulang pesan berdasarkan stempel waktu , semua pesan yang diterima setelah stempel waktu akan ditandai sebagai tidak dikonfirmasi. Pesan yang tidak terkonfirmasi kemudian akan dikirim ulang.

Anda dapat membuat snapshot setiap langganan sesuai permintaan tanpa perlu mengonfigurasi langganan terlebih dahulu. Misalnya, Anda dapat membuat snapshot saat men-deploy kode pelanggan baru karena Anda mungkin perlu memulihkan dari konfirmasi yang tidak terduga atau salah.

Fitur failsafe bawaan dengan topik yang dihentikan pengirimannya

Pub/Sub menyediakan fitur yang mirip dengan penanganan error Kafka 2.0 dan cara Kafka Connect menangani topik dead-letter. Untuk memberi tahu Pub/Sub bahwa pesan berhasil dikirim, pelanggan topik Pub/Sub dapat mengonfirmasi pesan yang mereka terima dan proses. Jika pelanggan Anda tidak dapat memproses pesan selama beberapa waktu, Pub/Sub dapat otomatis meneruskan pesan ini ke topik yang dihentikan pengirimannya dan menyimpannya untuk diakses nanti. Anda dapat mengonfigurasi jumlah percobaan yang dilakukan Pub/Sub untuk mengirimkan pesan sebelum mengirim pesan ke topik yang pengirimannya dihentikan.

Menghapus duplikat pesan di Pub/Sub menggunakan Dataflow

Pub/Sub mengirimkan setiap pesan yang dipublikasikan minimal sekali untuk setiap langganan. Secara umum, mengakomodasi pengiriman lebih dari sekali mengharuskan pelanggan Anda bersifat idempotent saat memproses pesan. Jika pelanggan yang ada tidak dapat beroperasi secara idempoten, Anda dapat memasukkan Dataflow untuk menghapus duplikat pesan. Jika pelanggan Anda melihat rasio pesan duplikat yang tinggi, hal ini dapat menunjukkan bahwa mereka tidak mengonfirmasi pesan dengan benar, atau bahwa batas waktu konfirmasi Anda terlalu singkat.

Pengurutan pesan di Pub/Sub

Jika aplikasi pelanggan Kafka Anda mengandalkan pengurutan pesan, Anda dapat mendukung persyaratan ini di Pub/Sub saat menggunakan kunci pengurutan. Saat ini, pengurutan dijamin untuk pesan yang dipublikasikan di wilayah tertentu. Untuk memanfaatkan pengurutan pesan, pastikan penayang dan pelanggan Anda menggunakan endpoint lokasi untuk merutekan pesan ke region yang benar.

Memahami tanggung jawab layanan yang dihosting sendiri versus layanan terkelola

Tabel berikut membandingkan fitur yang dihosting sendiri dengan Kafka dan fitur yang dikelola oleh Google menggunakan Pub/Sub:

Apache Kafka Pub/Sub
Ketersediaan Men-deploy Kafka ke lokasi tambahan secara manual Di-deploy di semua region Google Cloud untuk ketersediaan tinggi dan latensi rendah
Pemulihan dari bencana Mendesain dan mengelola pencadangan dan replikasi Anda sendiri Dikelola oleh Google
Pengelolaan infrastruktur Men-deploy dan mengoperasikan virtual machine (VM) atau mesin secara manual. Anda harus mempertahankan versi dan patch yang konsisten. Dikelola oleh Google
Perencanaan kapasitas Merencanakan kebutuhan penyimpanan dan komputasi secara manual terlebih dahulu Dikelola oleh Google
Dukungan Tidak ada Staf dan dukungan siaga 24 jam tersedia

Batas dan solusi ukuran pesan Pub/Sub

Kafka dan Pub/Sub memiliki performa yang baik saat menangani pesan kecil dalam jumlah besar. Kafka tidak menetapkan batas mutlak pada ukuran pesan dan memungkinkan Anda mengonfigurasi ukuran pesan yang diizinkan, sedangkan Pub/Sub membatasi pesan hingga 10 MB. Anda dapat secara tidak langsung mengirim payload yang lebih besar dengan menyimpan objek terlebih dahulu di Cloud Storage, seperti yang ditunjukkan dalam diagram berikut:

Penayang menyimpan objek di Cloud Storage.

Gambar sebelumnya menunjukkan bahwa saat penerbit menyimpan objek di Cloud Storage, penerbit akan memublikasikan pesan yang berisi URL ke objek yang disimpan tersebut. Saat menerima pesan yang berisi URL, subscriber akan mendownload file dari Cloud Storage dan melanjutkan pemrosesan seperti biasa.

Perbandingan biaya Kafka dan Pub/Sub

Cara Anda memperkirakan dan mengelola biaya di Pub/Sub berbeda dengan di Kafka. Biaya cluster Kafka di lokal atau di cloud mencakup biaya mesin, disk, jaringan, pesan masuk dan keluar, serta biaya overhead untuk mengelola dan memelihara sistem ini beserta infrastruktur terkaitnya. Saat mengelola cluster Kafka, komputer sering kali perlu diupgrade dan di-patch secara manual, kapasitas cluster sering kali perlu direncanakan, dan menerapkan disaster recovery memerlukan perencanaan dan pengujian yang ekstensif. Anda perlu menyimpulkan dan menggabungkan semua biaya ini untuk menentukan total biaya kepemilikan (TCO) yang sebenarnya.

Harga Pub/Sub mencakup transfer data dari penayang dan ke pelanggan, serta biaya penyimpanan pesan yang tidak terkonfirmasi untuk sementara. Anda membayar tepat resource yang Anda gunakan, yang secara otomatis menskalakan kapasitasnya sesuai dengan persyaratan aplikasi dan anggaran Anda.

Merancang arsitektur untuk keandalan

Pub/Sub adalah layanan terkelola global yang berjalan di semua region Google Cloud. Topik Pub/Sub bersifat global, artinya dapat dilihat dan diakses dari lokasi Google Cloud mana pun. Namun, setiap pesan yang dimaksud disimpan dalam satu region Google Cloud yang terdekat dengan penayang dan diizinkan oleh kebijakan lokasi resource. Dengan demikian, topik dapat memiliki pesan yang disimpan di berbagai region di seluruh Google Cloud. Pub/Sub tahan terhadap pemadaman layanan zona. Selama pemadaman layanan regional, pesan yang disimpan di region tertentu tersebut mungkin tidak dapat diakses hingga layanan dipulihkan. Bergantung pada persyaratan ketersediaan, Anda dapat menggunakan endpoint layanan lokasi untuk menerapkan kebijakan failover jika terjadi pemadaman layanan regional.

Keamanan dan autentikasi

Apache Kafka mendukung beberapa mekanisme autentikasi termasuk autentikasi berbasis sertifikat klien, Kerberos, LDAP, serta nama pengguna dan sandi. Untuk otorisasi, Kafka mendukung penggunaan daftar kontrol akses (ACL) untuk menentukan produsen dan konsumen mana yang memiliki akses ke topik mana.

Pub/Sub mendukung autentikasi untuk akun pengguna dan akun layanan Google Cloud. Kontrol akses terperinci ke topik dan langganan Pub/Sub diatur oleh Identity and Access Management (IAM) di Google Cloud. Operasi Pub/Sub dibatasi kapasitasnya saat menggunakan akun pengguna. Jika perlu melakukan transaksi dalam volume tinggi, Anda dapat menggunakan akun layanan untuk berinteraksi dengan Pub/Sub.

Merencanakan migrasi ke Pub/Sub

Setiap migrasi ke Google Cloud dimulai dengan menilai workload Anda dan membangun fondasi Anda.

Migrasi bertahap menggunakan Konektor Kafka Pub/Sub

Konektor Kafka Pub/Sub memungkinkan Anda memigrasikan infrastruktur Kafka ke Pub/Sub secara bertahap.

Anda dapat mengonfigurasi konektor Pub/Sub untuk meneruskan semua pesan pada topik tertentu dari Kafka ke Pub/Sub. Kemudian, Anda dapat mengupdate setiap aplikasi subscriber untuk menerima pesan tentang topik tersebut dari Pub/Sub, sementara aplikasi penayang Anda terus memublikasikan pesan ke Kafka. Pendekatan bertahap ini memungkinkan Anda mengupdate, menguji, dan memantau aplikasi pelanggan dengan cara iteratif yang meminimalkan risiko error dan downtime.

Bagian ini mencakup dua diagram yang dapat membantu Anda memvisualisasikan proses ini dalam dua fase yang berbeda. Diagram berikut menunjukkan konfigurasi selama fase migrasi:

Tahap satu migrasi.

Dalam diagram sebelumnya, pelanggan saat ini terus menerima pesan dari Kafka, dan Anda memperbarui pelanggan satu per satu untuk menerima pesan dari Pub/Sub.

Setelah semua pelanggan untuk topik tertentu telah diperbarui untuk menerima pesan dari Pub/Sub, Anda dapat memperbarui aplikasi penayang untuk topik tersebut guna memublikasikan pesan ke Pub/Sub. Kemudian, Anda dapat menguji dan memantau alur pesan secara menyeluruh untuk memverifikasi penyiapan.

Diagram berikut menunjukkan konfigurasi setelah semua subscriber menerima pesan dari Pub/Sub:

Tahap kedua migrasi.

Seiring waktu, semua penayang Anda akan diperbarui untuk memublikasikan langsung ke Pub/Sub, lalu migrasi Anda akan selesai. Banyak tim menggunakan pendekatan ini untuk mengupdate aplikasi secara paralel. Kafka dapat berdampingan dengan Pub/Sub selama diperlukan untuk memastikan migrasi berhasil.

Memantau Pub/Sub

Selama dan setelah migrasi dari Kafka ke Pub/Sub, Anda harus memantau aplikasi. Pub/Sub mengekspor metrik dengan menggunakan Cloud Monitoring, yang dapat membantu memberikan visibilitas terkait performa, waktu beroperasi, dan kondisi keseluruhan aplikasi Anda. Misalnya, Anda dapat memastikan bahwa pelanggan Anda tetap mengikuti alur pesan dengan memantau jumlah pesan yang tidak terkirim. Untuk memantau pesan yang belum diterima, Anda membuat pemberitahuan saat stempel waktu pesan yang tidak terkonfirmasi paling lama melampaui nilai minimum tertentu. Anda juga dapat memantau kondisi layanan Pub/Sub itu sendiri dengan memantau metrik jumlah permintaan pengiriman dan memeriksa kode respons.

Langkah selanjutnya