Bagikan melalui

Pendekatan arsitektur untuk messaging dalam solusi multitenant

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 pengiriman pesan khusus untuk setiap penyewa memberikan isolasi data yang lebih baik, mengurangi risiko kebocoran data, menghilangkan masalah Tetangga Berisik, dan memudahkan pembebanan kembali biaya Azure kepada para penyewa Anda.

Dalam artikel ini, Anda dapat menemukan perbedaan antara pesan-pesan dan event, serta panduan yang dapat diikuti arsitek solusi saat memutuskan pendekatan yang akan digunakan untuk infrastruktur pesan atau event 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:

Acara

Peristiwa adalah notifikasi sederhana 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. Sebuah acara menghimpun fakta dan mengkomunikasikannya ke layanan serta komponen lainnya. 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 mengonsumsi dapat memperbarui entitas domain mereka, yang dapat menyebabkan lebih banyak peristiwa integrasi dipublikasikan.
  • 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 diterapkan pada sejumlah item yang dipilih dan kemudian mengolah peristiwa ini, dengan menggunakan solusi mendekati real-time atau algoritma yang dilatih oleh 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 memuat informasi tentang kejadian tersebut, tetapi, secara umum, tidak memiliki data lengkap yang memicu peristiwa. Misalnya, peristiwa memberi tahu konsumen bahwa aplikasi pelaporan membuat file baru di akun penyimpanan. Muatan acara mungkin mengandung informasi umum tentang file, tetapi tidak menyertakan file tersebut. Kejadian diskret sangat ideal untuk solusi tanpa server yang perlu diskalakan.

Serangkaian kejadian 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 lapisan Azure Service Bus Premium, menyediakan isolasi sumber daya di tingkat CPU dan memori agar setiap beban kerja pelanggan berjalan dalam isolasi. Kontainer sumber daya ini disebut unit olahpesan. Setiap namespace premium diberikan setidaknya satu unit pengiriman pesan. Anda dapat membeli 1, 2, 4, 8, atau 16 unit pesan untuk setiap namespace Service Bus 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 tingkatan olahpesan Premium dan Standar pada Service Bus. 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 bagian sumber daya terisolasi (CPU, memori, dan penyimpanan) dalam infrastruktur yang mendasari. Throughput penyerapan dan streaming yang efektif per PU akan bergantung pada faktor-faktor berikut:

  • Jumlah produsen dan konsumen
  • Ukuran muatan
  • 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 penyediaan menggunakan alat infrastruktur sebagai kode (IaC) seperti Terraform, Bicep, atau templat JSON 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 dikonfigurasi untuk throughput maksimum melalui pesan per satuan 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 pesan untuk sejumlah penyewa terbatas, menggunakan sistem pesan tunggal bisa menjadi solusi yang tepat untuk memenuhi kebutuhan fungsi, terutama dalam hal throughput, dan dapat mengurangi biaya kepemilikan secara keseluruhan. Aplikasi banyak penyewa mungkin berbagi entitas olahpesan yang sama, seperti antrian dan topik untuk beberapa pelanggan. Atau mereka mungkin menggunakan sekumpulan komponen khusus untuk masing-masing komponen, untuk meningkatkan isolasi penyewa. Di sisi lain, penggunaan infrastruktur olahpesan yang sama oleh beberapa penyewa dapat menjadikan seluruh solusi rentan terhadap masalah Noisy Neighbor. Aktivitas satu penyewa dapat membahayakan penyewa lain, dalam hal performa dan pengoperasian.

Dalam hal ini, sistem olahpesan harus dipersiapkan dengan ukuran yang tepat untuk mempertahankan beban lalu lintas pada jam sibuk yang diharapkan. Idealnya, ini harus mendukung penskalakan otomatis. Sistem olahpesan harus secara dinamis memperluas skala ketika lalu lintas meningkat dan mengurangi skala 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 pesan ke mesin virtual, Anda harus menempatkan mesin virtual ini berdekatan 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 dan keandalan intra-wilayah dari beban kerja penting bisnis, termasuk sistem pesan. 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 melakukan peningkatan dan penurunan skala dengan benar, berdasarkan kondisi lalu lintas. Untuk informasi selengkapnya, lihat Gambaran Umum tentang penskalaan otomatis dengan set skala mesin virtual Azure.

Demikian juga, ketika menghosting sistem olahpesan Anda pada kluster Kubernetes, pertimbangkan untuk menggunakan pemilih simpul dan taint untuk menjadwalkan eksekusi pod-podnya pada kumpulan simpul khusus yang 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 pesan pihak ketiga di AKS, gunakan penskalaan otomatis Kubernetes untuk meningkatkan jumlah simpul pekerja secara dinamis ketika lalu lintas meningkat. Dengan Horizontal Pod Autoscaler dan AKS cluster autoscaler, volume node 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 Kubernetes Event-Driven Autoscaling (KEDA), jika Anda ingin menskalakan jumlah pod 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 Bus Layanan Azure, 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 multi-penyewa dapat menerima pesan yang membawa data untuk beberapa penyewa dari satu antrean Azure Service Bus. Solusi ini dapat menyebabkan masalah performa dan skalabilitas. Jika beberapa penyewa menghasilkan volume pesanan yang lebih besar daripada yang lain-lain, ini dapat menimbulkan 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 Service Bus 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 untuk disesuaikan dengan kebutuhan dari penyewa sistem tertentu. Ketika penyewa baru didaftarkan, selain sistem pesan 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 dapat menjadi layanan PaaS yang dikelola sepenuhnya, seperti namespace Azure Service Bus , 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 Azure Service Bus Premium yang terpisah untuk setiap penyewa. Untuk informasi selengkapnya, lihat mengonfigurasi kunci yang dikelola oleh pelanggan untuk mengenkripsi data Azure Service Bus saat 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 pesan khusus untuk setiap penyewa, adalah wajar untuk menggunakan kumpulan proses pekerja yang terpisah untuk masing-masing. Hal ini meningkatkan tingkat isolasi data dan mengurangi kompleksitas dalam menangani berbagai entitas pesan. 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 fleksibilitas yang tinggi, karena proses onboarding penyewa baru tidak memerlukan pembuatan sumber daya khusus untuk penyerapan peristiwa, tetapi menawarkan tingkat perlindungan data yang rendah, karena mencampuradukkan 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, sistem multipenyewa seharusnya menyediakan kemampuan untuk memesan namespace Event Hubs Premium, dengan pemulihan bencana geografis dan zona ketersediaan diaktifkan. Untuk informasi selengkapnya, lihat Azure Event Hubs - Pemulihan Bencana Geografis.
  • Event Hubs khusus, dengan fitur Event Hubs Capture diaktifkan, harus dibuat untuk pelanggan yang perlu mengarsipkan acara ke akun penyimpanan Azure, demi alasan dan kewajiban kepatuhan regulasi. 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 acara, yang memungkinkan aplikasi menerbitkan peristiwa ke ribuan topik, misalnya 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 pengguna. 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 Service Bus, Anda harus mengajukan pertanyaan berikut:
  • 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 isu Noisy Neighbor, jadi pertimbangkan kompromi dengan hati-hati.

Pendekatan dan pola yang perlu dipertimbangkan

Beberapa Pola Desain Cloud dari Azure Architecture Center dapat diterapkan pada sistem pesan 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 Bus Layanan multipenyewa untuk sebagian besar penyewa Anda, tetapi kemudian Anda dapat menyebarkan Bus Layanan khusus untuk penyewa tunggal bagi penyewa yang membayar lebih banyak atau yang memiliki persyaratan yang lebih tinggi, dalam hal 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 Cap Penempatan

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

Sistem olahpesan bersama

Anda mungkin mempertimbangkan untuk mengadopsi sistem pesan bersama, seperti Azure Service Bus, dan membagikannya untuk semua klien Anda.

Diagram memperlihatkan satu sistem olahpesan multipenyewa bersama untuk semua penyewa.

Pendekatan ini memberikan kepadatan penyewa tertinggi ke infrastruktur, sehingga mengurangi total biaya kepemilikan secara keseluruhan. Ini juga sering mengurangi overhead dalam manajemen, karena ada satu sistem olahpesan atau sumber daya yang perlu 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 namespace Bus Layanan dalam satu langganan Azure, jumlah maksimum Event Hubs dalam satu namespace, atau batas throughput maksimum, mungkin pada akhirnya menjadi penghalang yang sulit diatasi, jika dan saat arsitektur Anda berkembang untuk mendukung lebih banyak penyewa. Pertimbangkan dengan cermat skala maksimum yang perlu Anda capai dalam hal jumlah namespace per satu langganan Azure, atau antrian per satu namespace. 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 dapat menjadi faktor ketika Anda berbagi sumber daya di antara beberapa penyewa, terutama jika ada yang sangat sibuk atau 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 Service Bus, memungut biaya untuk operasi pesan. 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 pemecahan data (sharding)

Pola Sharding melibatkan penerapan beberapa sistem pesan, yang disebut shards, yang berisi entitas pesan dari satu atau lebih penyewa, seperti antrean dan tema. 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.

Diagram memperlihatkan sistem olahpesan pecahan. Satu sistem olahpesan berisi antrean untuk penyewa A dan B, dan yang lainnya berisi antrean untuk penyewa C.

Setiap sistem olahpesan atau shard dapat memiliki karakteristik yang berbeda dalam hal keandalan, SKU, dan lokasi. Misalnya, Anda dapat membagi penyewa di beberapa sistem pesan 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 klien tertentu ke sistem olahpesan yang berisi antreannya. Strategi pencarian menggunakan peta untuk mengidentifikasi sistem olahpesan target, berdasarkan nama penyewa atau ID. Beberapa tenant mungkin berbagi shard yang sama, tetapi entitas pesan yang digunakan oleh satu tenant tidak akan tersebar di beberapa shard. Peta tersebut dapat diimplementasikan dengan menggunakan satu kamus yang memetakan nama penyewa ke nama atau referensi sistem pesan yang dituju. 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 ke pecahan yang tinggi, sehingga biaya dapat menjadi 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.

Diagram memperlihatkan sistem olahpesan yang berbeda untuk setiap penyewa.

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 sistem streaming acara terpisah untuk setiap penyewa karena satu instance tidak cukup untuk memproses 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 geodes

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.

Diagram memperlihatkan pola Geode, dengan sistem olahpesan yang disebarkan di beberapa wilayah yang disinkronkan bersama-sama.

Azure Service Bus dan Azure Event Hubs mendukung pemulihan bencana metadata, di seluruh namespace pemulihan bencana primer dan sekunder dan di seluruh antar wilayah dan zona ketersediaan terpisah, untuk memberikan dukungan ketahanan terbaik di dalam wilayah. Selain itu, Azure Service Bus dan Azure Event Hubs menerapkan serangkaian pola federasi yang efektif mereplikasi topik logis, antrean, atau hub peristiwa yang sama sehingga tersedia di beberapa namespace, yang akhirnya berada di berbagai wilayah. Untuk informasi selengkapnya, lihat sumber daya berikut:

Kontributor

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

Penulis utama:

Kontributor lain:

Langkah berikutnya

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