Multi-tenancy e archiviazione code di Azure

archiviazione code di Azure archivia i messaggi per l'elaborazione asincrona. Questo articolo descrive le strategie di partizionamento, i modelli di isolamento e le funzionalità di Queue Storage per soluzioni multi-tenant. Fornisce indicazioni che consentono di distribuire il carico dei messaggi, isolare i messaggi dei tenant e gestire l'accesso, la crittografia e l'utilizzo.

Strategie di partizionamento

Queue Storage non espone una chiave di partizione o una coda secondaria all'interno di una coda. La queue è il confine più piccolo che è possibile usare per distribuire il caricamento dei messaggi e l'account di archiviazione è il confine successivo. Una coda condivisa non fornisce un throughput o un isolamento delle prestazioni specifici del tenant.

Per i messaggi di 1 KiB, una singola coda ha un throughput target fino a 2.000 messaggi al secondo e un account di archiviazione ha una frequenza massima di richieste di 20.000 messaggi al secondo. Le dimensioni dei messaggi e i modelli di accesso influiscono sul throughput ottenuto dal carico di lavoro. I messaggi in coda possono essere fino a 64 KiB. Per i messaggi più grandi o le funzionalità avanzate del broker, è consigliabile usare bus di servizio di Azure.

Se il carico di lavoro può superare l'obiettivo per coda, distribuire i messaggi tra più code. A seconda dei requisiti operativi e del routing, è possibile partizionare le code in base al tenant, al gruppo di tenant o al livello di servizio, al carico di lavoro funzionale, al deployment stamp o all'area. Un tenant con volumi elevati che condivide una coda con altri tenant può consumare una quota sproporzionata della velocità effettiva della coda e causare la limitazione per altri tenant.

Più code nello stesso account di archiviazione condividono comunque la capacità dell'account e la configurazione a livello di account. Se il carico di lavoro aggregato può superare il limite dell'account di archiviazione o se un tenant necessita di scalabilità indipendente o configurazione regionale, distribuire le code tra più account di archiviazione. Monitorare il throttling, usare i tentativi di backoff esponenziale e testare il carico di lavoro rispetto agli obiettivi di scalabilità di Queue Storage documentati. Per le opzioni di accesso ai tenant e isolamento dei dati, vedere Modelli di isolamento.

Modelli di isolamento

Dopo aver determinato come distribuire il carico dei messaggi, determinare il livello di isolamento del tenant da applicare. Archiviazione code di Azure supporta code condivise, code per ogni tenant e account di archiviazione per ogni tenant. La tabella seguente riepiloga le differenze tra i principali modelli di isolamento della tenancy per l'Archiviazione code.

Consideration Code condivise Coda per ogni istanza Account di archiviazione per ogni tenant
Isolamento dei dati Basso. Il programma assicura l'isolamento. Basso medio High
Isolamento delle prestazioni Low Basso. La maggior parte delle quote e dei limiti si applica all'intero account di archiviazione. High
Complessità della distribuzione Low Medium High
Complessità operativa Low Medium High
Scenario di esempio Una soluzione multi-tenant di grandi dimensioni ha un livello applicazione condiviso. Gli URL della firma di accesso condiviso con ambito del tenant vengono emessi. Ogni tenant ha un proprio timbro di distribuzione.

Note

Prendere in considerazione quote e limiti quando si seleziona un modello di isolamento. Questi limiti includono limiti del servizio Azure, obiettivi di scalabilità di Queue Storage e obiettivi di scalabilità per il provider di risorse di archiviazione.

Code condivise

Se si condivide una coda, tutti i tenant condividono il suo obiettivo di throughput. Un tenant con carico elevato può causare limitazioni per altri tenant. Per le strategie per distribuire il carico dei messaggi, vedere Strategie di partizionamento.

Le code non forniscono il partizionamento o sottocode, quindi tutti i dati dei tenant potrebbero diventare mescolati. L'applicazione deve identificare il tenant per ogni messaggio e applicare l'isolamento durante l'elaborazione. Non concedere ai tenant l'accesso diretto a una coda condivisa se non devono accedere ai messaggi di altri tenant.

Coda per ogni istanza

È possibile creare singole code per ogni tenant all'interno dello stesso account di archiviazione. Non esiste alcun limite al numero di code che è possibile creare all'interno di un account di archiviazione.

Le code per ogni tenant forniscono un routing e un confine di controllo di accesso, ma non forniscono l'isolamento delle prestazioni. Tutte le code nell'account condividono gli obiettivi di capacità e prestazioni dell'account di archiviazione.

Per questo scenario, è possibile usare il controllo di accesso ad Archiviazione code, inclusa la firma di accesso condiviso, per gestire l'accesso ai dati di ogni tenant.

Quando si creano code in modo dinamico per ogni tenant, considerare il modo in cui il livello dell'applicazione utilizza i messaggi della coda di ogni tenant. Per scenari avanzati, è consigliabile usare bus di servizio di Azure, che supporta funzionalità quali sessioni, inoltro automatico dei messaggi e topic e sottoscrizioni.

Account di archiviazione per ogni tenant

