Pendekatan arsitektur untuk komputasi di dalam solusi multi-penyewa

Olahpesan asinkron dan komunikasi berbasis peristiwa adalah aset penting saat membangun aplikasi terdistribusi yang terdiri dari beberapa layanan internal dan eksternal. Saat Anda merancang solusi multipenyewa, sangat penting untuk melakukan analisis awal untuk menentukan cara berbagi atau mempartisi pesan yang berkaitan dengan penyewa yang berbeda.

Berbagi sistem olahpesan yang sama atau layanan streaming peristiwa dapat secara signifikan mengurangi kompleksitas biaya operasional dan manajemen. Namun, menggunakan sistem olahpesan khusus untuk setiap penyewa memberikan isolasi data yang lebih baik, mengurangi risiko kebocoran data, menghilangkan masalah Noisy Neighbor, dan memungkinkan untuk membebankan kembali biaya Azure ke penyewa dengan mudah.

Dalam artikel ini, Anda dapat menemukan perbedaan antara pesan dan peristiwa, dan Anda akan menemukan panduan yang dapat diikuti arsitek solusi saat memutuskan pendekatan mana yang akan digunakan untuk olahpesan atau infrastruktur peristiwa dalam solusi multipenyewa.

Pesan, poin data, dan peristiwa diskrit

Semua sistem olahpesan memiliki fungsionalitas serupa, protokol transportasi, dan skenario penggunaan. Misalnya, sebagian besar sistem olahpesan modern mendukung komunikasi asinkron yang menggunakan antrean volatil atau persisten, protokol transportasi AMQP dan HTTPS, pengiriman setidaknya sekali, dan sebagainya. Namun, dengan melihat lebih dekat jenis informasi yang diterbitkan dan bagaimana data dikonsumsi dan diproses oleh aplikasi klien, kita dapat membedakan antara berbagai jenis pesan dan peristiwa. Ada perbedaan penting antara layanan yang memberikan peristiwa dan sistem yang mengirim pesan. Untuk informasi selengkapnya, lihat sumber daya berikut:

• Pilih antara layanan olahpesan Azure - Event Grid, Event Hubs, dan Bus Layanan
• Peristiwa, Poin Data, dan Pesan - Memilih layanan olahpesan Azure yang tepat untuk data Anda

Aktivitas

Kejadian adalah pemberitahuan ringan tentang kondisi atau perubahan status. Kejadian dapat menjadi unit diskret atau bagian dari rangkaian. Peristiwa adalah pesan yang umumnya tidak menyampaikan niat penerbit selain untuk memberi tahu. Peristiwa menangkap fakta dan mengkomunikasikannya ke layanan atau komponen lain. Konsumen acara dapat memproses acara sesuka hati dan tidak memenuhi harapan spesifik apa pun yang dimiliki penerbit. Kita dapat mengklasifikasikan peristiwa ke dalam dua kategori utama:

• Peristiwa diskrit menyimpan informasi tentang tindakan tertentu yang telah dilakukan aplikasi penerbitan. Saat menggunakan komunikasi berbasis peristiwa asinkron, aplikasi menerbitkan peristiwa pemberitahuan ketika sesuatu terjadi dalam domainnya. Satu atau beberapa aplikasi yang mengkonsumsi perlu mengetahui perubahan status ini, seperti perubahan harga dalam aplikasi katalog produk. Konsumen berlangganan peristiwa untuk menerimanya secara asinkron. Ketika peristiwa tertentu terjadi, aplikasi yang menggunakan dapat memperbarui entitas domain mereka, yang dapat menyebabkan lebih banyak peristiwa integrasi diterbitkan.
• Peristiwa seri membawa titik data informasi, seperti pembacaan suhu dari perangkat untuk analisis atau tindakan pengguna dalam solusi analitik klik, sebagai elemen dalam aliran berkelanjutan yang sedang berlangsung. Aliran peristiwa terkait dengan konteks tertentu, seperti suhu atau kelembaban yang dilaporkan oleh perangkat bidang. Semua peristiwa yang terkait dengan konteks yang sama memiliki urutan temporal ketat yang penting saat memproses peristiwa ini dengan mesin pemrosesan aliran peristiwa. Menganalisis aliran peristiwa yang membawa titik data memerlukan akumulasi peristiwa ini dalam buffer yang mencakup jendela waktu yang diinginkan. Atau dapat berada dalam jumlah item yang dipilih dan kemudian memproses peristiwa ini, dengan menggunakan solusi hampir real-time atau algoritma yang dilatih mesin. Analisis serangkaian peristiwa dapat menghasilkan sinyal, seperti rata-rata nilai yang diukur selama jendela waktu yang melewati ambang batas. Sinyal tersebut kemudian dapat dimunculkan sebagai peristiwa diskrit dan dapat ditindak lanjuti.

Peristiwa diskrit melaporkan perubahan status dan dapat ditindaklanjuti. Payload peristiwa memiliki informasi tentang apa yang terjadi, tetapi, secara umum, tidak memiliki data lengkap yang memicu peristiwa. Misalnya, peristiwa memberi tahu konsumen bahwa aplikasi pelaporan membuat file baru di akun penyimpanan. Payload peristiwa mungkin memiliki informasi umum tentang file, tetapi tidak memiliki file itu sendiri. Kejadian diskret sangat ideal untuk solusi tanpa server yang perlu diskalakan.

Kejadian seri melaporkan kondisi dan dapat dianalisis. Peristiwa diskrit diurutkan waktu dan saling terkait. Dalam beberapa konteks, konsumen perlu menerima urutan lengkap peristiwa untuk menganalisis apa yang terjadi dan mengambil tindakan yang diperlukan.

Pesan

Pesan berisi data mentah yang dihasilkan oleh layanan yang akan digunakan atau disimpan di tempat lain. Pesan sering membawa informasi yang diperlukan untuk layanan penerima untuk menjalankan langkah-langkah dalam alur kerja atau rantai pemrosesan. Contoh komunikasi semacam ini adalah pola Perintah. Penerbit mungkin juga mengharapkan penerima pesan untuk menjalankan serangkaian tindakan dan melaporkan kembali hasil pemrosesan mereka dengan pesan asinkron. Kontrak ada antara penerbit pesan dan penerima pesan. Misalnya, penerbit mengirim pesan dengan beberapa data mentah dan mengharapkan konsumen untuk membuat file dari data tersebut dan mengirim kembali pesan respons setelah selesai. Dalam situasi lain, proses pengirim dapat mengirim pesan satu arah asinkron untuk meminta layanan lain melakukan operasi tertentu, tetapi tanpa harapan mendapatkan kembali pesan pengakuan atau respons darinya.

Penanganan pesan kontraktual semacam ini sangat berbeda dari penerbit yang menerbitkan peristiwa diskrit kepada audiens agen konsumen, tanpa harapan khusus tentang bagaimana mereka akan menangani pemberitahuan ini.

Skenario contoh

Berikut adalah daftar beberapa contoh skenario multipenyewa untuk pesan, poin data, dan peristiwa diskrit:

• Peristiwa diskrit:
  • Platform berbagi musik melacak fakta bahwa pengguna tertentu dalam penyewa tertentu telah mendengarkan trek musik tertentu.
  • Dalam aplikasi web toko online, aplikasi katalog mengirimkan peristiwa menggunakan pola Penerbit-Pelanggan ke aplikasi lain untuk memberi tahu mereka bahwa harga item telah berubah.
  • Perusahaan manufaktur mendorong informasi real time kepada pelanggan dan pihak ketiga tentang pemeliharaan peralatan, kesehatan sistem, dan pembaruan kontrak.
• Titik data:
  • Sistem kontrol bangunan menerima peristiwa telemetri, seperti pembacaan suhu atau kelembaban dari sensor yang termasuk dalam beberapa pelanggan.
  • Sistem pemantauan berbasis peristiwa menerima dan memproses log diagnostik dengan cara yang hampir real-time dari beberapa layanan, seperti server web.
  • Skrip sisi klien di halaman web mengumpulkan tindakan pengguna dan mengirimkannya ke solusi analitik klik.
• Pesan:
  • Aplikasi keuangan B2B menerima pesan untuk mulai memproses catatan perbankan penyewa.
  • Alur kerja yang berjalan lama menerima pesan yang memicu eksekusi langkah berikutnya.
  • Aplikasi ke basket aplikasi toko online mengirimkan perintah CreateOrder, dengan menggunakan pesan persisten asinkron ke aplikasi pemesanan.

Pertimbangan dan persyaratan utama

Model penyebaran dan penyewaan yang Anda pilih untuk solusi Anda berdampak mendalam pada keamanan, performa, isolasi data, manajemen, dan kemampuan untuk biaya sumber daya lintas biaya ke penyewa. Analisis ini mencakup model yang Anda pilih untuk infrastruktur olahpesan dan peristiwa Anda. Di bagian ini, kami meninjau beberapa keputusan utama yang harus Anda buat ketika Anda merencanakan sistem olahpesan dalam solusi multipenyewa Anda.

Sisik

Jumlah penyewa, kompleksitas aliran pesan dan aliran peristiwa, volume pesan, profil lalu lintas yang diharapkan, dan tingkat isolasi harus mendorong keputusan saat merencanakan infrastruktur olahpesan atau peristiwa.

Langkah pertama terdiri dari melakukan perencanaan kapasitas lengkap dan menetapkan kapasitas maksimum yang diperlukan untuk sistem olahpesan dalam hal throughput untuk menangani volume pesan yang diharapkan dengan benar di bawah lalu lintas reguler atau puncak.

Beberapa penawaran layanan, seperti tingkat Azure Bus Layanan Premium, menyediakan isolasi sumber daya di tingkat CPU dan memori sehingga setiap beban kerja pelanggan berjalan dalam isolasi. Kontainer sumber daya ini disebut unit Olahpesan. Setiap namespace premium dialokasikan setidaknya satu unit pesan. Anda dapat membeli 1, 2, 4, 8, atau 16 unit olahpesan untuk setiap namespace Bus Layanan Premium. Satu beban kerja atau entitas dapat mencakup beberapa unit olahpesan, dan Anda dapat mengubah jumlah unit olahpesan seperlunya. Hasilnya adalah performa yang dapat diprediksi dan dapat diulang untuk solusi berbasis Bus Layanan Anda. Untuk informasi selengkapnya, lihat Bus Layanan tingkat olahpesan Premium dan Standar. Demikian juga, tingkat harga Azure Event Hubs memungkinkan Anda untuk mengukur namespace layanan, berdasarkan volume peristiwa masuk dan keluar yang diharapkan. Misalnya, penawaran Premium ditagih dengan unit pemrosesan (PUs), yang sesuai dengan berbagi sumber daya terisolasi (CPU, memori, dan penyimpanan) dalam infrastruktur yang mendasar . Throughput penyerapan dan streaming yang efektif per PU akan bergantung pada faktor-faktor berikut:

• Jumlah produsen dan konsumen
• Besar payload
• Jumlah partisi
• Laju permintaan egress
• Penggunaan Event Hubs Capture, Schema Registry, serta fitur canggih lainnya

Untuk informasi selengkapnya, lihat Gambaran Umum Event Hubs Premium.

Ketika solusi Anda menangani sejumlah besar penyewa, dan Anda memutuskan untuk mengadopsi sistem olahpesan terpisah untuk setiap penyewa, Anda harus memiliki strategi yang konsisten untuk mengotomatiskan penyebaran, pemantauan, peringatan, dan penskalaan setiap infrastruktur, secara terpisah satu sama lain.

Misalnya, sistem olahpesan untuk penyewa tertentu dapat disebarkan selama proses provisi menggunakan alat infrastruktur sebagai kode (IaC) seperti templat JSON Terraform, Bicep, atau Azure Resource Manager (ARM) dan sistem DevOps seperti Azure DevOps atau GitHub Actions. Untuk informasi selengkapnya, lihat Pendekatan arsitektur untuk penyebaran dan konfigurasi solusi multipenyewa.

Sistem olahpesan dapat berukuran dengan throughput maksimum dalam pesan per unit waktu. Jika sistem mendukung autoscaling dinamis, kapasitasnya dapat ditingkatkan atau dikurangi secara otomatis, berdasarkan kondisi lalu lintas dan metrik untuk memenuhi perjanjian tingkat layanan yang diharapkan.

Prediksi dan keandalan performa

Saat merancang dan membangun sistem olahpesan untuk sejumlah penyewa terbatas, menggunakan sistem olahpesan tunggal bisa menjadi solusi yang sangat baik untuk memenuhi persyaratan fungsional, dalam hal throughput, dan dapat mengurangi total biaya kepemilikan. Aplikasi multipenyewa mungkin berbagi entitas olahpesan yang sama, seperti antrean dan topik di beberapa pelanggan. Atau mereka mungkin menggunakan sekumpulan komponen khusus untuk masing-masing komponen, untuk meningkatkan isolasi penyewa. Di sisi lain, berbagi infrastruktur olahpesan yang sama di beberapa penyewa dapat mengekspos seluruh solusi untuk masalah Noisy Neighbor. Aktivitas satu penyewa dapat membahayakan penyewa lain, dalam hal performa dan pengoperasian.

Dalam hal ini, sistem olahpesan harus berukuran benar untuk mempertahankan beban lalu lintas yang diharapkan pada waktu sibuk. Idealnya, ini harus mendukung penskalakan otomatis. Sistem olahpesan harus secara dinamis menskalakan ketika lalu lintas meningkat dan menskalakan ketika lalu lintas berkurang. Sistem olahpesan khusus untuk setiap penyewa juga dapat mengurangi risiko Noisy Neighbor, tetapi mengelola sejumlah besar sistem olahpesan dapat meningkatkan kompleksitas solusi.

Aplikasi multipenyewa akhirnya dapat mengadopsi pendekatan hibrid, di mana layanan inti menggunakan serangkaian antrean dan topik yang sama dalam satu sistem olahpesan bersama, untuk mengimplementasikan komunikasi internal dan asinkron. Sebaliknya, layanan lain dapat mengadopsi sekelompok entitas olahpesan khusus atau bahkan sistem olahpesan khusus, bagi setiap penyewa untuk mengurangi masalah Noisy Neighbor dan menjamin isolasi data.

Saat menyebarkan sistem olahpesan ke komputer virtual, Anda harus menemukan bersama komputer virtual ini dengan sumber daya komputasi, untuk mengurangi latensi jaringan. Komputer virtual ini tidak boleh dibagikan dengan layanan atau aplikasi lain, untuk menghindari infrastruktur olahpesan untuk bersaing dengan sumber daya sistem, seperti CPU, memori, dan bandwidth jaringan dengan sistem lain. Komputer virtual juga dapat tersebar di zona ketersediaan, untuk meningkatkan ketahanan intra-wilayah dan keandalan beban kerja penting bisnis, termasuk sistem olahpesan. Misalkan Anda memutuskan untuk menghosting sistem olahpesan, seperti RabbitMQ atau Apache ActiveMQ, pada komputer virtual. Dalam hal ini, sebaiknya sebarkan ke set skala komputer virtual dan mengonfigurasinya untuk penskalaan otomatis, berdasarkan metrik seperti CPU atau memori. Dengan cara ini, jumlah simpul agen yang menghosting sistem olahpesan akan menskalakan dan menskalakan dengan benar, berdasarkan kondisi lalu lintas. Untuk informasi selengkapnya, lihat Gambaran Umum skala otomatis dengan set skala komputer virtual Azure.

Demikian juga, ketika menghosting sistem olahpesan Anda pada kluster Kubernetes, pertimbangkan untuk menggunakan pemilih node dan taint untuk menjadwalkan eksekusi pod-podnya pada kumpulan simpul khusus, tidak dibagikan dengan beban kerja lain, untuk menghindari masalah Noisy Neighbor. Saat menyebarkan sistem olahpesan ke kluster AKS zona-redundan, gunakan batasan penyebaran topologi Pod untuk mengontrol bagaimana pod didistribusikan di seluruh kluster AKS Anda di antara domain kegagalan, seperti wilayah, zona ketersediaan, dan simpul. Saat menghosting sistem olahpesan pihak ketiga di AKS, gunakan penskalaan otomatis Kubernetes untuk menskalakan jumlah simpul pekerja secara dinamis saat lalu lintas meningkat. Dengan Autoscaler Pod Horizontal dan autoscaler kluster AKS, volume simpul dan pod disesuaikan secara dinamis secara real time, agar sesuai dengan kondisi lalu lintas dan untuk menghindari waktu henti yang disebabkan oleh masalah kapasitas. Untuk informasi selengkapnya, lihat Menskalakan kluster secara otomatis untuk memenuhi tuntutan aplikasi pada Azure Kubernetes Service (AKS). Pertimbangkan untuk menggunakan Autoscaling Berbasis Genap (KEDA) Kubernetes, jika Anda ingin menskalakan jumlah pod dari sistem olahpesan yang dihosting Kubernetes, seperti RabbitMQ atau Apache ActiveMQ, berdasarkan panjang antrean tertentu. Dengan KEDA, Anda dapat mendorong penskalaan kontainer apa pun di Kubernetes, berdasarkan jumlah peristiwa yang perlu diproses. Misalnya, Anda dapat menggunakan KEDA untuk menskalakan aplikasi berdasarkan panjang antrean Azure Bus Layanan, antrean RabbitMQ, atau antrean ActiveMQ. Untuk informasi selengkapnya tentang KEDA, lihat Autoscaling berbasis Peristiwa Kubernetes.

Isolasi

Saat merancang sistem olahpesan untuk solusi multipenyewa, Anda harus mempertimbangkan bahwa berbagai jenis aplikasi memerlukan jenis isolasi yang berbeda, yang didasarkan pada persyaratan performa, privasi, dan audit penyewa.

• Beberapa penyewa dapat berbagi entitas olahpesan yang sama, seperti antrean, topik, dan langganan, dalam sistem olahpesan yang sama. Misalnya, aplikasi multipenyewa dapat menerima pesan yang membawa data untuk beberapa penyewa, dari satu antrean Azure Bus Layanan. Solusi ini dapat menyebabkan masalah performa dan skalabilitas. Jika beberapa penyewa menghasilkan volume pesanan yang lebih besar daripada yang lain, ini dapat menyebabkan backlog pesan. Masalah ini, juga dikenal sebagai masalah Noisy Neighbor, dapat menurunkan perjanjian tingkat layanan dalam hal latensi untuk beberapa penyewa. Masalahnya lebih jelas jika aplikasi konsumen membaca dan memproses pesan dari antrean, satu per satu, dalam urutan kronologis yang ketat, dan jika waktu yang diperlukan untuk memproses pesan tergantung pada jumlah item dalam payload. Saat berbagi satu atau beberapa sumber daya antrean di beberapa penyewa, infrastruktur olahpesan dan sistem pemrosesan harus dapat mengakomodasi lalu lintas yang diharapkan berbasis persyaratan skala dan throughput. Pendekatan arsitektur ini sangat cocok dalam skenario tersebut di mana solusi multipenyewa mengadopsi satu kumpulan proses pekerja, untuk menerima, memproses, dan mengirim pesan untuk semua penyewa.
• Beberapa penyewa berbagi sistem olahpesan yang sama tetapi menggunakan topik atau sumber daya antrean yang berbeda. Pendekatan ini memberikan isolasi dan perlindungan data yang lebih baik dengan biaya yang lebih tinggi, peningkatan kompleksitas operasional, dan kelincahan yang lebih rendah karena administrator sistem harus menyediakan, memantau, dan mempertahankan jumlah sumber daya antrean yang lebih tinggi. Solusi ini memastikan pengalaman yang konsisten dan dapat diprediksi untuk semua penyewa, dalam hal performa dan perjanjian tingkat layanan, karena mencegah penyewa membuat hambatan yang dapat memengaruhi penyewa lain.
• Sistem olahpesan khusus yang terpisah digunakan untuk setiap penyewa. Misalnya, solusi multipenyewa dapat menggunakan namespace Azure Bus Layanan yang berbeda untuk setiap penyewa. Solusi ini memberikan tingkat isolasi maksimum, dengan kompleksitas dan biaya operasional yang lebih tinggi. Pendekatan ini menjamin performa yang konsisten dan memungkinkan penyempurnaan sistem olahpesan, berdasarkan kebutuhan penyewa tertentu. Ketika penyewa baru di-onboarding, selain sistem olahpesan yang sepenuhnya khusus, aplikasi provisi mungkin juga perlu membuat identitas terkelola terpisah atau perwakilan layanan dengan izin RBAC yang tepat untuk mengakses namespace yang baru dibuat. Misalnya, ketika kluster Kubernetes dibagikan oleh beberapa instans aplikasi SaaS yang sama, satu untuk setiap penyewa, dan masing-masing berjalan di namespace terpisah, setiap instans aplikasi dapat menggunakan perwakilan layanan atau identitas terkelola yang berbeda untuk mengakses sistem olahpesan khusus. Dalam konteks ini, sistem olahpesan bisa menjadi layanan PaaS yang dikelola sepenuhnya, seperti namespace layanan Azure Bus Layanan, atau sistem olahpesan yang dihosting Kubernetes, seperti RabbitMQ. Saat menghapus penyewa dari sistem, aplikasi harus menghapus sistem olahpesan dan sumber daya khusus apa pun yang sebelumnya dibuat untuk penyewa. Kerugian utama dari pendekatan ini adalah meningkatkan kompleksitas operasional dan mengurangi kelincahan, terutama ketika jumlah penyewa tumbuh dari waktu ke waktu.

Tinjau pertimbangan dan pengamatan tambahan berikut:

• Jika penyewa perlu menggunakan kunci mereka sendiri untuk mengenkripsi dan mendekripsi pesan, solusi multipenyewa harus menyediakan opsi untuk mengadopsi namespace Layanan Azure Bus Layanan Premium terpisah untuk setiap penyewa. Untuk informasi selengkapnya, lihat Mengonfigurasi kunci yang dikelola pelanggan untuk mengenkripsi data Azure Bus Layanan tidak aktif.
• Jika penyewa membutuhkan tingkat ketahanan dan kelangsungan bisnis yang tinggi, solusi multipenyewa harus memberikan kemampuan untuk menyediakan namespace Bus Layanan Premium dengan pemulihan bencana geografis dan zona ketersediaan diaktifkan. Untuk informasi selengkapnya, lihat pemulihan Bencana geografis Azure Service Bus.
• Saat menggunakan sumber daya antrean terpisah atau sistem olahpesan khusus untuk setiap penyewa, wajar untuk mengadopsi kumpulan proses pekerja terpisah, agar masing-masing meningkatkan tingkat isolasi data dan mengurangi kompleksitas berurusan dengan beberapa entitas olahpesan. Setiap instans sistem pemrosesan dapat mengadopsi kredensial yang berbeda, seperti string koneksi, perwakilan layanan, atau identitas terkelola, untuk mengakses sistem olahpesan khusus. Pendekatan ini memberikan tingkat keamanan dan isolasi yang lebih baik antara penyewa, tetapi membutuhkan peningkatan kompleksitas dalam manajemen identitas.

Demikian juga, aplikasi berbasis peristiwa dapat menyediakan tingkat isolasi yang berbeda:

• Aplikasi berbasis peristiwa menerima peristiwa dari beberapa penyewa, melalui satu instans Azure Event Hubs bersama. Solusi ini memberikan tingkat kelincahan yang tinggi, karena onboarding penyewa baru tidak memerlukan pembuatan sumber daya penyerapan peristiwa khusus, tetapi menyediakan tingkat perlindungan data yang rendah, karena bergantian pesan dari beberapa penyewa dalam struktur data yang sama.
• Penyewa dapat memilih pusat aktivitas khusus atau topik Kafka untuk menghindari masalah Noisy Neighbor dan untuk memenuhi persyaratan isolasi data mereka, ketika peristiwa tidak boleh digabungkan dengan penyewa lain, untuk keamanan dan perlindungan data.
• Jika penyewa membutuhkan tingkat ketahanan dan kelangsungan bisnis yang tinggi, multipenyewa harus memberikan kemampuan untuk menyediakan namespace Layanan Premium Azure Event Hubs, dengan pemulihan bencana geografis dan zona ketersediaan diaktifkan. Untuk informasi selengkapnya, lihat Azure Event Hubs - Pemulihan Bencana Geo.
• Azure Event Hubs khusus, dengan Azure Event Hubs Capture diaktifkan, harus dibuat untuk pelanggan yang perlu mengarsipkan peristiwa ke Akun Azure Storage, untuk alasan dan kewajiban kepatuhan peraturan. Untuk informasi selengkapnya, lihat Menangkap peristiwa melalui Azure Event Hubs di Azure Blob Storage atau Azure Data Lake Storage.
• Satu aplikasi multipenyewa dapat mengirim pemberitahuan ke beberapa sistem internal dan eksternal, dengan menggunakan Azure Event Grid. Dalam hal ini, langganan Event Grid terpisah harus dibuat untuk setiap aplikasi konsumen. Jika aplikasi Anda menggunakan beberapa instans Event Grid untuk mengirim pemberitahuan ke sejumlah besar organisasi eksternal, pertimbangkan untuk menggunakan domain peristiwa, yang memungkinkan aplikasi menerbitkan peristiwa ke ribuan topik, seperti satu untuk setiap penyewa. Untuk informasi selengkapnya, lihat Memahami domain peristiwa untuk mengelola topik Event Grid.

Kompleksitas implementasi

Saat merancang solusi multipenyewa, penting untuk mempertimbangkan bagaimana sistem akan berkembang dalam jangka menengah ke panjang, untuk mencegah kompleksitasnya tumbuh dari waktu ke waktu, sampai perlu untuk mendesain ulang bagian dari atau seluruh solusi. Desain ulang ini akan membantu Anda mengatasi peningkatan jumlah penyewa. Saat merancang sistem olahpesan, Anda harus mempertimbangkan pertumbuhan volume pesan dan penyewa yang diharapkan, dalam beberapa tahun ke depan, dan kemudian membuat sistem yang dapat memperluas skala, untuk mengikuti prediksi lalu lintas dan untuk mengurangi kompleksitas operasi, seperti penyediaan, pemantauan, dan pemeliharaan.

Solusinya harus secara otomatis membuat atau menghapus entitas olahpesan yang diperlukan kapan saja aplikasi penyewa disediakan atau tidak disediakan, tanpa perlu operasi manual.

Perhatian khusus untuk solusi data multipenyewa adalah tingkat penyesuaian yang Anda dukung. Penyesuaian apa pun harus dikonfigurasi dan diterapkan secara otomatis oleh sistem provisi aplikasi (seperti sistem DevOps), yang didasarkan pada serangkaian parameter awal, setiap kali aplikasi penyewa tunggal atau multipenyewa disebarkan.

Kompleksitas manajemen dan operasi

Rencanakan dari awal bagaimana Anda berniat untuk mengoperasikan, memantau, dan memelihara infrastruktur olahpesan dan peristiwa Anda dan bagaimana pendekatan multitenansi Anda memengaruhi operasi dan proses Anda. Misalnya, pertimbangkan kemungkinan berikut:

• Anda mungkin berencana untuk menghosting sistem olahpesan yang digunakan oleh aplikasi Anda dalam sekumpulan komputer virtual khusus, satu untuk setiap penyewa. Jika demikian, bagaimana Anda berencana untuk menyebarkan, meningkatkan, memantau, dan menskalakan sistem ini?
• Demikian juga, jika Anda membuat kontainer dan menghosting sistem olahpesan Anda di kluster Kubernetes bersama, bagaimana Anda berencana untuk menyebarkan, meningkatkan, memantau, dan menskalakan sistem olahpesan individual?
• Misalkan Anda berbagi sistem olahpesan di beberapa penyewa. Bagaimana solusi Anda dapat mengumpulkan dan melaporkan metrik penggunaan per penyewa atau membatasi jumlah pesan yang dapat dikirim atau diterima oleh setiap penyewa?
• Saat sistem olahpesan Anda memanfaatkan layanan PaaS, seperti Azure Bus Layanan, Anda harus mengajukan pertanyaan berikut:
  • Bagaimana Anda dapat menyesuaikan tingkat harga untuk setiap penyewa, berdasarkan fitur dan tingkat isolasi (bersama atau khusus) yang diminta oleh penyewa?
  • Bagaimana Anda dapat membuat identitas pengelolaan per penyewa dan penetapan peran Azure untuk menetapkan izin yang tepat hanya ke entitas olahpesan, seperti antrean, topik, dan langganan, yang dapat diakses penyewa? Untuk informasi selengkapnya, lihat Mengautentikasi identitas terkelola dengan ID Microsoft Entra untuk mengakses sumber daya Azure Bus Layanan.
• Bagaimana Anda akan memigrasikan penyewa, jika mereka perlu pindah ke jenis layanan olahpesan yang berbeda, penyebaran yang berbeda, atau wilayah lain?

Biaya

Umumnya, semakin tinggi kepadatan penyewa ke infrastruktur penyebaran Anda, semakin rendah biaya untuk menyediakan infrastruktur itu. Namun, infrastruktur bersama meningkatkan kemungkinan masalah seperti masalah Noisy Neighbor, jadi pertimbangkan tradeoff dengan hati-hati.

Pendekatan dan pola yang perlu dipertimbangkan

Beberapa Pola Desain Cloud dari Azure Architecture Center dapat diterapkan ke sistem olahpesan multipenyewa. Anda dapat memilih untuk mengikuti satu atau beberapa pola secara konsisten, atau Anda dapat mempertimbangkan pola pencampuran dan pencocokan, berdasarkan kebutuhan Anda. Misalnya, Anda dapat menggunakan namespace Bus Layanan multipenyewa untuk sebagian besar penyewa Anda, tetapi kemudian Anda dapat menyebarkan namespace layanan khusus penyewa tunggal Bus Layanan untuk penyewa yang membayar lebih banyak atau yang memiliki persyaratan yang lebih tinggi, dalam hal atau isolasi dan performa. Demikian pula, sering kali merupakan praktik yang baik untuk menskalakan dengan menggunakan stempel penyebaran, bahkan ketika Anda menggunakan namespace Bus Layanan multipenyewa atau namespace khusus dalam stempel.

Pola Stempel Penyebaran

Untuk informasi selengkapnya tentang pola dan multitenansi Stempel Penyebaran, lihat bagian pola Stempel Penyebaran dari pendekatan Arsitektur untuk multipenyewa. Untuk informasi selengkapnya tentang model penyewaan, lihat Model penyewaan untuk dipertimbangkan untuk solusi multipenyewa.

Sistem olahpesan bersama

Anda mungkin mempertimbangkan untuk menyebarkan sistem olahpesan bersama, seperti Azure Bus Layanan, dan membagikannya di semua penyewa Anda.

Pendekatan ini memberikan kepadatan penyewa tertinggi ke infrastruktur, sehingga mengurangi total biaya kepemilikan secara keseluruhan. Ini juga sering mengurangi overhead manajemen, karena ada satu sistem olahpesan atau sumber daya untuk dikelola dan diamankan.

Namun, saat Anda berbagi sumber daya atau seluruh infrastruktur di beberapa penyewa, pertimbangkan peringatan berikut:

• Selalu ingat dan pertimbangkan batasan, kemampuan penskalaan, kuota, dan batas sumber daya yang dimaksud. Misalnya, jumlah maksimum Bus Layanan namespace layanan dalam langganan Azure, jumlah maksimum Azure Event Hubs dalam satu namespace layanan, atau batas throughput maksimum, mungkin pada akhirnya menjadi pemblokir keras, jika dan ketika arsitektur Anda tumbuh untuk mendukung lebih banyak penyewa. Pertimbangkan dengan cermat skala maksimum yang perlu Anda capai dalam hal jumlah namespace per satu langganan Azure, atau antrean per namespace layanan tunggal. Kemudian bandingkan perkiraan Anda saat ini dan di masa mendatang dengan kuota dan batasan yang ada dari sistem olahpesan pilihan, sebelum Anda memilih pola ini.
• Seperti disebutkan di bagian di atas, masalah Noisy Neighbor mungkin menjadi faktor, ketika Anda berbagi sumber daya di beberapa penyewa, terutama jika beberapa sangat sibuk atau jika mereka menghasilkan lalu lintas yang lebih tinggi daripada yang lain. Dalam hal ini, pertimbangkan untuk menerapkan pola Pembatasan atau pola Pembatasan Laju untuk mengurangi efek ini. Misalnya, Anda dapat membatasi jumlah maksimum pesan yang dapat dikirim atau diterima penyewa tunggal dalam satuan waktu.
• Anda mungkin mengalami kesulitan memantau aktivitas dan mengukur konsumsi sumber daya untuk satu penyewa. Beberapa layanan, seperti Azure Bus Layanan, dikenakan biaya untuk operasi olahpesan. Oleh karena itu, ketika Anda berbagi namespace di beberapa penyewa, aplikasi Anda harus dapat melacak jumlah operasi olahpesan yang dilakukan atas nama setiap penyewa dan biaya penagihan balik kepada mereka. Layanan lain tidak memberikan tingkat detail yang sama.

Penyewa mungkin memiliki persyaratan yang berbeda untuk keamanan, ketahanan intra-wilayah, pemulihan bencana, atau lokasi. Jika ini tidak cocok dengan konfigurasi sistem olahpesan Anda, Anda mungkin tidak dapat mengakomodasinya hanya dengan satu sumber daya.

Pola sharding

Pola Sharding melibatkan penyebaran beberapa sistem olahpesan, yang disebut shard, yang berisi satu atau beberapa entitas olahpesan penyewa, seperti antrean dan topik. Tidak seperti stempel penyebaran, pecahan tidak menyiratkan bahwa seluruh infrastruktur diduplikasi. Anda mungkin memecah sistem olahpesan tanpa juga menduplikasi atau memecah infrastruktur lain dalam solusi Anda.

Setiap sistem olahpesan atau pecahan dapat memiliki karakteristik yang berbeda dalam hal keandalan, SKU, dan lokasi. Misalnya, Anda dapat memecah penyewa di beberapa sistem olahpesan dengan karakteristik yang berbeda, berdasarkan lokasi atau kebutuhan mereka dalam hal performa, keandalan, perlindungan data, atau kelangsungan bisnis.

Saat menggunakan pola sharding, Anda perlu menggunakan strategi sharding, untuk memetakan penyewa tertentu ke sistem olahpesan yang berisi antreannya. Strategi pencarian menggunakan peta untuk memorientasi sistem olahpesan target, berdasarkan nama penyewa atau ID. Beberapa penyewa mungkin berbagi shard yang sama, tetapi entitas olahpesan yang digunakan oleh satu penyewa tidak akan tersebar di beberapa pecahan. Peta dapat diimplementasikan dengan satu kamus yang memetakan nama penyewa ke nama atau referensi sistem olahpesan target. Peta dapat disimpan dalam cache terdistribusi yang dapat diakses, oleh semua instans aplikasi multipenyewa, atau di penyimpanan persisten, seperti tabel dalam database relasional atau tabel di akun penyimpanan.

Pola Sharding dapat menskalakan ke jumlah penyewa yang sangat besar. Selain itu, tergantung pada beban kerja Anda, Anda mungkin dapat mencapai kepadatan penyewa yang tinggi hingga pecahan, sehingga biayanya bisa menarik. Pola Sharding juga dapat digunakan untuk mengatasi kuota, batas, dan batasan langganan dan layanan Azure.

Aplikasi multipenyewa dengan sistem olahpesan khusus untuk setiap penyewa

Pendekatan umum lainnya adalah menyebarkan satu aplikasi multipenyewa, dengan sistem olahpesan khusus untuk setiap penyewa. Dalam model penyewaan ini, Anda memiliki beberapa komponen bersama, seperti sumber daya komputasi, sementara layanan lain disediakan, dan dikelola menggunakan pendekatan penyebaran khusus penyewa tunggal. Misalnya, Anda dapat membangun satu tingkat aplikasi, lalu menyebarkan sistem olahpesan individual untuk setiap penyewa, seperti yang ditunjukkan dalam ilustrasi berikut.

Penyebaran yang dipartisi secara horizontal dapat membantu Anda mengurangi masalah tetangga yang berisik, jika Anda telah mengidentifikasi bahwa sebagian besar beban pada sistem Anda disebabkan oleh komponen tertentu yang dapat Anda sebarkan secara terpisah untuk setiap penyewa. Misalnya, Anda mungkin perlu menggunakan sistem olahpesan atau streaming peristiwa terpisah untuk setiap penyewa karena satu instans tidak cukup untuk mengikuti lalu lintas yang dihasilkan oleh beberapa penyewa. Saat menggunakan sistem olahpesan khusus untuk setiap penyewa, jika satu penyewa menyebabkan pesan atau peristiwa dalam volume besar, ini mungkin memengaruhi komponen bersama tetapi bukan sistem olahpesan penyewa lainnya.

Karena Anda menyediakan sumber daya khusus untuk setiap penyewa, biaya untuk pendekatan ini bisa lebih tinggi daripada model hosting bersama. Di sisi lain, lebih mudah untuk membebankan kembali biaya sumber daya dari sistem khusus ke penyewa unik yang memanfaatkannya, saat mengadopsi model penyewaan ini. Pendekatan ini memungkinkan Anda untuk mencapai kepadatan tinggi untuk layanan lain, seperti sumber daya komputasi, dan mengurangi biaya komponen ini.

Dengan penyebaran yang dipartisi secara horizontal, Anda perlu mengadopsi proses otomatis untuk menyebarkan dan mengelola layanan aplikasi multipenyewa, terutama yang digunakan oleh satu penyewa.

Pola geode

Pola Geode melibatkan penyebaran kumpulan layanan backend ke dalam serangkaian simpul geografis. Masing-masing dapat melayani permintaan apa pun untuk klien mana pun di wilayah mana pun. Pola ini memungkinkan Anda untuk melayani permintaan dengan gaya aktif-aktif, yang meningkatkan latensi dan meningkatkan ketersediaan, dengan mendistribusikan pemrosesan permintaan di seluruh dunia.

Azure Bus Layanan dan Azure Event Hubs mendukung pemulihan bencana metadata, di seluruh namespace layanan pemulihan bencana primer dan sekunder dan di seluruh wilayah dan zona ketersediaan terpisah, untuk memberikan dukungan untuk ketahanan intra-wilayah terbaik. Selain itu, Azure Bus Layanan dan Azure Event Hubs menerapkan serangkaian pola federasi yang secara aktif mereplikasi topik logis, antrean, atau hub peristiwa yang sama untuk tersedia di beberapa namespace, akhirnya terletak di wilayah yang berbeda. Untuk informasi selengkapnya, lihat sumber daya berikut:

• Replikasi pesan dan federasi lintas wilayah
• Pola tugas replikasi pesan
• Federasi multi-situs dan multi-wilayah
• Pola tugas replikasi peristiwa

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

• Paolo Salvatori | Teknisi Pelanggan Utama, FastTrack untuk Azure

Kontributor lain:

• John Downs | Teknisi Pelanggan Utama, FastTrack untuk Azure
• Clemens Vasters | Arsitek Utama, Layanan Olahpesan, dan Standar
• Arsen Vladimirskiy | Teknisi Pelanggan Utama, FastTrack untuk Azure

Langkah berikutnya

Untuk informasi selengkapnya tentang pola desain olahpesan, lihat sumber daya berikut ini:

• Pola Pemeriksaan Klaim
• Pola Konsumen yang Bersaing
• Pola Sumber Kejadian
• Pola Pipa dan Filter
• Pola Penerbit-Pelanggan
• Pola Konvoi Berurutan