Dokumen ini membahas perbedaan antara arsitektur lokal berbasis antrean pesan dan arsitektur cloud berbasis peristiwa yang diimplementasikan di Pub/Sub. Mencoba menerapkan pola lokal secara langsung ke teknologi berbasis cloud dapat menghilangkan nilai unik yang membuat cloud menarik sejak awal.
Dokumen ini ditujukan untuk arsitek sistem yang memigrasikan desain dari arsitektur lokal ke desain berbasis cloud. Dokumen ini mengasumsikan bahwa Anda sudah memiliki pemahaman awal tentang sistem pesan.
Diagram berikut menunjukkan ringkasan model antrean pesan dan model Pub/Sub.
Dalam diagram sebelumnya, model antrean pesan dibandingkan dengan model stream peristiwa Pub/Sub. Dalam model antrean pesan, penayang mengirim pesan ke sebuah antrean tempat setiap pelanggan dapat memproses antrean tertentu. Dalam model stream peristiwa yang menggunakan Pub/Sub, penayang mengirim pesan ke sebuah topik yang dapat diproses oleh banyak pelanggan. Perbedaan antara kedua model ini dijelaskan di bagian berikut.
Membandingkan stream peristiwa dan pesan berbasis antrean
Jika menggunakan sistem lokal, Anda tentu sudah memahami enterprise service bus (ESB) dan antrean pesan. Stream peristiwa adalah pola baru dan terdapat perbedaan penting dengan keunggulan konkret untuk sistem real-time modern.
Dokumen ini membahas perbedaan utama dalam mekanisme transpor dan data payload dalam arsitektur berbasis peristiwa.
Transpor pesan
Sistem yang memindahkan data dalam model ini disebut broker pesan, dan ada berbagai framework yang diimplementasikan di dalamnya. Salah satu konsep awalnya adalah mekanisme dasar yang memindahkan pesan dari penayang ke penerima. Dalam framework pesan lokal, sistem asal mengirimkan pesan eksplisit, jarak jauh, dan terpisah ke sistem pemrosesan downstream dengan menggunakan antrean pesan sebagai transpornya.
Diagram berikut menunjukkan model antrean pesan:
Dalam diagram sebelumnya, pesan mengalir dari proses penayang upstream ke proses pelanggan downstream dengan menggunakan antrean pesan.
Sistem A (penayang) mengirim pesan ke antrean pada broker pesan yang ditetapkan untuk Sistem B (pelanggan). Meskipun pelanggan antrean ini dapat terdiri atas banyak klien, semua klien tersebut merupakan instance duplikat dari Sistem B yang di-deploy untuk penskalaan dan ketersediaan. Jika proses downstream tambahan—misalnya Sistem C—perlu mengonsumsi pesan yang sama dari produsen (Sistem A), antrean baru diperlukan. Anda harus memberi tahu produsen agar menayangkan pesan ke antrean baru. Model ini sering disebut sebagai penerusan pesan.
Lapisan transpor pesan untuk antrean ini mungkin memberikan jaminan urutan pesan, mungkin juga tidak. Sering kali, antrean pesan diharapkan memberikan model jaminan urutan dengan data yang diurutkan dalam model akses first-in-first-out (FIFO) yang ketat, mirip dengan task queue. Pola ini awalnya mudah diimplementasikan, tetapi pada akhirnya memunculkan tantangan penskalaan dan operasional. Untuk mengimplementasikan pesan yang diurutkan, sistem membutuhkan proses terpusat untuk mengatur data. Proses ini membatasi kapabilitas penskalaan dan mengurangi ketersediaan layanan karena merupakan titik tunggal kegagalan.
Broker pesan dalam arsitektur ini cenderung mengimplementasikan logika tambahan seperti melacak pelanggan mana yang telah menerima pesan, dan memantau beban pelanggan. Pelanggan cenderung sekadar reaktif, tidak memiliki pengetahuan tentang sistem secara keseluruhan, dan hanya menjalankan fungsi setelah menerima pesan. Jenis arsitektur semacam ini disebut smart pipe (sistem antrean pesan) dan dumb endpoint (pelanggan).
Transpor Pub/Sub
Serupa dengan sistem berorientasi pesan, sistem streaming peristiwa juga memindahkan pesan dari sistem sumber ke sistem tujuan terpisah. Namun, alih-alih mengirim setiap pesan ke antrean yang ditarget proses, sistem berbasis peristiwa cenderung menayangkan pesan ke topik bersama, lalu satu atau beberapa penerima berlangganan ke topik tersebut untuk memproses pesan yang relevan.
Diagram berikut menunjukkan pengiriman berbagai pesan oleh penayang upstream ke sebuah topik, lalu dirutekan ke pelanggan downstream yang relevan:
Dari pola publish (menayangkan) dan subscribe (berlangganan) inilah istilah pub/sub berasal. Pola ini juga merupakan dasar untuk produk Google Cloud yang disebut Pub/Sub. Dalam dokumen ini, pub/sub mengacu kepada pola, sedangkan Pub/Sub mengacu kepada produk.
Pada model pub/sub, sistem pesan tidak perlu mengetahui pelanggan mana pun. Model ini tidak melacak pesan mana yang telah diterima, dan tidak mengelola beban pada proses pengonsumsinya. Sebagai gantinya, pelanggan melacak pesan mana yang telah diterima dan bertanggung jawab mengelola sendiri tingkat beban dan penskalaan.
Salah satu keunggulan utamanya adalah saat Anda mendapati bahwa data dalam model pub/sub memiliki penggunaan baru, Anda tidak perlu memperbarui sistem asalnya untuk menayangkan ke antrean baru atau menduplikasi data. Anda cukup menambahkan konsumen baru ke langganan baru tanpa memengaruhi sistem yang sudah ada.
Panggilan dalam sistem streaming peristiwa hampir selalu asinkron, yang berarti sistem mengirim peristiwa tanpa menunggu respons apa pun. Penggunaan peristiwa asinkron memungkinkan opsi penskalaan yang lebih besar baik bagi produsen maupun konsumen. Namun, pola asinkron ini dapat menimbulkan tantangan jika Anda mengharapkan jaminan urutan pesan FIFO.
Data antrean pesan
Data yang diteruskan antar-sistem dalam sistem antrean pesan dan sistem berbasis pub/sub secara umum disebut pesan dalam kedua konteks tersebut. Namun, model yang digunakan untuk menyajikan data tersebut berbeda. Dalam sistem antrean pesan, pesan mencerminkan perintah yang dimaksudkan untuk mengubah status data downstream. Jika Anda melihat data untuk sistem antrean pesan lokal, penayang mungkin menyatakan secara eksplisit tindakan yang harus dilakukan konsumen. Misalnya, pesan inventaris mungkin menunjukkan hal berikut:
<m:SetInventoryLevel>
<inventoryValue>3001</inventoryValue>
</m: SetInventoryLevel>
Dalam contoh ini, produsen memberi tahu konsumen bahwa mereka perlu menetapkan tingkat inventaris ke 3001. Pendekatan ini dapat menjadi tantangan karena produser perlu memahami logika bisnis setiap konsumen dan perlu membuat struktur pesan terpisah untuk berbagai kasus penggunaan. Sistem antrean pesan ini merupakan praktik umum dengan monolit besar yang diimplementasikankan oleh sebagian besar perusahaan. Namun, jika Anda ingin bergerak lebih cepat, menskalakan lebih luas, dan berinovasi lebih banyak daripada sebelumnya, sistem terpusat ini dapat menjadi bottleneck karena perubahan berjalan lambat dan berisiko.
Pola ini juga memunculkan tantangan operasional. Saat data berkualitas rendah, kumpulan data duplikat, atau masalah lainnya terjadi dan perlu dikoreksi, model pesan ini akan memunculkan tantangan signifikan. Misalnya, jika perlu me-roll back pesan yang digunakan dalam contoh sebelumnya, Anda tidak tahu apa yang harus ditetapkan ke nilai yang telah dikoreksi karena Anda tidak memiliki referensi ke status sebelumnya. Anda tidak memiliki insight tentang apakah nilai inventaris tersebut 3.000 atau 4.000 sebelum pesan dikirim.
Data pub/sub
Peristiwa adalah cara lain untuk mengirim data pesan. Yang unik adalah sistem berbasis peristiwa berfokus pada peristiwa yang terjadi, bukan hasil yang seharusnya terjadi. Alih-alih mengirim data yang menunjukkan tindakan yang harus dilakukan konsumen, data difokuskan pada detail peristiwa sebenarnya yang dihasilkan. Anda dapat mengimplementasikan sistem berbasis peristiwa di berbagai platform, tetapi sistem ini banyak digunakan di sistem berbasis pub/sub.
Misalnya, peristiwa inventaris mungkin terlihat seperti berikut:
{ "inventory":-1 }
Data peristiwa sebelumnya menunjukkan bahwa terjadi peristiwa yang menurunkan inventaris sebesar 1. Pesan ini berfokus pada peristiwa yang terjadi pada masa lalu, bukan status yang akan diubah pada masa mendatang. Penayang dapat mengirim pesan secara asinkron, sehingga sistem berbasis peristiwa lebih mudah diskalakan daripada model antrean pesan. Dalam model pub/sub, Anda dapat memisah logika bisnis sehingga produsen hanya perlu memahami tindakan yang dilakukan pada logika tersebut tanpa perlu memahami proses downstream-nya. Pelanggan data tersebut dapat memilih cara terbaik untuk menangani data yang mereka terima. Karena pesan-pesan ini bukan perintah imperatif, urutan pesan menjadi kurang penting.
Dengan pola ini, roll back perubahan lebih mudah dilakukan. Dalam contoh ini, tidak ada informasi tambahan yang diperlukan karena Anda dapat menegasikan nilai inventaris untuk memindahkannya ke arah berlawanan. Pesan yang masuk terlambat atau tidak sesuai urutan tidak lagi menjadi masalah.
Perbandingan model
Dalam skenario ini, Anda memiliki empat item dari produk yang sama dalam inventaris. Seorang pelanggan mengembalikan satu unit produk, dan pelanggan berikutnya membeli tiga unit produk yang sama. Untuk skenario ini, asumsikan bahwa pesan untuk produk yang dikembalikan masuk terlambat.
Tabel berikut membandingkan tingkat inventaris model antrean pesan yang menerima jumlah inventaris dalam urutan yang benar, dengan model yang sama yang menerima jumlah inventaris secara tidak berurutan:
| Antrean pesan (urutan benar) | Antrean pesan (tidak berurutan) |
|---|---|
Inventaris awal: 4 |
Inventaris awal: 4 |
Pesan 1: setInventory(5) |
Pesan 2: setInventory(2) |
Pesan 2: setInventory(2) |
Pesan 1: setInventory(5) |
Tingkat inventaris: 2 |
Tingkat inventaris: 5 |
Dalam model antrean pesan, urutan masuknya pesan sangatlah penting karena pesan berisi nilai yang telah dihitung sebelumnya. Dalam contoh ini, jika pesan masuk dalam urutan yang benar, tingkat inventarisnya adalah 2. Namun, jika pesan masuk secara tidak berurutan, tingkat inventarisnya adalah 5, dan itu tidak akurat.
Tabel berikut membandingkan tingkat inventaris sistem berbasis pub/sub yang menerima jumlah inventaris dalam urutan yang benar, dengan sistem yang sama yang menerima jumlah inventaris secara tidak berurutan:
| Pub/sub (urutan benar) | Pub/sub (tidak berurutan) |
|---|---|
| Inventaris awal: 4 | Inventaris awal: 4 |
Pesan 2: "inventory":-3 |
Pesan 1: "inventory":+1 |
Pesan 1: "inventory":+1 |
Pesan 2: "inventory":-3 |
Tingkat inventaris: 2 |
Tingkat inventaris: 2 |
Dalam sistem berbasis pub/sub, urutan pesan tidak penting karena hal itu ditentukan oleh layanan yang menghasilkan peristiwa. Apa pun urutan masuknya pesan, tingkat inventarisnya sekarang akurat.
Diagram berikut menunjukkan bahwa, dalam model antrean pesan, antrean mengeksekusi perintah yang memberi tahu pelanggan bagaimana status akan berubah, sedangkan dalam model pub/sub, pelanggan bereaksi terhadap data peristiwa yang menyatakan apa yang telah terjadi di penayang:
Mengimplementasikan arsitektur berbasis peristiwa
Ada berbagai konsep yang perlu dipertimbangkan saat mengimplementasikan arsitektur berbasis peristiwa. Bagian berikut memperkenalkan beberapa topik tersebut.
Jaminan pengiriman
Salah satu konsep yang mengemuka dalam diskusi sistem adalah keandalan jaminan pengiriman pesan. Vendor dan sistem yang berbeda mungkin memberikan tingkat keandalan yang berbeda, sehingga penting untuk memahami variasinya.
Jenis jaminan yang pertama mengajukan pertanyaan sederhana: jika pesan terkirim, adakah jaminan bahwa pesan tersebut akan sampai? Inilah yang disebut pengiriman setidaknya satu kali. Pesan dijamin akan sampai minimal satu kali, tetapi mungkin dikirim lebih dari sekali.
Jenis jaminan yang kedua adalah pengiriman paling banyak satu kali. Dengan pengiriman paling banyak satu kali, pesan akan sampai maksimal satu kali, tetapi tidak ada jaminan bahwa pesan tersebut akan benar-benar sampai.
Variasi jaminan pengiriman yang terakhir adalah pengiriman tepat satu kali. Dalam model ini, sistem mengirim satu dan hanya satu salinan pesan yang dijamin akan sampai.
Urutan dan duplikat
Dalam arsitektur lokal, pesan sering mengikuti model FIFO. Untuk mewujudkan model ini, sebuah sistem pemrosesan terpusat akan mengelola perangkaian pesan untuk memastikan pengurutan yang akurat. Pesan yang diurutkan menimbulkan tantangan karena untuk setiap pesan yang gagal, semua pesan harus dikirim ulang secara berurutan. Setiap sistem terpusat dapat menjadi tantangan untuk ketersediaan dan skalabilitas. Penskalaan sistem pusat yang mengelola pengurutan biasanya hanya dapat dilakukan dengan menambahkan lebih banyak resource ke mesin yang ada. Dengan satu sistem yang mengelola urutan, setiap masalah keandalan akan memengaruhi seluruh sistem, bukan hanya mesin itu saja.
Layanan pesan yang memiliki skalabilitas dan ketersediaan tinggi sering menggunakan beberapa sistem pemrosesan untuk memastikan pesan sampai setidaknya satu kali. Dengan banyak sistem, pengelolaan urutan pesan tidak dapat dijamin.
Arsitektur berbasis peristiwa tidak mengandalkan urutan pesan dan dapat menoleransi pesan duplikat. Jika urutan diperlukan, subsistem dapat mengimplementasikan teknik agregasi dan windowing. Namun, pendekatan ini mengorbankan skalabilitas dan ketersediaan dalam komponen tersebut.
Teknik pemfilteran dan fanout
Karena stream peristiwa dapat berisi data yang mungkin diperlukan atau tidak diperlukan oleh setiap pelanggan, kebutuhan untuk membatasi data yang diterima pelanggan tertentu sering kali diperlukan. Ada dua pola untuk mengelola persyaratan ini: filter peristiwa dan fanout peristiwa.
Diagram berikut menunjukkan sistem berbasis peristiwa dengan filter peristiwa yang memfilter pesan untuk pelanggan:
Dalam diagram sebelumnya, filter peristiwa menggunakan mekanisme pemfilteran yang membatasi peristiwa yang sampai kepada pelanggan. Dalam model ini, satu topik berisi semua variasi dari sebuah pesan. Alih-alih membuat pelanggan membaca setiap pesan dan memverifikasi apakah pesan tersebut berlaku, logika pemfilteran dalam sistem pesan akan mengevaluasi pesan tersebut dan menjaganya dari pelanggan lainnya.
Diagram berikut menunjukkan variasi pola pemfilteran peristiwa yang disebut fanout peristiwa, yang menggunakan multi-topik:
Dalam diagram di atas, topik utama berisi semua variasi dari sebuah pesan, tetapi mekanisme fanout peristiwa menayangkan ulang pesan tersebut pada topik yang terkait dengan sebagian pelanggan tersebut.
Antrean pesan yang belum diproses
Dalam sistem terbaik sekalipun, kegagalan dapat terjadi. Antrean pesan yang belum diproses merupakan teknik untuk menangani kegagalan semacam itu. Dalam sebagian besar arsitektur berbasis peristiwa, sistem pesan akan terus memberikan pesan kepada pelanggan hingga pelanggan tersebut mengonfirmasinya.
Jika ada masalah dengan sebuah pesan—misalnya karakter yang tidak valid dalam isi pesan—pelanggan mungkin tidak dapat mengonfirmasi pesan tersebut. Sistem dapat gagal menangani skenario ini atau bahkan dapat menghentikan proses.
Sistem biasanya mencoba kembali pesan yang tidak terkonfirmasi atau salah. Jika pesan yang tidak valid tidak dikonfirmasi setelah jangka waktu yang ditentukan, pesan akan kehabisan waktu dan dihapus dari topik. Dari sudut pandang operasional, sebaiknya tinjau pesan agar tidak hilang. Di sinilah antrean pesan yang belum diproses berperan. Alih-alih dihapus dari topik, pesan akan dipindahkan ke topik lain agar dapat diproses ulang atau ditinjau untuk memahami penyebab error.
Histori stream dan replay
Stream peristiwa merupakan arus data yang berkelanjutan. Akses ke data historis ini sangat berguna. Anda mungkin ingin tahu bagaimana sistem mencapai status tertentu. Anda mungkin memiliki pertanyaan terkait keamanan yang mengharuskan data diaudit. Kemampuan untuk menangkap log historis peristiwa sangat penting dalam operasi jangka panjang sistem berbasis peristiwa.
Salah satu penggunaan umum data peristiwa historis adalah menggunakannya dengan sistem replay. Replay digunakan untuk tujuan pengujian. Dengan memutar ulang data peristiwa dari produksi di lingkungan lain seperti staging dan pengujian, Anda dapat memvalidasi fungsionalitas baru berdasarkan set data sebenarnya. Anda juga dapat memutar ulang data historis untuk memulihkan dari status gagal. Jika sistem tidak aktif atau kehilangan data, tim dapat memutar ulang histori peristiwa dari titik akurat yang diketahui dan layanan dapat membangun ulang status yang hilang.
Merekam peristiwa ini dalam antrean berbasis log atau stream logging juga berguna saat pelanggan memerlukan akses ke urutan peristiwa pada waktu berlainan. Stream logging dapat dilihat dalam sistem dengan kapabilitas offline. Dengan menggunakan histori stream, Anda dapat memproses entri baru terkini dengan membaca stream tersebut mulai dari pointer last-read (terakhir dibaca).
Tampilan data: real-time dan hampir real-time
Dengan semua data yang mengalir melalui sistem, penting bagi Anda untuk dapat menggunakan data tersebut. Ada banyak teknik untuk mengakses dan menggunakan stream peristiwa ini, tetapi kasus penggunaan yang umum adalah untuk memahami status data secara keseluruhan pada momen tertentu. Hal ini sering kali berupa pertanyaan yang berorientasi penghitungan, seperti "berapa banyak" atau "tingkat saat ini" yang dapat digunakan oleh sistem lain atau untuk konsumsi manusia. Ada beberapa implementasi yang dapat menjawab pertanyaan-pertanyaan ini:
- Sistem real-time dapat berjalan terus-menerus dan melacak status saat ini. Namun, karena sistem hanya memiliki penghitungan dalam memori, periode nonaktif apa pun akan menetapkan penghitungan ke nol.
- Sistem dapat menghitung nilai dari tabel histori untuk setiap permintaan, tetapi hal ini bisa menjadi masalah karena mencoba menghitung nilai untuk setiap permintaan, sementara datanya terus bertambah, pada akhirnya makin tidak mungkin dilakukan.
- Sistem dapat membuat snapshot penghitungan pada interval tertentu, tetapi menggunakan snapshot saja tidak mencerminkan data real-time.
Pola yang berguna untuk diimplementasikan adalah arsitektur Lambda yang memiliki kapabilitas real-time dan hampir real-time. Misalnya, halaman produk di sebuah situs e-commerce dapat menggunakan tampilan data inventaris yang hampir real-time. Saat pelanggan melakukan pemesanan, layanan real-time digunakan untuk memastikan pembaruan status data inventaris terbaru. Untuk mengimplementasikan pola ini, layanan merespons permintaan hampir real-time dari tabel snapshot yang berisi nilai terhitung pada interval tertentu. Permintaan real-time menggunakan tabel snapshot dan nilai dalam tabel histori sejak snapshot terakhir untuk mendapatkan status yang benar-benar terbaru. Tampilan terwujud dari stream peristiwa ini memberikan data yang dapat ditindaklanjuti untuk mendorong proses bisnis yang nyata.
Langkah berikutnya
- Baca artikel Pub/Sub atau Cloud Tasks untuk penerusan pesan dan integrasi asinkron.
- Coba panduan memulai Pub/Sub.
- Lihat Ringkasan arsitektur Pub/Sub.
- Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.