Condividi tramite

Multi-tenancy e Azure Cosmos DB

  • Articolo

Questo articolo descrive le funzionalità di Azure Cosmos DB che è possibile usare per i sistemi multi-tenant. Fornisce indicazioni ed esempi su come usare Azure Cosmos DB in una soluzione multi-tenant.

Requisiti di multi-tenancy

Quando si pianifica una soluzione multi-tenant, si hanno due requisiti chiave:

  • Garantire un isolamento sicuro tra i tenant e soddisfare requisiti di sicurezza rigorosi per gli utenti che ne hanno bisogno.
  • Mantenere un costo basso per tenant. Poiché il provider garantisce che il costo per l'esecuzione dell'applicazione rimanga sostenibile man mano che viene ridimensionato.

Queste due esigenze possono spesso entrare in conflitto e introdurre un compromesso in cui è necessario classificare una priorità rispetto all'altra. Le linee guida contenute in questo articolo consentono di comprendere meglio i compromessi che è necessario apportare per soddisfare queste esigenze. Questo articolo consente di esplorare queste considerazioni in modo da poter prendere decisioni informate quando si progetta la soluzione multi-tenant.

Modalità di isolamento

Determinare il livello di isolamento necessario tra i tenant. Azure Cosmos DB supporta una gamma di modelli di isolamento, ma per la maggior parte delle soluzioni è consigliabile usare una delle strategie seguenti:

  • Una chiave di partizione per tenant viene spesso usata per soluzioni completamente multi-tenant, ad esempio soluzioni SaaS (SaaS) da business a consumer.
  • Un account di database per tenant viene spesso usato per soluzioni SaaS business-to-business (B2B).

Per scegliere il modello di isolamento più appropriato, prendere in considerazione il modello aziendale e i requisiti dei tenant. Ad esempio, un forte isolamento delle prestazioni potrebbe non essere una priorità per alcuni modelli B2C in cui un'azienda vende un prodotto o un servizio direttamente a un singolo cliente. Tuttavia, i modelli B2B potrebbero classificare in ordine di priorità l'isolamento avanzato della sicurezza e delle prestazioni e potrebbero richiedere che i tenant dispongano del proprio account di database di cui è stato effettuato il provisioning.

È anche possibile combinare più modelli in base alle diverse esigenze dei clienti. Si supponga, ad esempio, di creare una soluzione SaaS B2B che si vende ai clienti aziendali e di fornire una versione di valutazione gratuita per i nuovi clienti potenziali. È possibile distribuire un account di database separato per tenant aziendali a pagamento che necessitano di garanzie di sicurezza e isolamento avanzate. È anche possibile condividere un account di database e usare le chiavi di partizione per isolare i clienti della versione di valutazione.

Il modello partition-key-per-tenant e il modello database-account-per-tenant sono i modelli di isolamento più comuni per le soluzioni multi-tenant. Questi modelli offrono il miglior equilibrio tra l'isolamento del tenant e l'efficienza dei costi.

Modello partition-key-per-tenant

Se si isolano i tenant in base alla chiave di partizione, la velocità effettiva viene condivisa tra tenant e gestita all'interno dello stesso contenitore.

Nota

Un'unità richiesta (UR) è un'astrazione logica del costo di un'operazione o di una query di database. In genere, viene effettuato il provisioning di un numero definito di unità richiesta al secondo (UR/sec) per il carico di lavoro, detto velocità effettiva.

Vantaggi

  • Efficienza dei costi: tutti i tenant vengono inseriti in un unico contenitore, partizionato dall'ID tenant. Questo approccio ha una sola risorsa fatturabile che effettua il provisioning e condivide le UR tra più tenant. Questo modello è in genere più conveniente e più semplice da gestire rispetto alla presenza di account separati per ogni tenant.

  • Gestione semplificata: sono disponibili meno account Azure Cosmos DB da gestire.

Compromessi

  • Contesa di risorse: la velocità effettiva condivisa (UR/sec) tra i tenant che si trovano nello stesso contenitore può causare conflitti durante il picco di utilizzo. Questa contesa può creare problemi adiacente rumorosi e problemi di prestazioni se i tenant hanno carichi di lavoro elevati o sovrapposti. Usare questo modello di isolamento per i carichi di lavoro che necessitano di UR garantite in un singolo tenant e possono condividere la velocità effettiva.

  • Isolamento limitato: questo approccio fornisce l'isolamento logico, non l'isolamento fisico. Potrebbe non soddisfare requisiti di isolamento rigorosi dal punto di vista delle prestazioni o della sicurezza.

  • Minore flessibilità: non è possibile personalizzare le funzionalità a livello di account, ad esempio la replica geografica, il ripristino temporizzato e le chiavi gestite dal cliente, per ogni tenant se si isola per chiave di partizione o per database o contenitore.

Funzionalità di Azure Cosmos DB per la multi-tenancy

  • Controllare la velocità effettiva: esplorare le funzionalità che consentono di controllare il problema del vicino rumoroso quando si usa una chiave di partizione per isolare i tenant. Usare funzionalità come la riallocazione della velocità effettiva, la capacità burst e il controllo della velocità effettiva in Java SDK.

  • Chiavi di partizione gerarchiche: usare Azure Cosmos DB in modo che ogni partizione logica possa aumentare le dimensioni fino a 20 GB. Se si ha un singolo tenant che deve archiviare più di 20 GB di dati, è consigliabile distribuire i dati tra più partizioni logiche. Ad esempio, anziché avere una singola chiave di partizione di , è possibile distribuire le chiavi di Contosopartizione creando più chiavi di partizione per un tenant, ad esempio Contoso1 e Contoso2.

    Quando si eseguono query sui dati per un tenant, è possibile usare la WHERE IN clausola per corrispondere a tutte le chiavi di partizione. È anche possibile usare chiavi di partizione gerarchiche per fornire tenant di grandi dimensioni con spazio di archiviazione maggiore di 20 GB se si ha una cardinalità elevata dei tenant. Non è necessario usare chiavi di partizione sintetiche o più valori di chiave di partizione per ogni tenant per questo metodo.

    Si supponga di avere un carico di lavoro che isola i tenant in base alla chiave di partizione. Un tenant, Contoso, è più grande e più pesante da scrivere rispetto ad altri e continua a crescere di dimensioni. Per evitare il rischio di non poter inserire più dati per questo tenant, è possibile usare chiavi di partizione gerarchica. Specificare TenantID come chiave di primo livello e quindi aggiungere un secondo livello, ad esempio UserId. Se si prevede la TenantID combinazione e UserID per produrre partizioni logiche che superano il limite di 20 GB, è possibile partizionare ulteriormente fino a un altro livello, ad esempio SessionID. Le query che specificano TenantID o entrambe TenantID e UserID vengono instradate in modo efficace solo al subset di partizioni fisiche che contengono i dati pertinenti, evitando così una query full fan-out. Se il contenitore ha 1.000 partizioni fisiche, ma un valore specifico TenantId è solo su cinque partizioni fisiche, la query viene instradata al numero inferiore di partizioni fisiche pertinenti.

    Se il primo livello non ha cardinalità sufficientemente elevata e si raggiunge il limite di partizione logica di 20 GB sulla chiave di partizione, è consigliabile usare una chiave di partizione sintetica anziché una chiave di partizione gerarchica.

Modello database-account-per-tenant

Se si isolano i tenant in base all'account del database, ogni tenant ha una propria velocità effettiva di cui è stato effettuato il provisioning a livello di database o contenitore.

Vantaggi

  • Isolamento elevato: questo approccio evita contese o interferenze a causa di account e contenitori di Azure Cosmos DB dedicati che hanno effettuato il provisioning di UR per ogni tenant univoco.

  • Contratti di servizio personalizzati: ogni tenant ha un proprio account, in modo da poter fornire risorse personalizzate specifiche, contratti di servizio per i clienti e garanzie, perché è possibile ottimizzare l'account di database di ogni tenant in modo indipendente per la velocità effettiva.

  • Sicurezza avanzata: l'isolamento dei dati fisici garantisce una sicurezza affidabile perché i clienti possono abilitare chiavi gestite dal cliente a livello di account per tenant. I dati di ogni tenant sono isolati dall'account, anziché trovarsi nello stesso contenitore.

  • Flessibilità: i tenant possono abilitare funzionalità a livello di account come la replica geografica, il ripristino temporizzato e le chiavi gestite dal cliente in base alle esigenze.

Compromessi

  • Maggiore gestione: questo approccio è più complesso perché si gestiscono più account Azure Cosmos DB.

  • Costi più elevati: più account indicano che è necessario effettuare il provisioning della velocità effettiva in ogni risorsa, ad esempio database o contenitori, all'interno dell'account per ogni tenant. Ogni volta che una risorsa effettua il provisioning delle UR, i costi di Azure Cosmos DB aumentano.

  • Limitazioni delle query: tutti i tenant si trovano in account diversi, quindi le applicazioni che eseguono query su più tenant richiedono più chiamate all'interno della logica dell'applicazione.

Funzionalità di Azure Cosmos DB per la multi-tenancy

  • Funzionalità di sicurezza: questo modello offre un maggiore isolamento della sicurezza dell'accesso ai dati tramite il controllo degli accessi in base al ruolo di Azure. Questo modello fornisce anche l'isolamento della sicurezza della crittografia del database a livello di tenant tramite chiavi gestite dal cliente.

  • Configurazione personalizzata: è possibile configurare il percorso dell'account del database in base ai requisiti del tenant. È anche possibile ottimizzare la configurazione delle funzionalità di Azure Cosmos DB, ad esempio la replica geografica e le chiavi di crittografia gestite dal cliente, in base ai requisiti di ogni tenant.

Quando si usa un account Azure Cosmos DB dedicato per tenant, prendere in considerazione il numero massimo di account Azure Cosmos DB per ogni sottoscrizione di Azure.

Elenco completo dei modelli di isolamento

Esigenze del carico di lavoro Chiave di partizione per tenant (scelta consigliata) Contenitore per tenant (velocità effettiva condivisa) Contenitore per tenant (velocità effettiva dedicata) Database per tenant Account di database per tenant (scelta consigliata)
Query tra tenant Facile (il contenitore funge da limite per le query) Difficile Difficile Difficile Difficile
Densità del tenant Alto (costo minimo per tenant) Medio Basso Basso Basso
Eliminazione dei dati del tenant Facile Facile (rilascio del contenitore quando il tenant esce) Facile (rilascio del contenitore quando il tenant esce) Facile (rilascio del database quando il tenant esce) Facile (rilascio del database quando il tenant esce)
Isolamento della sicurezza dell'accesso ai dati È necessario implementare all'interno dell'applicazione Controllo degli accessi in base al ruolo del contenitore Controllo degli accessi in base al ruolo del contenitore Controllo degli accessi in base al ruolo del database RBAC
Replica geografica Replica geografica per tenant non possibile Raggruppare i tenant all'interno degli account di database in base ai requisiti Raggruppare i tenant all'interno degli account di database in base ai requisiti Raggruppare i tenant all'interno degli account di database in base ai requisiti Raggruppare i tenant all'interno degli account di database in base ai requisiti
Prevenzione dei vicini rumorosi No No Sì Sì Sì
Latenza di creazione del nuovo tenant Immediate Veloce Veloce Medio Lente
Vantaggi della modellazione dei dati None Condivisione delle entità Condivisione delle entità Più contenitori per modellare le entità tenant Più contenitori e database per modellare i tenant
Encryption key Uguale per tutti i tenant Uguale per tutti i tenant Uguale per tutti i tenant Uguale per tutti i tenant Chiave gestita dal cliente per tenant
Requisiti di velocità effettiva >0 UR per tenant >100 UR per tenant >100 UR per tenant (con scalabilità automatica solo, altrimenti >400 UR per tenant) >400 UR per tenant >400 UR per tenant
Esempio di caso d'uso App B2C Offerta Standard per le app B2B Offerta Premium per le app B2B Offerta Premium per le app B2B Offerta Premium per le app B2B

Modello contenitore per tenant

È possibile effettuare il provisioning di contenitori dedicati per ogni tenant. I contenitori dedicati funzionano bene quando è possibile combinare i dati archiviati per il tenant in un singolo contenitore. Questo modello offre un isolamento delle prestazioni maggiore rispetto al modello partition-key-per-tenant. Offre anche un maggiore isolamento della sicurezza dell'accesso ai dati tramite il controllo degli accessi in base al ruolo di Azure.

Quando si usa un contenitore per ogni tenant, è consigliabile condividere la velocità effettiva con altri tenant effettuando il provisioning della velocità effettiva a livello di database. Prendere in considerazione le restrizioni e i limiti per il numero minimo di UR per il database e il numero massimo di contenitori nel database. Valutare anche se i tenant richiedono un livello di prestazioni garantito e se sono soggetti al problema dei vicini rumorosi. Quando si condivide la velocità effettiva a livello di database, il carico di lavoro o l'archiviazione in tutti i contenitori deve essere relativamente uniforme. In caso contrario, se si dispone di uno o più tenant di grandi dimensioni, è possibile che si verifichi un problema con un vicino rumoroso. Se necessario, pianificare il raggruppamento di questi tenant in database diversi basati su modelli di carico di lavoro.

In alternativa, è possibile effettuare il provisioning della velocità effettiva dedicata per ogni contenitore. Questo approccio funziona bene per i tenant di dimensioni maggiori e per i tenant che sono a rischio del problema dei vicini rumorosi. Tuttavia, la velocità effettiva di base per ogni tenant è superiore, quindi considerare i requisiti minimi e le implicazioni sui costi di questo modello.

Se il modello di dati del tenant richiede più di un'entità e se tutte le entità possono condividere la stessa chiave di partizione, è possibile suddividerle nello stesso contenitore. Tuttavia, se il modello di dati del tenant è più complesso e richiede entità che non possono condividere la stessa chiave di partizione, prendere in considerazione i modelli database-per-tenant o database-account-per-tenant. Per altre informazioni, vedere Modellare e partizionare i dati in Azure Cosmos DB.

La gestione del ciclo di vita è in genere più semplice quando si dedicano contenitori ai tenant. È possibile spostare facilmente i tenant tra modelli di velocità effettiva condivisi e dedicati. Quando si esegue il deprovisioning di un tenant, è possibile eliminare rapidamente il contenitore.

Modello di database per tenant

È possibile effettuare il provisioning dei database per ogni tenant nello stesso account di database. Analogamente al modello container-per-tenant, questo modello offre un isolamento delle prestazioni maggiore rispetto al modello partition-key-per-tenant. Offre anche un maggiore isolamento della sicurezza dell'accesso ai dati tramite il controllo degli accessi in base al ruolo di Azure.

Analogamente al modello account-per-tenant, questo approccio offre il livello di isolamento delle prestazioni più elevato, ma offre la densità del tenant più bassa. Usare questa opzione se ogni tenant richiede un modello di dati più complesso di quanto sia fattibile nel modello contenitore per tenant. In alternativa, seguire questo approccio se la creazione di un nuovo tenant deve essere veloce o senza sovraccarichi iniziali. Per alcuni framework di sviluppo software, il modello di database per tenant potrebbe essere l'unico livello di isolamento delle prestazioni supportato dal framework. Questi framework in genere non supportano l'isolamento a livello di entità (contenitore) e la condivisione delle entità.

Funzionalità di Azure Cosmos DB che supportano la multi-tenancy

Partizionamento

Usare le partizioni con i contenitori di Azure Cosmos DB per creare contenitori condivisi da più tenant. In genere si usa l'identificatore del tenant come chiave di partizione, ma è anche consigliabile usare più chiavi di partizione per un singolo tenant. Una strategia di partizionamento ben pianificata implementa efficacemente il modello di partizionamento orizzontale. Quando si hanno contenitori di grandi dimensioni, Azure Cosmos DB distribuisce i tenant in più nodi fisici per ottenere un livello elevato di scalabilità.

Prendere in considerazione le chiavi di partizione gerarchica per migliorare le prestazioni della soluzione multi-tenant. Usare chiavi di partizione gerarchica per creare una chiave di partizione che include più valori. Ad esempio, è possibile usare una chiave di partizione gerarchica che include l'identificatore del tenant, ad esempio un GUID con cardinalità elevata, per consentire una scalabilità quasi illimitata. In alternativa, è possibile specificare una chiave di partizione gerarchica che include una proprietà che esegue query di frequente. Questo approccio consente di evitare query tra partizioni. Usare chiavi di partizione gerarchiche per superare il limite di partizione logica di 20 GB per valore della chiave di partizione e limitare query di fanout costose.

Per ulteriori informazioni, vedi le seguenti risorse:

Gestire le UR

Il modello di determinazione prezzi di Azure Cosmos DB si basa sul numero di UR/sec di cui si effettua il provisioning o l'utilizzo. Azure Cosmos DB offre diverse opzioni per effettuare il provisioning della velocità effettiva. In un ambiente multi-tenant, la selezione influisce sulle prestazioni e sul prezzo delle risorse di Azure Cosmos DB.

Per i tenant che richiedono un isolamento garantito delle prestazioni e della sicurezza, è consigliabile isolare i tenant in base all'account del database e allocare ur al tenant. Per i tenant con requisiti meno rigorosi, è consigliabile isolare i tenant in base alla chiave di partizione. Usare questo modello per condividere le UR tra i tenant e ottimizzare il costo per tenant.

Un modello di tenancy alternativo per Azure Cosmos DB prevede la distribuzione di contenitori separati per ogni tenant all'interno di un database condiviso. Usare Azure Cosmos DB per effettuare il provisioning di UR per un database in modo che tutti i contenitori convidano le UR. Se i carichi di lavoro del tenant non si sovrappongono in genere, questo approccio può contribuire a ridurre i costi operativi. Tuttavia, questo approccio è soggetto al problema del vicino rumoroso perché il contenitore di un singolo tenant potrebbe utilizzare una quantità sproporzionata delle UR di cui è stato effettuato il provisioning condiviso. Per attenuare questo problema, identificare prima di tutto i tenant rumorosi. È quindi possibile impostare facoltativamente la velocità effettiva con provisioning in un contenitore specifico. Gli altri contenitori nel database continuano a condividere la velocità effettiva, ma il tenant rumoroso usa la propria velocità effettiva dedicata.

Azure Cosmos DB offre anche un livello serverless, adatto ai carichi di lavoro con traffico intermittente o imprevedibile. In alternativa, è possibile usare la scalabilità automatica per configurare i criteri che specificano il ridimensionamento della velocità effettiva con provisioning. È anche possibile sfruttare la capacità burst di Azure Cosmos DB per ottimizzare l'utilizzo della capacità di velocità effettiva con provisioning, altrimenti limitata dai limiti di velocità. In una soluzione multi-tenant, è possibile combinare tutti questi approcci per supportare diversi tipi di tenant.

Nota

Quando si pianifica la configurazione di Azure Cosmos DB, prendere in considerazione le quote e i limiti del servizio.

Per monitorare e gestire i costi associati a ogni tenant, tenere presente che ogni operazione che usa l'API di Azure Cosmos DB include le UR usate. È possibile usare queste informazioni per aggregare e confrontare le UR effettive utilizzate da ogni tenant. È quindi possibile identificare i tenant con caratteristiche di prestazioni diverse.

Per ulteriori informazioni, vedi le seguenti risorse:

Chiavi gestite dal cliente

Alcuni tenant potrebbero richiedere l'uso delle proprie chiavi di crittografia. Azure Cosmos DB offre una funzionalità chiave gestita dal cliente. Questa funzionalità viene applicata al livello di un account Azure Cosmos DB. Pertanto, se i tenant richiedono chiavi di crittografia personalizzate, è necessario usare account Azure Cosmos DB dedicati per distribuire i tenant.

Per altre informazioni, vedere Configurare chiavi gestite dal cliente per l'account Azure Cosmos DB con Azure Key Vault.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

Altri contributori:

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

Passaggi successivi

Altre informazioni sulla multi-tenancy e Azure Cosmos DB:

Fare riferimento ad alcuni degli altri scenari architetturali di Azure Cosmos DB: