Multi-tenancy e Azure Cosmos DB

In questa pagina vengono descritte alcune delle funzionalità di Azure Cosmos DB utili quando si lavora con sistemi multi-tenant. Sono disponibili anche collegamenti a linee guida ed esempi per l'uso di Azure Cosmos DB in una soluzione multi-tenant.

Requisiti di multi-tenancy

Quando si pianifica una soluzione multi-tenant, potrebbe essere necessario progettare due esigenze principali per:

• Garantire un forte isolamento tra i tenant e soddisfare requisiti di sicurezza rigorosi per coloro che ne hanno bisogno.
• Gestione di un costo basso per tenant. In qualità di provider, si vuole garantire che il costo dell'esecuzione dell'applicazione rimanga sostenibile man mano che viene ridimensionato.

Queste due esigenze possono spesso entrare in conflitto, richiedendo compromessi e assegnando una priorità rispetto all'altra. Esistono alcune linee guida che è possibile seguire per comprendere meglio i compromessi coinvolti nell'affrontare entrambe le esigenze descritte in precedenza. Questo documento consente di esplorare queste considerazioni in modo da poter prendere decisioni informate durante la progettazione della soluzione multi-tenant.

Modalità di isolamento

È necessario decidere il livello di isolamento 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:

• Chiave di partizione per tenant, spesso usata per soluzioni multi-tenant come quelle usate nel software business-to-consumer come servizio (SaaS B2C).
• Account di database per tenant, che è spesso. usato in SaaS business-to-business (B2B).

Per selezionare 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 le aziende vendono direttamente a un singolo cliente usando il prodotto o il servizio. Tuttavia, i modelli B2B possono classificare in ordine di priorità l'isolamento avanzato della sicurezza e delle prestazioni e potrebbe 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 potenziali clienti. È possibile distribuire un account di database separato per tenant aziendali a pagamento, che necessitano di garanzie di sicurezza e isolamento avanzate, condividendo un account di database e usando chiavi di partizione per isolare i clienti della versione di valutazione.

Modelli di isolamento consigliati

Chiave di partizione per tenant

Isolando i tenant in base alla chiave di partizione, la velocità effettiva verrà condivisa tra tenant e raggruppati all'interno dello stesso contenitore.

Vantaggi:

• Efficienza dei costi: tutti i tenant vengono inseriti all'interno di un contenitore, partizionato in base all'ID tenant. Poiché è disponibile una sola risorsa fatturabile in cui viene effettuato il provisioning delle UR/sec e condivisa tra più tenant, questo approccio è in genere più conveniente e più semplice da gestire rispetto alla presenza di account separati per tenant.
• Gestione semplificata: meno account Azure Cosmos DB da gestire.

Compromessi:

• Contesa di risorse: la condivisione della velocità effettiva (UR/sec) tra tenant nello stesso contenitore può causare conflitti durante il picco di utilizzo, causando il problema Noisy Neighbor che può causare problemi di prestazioni se i tenant hanno carichi di lavoro elevati o sovrapposti. Questo modello di isolamento è appropriato per i carichi di lavoro che necessitano di UR/sec garantiti in un singolo tenant e possono condividere.
• Isolamento limitato: questo approccio fornisce l'isolamento logico, non l'isolamento fisico. Potrebbe non soddisfare requisiti di isolamento rigorosi, indipendentemente dal punto di vista delle prestazioni e della sicurezza.
• Minore flessibilità: la personalizzazione di funzionalità a livello di account come la replica geografica, il ripristino temporizzato (PITR) e le chiavi gestite dal cliente (CMK) per tenant non sono disponibili se l'isolamento tramite chiave di partizione (o da database/contenitore).

Funzionalità pertinenti di Azure Cosmos DB:

• Controllare la velocità effettiva: esplorare le funzionalità che consentono di controllare il problema del vicino rumoroso durante la modellazione del tenant in base alla partizione, ad esempio la riallocazione della velocità effettiva, la capacità burst e il controllo della velocità effettiva in Java SDK.

• Chiavi di partizione gerarchiche: Azure Cosmos DB consente a ogni partizione logica di crescere 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, invece di avere una singola chiave di partizione di , è possibile che le chiavi di Contosopartizione vengano saltato creando più chiavi di partizione per un tenant, ad esempio Contoso1, Contoso2e così via.

  Quando si eseguono query sui dati per un tenant, è possibile usare la WHERE IN clausola per trovare una corrispondenza con tutte le chiavi di partizione. Le chiavi di partizione gerarchiche possono essere usate anche per supportare tenant di grandi dimensioni (purché si disponga di cardinalità elevata dei tenant), con archiviazione maggiore di 20 GB, senza dover usare chiavi di partizione sintetiche o più valori di chiave di partizione per tenant.

  Si supponga di avere un carico di lavoro che isola i tenant in base alla chiave di partizione. Un tenant, Contoso, è molto più grande e 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, SessionIDad esempio . 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 una query completa di fan-out. Se il contenitore aveva 1.000 partizioni fisiche, ma un valore specifico TenantId era solo su 5 partizioni fisiche, la query verrà instradata al numero inferiore di partizioni fisiche pertinenti.

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

Account di database per tenant

Isolando i tenant in base all'account del database, ogni tenant avrà una propria velocità effettiva di cui viene effettuato il provisioning a livello di database o contenitore.

Vantaggi:

• Isolamento elevato: questo approccio evita conflitti o interferenze a causa di account e contenitori di Azure Cosmos DB dedicati con ur/sec di cui è stato effettuato il provisioning per ogni tenant univoco.
• Contratti di servizio personalizzati: a causa di ogni tenant con un proprio account, è possibile fornire risorse personalizzate specifiche, contratti di servizio per i clienti e garanzie perché l'account di database di ogni tenant può essere ottimizzato in modo indipendente per la velocità effettiva.
• Sicurezza avanzata: l'isolamento dei dati fisici garantisce una sicurezza affidabile perché i clienti possono abilitare le chiavi gestite dal cliente a livello di account per ogni 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 (PITR) e le chiavi gestite dal cliente in base alle esigenze.

Compromessi:

• Maggiore gestione: questo approccio offre una maggiore complessità perché si gestiscono più account Azure Cosmos DB.
• Costi più elevati: più account indicano la velocità effettiva di provisioning (UR/sec) in ogni risorsa (database e/o contenitori) all'interno dell'account, per ogni tenant. Ogni volta che una risorsa effettua il provisioning di UR/sec, i costi di Azure Cosmos DB aumentano.
• Limitazioni delle query: poiché tutti i tenant si trovano all'interno di account diversi, sono necessarie più chiamate all'interno della logica dell'applicazione per ogni tenant durante l'esecuzione di query per più tenant.

Funzionalità pertinenti di Azure Cosmos DB:

• Funzionalità di sicurezza: questo modello offre un maggiore isolamento della sicurezza dell'accesso ai dati usando il controllo degli accessi in base al ruolo di Azure. Questo modello fornisce inoltre 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 ogni tenant, prendere in considerazione il numero massimo di account Azure Cosmos DB per ogni sottoscrizione di Azure.

Elenco completo dei modelli di isolamento

Contenitore per tenant

È possibile effettuare il provisioning di contenitori dedicati per ogni tenant. I contenitori dedicati funzionano bene quando i dati archiviati per il tenant possono essere combinati in un singolo contenitore. Questo modello offre un isolamento delle prestazioni maggiore rispetto al modello partition-key-per-tenant precedente e 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, è possibile considerare la condivisione della velocità effettiva con altri tenant effettuando il provisioning della velocità effettiva a livello di database. Prendere in considerazione le restrizioni e i limiti relativi al numero minimo di unità richiesta per il database e al numero massimo di contenitori nel database. Valutare anche se i tenant richiedono un livello di prestazioni garantito e se sono soggetti al problema Noisy Neighbor. 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, potrebbe verificarsi un problema rumoroso vicino, se sono presenti uno o più tenant di grandi dimensioni. 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 a rischio del problema Noisy Neighbor. 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à, purché tutte le entità possano condividere la stessa chiave di partizione, possono essere condivise 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 di seguito. Per altre indicazioni, vedere l'articolo su come modellare e partizionare i dati in Azure Cosmos DB usando un esempio reale.

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

Database per tenant

È possibile effettuare il provisioning dei database per ogni tenant nello stesso account di database. Analogamente al modello container-per-tenant precedente, questo modello offre un isolamento delle prestazioni maggiore rispetto al modello partition-key-per-tenant e 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. Tuttavia, questa opzione è ottimale quando ogni tenant richiede un modello di dati più complesso di quanto sia fattibile nel modello container-per-tenant. In alternativa, è consigliabile seguire questo approccio quando è necessario che la creazione di nuovi tenant sia veloce e/o senza alcun sovraccarico per creare account tenant in anticipo. Può anche essere il caso, per il framework di sviluppo software specifico usato, che database per tenant è l'unico livello di isolamento delle prestazioni riconosciuto in tale framework. L'isolamento a livello di entità (contenitore) e la condivisione delle entità non sono in genere supportati in modo nativo in tali framework.

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

Partizionamento

