Replikasi pesan dan federasi lintas wilayah
Dalam namespace, Azure Service Bus mendukung pembuatan topologi antrean berantai dan langganan topik menggunakan autoforwarding untuk memungkinkan penerapan berbagai pola perutean. Misalnya, Anda dapat menyediakan antrean khusus ke tujuan dengan izin yang sudah dikirim atau diterima mitra dan yang dapat ditangguhkan sementara jika diperlukan, serta secara fleksibel menyambungkan mereka ke entitas lain yang bersifat pribadi ke aplikasi. Anda juga dapat membuat topologi perutean multitahap yang kompleks, atau membuat antrean bergaya kotak surat yang mengosongkan langganan topik seperti antrean dan memungkinkan kapasitas penyimpanan yang lebih banyak per pelanggan.
Sejumlah solusi canggih juga mengharuskan pesan untuk direplikasi di seluruh batas namespace guna mengimplementasikan ini dan pola lainnya. Pesan mungkin harus mengalir di antara namespace yang terkait dengan beberapa penyewa aplikasi yang berbeda, atau di beberapa wilayah Azure yang berbeda.
Solusi Anda akan mempertahankan beberapa namespace Service Bus di berbagai wilayah dan mereplikasi pesan antara Antrean dan Topik, dan /atau Anda akan bertukar pesan dengan sumber serta target seperti Azure Event Hubs, Azure IoT Hub,atau Apache Kafka.
Skenario ini adalah fokus artikel ini.
Pola Federasi
Ada banyak motivasi potensial terkait alasan Anda mungkin ingin memindahkan pesan antara entitas Service Bus seperti Antrean atau Topik, atau antara Service Bus dan sumber serta target lainnya.
Dibandingkan dengan set pola serupa untuk Event Hubs, federasi untuk entitas seperti antrean lebih kompleks karena antrean pesan menjanjikan konsumen mereka kepemilikan eksklusif atas pesan apa pun, diharapkan untuk mempertahankan urutan kedatangan dalam pengiriman pesan, dan broker-nya mengoordinasikan distribusi pesan yang adil antar konsumen yang bersaing.
Ada hambatan praktis, termasuk kendala teorema CAP, yang menyulitkan untuk memberikan pandangan terpadu tentang antrean yang secara bersamaan tersedia di beberapa wilayah, dan yang memungkinkan konsumen yang bersaing yang terdistribusi secara regional untuk mengambil kepemilikan eksklusif pesan. Antrean terdistribusi geografis tersebut akan membutuhkan replikasi yang sepenuhnya konsisten, tidak hanya dari pesan, tetapi juga dari status pengiriman setiap pesan sebelum pesan dapat disediakan untuk konsumen. Tujuan konsistensi penuh untuk antrean hipotetis yang didistribusikan secara regional bertentangan langsung dengan tujuan utama yang secara praktis dimiliki semua pelanggan Azure Service Bus ketika mempertimbangkan skenario federasi: Ketersediaan dan keandalan maksimum untuk solusi mereka.
Oleh karena itu, pola yang disajikan di sini berfokus pada ketersediaan dan keandalan, sembari bertujuan sedapat mungkin menghindari kehilangan informasi dan penanganan duplikat pesan.
Ketahanan terhadap peristiwa ketersediaan regional
Meskipun ketersediaan dan keandalan maksimum adalah prioritas operasional teratas untuk Service Bus, ada banyak cara yang memungkinkan produsen atau konsumen dicegah untuk berinteraksi dengan Service Bus "utama" yang ditetapkan karena masalah jaringan atau resolusi nama, atau saat entitas Service Bus mungkin memang tidak responsif atau mengembalikan kesalahan untuk sementara waktu. Prosesor pesan yang ditetapkan mungkin juga menjadi tidak tersedia.
Kondisi seperti itu bukan "bencana" sehingga Anda ingin sepenuhnya meninggalkan penyebaran regional seperti yang mungkin Anda lakukan dalam situasi pemulihan bencana, tetapi skenario bisnis beberapa aplikasi mungkin sudah terpengaruh oleh peristiwa ketersediaan yang berlangsung tidak lebih dari beberapa menit atau bahkan detik. Azure Service Bus sering digunakan di lingkungan cloud hybrid dan dengan klien yang tinggal di sekitar jaringan, misalnya di penyimpanan ritel, restoran, cabang perbankan, lokasi manufaktur, fasilitas logistik, dan bandara. Masalah perutean atau kemacetan jaringan mungkin berdampak pada kemampuan suatu lokasi untuk mencapai titik akhir Service Bus yang ditetapkannya sekalipun titik akhir sekunder di wilayah yang berbeda mungkin dapat dijangkau. Pada saat yang sama, sistem yang memproses pesan yang tiba dari lokasi ini mungkin masih memiliki akses tanpa hambatan ke titik akhir Service Bus utama dan sekunder.
Ada banyak contoh praktis dari aplikasi cloud hybrid dan edge tersebut dengan toleransi bisnis yang rendah untuk dampak masalah perutean jaringan atau masalah ketersediaan sementara entitas Service Bus. Hal tersebut termasuk pemrosesan pembayaran di lokasi ritel, boarding di gerbang bandara, serta pesanan ponsel di restoran dan semuanya tersedia secara instan, dan menyelesaikan kemacetan setiap kali jalur komunikasi yang dapat diandalkan tidak tersedia.
Dalam kategori ini, kita membahas tiga pola terdistribusi yang berbeda: replikasi "aktif-penuh", replikasi "aktif-pasif", dan replikasi "tumpahan".
Replikasi Aktif-Penuh
Pola replikasi "aktif-penuh" memungkinkan replika aktif dari topik logis yang sama (atau antrean) untuk tersedia di beberapa namespace (dan wilayah), dan agar semua pesan tersedia di semua replika, terlepas dari tempat pesan mengantre. Pola tersebut umumnya mempertahankan urutan pesan yang berkaitan dengan penerbit mana pun.
Seperti yang ditunjukkan dalam ilustrasi, pola ini umumnya didasarkan pada Topik Service Bus. Satu topik untuk setiap namespace yang akan berpartisipasi dalam skema replikasi. Setiap topik ini memiliki satu "langganan replikasi" untuk salah satu topik lain yang pesannya harus direplikasi. Dalam ilustrasi di atas, kita hanya memiliki sepasang topik, yang artinya, satu langganan replikasi untuk masing-masing topik lain. Dalam skenario dengan tiga namespace {n1, n2, n3} , topik di namespace n1 akan memiliki dua langganan replikasi, satu untuk topik yang sesuai di n2 dan satu untuk topik yang sesuai di n3.
Setiap langganan replikasi memiliki aturan yang menggabungkan ekspresi filter SQL (replicated <> 1) dan tindakan SQL (set replicated = 1). Filter aturan memastikan bahwa hanya pesan dengan properti kustom replication yang tidak diatur atau tidak memiliki nilai 1 yang memenuhi syarat untuk langganan ini, dan tindakan ini menetapkan properti tepat ke nilai 1 di setiap pesan yang dipilih setelahnya. Efeknya adalah, ketika disalin ke topik yang sesuai, pesan tidak lagi memenuhi syarat untuk replikasi ke arah yang berlawanan, oleh karena itu, kita menghindari pesan memantul di antara replika.
Langganan dengan aturan masing-masing dapat dengan mudah ditambahkan ke topik apa pun menggunakan Azure CLI seperti ini.
az servicebus topic subscription rule create --resource-group myresourcegroup \
--namespace mynamespace --topic-name mytopic \
--subscription-name replication --name replication \
--action-sql-expression "set replication = 1" \
--filter-sql-expression "replication IS NULL"
Untuk memodelkan antrean, setiap topik dibatasi hanya untuk satu langganan reguler (selain langganan replikasi) yang dimiliki semua konsumen.
Model replikasi aktif-penuh menempatkan salinan setiap pesan yang dikirim ke salah satu topik ke dalam setiap topik. Artinya, kode aplikasi Anda di setiap wilayah akan melihat dan memproses semua pesan. Pola ini cocok untuk skenario saat data dibagikan ke beberapa wilayah atau jika pemrosesan berlebihan umumnya diinginkan. Jika hanya perlu memproses setiap pesan satu, seperti antrean reguler, Anda perlu mempertimbangkan satu dari dua pola berikut.
Replikasi Aktif-Pasif
Pola replikasi "aktif-pasif" adalah variasi dari pola sebelumnya, dengan hanya salah satu topik ("primer") yang secara aktif digunakan oleh aplikasi untuk mengirim serta menerima pesan dan pesan direplikasi ke topik sekunder untuk kasus jika topik utama mungkin tidak tersedia atau tidak dapat dijangkau.
Perbedaan utama antara pola ini dan pola sebelumnya adalah replikasi tidak langsung dari topik utama menjadi topik sekunder. Topik sekunder tidak pernah menjadi primer, tetapi merupakan opsi cadangan ketika topik primer untuk sementara tidak dapat digunakan.
Perbedaan penggunaan pola ini adalah pola ini mencoba untuk membantu meminimalkan pemrosesan duplikat. Selama replikasi, properti pesan TimeToLive diatur ke durasi pada pesan yang direplikasi yang mencerminkan waktu yang diharapkan selama kegagalan primer akan menyebabkan kegagalan. Misalnya, jika skenario penggunaan Anda memerlukan peralihan konsumen ke sekunder dalam waktu paling lama 1 menit setelah pengambilan pesan dari primer mulai menunjukkan masalah, sekunder idealnya harus memiliki semua pesan yang tersedia yang tidak dapat Anda akses di primer, tetapi sejumlah kecil pesan yang telah Anda proses dari primer sebelum masalah muncul. Jika kita mengatur TimeToLive ke dua kali periode tersebut, 2 menit, selama replikasi (set sys.TimeToLive = '0:2:0' dalam tindakan aturan), sekunder hanya akan mempertahankan pesan selama 2 menit dan akan membuang yang lebih lama. Artinya, ketika beralih ke sekunder, penerima dapat dengan cepat membaca dan membuang pesan yang lebih lama dari yang terakhir diproses kemudian memproses dari pesan pertama yang belum dilihatnya. Durasi retensi aktual akan bergantung pada kasus penggunaan tertentu dan dengan cepat yang Anda inginkan serta dapat beralih ke sekunder di aplikasi Anda. Pengaturan TimeToLive ini dijalankan dalam kisaran dari beberapa detik hingga beberapa hari.
Sekalipun menggunakan sekunder, aplikasi juga dapat memublikasikan secara langsung ke topik sekunder yang kemudian bertindak seperti topik reguler apa pun. Setelah beralih ke sekunder, konsumen selanjutnya akan melihat perpaduan pesan yang direplikasi dan pesan yang diterbitkan langsung ke sekunder. Oleh karena itu, aplikasi harus terlebih dahulu mengalihkan penerbitan kembali ke primer dan tetap mengizinkan pengosongan pesan yang diterbitkan secara lokal sebelum mengalihkan konsumen kembali ke sekunder. Karena replikasi dilanjutkan secara otomatis setelah primer kembali tersedia, konsumen juga akan mendapatkan pesan baru yang diterbitkan ke primer selama waktu tersebut meskipun dengan latensi yang agak lebih tinggi.
Pola ini cocok untuk skenario saat pesan hanya harus diproses sekali. Aplikasi perlu bekerja sama dalam melacak pesan yang telah diproses dari primer karena akan menemukan duplikat selama durasi jendela failover di sekunder, dan akan kembali menemukan duplikat saat beralih kembali. Kriteria de-duplikasi sebaiknya berupa
MessageIdyang disediakan aplikasi. NilaiEnqueuedTimeUtcjuga cocok sebagai indikator watermark, tetapi aplikasi perlu mengizinkan beberapa jumlah drift jam (beberapa detik) antara primer dan sekunder seperti sistem terdistribusi apa pun.
Replikasi Tumpahan
Pola replikasi "spillover" memungkinkan penggunaan aktif/aktif beberapa entitas Service Bus di beberapa wilayah untuk menangani skenario saat Service Bus sehat, tetapi konsumen kewalahan karena jumlah pesan yang tertunda atau langsung tidak tersedia. Alasannya mungkin database yang mendukung proses konsumen mungkin lambat atau tidak tersedia. Pola ini bekerja dengan antrean biasa dan dengan langganan topik.
Seperti yang ditunjukkan dalam ilustrasi, pola replikasi tumpahan mereplikasi pesan dari antrean atau antrean dead-letter terkait antrean atau langganan ke antrean atau topik yang dipasangkan di namespace yang berbeda.
Tanpa ada situasi kegagalan, kedua namespace digunakan secara paralel, masing-masing menerima beberapa subset dari lalu lintas pesan keseluruhan dan konsumen terkait mereka menangani subset itu. Saat salah satu konsumen mulai menunjukkan tingkat kegagalan yang tinggi atau berhenti langsung, masing-masing pesan akan berakhir dalam antrean dead-letter, baik melalui melebihi jumlah pengiriman atau karena kedaluwarsa. Tugas replikasi kemudian akan mengambilnya dan mengantrekannya kembali ke antrean yang dipasangkan yang menampilkannya ke konsumen yang mungkin sehat.
Jika pemrosesan harus terjadi dalam tenggat waktu tertentu, TimeToLive untuk antrean dan/atau pesan harus diatur sedemikian rupa sehingga pemrosesan masih dapat terjadi tepat waktu oleh sekunder tumpahan, misalnya TimeToLive mungkin diatur ke setengah dari waktu yang diizinkan.
Seperti pola aktif-penuh, aplikasi dapat menambahkan indikator ke pesan apakah pesan telah direplikasi sekali sedemikian rupa sehingga pesan tidak memantul di antara pasangan antrean, tetapi diposting ke dalam antrean tambahan yang bertindak sebagai antrean dead-letter untuk pola komposit.
Pola ini cocok untuk skenario saat perhatian utamanya adalah melindungi dari masalah ketersediaan di konsumen atau sumber daya yang diandalkan konsumen, dan juga untuk mendistribusikan kembali lonjakan lalu lintas pada salah satu antrean yang dipasangkan. Ini juga memberikan perlindungan terhadap salah satu namespace menjadi tidak tersedia jika konsumen membaca dari kedua antrean, tetapi lag replikasi yang diberlakukan oleh masa kedaluwarsa
TimeToLivedapat menyebabkan pesan dalam jendela waktu tersebut terhempas ke namespace yang tidak tersedia.
Pengoptimalan latensi
Topik digunakan untuk mendistribusikan informasi ke beberapa konsumen. Dalam beberapa kasus, terutama konsumen dengan distribusi geografis yang luas, mereplikasi pesan dari topik menjadi topik di namespace sekunder yang lebih dekat dengan konsumen mungkin berguna.
Misalnya, saat berbagi data antara hub regional dan kontinental, lebih efisien untuk mentransfer informasi hanya sekali antar hub dan meminta konsumen mendapatkan salinan data dari hub tersebut.
Transfer replikasi dapat dilakukan dalam sejumlah batch yang sering diperoleh konsumen dan menyelesaikan pesan satu per satu. Dengan latensi jaringan dasar 100 ms antara, misalnya, Amerika Utara dan Eropa, setiap pesan membutuhkan waktu 200 ms lebih lama untuk diproses untuk dua perjalanan pulang-pergi ke entitas terpencil guna memperoleh dan menyelesaikan pesan jika dibandingkan dengan entitas di wilayah yang sama.
Validasi, pengurangan, dan pengayaan
Pesan dapat dikirimkan ke dalam antrean atau topik Service Bus oleh klien di luar solusi Anda sendiri.
Pesan tersebut mungkin memerlukan pemeriksaan kepatuhan terhadap skema tertentu, dan meminta agar pesan yang tidak sesuai dihilangkan atau di-dead-letter. Beberapa pesan mungkin harus dikurangi kompleksitasnya dengan menghilangkan data dan beberapa mungkin harus diperkaya dengan menambahkan data berdasarkan pencarian data referensi. Operasi dapat dilakukan dengan fungsionalitas kustom dalam tugas replikasi.
Replikasi Stream Ke Replikasi
Azure Event Hubs adalah solusi ideal untuk menangani volume ekstrem peristiwa masuk. Tetapi, baik Event Hubs maupun mesin serupa seperti Apache Kafka tidak menyediakan model konsumen bersaing yang dikelola layanan saat beberapa konsumen dapat menangani pesan dari sumber yang sama secara bersamaan tanpa mempertaruhkan pemrosesan duplikat, dan akhirnya menyelesaikan pesan tersebut setelah diproses.
Stream untuk mengantrekan replikasi mentransfer konten satu partisi Event Hub atau konten Event Hub penuh ke dalam antrean Service Bus tempat pesan dapat diproses dengan aman, transaksional, dan dengan konsumen yang bersaing. Replikasi ini juga memungkinkan penggunaan semua kemampuan Service Bus lainnya untuk pesan tersebut, termasuk perutean dengan demultiplexing berdasarkan topik dan sesi.
Konsolidasi dan normalisasi
Solusi global sering terdiri dari jejak regional yang sebagian besar bersifat independen, termasuk memiliki kemampuan analitik mereka sendiri, tetapi perspektif supraregional dan global akan membutuhkan integrasi data, oleh karena itu, konsolidasi sentral dari data pesan yang sama yang dievaluasi dalam jejak regional masing-masing untuk perspektif lokal.
Normalisasi adalah versi skenario konsolidasi saat dua atau lebih urutan pesan yang masuk membawa jenis informasi yang sama, tetapi dengan struktur yang berbeda atau pengkodean yang berbeda, dan pesan harus ditranskodekan atau diubah sebelum dapat digunakan.
Normalisasi juga dapat mencakup pekerjaan kriptografi seperti mendekripsi payload terenkripsi end-to-end dan mengenkripsi ulang dengan kunci dan algoritma yang berbeda untuk audiens konsumen hilir.
Pemisahan dan perutean
Topik Service Bus dan aturan langganannya sering digunakan untuk memfilter aliran pesan untuk audiens tertentu, dan audiens tersebut kemudian mendapatkan set yang difilter dari langganan.
Dalam sistem global saat audiens untuk pesan-pesan tersebut didistribusikan secara global atau milik aplikasi yang berbeda, replikasi dapat digunakan untuk mentransfer pesan dari langganan seperti itu ke antrean atau topik di namespace yang berbeda dari tempat pesan digunakan.
Aplikasi replikasi di Azure Functions
Menerapkan pola di atas memerlukan lingkungan eksekusi yang dapat diskalakan dan dapat diandalkan untuk tugas replikasi yang ingin Anda konfigurasikan dan jalankan. Di Azure, lingkungan runtime yang paling cocok untuk tugas stateless adalah Azure Functions.
Azure Functions dapat dijalankan di identitas terkelola Azure dengan sedemikian rupa sehingga tugas replikasi dapat diintegrasikan dengan aturan kontrol akses berbasis peran dari layanan sumber dan target tanpa Anda harus mengelola rahasia di sepanjang jalur replikasi. Untuk sumber replikasi dan target yang memerlukan kredensial eksplisit, Azure Functions dapat menyimpan nilai konfigurasi untuk kredensial tersebut dalam penyimpanan yang dikontrol dengan ketat di dalam Azure Key Vault.
Azure Functions selanjutnya memungkinkan tugas replikasi untuk secara langsung berintegrasi dengan jaringan virtual Azure dan titik akhir layanan untuk semua layanan olah pesan Azure, dan ini siap diintegrasikan dengan Azure Monitor.
Hal yang paling penting, Azure Functions memiliki pemicu dan pengikatan output yang telah dibuat sebelumnya dan dapat diskalakan untuk Azure Event Hubs, Azure IoT Hub, Azure Service Bus, Azure Event Grid, dan Azure Queue Storage, serta ekstensi kustom untuk RabbitMQ, dan Apache Kafka. Sebagian besar pemicu secara dinamis akan beradaptasi dengan kebutuhan throughput dengan menskalakan jumlah instans yang mengeksekusi secara bersamaan ke atas dan ke bawah berdasarkan metrik yang terdokumentasi.
Dengan paket konsumsi Azure Functions, pemicu bawaan bahkan dapat menurunkan skala ke nol sekalipun tidak ada pesan yang tersedia untuk replikasi, yang berarti Anda tidak dikenakan biaya untuk menjaga konfigurasi siap untuk meningkatkan skala. Kelemahan utama dari penggunaan rencana konsumsi adalah latensi untuk tugas replikasi "bangun" dari keadaan ini secara signifikan lebih tinggi daripada dengan paket hosting tempat infrastruktur tetap dijalankan.
Berbeda dengan semua ini, mesin replikasi yang paling umum untuk olah pesan dan peristiwa seperti MirrorMaker Apache Kafka mengharuskan Anda untuk menyediakan lingkungan hosting dan menskalakan mesin replikasi sendiri. Itu termasuk mengonfigurasikan dan mengintegrasikan fitur keamanan dan jaringan dan memfasilitasi alur data pemantauan, dan kemudian Anda masih tidak memiliki kesempatan untuk menyuntikkan tugas replikasi kustom ke dalam alur.
Tugas replikasi dengan Azure Logic Apps
Alternatif non-coding untuk melakukan replikasi menggunakan Functions adalah menggunakan Logic Apps. Logic Apps memiliki tugas replikasi yang telah ditentukan sebelumnya untuk Azure Service Bus. Tugas ini dapat membantu dalam menyiapkan replikasi antara instans yang berbeda, dan dapat disesuaikan untuk penyesuaian lebih lanjut.
Langkah berikutnya
Dalam artikel ini, kami mengeksplorasi berbagai pola federasi dan menjelaskan peran Azure Functions sebagai runtime replikasi peristiwa dan olah pesan di Azure.
Selanjutnya, Anda mungkin ingin membaca cara menyiapkan aplikasi replikator dengan Azure Functions dan cara mereplikasi alur peristiwa antar Event Hubs dan berbagai sistem peristiwa dan olah pesan lainnya: