Multitenansi dan Azure Queue Storage

Azure Queue Storage menyimpan pesan untuk pemrosesan asinkron. Artikel ini menjelaskan strategi partisi, model isolasi, dan fitur Queue Storage untuk solusi multipenyewa. Ini menyediakan panduan yang dapat membantu Anda mendistribusikan beban pesan, mengisolasi pesan milik tenant, dan mengelola akses, enkripsi, dan penggunaan.

Strategi partisi

Queue Storage tidak mengekspos kunci partisi atau subantrean dalam antrean. Antrean adalah batas terkecil yang dapat Anda gunakan untuk mendistribusikan beban pesan, dan akun penyimpanan adalah batas berikutnya. Antrean bersama tidak menyediakan throughput per penyewa atau isolasi performa.

Untuk pesan berukuran 1 KiB, satu antrean memiliki throughput target hingga 2.000 pesan per detik, dan akun penyimpanan memiliki tingkat permintaan maksimum 20.000 pesan per detik. Ukuran pesan dan pola akses memengaruhi throughput yang dicapai oleh beban kerja Anda. Pesan antrean dapat mencapai 64 KiB. Untuk pesan yang lebih besar atau fitur broker tingkat lanjut, pertimbangkan untuk menggunakan Azure Service Bus.

Jika beban kerja Anda dapat melebihi target per antrean, distribusikan pesan di beberapa antrean. Bergantung pada persyaratan perutean dan operasional, Anda dapat mempartisi antrean berdasarkan tenant, grup tenant atau tingkat layanan, beban kerja fungsional, deployment stamp, atau wilayah. Tenant volume tinggi yang berbagi antrean dengan tenant lain dapat menggunakan bagian throughput antrean yang tidak proporsional dan menyebabkan pembatasan untuk tenant lain.

Beberapa antrean di akun penyimpanan yang sama masih berbagi kapasitas akun dan konfigurasi tingkat akun. Jika beban kerja agregat dapat melebihi target akun penyimpanan, atau jika penyewa memerlukan skala independen atau konfigurasi regional, distribusikan antrean di beberapa akun penyimpanan. Pantau throttling, gunakan percobaan ulang eksponensial-backoff, dan uji beban kerja Anda terhadap target skalabilitas Queue Storage yang didokumentasikan. Untuk opsi akses penyewa dan isolasi data, lihat Model isolasi.

Model isolasi

Setelah Anda menentukan cara mendistribusikan beban pesan, tentukan tingkat isolasi penyewa yang akan diterapkan. Queue Storage mendukung antrean bersama, antrean untuk setiap penyewa, dan akun penyimpanan untuk setiap penyewa. Tabel berikut ini meringkas perbedaan antara model isolasi tenant utama untuk Queue Storage.

Consideration Antrian gabungan Antrean untuk setiap penyewa Akun penyimpanan untuk setiap penyewa
Isolasi data Rendah. Aplikasi memberlakukan isolasi. Rendah-sedang High
Isolasi kinerja Low Rendah. Sebagian besar kuota dan batasan berlaku untuk seluruh akun penyimpanan. High
Kompleksitas penyebaran Low Medium High
Kompleksitas operasional Low Medium High
Contoh skenario Solusi multipenyewa besar memiliki lapisan aplikasi bersama. URL tanda tangan akses bersama (SAS) bercakupan tenant dikeluarkan. Setiap penyewa memiliki stempel penyebarannya sendiri.

Note

Pertimbangkan kuota dan batasan saat Anda memilih model isolasi. Batas ini termasuk batas layanan Azure, target skalabilitas Queue Storage, dan target skalabilitas untuk penyedia sumber daya Storage.

Antrian gabungan

Jika Anda menggunakan antrean bersama, semua penyewa berbagi target throughputnya. Tenant yang sibuk dapat menyebabkan pembatasan untuk tenant lain. Untuk strategi mendistribusikan beban pesan, lihat Strategi pemartisian.

Antrean tidak menyediakan partisi atau subantrean, sehingga data dari semua penyewa mungkin menjadi tercampur. Aplikasi Anda harus mengidentifikasi tenant untuk setiap pesan dan menerapkan isolasi selama pemrosesan. Jangan memberi penyewa akses langsung ke antrean bersama jika mereka tidak boleh mengakses pesan penyewa lain.

Antrean untuk setiap penyewa

Anda dapat membuat antrean individual untuk setiap penyewa dalam satu akun penyimpanan. Tidak ada batasan jumlah antrean yang dapat Anda buat dalam akun penyimpanan.

Antrean untuk setiap penyewa menyediakan batas perutean dan kontrol akses, tetapi tidak menyediakan isolasi performa. Semua antrean di akun berbagi target kapasitas dan performa akun penyimpanan.

Untuk skenario ini, Anda dapat menggunakan kontrol akses Queue Storage, termasuk SAS, untuk mengelola akses ke data setiap penyewa.

Saat Anda membuat antrean secara dinamis untuk setiap penyewa, pertimbangkan bagaimana tingkat aplikasi Anda menggunakan pesan dari antrean setiap penyewa. Untuk skenario lanjutan, pertimbangkan untuk menggunakan Azure Service Bus, yang mendukung fitur seperti sesi, autoforwarding pesan, serta topik dan langganan.

Akun penyimpanan untuk setiap penyewa

Tingkat isolasi terkuat menggunakan akun penyimpanan khusus untuk setiap penyewa. Model ini memastikan isolasi penuh kunci akun penyimpanan, yang dapat Anda rotasi secara independen. Ini juga memungkinkan Anda untuk menskalakan solusi Anda di luar batas dan kuota untuk setiap akun penyimpanan. Pertimbangkan model ini untuk penyewa yang secara konsisten memiliki volume pesan tinggi atau memerlukan konfigurasi regional independen atau target performa independen. Tetapi Anda juga harus mempertimbangkan jumlah maksimum akun penyimpanan yang diizinkan dalam satu langganan Azure.

Fitur Queue Storage yang mendukung multitenansi

Fitur Queue Storage berikut dapat membantu Anda menerapkan dan mengoperasikan model isolasi yang Anda pilih.

Tanda tangan akses bersama

Saat Anda menggunakan Queue Storage dari aplikasi klien, pertimbangkan apakah akan merutekan permintaan melalui tingkat aplikasi Anda atau mengizinkan klien untuk terhubung langsung ke antrean. Akses klien langsung dapat mengurangi beban pada aplikasi back-end Anda dan jumlah hop jaringan.

shared access signature (SAS) memungkinkan Anda menyediakan aplikasi klien dengan akses terbatas ke antrean. Anda dapat membatasi operasi yang dapat dilakukan klien dan periode waktu saat akses diizinkan. Misalnya, Anda dapat mengeluarkan SAS yang memungkinkan penyewa menambahkan pesan ke antreannya sendiri tanpa mengizinkannya membaca atau menghapus pesan.

Gunakan pola Kunci Valet untuk mengeluarkan token SAS yang dibatasi dan tercakup dari tingkat aplikasi Anda. Autentikasi klien dengan menggunakan sistem autentikasi aplikasi Anda, tentukan queue milik tenant mana yang dapat mereka akses, dan terbitkan token hanya untuk operasi yang diperlukan.

Kebijakan akses tersimpan memungkinkan Anda menentukan satu kebijakan yang akan digunakan saat Anda mengeluarkan beberapa token SAS layanan. Kebijakan akses tersimpan tidak berlaku untuk token SAS delegasi pengguna atau token SAS akun.

Delegasi pengguna SAS

SAS layanan atau SAS akun ditandatangani dengan salah satu kunci akun penyimpanan Anda. Delegasi pengguna SAS diamankan dengan kredensial Microsoft Entra sebagai gantinya. Tingkat aplikasi Anda meminta kunci delegasi pengguna dengan menggunakan identitas terkelolanya sendiri, lalu menandatangani token dengan cakupan tertentu dan berlaku terbatas waktu untuk setiap penyewa. Anda tidak mendistribusikan atau menyimpan kunci akun. Microsoft merekomendasikan penggunaan SAS delegasi pengguna alih-alih SAS kunci akun saat desain Anda mendukungnya.

Gunakan masa pakai token pendek dan rencanakan cara mencabut akses jika token dikompromikan. Untuk mengkorelasikan log aplikasi Anda dengan log Queue Storage, atur ID permintaan klien (x-ms-client-request-id) pada permintaan penyimpanan dan catat bersama ID penyewa Anda.

Kontrol akses berbasis identitas

Queue Storage menyediakan kontrol akses berbasis identitas melalui Microsoft Entra ID. Gunakan identitas terkelola dan kontrol akses berbasis peran Azure untuk mengotorisasi aplikasi Anda untuk mengakses antrean tanpa menyimpan kunci akun. Batasi akses ke antrean setiap penyewa saat penyewa memerlukan akses langsung. Otorisasi tingkat antrean tidak mengisolasi pesan tenant individual dalam antrean bersama.

Encryption

Queue Storage mengenkripsi data saat disimpan dengan kunci yang dikelola Microsoft secara default. Untuk menggunakan kunci yang dikelola pelanggan, konfigurasikan akun penyimpanan untuk menggunakan kunci enkripsi cakupan akun untuk antrean saat Anda membuat akun. Anda tidak dapat mengubah cakupan kunci enkripsi ini setelah pembuatan akun.

Jika tenant memerlukan kunci terpisah yang dikelola pelanggan, gunakan akun storage terpisah. Blob Storage cakupan enkripsi dan kunci yang disediakan pelanggan pada permintaan individual tidak berlaku untuk Queue Storage. Rencanakan rotasi dan pencabutan kunci bersama siklus hidup tenant Anda.

Monitoring

Dalam solusi multipenyewa, pertimbangkan apakah Anda perlu mengukur konsumsi untuk setiap penyewa. Tentukan metrik tertentu untuk dilacak, seperti jumlah pesan atau operasi untuk setiap penyewa. Anda juga dapat menggunakan alokasi biaya untuk melacak biaya penggunaan setiap penyewa dan mengaktifkan penagihan balik di beberapa langganan.

Queue Storage menyediakan kemampuan pemantauan bawaan. Saat penyewa berbagi antrean, sertakan pengidentifikasi penyewa dalam telemetri aplikasi Anda sehingga Anda dapat mengaitkan pemrosesan dan penggunaan pesan ke penyewa yang benar.

Pantau tingkat permintaan dan respons HTTP 500 dan 503 untuk mendeteksi antrean atau akun yang mendekati target skalabilitas. Kaitkan telemetri ini dengan pengidentifikasi penyewa sehingga Anda dapat mengidentifikasi penyewa yang penggunaannya memengaruhi kapasitas bersama.

Anda dapat mengumpulkan log permintaan, lalu mengagregasi dan menganalisisnya bersama telemetri aplikasi Anda. Dalam solusi yang membuat permintaan dalam volume tinggi, pertimbangkan apakah manfaatnya sepadan dengan biayanya untuk menangkap dan memproses log tersebut.

Kontributor

Microsoft mempertahankan artikel ini. Kontributor berikut menulis artikel ini.

Penulis utama:

  • John Downs | Insinyur Perangkat Lunak Utama, Pola & Praktik Azure

Kontributor lain:

  • Dr. Christian Geuer-Pollmann | Teknisi Pelanggan Utama, FastTrack untuk Azure
  • Patrick Horn | Senior Customer Engineering Manager, FastTrack untuk Azure
  • Ben Hummerstone | Teknisi Pelanggan Utama, FastTrack untuk Azure
  • Vic Perdana | Arsitek Solusi Cloud, Azure ISV
  • Daniel Scott-Raynsford | Arsitek Solusi untuk Mitra, Data & AI
  • Arsen Vladimirskiy | Teknisi Pelanggan Utama, FastTrack untuk Azure

Untuk melihat profil LinkedIn nonpublik, masuk ke LinkedIn.

  • Terakhir diperbarui pada