Il livello di isolamento più elevato usa un account di archiviazione dedicato per ogni tenant. Questo modello garantisce l'isolamento completo delle chiavi dell'account di archiviazione, che è possibile ruotare in modo indipendente. Consente anche di ridimensionare la soluzione oltre i limiti e le quote per ogni account di archiviazione. Si consideri questo modello per i tenant con volumi elevati e costanti di messaggi o che richiedono configurazione regionale indipendente o obiettivi di prestazioni indipendenti. È tuttavia necessario considerare anche il numero massimo di account di archiviazione consentiti all'interno di una singola sottoscrizione di Azure.

Funzionalità di Queue Storage che supportano la multi-tenancy

Le funzionalità di Queue Storage seguenti consentono di implementare e gestire il modello di isolamento scelto.

Firme di accesso condiviso

Quando si usa Queue Storage da un'applicazione client, valutare se instradare le richieste tramite il livello applicazione o consentire ai client di connettersi direttamente a una coda. L'accesso client diretto può ridurre il carico sulle applicazioni back-end e il numero di hop di rete.

Una firma di accesso condiviso (SAS) consente di fornire alle applicazioni client l'accesso limitato a una coda. È possibile limitare le operazioni che un client può eseguire e il periodo di tempo in cui è consentito l'accesso. Ad esempio, è possibile emettere un token SAS che consente a un tenant di aggiungere messaggi alla propria coda senza consentirgli di leggere o eliminare messaggi.

Usare il modello Valet Key per rilasciare token SAS vincolati e con ambito dal tier applicazione. Autentica il client usando il sistema di autenticazione dell'applicazione, determina a quale coda del tenant può accedere e rilascia un token solo per le operazioni necessarie.

I criteri di accesso archiviati consentono di definire un singolo criterio da usare quando si rilasciano più token di firma di accesso condiviso del servizio. I criteri di accesso archiviati non si applicano ai token SAS di delega utente o ai token SAS dell'account.

Firma di accesso condiviso con delega utente

Una firma di accesso condiviso (SAS) del servizio o una firma di accesso condiviso (SAS) dell'account è firmata con una delle chiavi dell'account di archiviazione. Una SAS di delega utente è protetta con credenziali Microsoft Entra. Il livello applicazione richiede una chiave di delega utente usando la propria identità gestita, quindi firma i token con ambito limitato al tempo per ogni tenant. Non si distribuiscono o si archiviano le chiavi dell'account. Microsoft consiglia di usare una SAS di delega utente anziché una SAS con chiave dell'account quando la progettazione lo supporta.

Usare durate di token brevi e pianificare come revocare l'accesso se un token viene compromesso. Per correlare i log dell'applicazione con i log di Queue Storage, impostare un ID richiesta client (x-ms-client-request-id) nelle richieste di archiviazione e registrarlo insieme all'ID tenant.

Controllo degli accessi in base all'identità

Queue Storage fornisce il controllo degli accessi in base all'identità tramite Microsoft Entra ID. Usare le identità gestite e il controllo degli accessi in base al ruolo di Azure per autorizzare l'applicazione ad accedere alle code senza archiviare le chiavi dell'account. Limitare l'accesso alla coda di ogni tenant quando i tenant richiedono l'accesso diretto. L'autorizzazione a livello di coda non isola i messaggi dei singoli tenant all'interno di una coda condivisa.

Encryption

Queue Storage crittografa i dati archiviati con chiavi gestite da Microsoft per impostazione predefinita. Per usare le chiavi gestite dal cliente, configurare l'account di archiviazione per usare una chiave di crittografia con ambito account per le code quando si crea l'account. Non è possibile modificare questo ambito della chiave di crittografia dopo la creazione dell'account.

Se i tenant richiedono chiavi separate gestite dal cliente, usare account di archiviazione separati. Gli ambiti di crittografia di gestione rete virtuale di Azure e le chiavi fornite dal cliente nelle singole richieste non si applicano a Queue Storage. Pianificare la rotazione e la revoca delle chiavi insieme al ciclo di vita del tenant.

Monitoring

In una soluzione multi-tenant valutare se è necessario misurare il consumo per ogni tenant. Definire le metriche specifiche di cui tenere traccia, ad esempio il numero di messaggi o operazioni per ogni tenant. È anche possibile usare l'allocazione dei costi per tenere traccia del costo dell'utilizzo di ogni tenant e abilitare il chargeback tra più sottoscrizioni.

Queue Storage offre funzionalità di monitoraggio predefinite. Quando i tenant condividono una coda, includete gli identificatori del tenant nei dati di telemetria dell'applicazione in modo da poter attribuire l'elaborazione e l'utilizzo dei messaggi al tenant corretto.

Monitorare le frequenze delle richieste e le risposte HTTP 500 e 503 per rilevare code o risorse che si avvicinano agli obiettivi di scalabilità. Correlare questi dati di telemetria con gli identificatori del tenant in modo che sia possibile identificare i tenant il cui utilizzo influisce sulla capacità condivisa.

È possibile raccogliere i log delle richieste, quindi aggregarli e analizzarli insieme ai dati di telemetria dell'applicazione. Nelle soluzioni che creano volumi elevati di richieste, valutare se il vantaggio giustifica il costo per acquisire ed elaborare tali log.

Contributors

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

Autore principale:

  • John Downs | Principal Software Engineer, Azure Patterns & Practices

Altri contributori:

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

  • Ultimo aggiornamento: