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 suatu topik. Aplikasi pelanggan membuat langganan ke topik untuk menerima pesan darinya. Langganan adalah entitas bernama yang mewakili minat untuk 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 dijelaskan 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 agar 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 open source, terdistribusi, dan streaming peristiwa, yang memungkinkan aplikasi memublikasikan, berlangganan, menyimpan, dan memproses aliran 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 aliran data.
Dalam cluster Kafka, beberapa node di cluster ditetapkan sebagai broker. Broker menerima pesan dari produsen dan menyimpannya di disk. Pesan yang disimpan diatur berdasarkan topik dan dipartisi di beberapa perantara berbeda di cluster. Peristiwa baru yang dipublikasikan ke topik akan 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:
Dalam diagram sebelumnya, setiap M mewakili sebuah 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 akan mengonfigurasi setiap topik Kafka dengan jumlah partisi yang diperlukan untuk menangani beban konsumen yang diharapkan. Pub/Sub menskalakan 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 berdasarkan penyimpanan mesin yang tersedia | 31 hari. Topik dapat mempertahankan pesan yang dipublikasikan, termasuk pesan yang dikonfirmasi, selama maksimum 31 hari. Nilai ini dapat dikonfigurasi berdasarkan properti `message_retention_duration` pada topik. |
| Putar ulang pesan | Ya | Ya |
| Locality | Cluster lokal dapat mereplikasi menggunakan MirrorMaker | Layanan terdistribusi secara global dengan lokasi penyimpanan pesan yang dapat dikonfigurasi |
| Logging dan pemantauan | Dikelola sendiri | Otomatis dengan Cloud Logging dan Cloud Monitoring |
| Stream processing | Ya, untuk KSQL | Ya, dengan Dataflow |
Memahami penyimpanan dan replay pesan Pub/Sub
Secara default, Pub/Sub menyimpan pesan yang tidak dikonfirmasi hingga 7 hari, tetapi Anda dapat mengonfigurasi langganan Pub/Sub untuk mempertahankan pesan yang dikonfirmasi hingga 7 hari juga, bergantung pada usia pesan terlama (dikonfirmasi atau tidak dikonfirmasi) dalam langganan. Dengan mempertahankan pesan yang dikonfirmasi, Anda dapat memutar ulang sebagian atau semua pesan tersebut berdasarkan stempel waktu. Jika Anda memutar ulang pesan berdasarkan stempel waktu, semua pesan yang diterima setelah stempel waktu akan ditandai sebagai tidak dikonfirmasi. Pesan yang tidak dikonfirmasi akan dikirim ulang.
Anda dapat membuat snapshot setiap langganan on demand tanpa perlu mengonfigurasi langganan Anda terlebih dahulu. Misalnya, Anda dapat membuat snapshot saat men-deploy kode pelanggan baru karena Anda mungkin perlu melakukan pemulihan dari konfirmasi yang tidak terduga atau salah.
Alat pengaman bawaan dengan topik yang dihentikan pengirimannya
Pub/Sub menyediakan fitur yang mirip dengan penanganan error Kafka 2.0 dan cara Kafka Connect menangani topik yang dihentikan pengirimannya. 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 untuk beberapa waktu, Pub/Sub dapat secara otomatis meneruskan pesan ini ke topik yang dihentikan pengirimannya dan menyimpannya untuk diakses di lain waktu. Anda dapat mengonfigurasi jumlah upaya yang dilakukan Pub/Sub untuk mengirim pesan sebelum mengirim pesan ke topik yang dihentikan pengirimannya.
Menduplikasi pesan di Pub/Sub menggunakan Dataflow
Pub/Sub mengirimkan setiap pesan yang dipublikasikan setidaknya satu kali untuk setiap langganan. Secara umum, mengakomodasi pengiriman lebih dari satu kali mengharuskan pelanggan Anda idempoten saat memproses pesan. Jika pelanggan lama tidak dapat beroperasi secara idempoten, Anda dapat menggabungkan Dataflow untuk menghapus duplikat pesan. Jika pelanggan Anda melihat banyak pesan duplikat, hal ini dapat menunjukkan bahwa mereka tidak mengonfirmasi pesan dengan benar, atau 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 terjamin untuk pesan yang dipublikasikan di wilayah tertentu. Untuk memanfaatkan pengurutan pesan, pastikan penayang dan pelanggan Anda menggunakan endpoint lokasi untuk mengarahkan pesan ke region yang benar.
Memahami tanggung jawab layanan yang dihosting sendiri versus layanan terkelola
Tabel berikut membandingkan fitur apa saja yang dihosting sendiri dengan Kafka dan fitur apa saja 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 | Desain dan kelola cadangan dan replikasi Anda sendiri | Dikelola oleh Google |
| Pengelolaan infrastruktur | Men-deploy dan mengoperasikan virtual machine (VM) atau mesin secara manual. Anda harus menjaga pembuatan versi dan patch yang konsisten. | Dikelola oleh Google |
| Perencanaan kapasitas | Rencanakan kebutuhan penyimpanan dan komputasi secara manual di awal | Dikelola oleh Google |
| Support | Tidak ada | Staf siaga dan dukungan 24 jam tersedia |
Batas ukuran pesan Pub/Sub dan solusi
Kafka dan Pub/Sub berperforma baik saat menangani pesan berukuran kecil dalam jumlah besar. Kafka tidak membatasi 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:
Gambar sebelumnya menunjukkan bahwa saat penayang menyimpan objek di Cloud Storage, penayang akan memublikasikan pesan yang berisi URL ke objek yang disimpan tersebut. Saat menerima pesan yang berisi URL, pelanggan akan mendownload file dari Cloud Storage dan terus memproses 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 infrastruktur lokal atau di cloud mencakup biaya mesin, disk, jaringan, pesan masuk dan keluar, serta biaya overhead pengelolaan dan pemeliharaan sistem ini beserta infrastruktur terkait. Saat mengelola cluster Kafka, mesin sering kali harus diupgrade dan di-patch secara manual, kapasitas cluster sering kali perlu direncanakan, dan penerapan pemulihan dari bencana membutuhkan 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 penerbit dan pelanggan, serta biaya penyimpanan pesan yang tidak dikonfirmasi untuk sementara. Anda membayar sesuai dengan resource yang digunakan, dengan 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 tertentu disimpan di 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 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 yang memiliki akses ke topik tertentu.
Pub/Sub mendukung autentikasi untuk akun pengguna dan akun layanan Google Cloud. Kontrol akses terperinci untuk topik dan langganan Pub/Sub diatur oleh Identify and Access Management (IAM) di Google Cloud. Operasi Pub/Sub dibatasi kapasitas saat menggunakan akun pengguna. Jika perlu melakukan transaksi bervolume 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 Pub/Sub Kafka
Konektor Pub/Sub Kafka memungkinkan Anda memigrasikan infrastruktur Kafka ke Pub/Sub secara bertahap.
Anda dapat mengonfigurasi konektor Pub/Sub untuk meneruskan semua pesan tentang topik tertentu dari Kafka ke Pub/Sub. Kemudian, Anda dapat mengupdate setiap aplikasi pelanggan untuk menerima pesan mengenai topik tersebut dari Pub/Sub, sementara aplikasi penerbit Anda akan terus memublikasikan pesan ke Kafka. Pendekatan bertahap ini memungkinkan Anda mengupdate, menguji, dan memantau aplikasi pelanggan secara berulang yang meminimalkan risiko error dan periode nonaktif.
Bagian ini menyertakan dua diagram yang dapat membantu Anda memvisualisasikan proses ini dalam dua fase yang berbeda. Diagram berikut menunjukkan konfigurasi selama fase migrasi:
Dalam diagram sebelumnya, pelanggan saat ini akan terus menerima pesan dari Kafka, dan Anda akan memperbarui pelanggan satu per satu untuk menerima pesan dari Pub/Sub.
Setelah semua pelanggan topik tertentu diupdate untuk menerima pesan dari Pub/Sub, Anda kemudian dapat mengupdate aplikasi penerbit untuk topik tersebut agar memublikasikan pesan ke Pub/Sub. Kemudian, Anda dapat menguji dan memantau alur pesan secara menyeluruh untuk memverifikasi penyiapan.
Diagram berikut menunjukkan konfigurasi setelah semua pelanggan menerima pesan dari Pub/Sub:
Seiring waktu, semua penayang Anda akan diupdate untuk memublikasikannya langsung ke Pub/Sub, lalu migrasi Anda selesai. Banyak tim menggunakan pendekatan ini untuk mengupdate aplikasi mereka secara paralel. Kafka dapat berdampingan dengan Pub/Sub selama diperlukan untuk memastikan keberhasilan migrasi.
Memantau Pub/Sub
Selama dan setelah migrasi dari Kafka ke Pub/Sub, penting untuk memantau aplikasi Anda. Pub/Sub mengekspor metrik menggunakan Cloud Monitoring, yang dapat membantu memberikan visibilitas terkait performa, waktu beroperasi, dan kondisi aplikasi Anda secara keseluruhan. Misalnya, Anda dapat memastikan bahwa pelanggan dapat mengikuti alur pesan dengan memantau jumlah pesan yang tidak terkirim. Untuk memantau pesan yang tidak terkirim, Anda membuat pemberitahuan saat stempel waktu pesan terlama yang tidak dikonfirmasi melampaui batas tertentu. Anda juga dapat memantau kondisi layanan Pub/Sub itu sendiri dengan memantau metrik jumlah permintaan pengiriman dan memeriksa kode respons.
Langkah selanjutnya
- Analisis streaming dengan Pub/Sub.
- Referensi Pub/Sub API.
- Dokumentasi Pub/Sub Monitoring.
- Merancang pemulihan dari bencana untuk pemadaman infrastruktur cloud.
- Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.