Condividi tramite

Considerazioni sul bus di servizio di Azure per la multi-tenancy

  • Articolo

Il bus di servizio di Azure offre messaggistica cloud altamente affidabile e asincrona tra applicazioni e servizi che non sono necessariamente online contemporaneamente. Il Service Bus è un broker di messaggi a livello aziendale completamente gestito che supporta sia le code di messaggi che i temi di pubblicazione-sottoscrizione. Questo articolo descrive le funzionalità del bus di servizio utili per le soluzioni multi-tenant. Fornisce anche risorse che consentono di pianificare come usare il bus di servizio.

Modelli di isolamento

Quando si usa un sistema multi-tenant che usa il bus di servizio, è necessario prendere una decisione sul livello di isolamento che si vuole adottare. Il bus di servizio supporta diversi modelli di isolamento.

La tabella seguente riepiloga le differenze tra i principali modelli di tenancy per il bus di servizio.

Considerazione Spazio dei nomi per ciascun tenant Spazio dei nomi condiviso o argomenti o code separati per ogni tenant Spazio dei nomi, argomenti o code condivise tra tenant
Isolamento dei dati Alto Intermedio Nessuno
Isolamento delle prestazioni Sommo. Gestire le esigenze di prestazioni in base ai requisiti di ogni tenant. Medio. Potenzialmente soggetto a problemi di vicini rumorosi. Basso. Potenzialmente soggetto a problemi di vicini rumorosi.
Complessità della distribuzione Medio. Tenere presente le quote e i limiti del bus di servizio a livello di sottoscrizione. Medio. Le entità messaggio devono essere distribuite separatamente per ogni tenant. Tenere presente le quote e i limiti del Service Bus nel livello di spazio dei nomi. Basso livello
Complessità operativa Alto. Gestire gli spazi dei nomi separatamente per ogni tenant. Medio. La gestione granulare delle entità messaggio potrebbe essere necessaria a seconda del tenant. Basso livello
Scenario di esempio Singole istanze dell'applicazione per ogni cliente Code dedicate per ogni inquilino Soluzione multi-tenant di grandi dimensioni con un livello applicativo condiviso e una o più code e argomenti condivisi

Spazio dei nomi dedicato per ogni tenant

All'interno della soluzione è possibile usare uno spazio dei nomi del bus di servizio specifico per ogni tenant. Questo approccio di distribuzione offre alla soluzione il livello massimo di isolamento e la possibilità di offrire prestazioni coerenti per ogni tenant.

È anche possibile ottimizzare le funzionalità di messaggistica per ogni tenant in base alle proprie esigenze usando gli approcci seguenti:

  • Distribuire lo spazio dei nomi in un'area vicina al tenant.

  • Distribuire uno spazio dei nomi specifico del tenant con un piano tariffario appropriato per tale tenant. Ad esempio, è possibile effettuare il provisioning di spazi dei nomi Premium con un numero diverso di unità di messaggistica (MU).

  • Applicare restrizioni di rete in base alle esigenze del tenant.

  • Usare chiavi di crittografia specifiche del tenant.

  • Configurare il ripristino di emergenza geografico o la replica geografica per replicare i metadati e i dati dello spazio dei nomi in un'altra area.

Lo svantaggio di questo modello di isolamento è che, man mano che il numero di tenant aumenta nel tempo, aumenta anche la complessità operativa della gestione degli spazi dei nomi. Se si raggiunge il numero massimo di namespace per ogni sottoscrizione di Azure, è possibile distribuire namespace tra diverse sottoscrizioni. Per altre informazioni, vedere Modello stamp di distribuzione. Questo approccio aumenta anche i costi delle risorse perché si paga per ogni spazio dei nomi di cui si effettua il provisioning.

Separare argomenti e code in uno spazio dei nomi condiviso

È possibile isolare i tenant a livello di entità di messaggistica. Ad esempio, ogni tenant all'interno del sistema può avere una o più code dedicate a cui è in ascolto. È possibile autenticare e autorizzare l'accesso all'entità di messaggistica di ogni tenant con una firma di accesso condiviso diversa o un'identità Microsoft Entra.

Man mano che il numero di tenant aumenta all'interno del sistema, aumenta anche il numero di code, argomenti o sottoscrizioni per accomodare ogni tenant. Questa crescita potrebbe comportare costi operativi più elevati e una minore agilità organizzativa.

Poiché lo spazio dei nomi è condiviso fra tutti i tenant, con questo approccio è più probabile che si verifichino problemi di interferenze. Ad esempio, è possibile che le entità di messaggistica di un singolo tenant possano utilizzare una quantità sproporzionata delle risorse dello spazio dei nomi e influire su tutti gli altri tenant. I namespace del bus di servizio hanno limiti relativi alla capacità delle Unità di Messaggio (MU) e al numero di connessioni concorrenti a un namespace. Valutare se un singolo utente potrebbe utilizzare più della propria giusta quota di queste risorse.

Esistono anche limiti al numero di argomenti e code che è possibile configurare all'interno di un singolo namespace. Tuttavia, questi limiti sono superiori al limite di namespace in una sottoscrizione.

Argomenti o code condivisi

Usare lo stesso spazio dei nomi e le stesse entità di messaggistica per tutti i tenant per ridurre la complessità operativa e diminuire i costi delle risorse. Può anche sbloccare scenari avanzati di messaggistica e filtro .

Tuttavia, la presenza di un singolo spazio dei nomi condiviso da tutti i tenant può comportare anche il problema del vicino rumoroso , che potrebbe causare una latenza più elevata per alcuni tenant. È anche necessario rendere il codice dell'applicazione consapevole della multitenancy. Ad esempio, è possibile passare il contesto del tenant all'interno del payload del messaggio o in una proprietà definita dall'utente. Questo approccio consente di gestire correttamente i messaggi destinati a tenant diversi. Il bus di servizio fornisce filtri e azioni di argomento, che possono essere usati per definire il messaggio che deve ricevere un sottoscrittore specifico. Quando si usa un argomento o una coda condivisa, non esiste alcun isolamento dei dati tra i tenant, quindi è necessario implementare i requisiti di isolamento dei dati all'interno della logica dell'applicazione.

Annotazioni

Le sessioni sono una funzionalità utile per supportare i requisiti di ordinamento dei messaggi. Tuttavia, non vengono in genere usati per isolare i dati tra i tenant, a meno che non si dispongano anche dei requisiti per l'ordinamento dei messaggi all'interno di un tenant. Per la maggior parte delle soluzioni multi-tenant, è consigliabile usare uno degli altri modelli di isolamento descritti in questo articolo.

Funzionalità di Service Bus che supportano la multitenancy

Autenticazione Microsoft Entra

Il bus di servizio è integrato con Microsoft Entra ID. Questa integrazione consente ai client di autenticare un'identità gestita con l'ID Microsoft Entra alle risorse del bus di servizio. Il Service Bus definisce un set di ruoli integrati che è possibile concedere ai clienti per l'accesso alle entità di Service Bus. Ad esempio, è possibile usare l'autenticazione di Microsoft Entra per concedere a un tenant l'accesso a una coda o a un argomento specifico che contiene i suoi messaggi. Questo approccio lo isola dagli altri tenant all'interno della tua applicazione.

Per altre informazioni, vedere Autenticare un'identità gestita usando Microsoft Entra ID per accedere alle risorse del bus di servizio.

Chiavi gestite dal cliente

Se i tenant devono usare le proprie chiavi per crittografare e decrittografare i messaggi, è possibile configurare chiavi gestite dal cliente negli spazi dei nomi Premium del bus di servizio. Questa funzionalità richiede l'adozione del modello di isolamento namespace dedicato per ogni tenant.

Per ulteriori informazioni, vedere Configurare le chiavi gestite dal cliente per crittografare i dati del Service Bus a riposo.

Firme di accesso condiviso

Le firme di accesso condiviso consentono di concedere a un tenant l'accesso alle risorse del bus di servizio con diritti specifici. Se si sceglie di isolare i tenant a livello di entità di messaggistica, è possibile concedere chiavi di firma di accesso condiviso in una coda o un argomento applicabile solo a un tenant specifico.

Per altre informazioni, vedere gli articoli seguenti:

Filtri e azioni per gli argomenti

Se si usano argomenti del bus di servizio all'interno dello spazio dei nomi, è possibile usare filtri e azioni degli argomenti per consentire ai sottoscrittori di definire i messaggi che desiderano ricevere da un argomento. Ogni regola ha una condizione di filtro che seleziona il messaggio desiderato, insieme a un'azione che annota il messaggio. Ad esempio, se le sottoscrizioni degli argomenti sono divise per tenant, è possibile usare i filtri per ricevere messaggi da un argomento destinato solo a tale tenant.

Per altre informazioni, vedere Filtri e azioni per gli argomenti.

Sospendere e riattivare le entità di messaggistica

È possibile sospendere temporaneamente le entità del messaggio. La sospensione inserisce l'entità di messaggistica in uno stato disabilitato e tutti i messaggi vengono mantenuti nell'archiviazione. La possibilità di disattivare le entità di messaggistica è utile quando si gestisce il ciclo di vita del tenant. Ad esempio, se un inquilino annulla la sottoscrizione al prodotto, è possibile disabilitare le code specifiche di quel tenant.

Per altre informazioni, vedere Sospendere e riattivare le entità di messaggistica (disabilita).For more information, see Suspend and reactivate messaging entities (disable).

Partizionamento

È possibile usare le partizioni per migliorare la velocità effettiva delle entità di messaggistica distribuendo i messaggi tra più broker di messaggi e archivi messaggi.

È possibile assegnare una partizione a un tenant specifico impostando la chiave di partizione del messaggio sull'identificatore del tenant. Questo approccio garantisce che il Service Bus assegni il messaggio alla partizione del tenant. Tuttavia, il bus di servizio prevede limiti per il numero di partizioni che è possibile supportare in una singola entità. Per le entità condivise, è consigliabile usare chiavi di partizione derivate dall'ID tenant. Ad esempio, è possibile usare un algoritmo hash che converte gli ID tenant in un numero fisso di chiavi di partizione.

Il partizionamento è disponibile quando si implementano namespace con SKU specifici. Per altre informazioni, vedere Livelli di messaggistica Premium del bus di servizio e code e argomenti partizionati.

Aggiornamento automatico delle UM

I namespace Premium del Service Bus possono regolare automaticamente il numero di unità di elaborazione assegnate a un namespace. Abilitare questa funzionalità per consentire la scalabilità elastica dello spazio dei nomi in base al carico. Il ridimensionamento elastico può essere utile nelle progettazioni multi-tenant dello spazio dei nomi condivise per ridurre il rischio di problemi di prossimità rumorosi senza richiedere l'intervento manuale.

Per ulteriori informazioni, vedere Aggiornare automaticamente le MUs di uno spazio dei nomi di Service Bus.

Contributori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autore principale:

  • Will Velida | Customer Engineer 2, FastTrack per Azure

Altri collaboratori:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passo successivo