Usando le partizioni con i contenitori di Azure Cosmos DB, è possibile creare contenitori condivisi tra 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. Con contenitori di grandi dimensioni, Azure Cosmos DB distribuisce i tenant tra più nodi fisici per ottenere un livello elevato di scalabilità.

È consigliabile esplorare l'uso delle chiavi di partizione gerarchica per migliorare le prestazioni della soluzione multi-tenant. Le chiavi di partizione gerarchica consentono di 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à usata di frequente nelle query. Questo approccio consente di evitare query tra partizioni. Usando chiavi di partizione gerarchiche, è possibile superare il limite di partizioni logiche di 20 GB per ogni valore della chiave di partizione e limitare query di fan-out costose.

Ulteriori informazioni:

• Partizionamento e scalabilità orizzontale in Azure Cosmos DB
• Chiavi di partizione gerarchica

Gestione delle unità richiesta

Il modello tariffario di Azure Cosmos DB si basa sul numero di unità richiesta al secondo di cui è stato effettuato il provisioning o l'utilizzo. Un'unità richiesta è 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 per il carico di lavoro, detto velocità effettiva. Azure Cosmos DB offre diverse opzioni per il provisioning della velocità effettiva. In un ambiente multi-tenant, la selezione effettuata 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 unità richiesta al tenant. Per i tenant con requisiti meno rigorosi, è consigliabile isolare i tenant in base alla chiave di partizione, che consente di condividere le unità richiesta tra i tenant e di ottimizzare per un costo basso 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. Azure Cosmos DB consente di effettuare il provisioning delle unità richiesta per un database e tutti i contenitori condividono le unità richiesta. 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 Noisy Neighbor perché il contenitore di un singolo tenant potrebbe utilizzare una quantità sproporzionata delle unità richiesta con 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 per i carichi di lavoro con traffico intermittente o imprevedibile. In alternativa, la scalabilità automatica consente di configurare i criteri per specificare il ridimensionamento della velocità effettiva con provisioning. È anche possibile sfruttare la capacità burst di Azure Cosmos DB, ottimizzando l'utilizzo della capacità di velocità effettiva con provisioning, che sarebbe stata limitata in caso contrario. In una soluzione multi-tenant è possibile combinare tutti questi approcci per supportare diversi tipi di tenant.

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

Ulteriori informazioni:

• Provisioning velocità effettiva
• Scalabilità automatica
• Senza server
• Misurazione dell'addebito ur di una richiesta
• Quote del servizio Azure Cosmos DB
• Capacità burst

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, quindi i tenant che richiedono le proprie chiavi di crittografia devono essere distribuiti usando account Azure Cosmos DB dedicati.

Ulteriori informazioni:

• Configurare le 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:

• Tara Bhatia | Program Manager, Azure Cosmos DB
• Paul Burpo | Principal Customer Engineer, FastTrack per Azure
• John Downs | Principal Software Engineer

Altri contributori:

• Mark Brown | Principal PM Manager, Azure Cosmos DB
• Deborah Chen | Principal Program Manager
• Theo van Kraay | Senior Program Manager, Azure Cosmos DB
• Arsen Vladimirintune | Principal Customer Engineer, FastTrack per Azure
• Thomas Weiss | Principal Program Manager
• Vic Perdana | Cloud Solution Architect, Azure ISV

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

Passaggi successivi

Esaminare gli approcci di archiviazione e dati per la multi-tenancy.

Altre informazioni sulla multi-tenancy e Azure Cosmos DB:

• Progettare e creare app SaaS multi-tenant su larga scala con Azure Cosmos DB: una sessione alla build 2024 che illustra come progettare per la multi-tenancy in Azure Cosmos DB e apprendere le procedure consigliate da un ISV reale.
• Azure Cosmos DB e sistemi multi-tenant: post di blog che illustra come creare un sistema multi-tenant che usa Azure Cosmos DB.
• Applicazioni multi-tenant con Azure Cosmos DB (video)
• Creazione di un saaS multi-tenant con Azure Cosmos DB e Azure (video): un case study reale su come Whally, un'avvio SaaS multi-tenant, ha creato una piattaforma moderna da zero in Azure Cosmos DB e Azure. Whally mostra le decisioni di progettazione e implementazione prese in relazione al partizionamento, alla modellazione dei dati, alla multi-tenancy sicura, alle prestazioni, allo streaming in tempo reale dal feed di modifiche a SignalR e altro ancora. Tutte queste soluzioni usano ASP.NET Core nei servizi app Azure.

Risorse correlate

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

• App serverless con Azure Cosmos DB
• Modello Outbox transazionale con Azure Cosmos DB
• Ricerca visiva nel settore della vendita al dettaglio con Azure Cosmos DB
• Giochi con Azure Cosmos DB