Federasi multi-situs dan multi-wilayah
Banyak solusi canggih mengharuskan aliran peristiwa yang sama tersedia untuk dikonsumsi di beberapa lokasi, atau mereka mengharuskan aliran peristiwa dikumpulkan di beberapa lokasi dan kemudian dikonsolidasikan ke lokasi tertentu untuk dikonsumsi. Ada juga kebutuhan untuk memperkaya atau mengurangi aliran peristiwa atau melakukan konversi format peristiwa, juga untuk dalam satu wilayah dan solusi.
Secara praktis, itu berarti solusi Anda akan mempertahankan beberapa Azure Event Hubs, seringkali di berbagai wilayah dan namespace layanan Azure Event Hubs yang berbeda, lalu mereplikasi peristiwa di antara mereka. Anda juga dapat bertukar peristiwa dengan sumber dan target seperti Azure Service Bus, Azure IoT Hub, atau Apache Kafka.
Mempertahankan beberapa Azure Event Hubs aktif di berbagai wilayah juga memungkinkan klien untuk memilih dan beralih di antara mereka jika konten mereka digabungkan, yang membuat sistem keseluruhan lebih tangguh terhadap masalah ketersediaan regional.
Bab "Federasi" ini menjelaskan pola federasi dan cara mewujudkan pola-pola ini menggunakan Azure Stream Analytics tanpa server atau runtime Azure Functions, dengan opsi memiliki kode transformasi atau pengayaan Anda sendiri tepat di jalur alur peristiwa.
Pola Federasi
Ada banyak motivasi potensial mengapa Anda mungkin ingin memindahkan peristiwa antara Azure Event Hubs yang berbeda atau sumber dan target lain, dan kami menghitung pola yang paling penting di bagian ini dan juga menautkan ke panduan yang lebih rinci untuk pola masing-masing.
- Ketahanan terhadap peristiwa ketersediaan regional
- Pengoptimalan latensi
- Validasi, pengurangan, dan pengayaan
- Integrasi dengan layanan analitik
- Konsolidasi dan normalisasi aliran peristiwa
- Memisahkan dan perutean aliran peristiwa
- Proyeksi log
Ketahanan terhadap peristiwa ketersediaan regional
Meskipun ketersediaan dan keandalan maksimum adalah prioritas operasional teratas untuk Azure Event Hubs, ada banyak cara ketika produsen atau konsumen mungkin dicegah untuk berbicara dengan Azure Event Hubs "utama" yang ditetapkan karena masalah jaringan atau resolusi nama, atau di mana Azure Event Hubs mungkin memang tidak responsif atau mengembalikan kesalahan untuk sementara waktu.
Kondisi seperti itu bukan "bencana" sehingga Anda ingin meninggalkan penyebaran regional sama sekali 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.
Ada dua pola dasar untuk mengatasi skenario tersebut:
- Pola replikasi adalah tentang mereplikasi konten Azure Event Hubs utama ke Azure Event Hubs sekunder, di mana Azure Event Hubs utama umumnya digunakan oleh aplikasi untuk memproduksi dan mengonsumsi peristiwa dan yang sekunder berfungsi sebagai opsi alternatif jika Azure Event Hubs utama tidak tersedia. Karena replikasi tidak searah, dari primer ke sekunder, peralihan produsen dan konsumen dari primer yang tidak tersedia ke sekunder akan menyebabkan primer lama tidak lagi menerima peristiwa baru dan karenanya tidak akan lagi kekinian. Oleh karena itu replikasi murni hanya cocok untuk skenario kegagalan satu arah. Setelah kegagalan dilakukan, primer lama ditinggalkan dan Azure Event Hubs sekunder baru perlu dibuat di wilayah target yang berbeda.
- Polapenggabungan memperluas pola replikasi dengan melakukan penggabungan berkelanjutan dari konten dua Azure Event Hubs atau lebih. Setiap peristiwa yang awalnya diproduksi untuk salah satu Azure Event Hubs yang disertakan dalam skema direplikasi ke Azure Event Hubs lainnya. Ketika peristiwa direplikasi, mereka dianotasi sedemikian rupa sehingga mereka kemudian diabaikan oleh proses replikasi dari target replikasi. Hasil penggunaan pola penggabungan adalah dua atau lebih Azure Event Hubs yang akan berisi set peristiwa yang sama dengan mode yang akhirnya konsisten.
Dalam kedua kasus tersebut, konten Azure Event Hubs tidak akan identik. Peristiwa dari salah satu produsen dan dikelompokkan berdasarkan kunci partisi yang sama akan muncul dalam urutan relatif yang sama seperti yang semula dikirimkan, tetapi urutan peristiwa absolutnya mungkin berbeda. Hal ini terutama berlaku untuk skenario di mana jumlah partisi sumber dan target Azure Event Hubs berbeda, yang diinginkan untuk beberapa pola perluasan yang dijelaskan di sini. Splitter atau router dapat memperoleh irisan Azure Event Hubs yang jauh lebih besar dengan ratusan partisi dan corong menjadi Azure Event Hubs yang lebih kecil hanya dengan beberapa partisi, lebih cocok untuk menangani subset dengan sumber daya pemrosesan terbatas. Sebaliknya, konsolidasi dapat menyalurkan data dari beberapa Azure Event Hubs yang lebih kecil ke dalam Azure Event Hubs tunggal yang lebih besar dengan lebih banyak partisi untuk mengatasi throughput konsolidasi dan kebutuhan pemrosesan.
Kriteria untuk menjaga peristiwa bersama-sama adalah kunci partisi dan bukan ID partisi asli. Pertimbangan lebih lanjut tentang urutan relatif dan cara melakukan kegagalan dari satu Azure Event Hubs ke yang berikutnya tanpa mengandalkan cakupan offset aliran yang sama dibahas dalam deskripsi pola replikasi.
Panduan:
Pengoptimalan latensi
Aliran peristiwa ditulis oleh produsen sekali, tetapi dapat dibaca berkali-kali oleh konsumen peristiwa. Untuk skenario ketika aliran peristiwa di suatu wilayah dibagikan oleh beberapa konsumen, dan perlu diakses berulang kali selama pemrosesan analitik yang berada di wilayah yang berbeda, atau dengan seluruh tuntutan yang akan membuat konsumen yang bersamaan kelaparan, mungkin bermanfaat untuk menempatkan salinan aliran peristiwa di dekat prosesor analitik untuk mengurangi latensi pulang pergi.
Contoh yang baik tentang kapan replikasi sebaiknya lebih disukai daripada mengonsumsi peristiwa dari jarak jauh dari seluruh wilayah adalah terutama untuk wilayah yang sangat jauh terpisah, misalnya Eropa dan Australia yang hampir antipoda secara geografis dan keterlambatan jaringan dapat dengan mudah melebihi 250 ms untuk setiap perjalanan pulang pergi. Anda tidak dapat mempercepat kecepatan cahaya, tetapi Anda dapat mengurangi jumlah perjalanan pulang pergi berlatensi tinggi untuk berinteraksi dengan data.
Panduan:
Validasi, pengurangan, dan pengayaan
Aliran peristiwa dapat dikirimkan ke Azure Event Hubs oleh klien di luar solusi Anda sendiri. Aliran peristiwa tersebut mungkin mengharuskan peristiwa yang dikirim secara eksternal untuk diperiksa kepatuhannya terhadap skema tertentu, dan agar peristiwa yang tidak sesuai kepatuhan dihilangkan.
Dalam skenario ketika klien sangat dibatasi bandwidth seperti halnya dalam banyak skenario kasus "Internet of Things" dengan bandwidth terukur, atau ketika peristiwa awalnya dikirim melalui jaringan non-IP dengan ukuran paket yang dibatasi, peristiwa tersebut mungkin harus diperkaya dengan data referensi untuk menambahkan konteks lebih lanjut agar dapat digunakan oleh prosesor peristiwa hilir.
Dalam kasus lain, terutama ketika aliran sedang dikonsolidasikan, data peristiwa mungkin harus dikurangi kompleksitas atau ukurannya dengan menghilangkan beberapa detail.
Salah satu operasi ini dapat terjadi sebagai bagian dari replikasi, konsolidasi, atau penggabungan alur.
Panduan:
Integrasi dengan layanan analitik
Beberapa layanan analitik cloud-native Azure seperti Azure Stream Analytics atau Azure Synapse bekerja paling baik dengan aliran data atau data pra-batch yang disajikan dari Azure Event Hubs, dan Azure Event Hubs juga memungkinkan integrasi dengan beberapa paket analitik sumber terbuka seperti Apache Samza, Apache Flink, Apache Spark, dan Apache Storm.
Jika solusi Anda terutama menggunakan Azure Service Bus atau Event Grid, Anda dapat membuat peristiwa ini mudah diakses oleh sistem analitik tersebut dan juga untuk pengarsipan dengan Azure Event Hubs Capture jika Anda menyalurkannya ke Azure Event Hubs. Event Grid dapat melakukannya secara asli dengan integrasi Azure Event Hubs-nya, untuk Azure Service Bus Anda mengikuti panduan replikasi Azure Service Bus.
Azure Stream Analytics terintegrasi dengan Hub Peristiwa secara langsung.
Panduan:
Konsolidasi dan normalisasi aliran peristiwa
Solusi global sering terdiri dari jejak regional yang sebagian besar independen termasuk memiliki kemampuan analitik mereka sendiri, tetapi perspektif analitik supra-regional dan global akan membutuhkan perspektif terintegrasi dan itulah sebabnya konsolidasi sentral dari aliran peristiwa yang sama yang dievaluasi dalam jejak regional masing-masing untuk perspektif lokal.
Normalisasi adalah rasa dari skenario konsolidasi, di mana dua atau lebih aliran peristiwa yang masuk membawa jenis peristiwa yang sama, tetapi dengan struktur yang berbeda atau pengkodean yang berbeda, dan peristiwa yang paling banyak ditranskodekan atau diubah sebelum dapat dikonsumsi.
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.
Panduan:
Pemisahan dan perutean aliran peristiwa
Azure Event Hubs kadang-kadang digunakan dalam skenario gaya "terbitkan-berlangganan" di mana torrent masuk peristiwa yang terserap jauh melebihi kapasitas Azure Service Bus atau Azure Event Grid, yang keduanya memiliki kemampuan pemfilteran dan distribusi terbitkan-berlangganan asli dan lebih disukai untuk pola ini.
Sementara kemampuan "terbitkan-berlangganan" sejati menyerahkannya kepada pelanggan untuk memilih peristiwa yang mereka inginkan, pola pemisahan memiliki peristiwa peta produsen ke partisi oleh model distribusi yang telah ditentukan dan konsumen yang ditunjuk kemudian secara eksklusif menarik dari partisi "mereka". Karena Azure Event Hubs melakukan buffering atas lalu lintas keseluruhan, konten partisi tertentu, yang mewakili sebagian kecil dari volume throughput asli, kemudian dapat direplikasi menjadi antrean untuk konsumsi konsumen yang andal, transaksional, dan bersaing.
Banyak skenario di mana Azure Event Hubs terutama digunakan untuk memindahkan peristiwa dalam aplikasi dalam suatu wilayah memiliki beberapa kasus di mana peristiwa tertentu, mungkin hanya dari satu partisi, juga harus tersedia di tempat lain. Skenario ini mirip dengan skenario pemisahan, tetapi mungkin menggunakan router yang dapat diskalakan yang mempertimbangkan semua pesan yang tiba di Azure Event Hubs dan hanya memilih beberapa untuk perutean seterusnya dan mungkin membedakan target perutean berdasarkan metadata peristiwa atau konten.
Panduan:
Proyeksi log
Dalam beberapa skenario, Anda ingin memiliki akses ke nilai terbaru yang dikirim untuk setiap subaliran suatu peristiwa, dan biasanya dibedakan oleh kunci partisi. Di Apache Kafka, hal ini seringkali dicapai dengan mengaktifkan "pemadatan log" pada sebuah topik, yang membuang semua kecuali peristiwa terbaru yang dilabeli dengan kunci unik apa pun. Pendekatan pemadatan log memiliki tiga kelemahan penggabungan:
- Pemadatan memerlukan reorganisasi log secara berkelanjutan, yang merupakan operasi yang terlalu mahal untuk broker yang dioptimalkan untuk beban kerja tambahan saja.
- Pemadatan bersifat merusak dan tidak memungkinkan perspektif yang dipadatkan dan tidak dipadatkan dari aliran yang sama.
- Aliran yang dipadatkan masih memiliki model akses berurutan, yang berarti bahwa menemukan nilai yang diinginkan dalam log mengharuskan membaca seluruh log dalam kasus terburuk, yang biasanya mengarah pada pengoptimalan yang mengimplementasikan pola yang tepat yang disajikan di sini: memproyeksikan konten log ke dalam database atau cache.
Pada akhirnya, log yang dipadatkan adalah penyimpanan bernilai kunci dan dengan demikian, ini adalah opsi implementasi terburuk yang mungkin untuk penyimpanan semacam itu. Jauh lebih efisien untuk pencarian dan kueri untuk membuat dan menggunakan proyeksi permanen log ke penyimpanan bernilai kunci yang tepat atau beberapa database lainnya.
Karena peristiwa tidak dapat diubah dan urutan selalu dipertahankan dalam log, proyeksi log apa pun ke penyimpanan bernilai kunci akan selalu identik untuk berbagai peristiwa yang sama, yang berarti bahwa proyeksi yang terus Anda perbarui selalu memberikan tampilan otoritatif dan tidak pernah ada alasan yang baik untuk membangunnya kembali dari konten log setelah dibuat.
Panduan:
Teknologi aplikasi replikasi
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 tersebut adalah tugas stateless adalah Azure Stream Analytics untuk tugas replikasi aliran stateful dan Azure Functions untuk tugas replikasi stateless.
Aplikasi replikasi stateful di Azure Stream Analytics
Untuk aplikasi replikasi stateful yang perlu mempertimbangkan hubungan antar peristiwa, membuat peristiwa komposit, memperkaya peristiwa, atau mengurangi peristiwa, membuat agregasi data, dan mengubah muatan peristiwa, Azure Stream Analytics adalah opsi implementasi terbaik.
Di Azure Stream Analytics, Andamembuat pekerjaan yang mengintegrasikan input dan output dan mengintegrasikan data dari input melalui kueri yang menghasilkan hasil yang kemudian tersedia di output.
Kueri didasarkan pada bahasa kueri SQL dan dapat digunakan untuk memfilter, mengurutkan, menggabungkan, dan menggabungkan data streaming dengan mudah selama periode waktu tertentu. Anda juga dapat memperluas bahasa SQL ini denganJavaScript dan C# fungsi yang ditentukan pengguna (UDF). Anda dapat dengan mudah menyesuaikan opsi urutan peristiwa dan durasi jendela waktu saat melakukan operasi agregasi melalui konstruksi dan/atau konfigurasi bahasa sederhana.
Setiap pekerjaan memiliki satu atau beberapa output untuk data yang ditransformasi, dan Anda dapat mengontrol apa yang terjadi sebagai respons terhadap informasi yang telah Anda analisis. Sebagai contoh, Anda dapat:
- Mengirim data ke layanan seperti Azure Functions, Topik Azure Service Bus, atau Antrean untuk memicu komunikasi atau alur kerja kustom di hilir.
- Mengirim data ke dasbor Power BI untuk dasbor real-time.
- Menyimpan data di layanan penyimpanan Azure lainnya (misalnya, Azure Data Lake, Azure Synapse Analytics, dll.) untuk melakukan analisis batch atau melatih model pembelajaran mesin berdasarkan kumpulan data historis yang sangat besar dan terindeks.
- Menyimpan proyeksi (juga disebut "tampilan materialisasi") dalam database (SQL Database, Azure Cosmos DB).
Aplikasi replikasi stateless di Azure Functions
Untuk tugas replikasi stateless di mana Anda ingin meneruskan peristiwa tanpa mempertimbangkan payload atau proses mereka sendiri-sendiri tanpa harus mempertimbangkan hubungan peristiwa (kecuali urutan relatifnya), Anda dapat menggunakan Azure Functions, yang memberikan fleksibilitas luar biasa.
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 akan secara dinamis beradaptasi dengan kebutuhan throughput dengan menskalakan jumlah instans yang mengeksekusi secara bersamaan ke atas dan ke bawah berdasarkan metrik yang terdokumentasi.
Untuk membangun proyeksi log, Azure Functions mendukung pengikatan output untuk Azure Cosmos DB dan Azure Table Storage.
Azure Functions dapat berjalan di bawah identitas terkelola Azure dan dengan itu, ia dapat menahan nilai konfigurasi untuk info masuk dalam penyimpanan yang dikontrol dengan akses 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 itu mudah diintegrasikan dengan Azure Monitor.
Dengan paket konsumsi Azure Functions, pemicu bawaan bahkan dapat menurunkan skala ke nol ketika tidak ada pesan yang tersedia untuk direplikasi, yang berarti Anda tidak dikenakan biaya untuk menjaga agar konfigurasi siap untuk menskalakan kembali; kelemahan utama penggunaan paket konsumsi adalah bahwa latensi untuk tugas replikasi "bangun" dari kondisi ini secara signifikan lebih tinggi daripada dengan paket hosting di mana infrastruktur tetap berjalan.
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.
Memilih antara Azure Functions dan Azure Stream Analytics
Azure Stream Analytics (ASA) adalah opsi terbaik kapan pun Anda perlu memproses payload peristiwa Anda saat mereplikasinya. ASA dapat menyalin peristiwa satu per satu atau membuat agregat yang memadatkan informasi aliran peristiwa sebelum meneruskannya. Ini dapat dengan mudah bersandar pada melengkapi data referensi yang diadakan di Azure Blob Storage atau Azure SQL Database tanpa harus mengimpor data tersebut ke dalam aliran.
Dengan ASA, Anda dapat dengan mudah membuat tampilan aliran yang persisten dan terwujud dalam database skala hiper. Ini adalah pendekatan yang jauh lebih unggul untuk model "pemadatan log" yang kaku dari Apache Kafka dan proyeksi tabel berorientasi klien yang mudah menguap dari Kafka Streams.
ASA dapat dengan mudah memproses peristiwa yang memiliki payload yang dikodekan dalam format CSV, JSON, dan Apache Avro dan Anda dapat mencolokkan deserializer kustom untuk format lain.
Untuk semua tugas replikasi di mana Anda ingin menyalin aliran peristiwa "apa adanya" dan tanpa menyentuh payload, atau jika Anda perlu menerapkan router, melakukan pekerjaan kriptografi, mengubah pengkodean payload, atau jika perlu kontrol penuh atas konten aliran data, Azure Functions adalah opsi terbaik.
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 Stream Analytics atau Azure Functions lalu cara mereplikasi alur peristiwa antara Hub Peristiwa dan berbagai sistem peristiwa dan olah pesan lainnya: