Multi-tenancy e Archiviazione tabelle di Azure

Archiviazione tabelle di Azure archivia dati strutturati e non relazionali. Questo articolo descrive le strategie di partizionamento, i modelli di isolamento e le funzionalità di Table Storage per soluzioni multi-tenant. Fornisce indicazioni che consentono di distribuire i dati delle entità e il carico delle richieste, isolare le entità dei tenant e gestire l'accesso, la crittografia e l'utilizzo.

Strategie di partizionamento

Table Storage partiziona automaticamente le entità in base al valore della proprietà PartitionKey. Ogni entità deve includere un PartitionKey e un RowKey. Insieme, queste proprietà identificano in modo univoco l'entità. Ogni proprietà può contenere una stringa di un massimo di 1.024 caratteri.

Tutte le entità con lo stesso PartitionKey valore appartengono alla stessa partizione. Quando l'applicazione scrive la prima entità con un nuovo valore PartitionKey, Table Storage crea la partizione logica corrispondente e ne gestisce il posizionamento fisico. Table Storage distribuisce le partizioni tra i nodi di archiviazione e può ribilanciarle quando cambiano i modelli di richiesta. Questa gestione automatica delle partizioni consente al servizio di scalare orizzontalmente quando si aggiungono valori di chiave di partizione.

Chiavi di progettazione per i modelli di accesso

Scegliere PartitionKey e RowKey valori in base al modo in cui l'applicazione esegue query e modifica i dati. Una query puntuale che specifica entrambi i valori è la query più efficiente. Le query che specificano un PartitionKey e un intervallo di valori RowKey analizzano una sola partizione. Le query che non specificano un PartitionKey devono analizzare più partizioni o l'intera tabella. Scegliere un RowKey che supporti le query relative all'ordinamento e all'intervallo usate più di frequente dal carico di lavoro.

Una chiave naturale è candidata per PartitionKey solo quando è allineata ai requisiti di query, distribuzione e transazione del carico di lavoro. Se una partizione logica contiene esattamente un'entità, è possibile usare la chiave naturale come PartitionKey e una stringa vuota come RowKey. Se un'entità dispone di più proprietà chiave stabili, scegliere il valore o i valori per PartitionKey che distribuiscano il carico delle richieste, supportino le query predominanti e raggruppino le entità che richiedono transazioni atomiche. Usare RowKey per identificare e ordinare in modo univoco le entità all'interno di tale partizione. Se nessuna singola proprietà soddisfa questi requisiti, costruire una chiave sintetica concatenando i valori delle proprietà stabili.

Archiviazione tabelle indicizza automaticamente solo PartitionKey e RowKey. Se si esegue regolarmente una query in base ad altre proprietà, è consigliabile implementare il modello di tabella dell'indice, duplicare le entità per supportare un altro modello di accesso oppure utilizzare un archivio dati che supporti gli indici secondari. Per altre informazioni sulla progettazione di query, vedere Progettazione per le query.

Suddividi verticalmente le proprietà dell'entità

Per le entità logiche che contengono molte proprietà, usare la proiezione lato server per recuperare solo le proprietà richieste da ogni query. Se i gruppi di proprietà hanno modelli di accesso o aggiornamento sostanzialmente diversi o se un'entità logica si avvicina ai limiti di un'entità di Table Storage, è consigliabile suddividerla tra più entità o tabelle. Mantieni le entità correlate nella stessa tabella con lo stesso PartitionKey quando è necessario aggiornarle in una transazione del gruppo di entità. Per altre informazioni, vedere Schemi di progettazione delle tabelle.

Scegliere la granularità della chiave di partizione

La granularità dei valori PartitionKey influisce sulla scalabilità, sull'efficienza delle query e sui confini delle transazioni:

  • Una partizione per molte entità: L'uso dello stesso PartitionKey valore per molte entità mantiene insieme i dati correlati. Le query possono recuperare il gruppo da una partizione e le transazioni di gruppo di entità possono aggiornare le entità in modo atomico. Tuttavia, tutte le richieste per tali entità condividono l'obiettivo di throughput della partizione. L'uso di un PartitionKey valore per un'intera tabella può creare una partizione ad accesso frequente ed è adatto solo per carichi di lavoro di piccole dimensioni.
  • Una partizione per ogni entità: L'uso di un valore univoco PartitionKey per ogni entità distribuisce il carico delle richieste tra più partizioni. Le query point rimangono efficienti, ma le query che recuperano più entità potrebbero dover accedere a molte partizioni. Più entità non possono partecipare alla stessa transazione di un gruppo di entità perché non condividono PartitionKey.
  • Una partizione per ogni gruppo correlato: La condivisione di un PartitionKey valore tra le entità su cui l'applicazione esegue comunemente query o che aggiorna insieme bilancia la località delle query, il supporto delle transazioni e la scalabilità. Per un carico di lavoro multi-tenant, il gruppo correlato potrebbe essere un tenant o un bucket di entità all'interno di un tenant di grandi dimensioni.

Evitare valori PartitionKey monotonamente crescenti o decrescenti nei carichi di lavoro con elevato utilizzo di scrittura, ad esempio 0001, 0002 e 0003. Questi valori possono concentrare le scritture in un intervallo di chiavi ristretto e creare una partizione ad accesso frequente. Usare l'hashing o la bucketizzazione stabile quando è necessario distribuire le scritture e testare la strategia di partizionamento in base al carico di picco previsto. Per informazioni aggiornate su limiti e linee guida sulla progettazione, vedere Obiettivi di scalabilità di Archiviazione tabelle e Progettare una strategia di partizionamento scalabile per Archiviazione tabelle.

Partizionamento per tenant

In una tabella condivisa è possibile usare l'identificatore del tenant come PartitionKeychiave di partizione quando la maggior parte delle operazioni è limitata a un tenant e il carico di lavoro massimo di ogni tenant rientra nell'ambito dell'obiettivo di scalabilità per una singola partizione. Per le entità di 1 KiB, una partizione ha un throughput target fino a 2.000 entità al secondo e un account di archiviazione ha una velocità massima di richiesta di 20.000 transazioni al secondo. Un tenant attivo in modo sproporzionato può creare una partizione ad accesso frequente e subire limitazioni anche quando altre partizioni hanno capacità inutilizzata.

La creazione di più tabelle all'interno dello stesso account di archiviazione non aumenta l'obiettivo di richieste a livello di account. Se una partizione si avvicina al suo obiettivo, perfezionare la strategia PartitionKey per distribuire il carico delle richieste. Se il carico di lavoro aggregato si avvicina all'obiettivo dell'account di archiviazione, distribuire il carico di lavoro tra più account di archiviazione.

Per i tenant di grandi dimensioni o attivi, creare più valori specifici per tenant PartitionKey combinando l'identificatore del tenant con un bucket stabile o un valore specifico del dominio. Questo approccio distribuisce le entità di un tenant e il carico delle richieste tra le partizioni, ma introduce compromessi:

  • Le query a livello di tenant potrebbero dover eseguire query su più partizioni.
  • Le transazioni del gruppo di entità non possono estendersi sulle partizioni del tenant.
  • L'applicazione deve instradare le operazioni alla partizione corretta.
  • Le firme di accesso condiviso con ambito intervallo di chiavi diventano più complesse da progettare ed emettere.

Pianificare i confini delle transazioni

Table Storage supporta le transazioni del gruppo di entità per le entità nella stessa tabella con lo stesso valore PartitionKey. Una transazione può includere al massimo 100 entità e il relativo payload deve essere inferiore a 4 MiB. Tutte le operazioni nella transazione riescono o falliscono tutte in modo atomico.

Le operazioni che si estendono su partizioni non sono transazionali. Se un'operazione aziendale deve aggiornare le entità in modo atomico, archiviate tali entità nella stessa partizione. In caso contrario, progettare l'applicazione per gestire i guasti parziali e usare una strategia di coerenza appropriata. Per altre informazioni, vedere Eseguire transazioni del gruppo di entità.

Modelli di isolamento

Dopo aver progettato le chiavi di partizione con riconoscimento del tenant, determinare il livello di isolamento del tenant da applicare. Table Storage supporta tabelle condivise, tabelle 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 Table Storage.

Consideration Tabelle condivise con chiavi di partizione consapevoli del tenant Tabelle per ogni tenant Account di archiviazione per ogni tenant
Isolamento dei dati Basso. L'applicazione o una firma di accesso condiviso con ambito di intervallo di chiavi applica 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 di firma di accesso condiviso con ambito 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 Table Storage e obiettivi di scalabilità per il provider di risorse di archiviazione.

Tabelle condivise con chiavi di partizione consapevoli del tenant

Quando si usa una singola tabella condivisa, usare l'identificatore del tenant come PartitionKey completo per i tenant i cui dati e il carico delle richieste rientrano in una partizione, ad esempio tenant più piccoli, o come componente di un PartitionKey sintetico per tenant di dimensioni maggiori. Per considerazioni chiave sulla progettazione e sulla scalabilità, vedere Strategie di partizionamento.

I token SAS consentono di specificare un intervallo di chiavi di partizione. Table Storage garantisce che le richieste che contengono la firma possano accedere solo alle entità negli intervalli specificati di chiave di partizione e di chiave di riga. Se i dati di un tenant si estendono su più PartitionKey valori, progettare i valori e gli intervalli SAS in modo che il token non possa concedere l'accesso alle entità di un altro tenant. È possibile implementare il pattern Valet Key per consentire ai client non attendibili di accedere alle entità di un tenant senza concedere l'accesso ad altri tenant.

Se l'applicazione accede a una tabella condivisa per conto dei tenant, applica l'intervallo di chiavi del tenant a ogni operazione. Una convenzione di denominazione della chiave di partizione non fornisce l'isolamento dell'accesso da solo.

Tabelle per ogni tenant

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

Le tabelle separate forniscono un routing e una barriera di controllo di accesso, ma non forniscono l'isolamento delle prestazioni. Tutte le tabelle nell'account condividono gli obiettivi di capacità e prestazioni dell'account di archiviazione.

Per questo scenario, è possibile usare il controllo di accesso di Table Storage, inclusa SAS (firma di accesso condiviso), per gestire l'accesso ai dati di ogni tenant.

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 di transazioni elevati sostenuti o che richiedono una configurazione a livello di area indipendente, chiavi di crittografia o obiettivi di prestazioni. È anche necessario considerare il numero massimo di account di archiviazione consentiti all'interno di una singola sottoscrizione Azure.

Funzionalità di Table Storage che supportano la multi-tenancy

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

Firme di accesso condiviso

Quando si usa Table Storage da un'applicazione client, valutare se instradare le richieste tramite il livello applicazione o consentire ai client di connettersi direttamente a una tabella. 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 tabella. È possibile limitare le operazioni che un client può eseguire, gli intervalli di chiavi di partizione e riga a cui può accedere e il periodo di tempo in cui è consentito l'accesso. Ad esempio, è possibile rilasciare un SAS che consente a un tenant di leggere solo le entità all'interno del proprio intervallo di chiavi di partizione.

Usare il modello Valet Key per rilasciare token SAS vincolati e con ambito dal tier applicazione. Autenticate il client usando il sistema di autenticazione dell'applicazione, determinate a quali entità del tenant può accedere e rilasciate un token solo per gli intervalli di chiavi e le operazioni necessari.

I criteri di accesso memorizzati 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 firma di accesso condiviso della delega utente anziché una firma di accesso condiviso 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 Table 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à

Table 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 tabelle senza archiviare le chiavi dell'account. Limitare l'accesso alla tabella di ogni tenant quando i tenant richiedono l'accesso diretto. Le assegnazioni di ruolo a livello di tabella non limitano l'accesso alla partizione di un tenant all'interno di una tabella condivisa.

Encryption

Table Storage crittografa i dati at-rest con chiavi gestite da Microsoft per impostazione predefinita. Per usare le chiavi gestite dal cliente, configurare l'account di archiviazione in modo da usare una chiave di crittografia con ambito account per le tabelle quando si crea l'account. Non è possibile modificare questo ambito della chiave di crittografia dopo la creazione dell'account. La capacità di archiviazione tabelle e le transazioni vengono fatturate a tariffe diverse quando l'account viene creato per usare una chiave di crittografia con ambito account per le tabelle, anche se Microsoft gestisce la chiave.

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 per singole richieste non si applicano a Table 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 entità o operazioni per i dati di 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.

Table Storage offre funzionalità di monitoraggio predefinite. Quando i tenant condividono la stessa tabella, includere gli identificatori del tenant nei dati di telemetria dell'applicazione in modo da poter attribuire operazioni e utilizzo al tenant corretto.

Monitorare le frequenze delle richieste e le risposte HTTP 500 e 503 per rilevare partizioni o account 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: