Modelli di tenancy di database delle applicazioni SaaS multi-tenant
Si applica a: 
Database SQL di Azure
Questo articolo descrive i vari criteri di tenancy disponibili per un'applicazione SaaS multi-tenant.
Quando si progetta un'applicazione SaaS multi-tenant, è necessario scegliere con attenzione il criterio di tenancy più adatto alle esigenze dell'applicazione. Un modello di tenancy determina la modalità di mapping dei dati di ogni tenant alla risorsa di archiviazione. La scelta del modello di tenancy influisce sulla progettazione e sulla gestione dell'applicazione. In alcuni casi il passaggio a un modello diverso in un secondo momento è dispendioso.
R. Concetti e terminologia relativi a SaaS
Nel criterio Software as a Service (SaaS), l'azienda non vende licenze del proprio software. ma il cliente paga un noleggio all'azienda e diventa tenant dell'azienda stessa.
In cambio della tariffa di noleggio, ogni tenant ottiene l'accesso ai componenti dell'applicazione SaaS e l'archiviazione dei propri dati nel sistema SaaS.
Il termine modello di tenancy indica il modo in cui sono organizzati i dati dei tenant che vengono archiviati:
- A tenancy singolo: in ogni database sono archiviati i dati di un solo tenant.
- A più tenancy: in ogni database sono archiviati i dati di più tenant diversi, con meccanismi per proteggere la privacy dei dati.
- Sono disponibili anche modelli di tenancy ibridi.
B. Come scegliere il modello di tenancy appropriato
In generale, il criterio di tenancy non influisce sul funzionamento di un'applicazione, ma è probabile che influisca su altri aspetti della soluzione globale. Per valutare ogni modello vengono usati i criteri seguenti:
Scalabilità:
- Numero di tenant.
- Archiviazione per tenant.
- Archiviazione in modo aggregato.
- Carico di lavoro.
Isolamento del tenant: isolamento dei dati e prestazioni (se il carico di lavoro di un tenant influisce su altri).
Costo per tenant: costi del database.
Complessità di sviluppo:
- Modifiche allo schema.
- Modifiche alle query (richieste dal modello).
Complessità operativa:
- Monitoraggio e gestione delle prestazioni.
- Gestione degli schemi.
- Ripristino di un tenant.
- Ripristino di emergenza.
Personalizzabilità: facilità di supporto delle personalizzazioni degli schemi specifiche del tenant o della classe del tenant.
La discussione sui tenancy è incentrata sul livello dei dati. Consideriamo tuttavia per un momento il livello dell'applicazione. Il livello dell'applicazione viene considerato come un'entità monolitica. Se si divide l'applicazione in vari componenti di dimensioni inferiori, la scelta del modello di tenancy potrebbe cambiare. È possibile trattare alcuni componenti in modo diverso rispetto ad altri in merito alla tenancy e alla tecnologia di archiviazione o alla piattaforma usata.
C. App autonoma a tenant singolo con database a tenant singolo
Isolamento del livello dell'applicazione
In questo modello, l'intera applicazione viene installata più volte, una per ogni tenant. Ogni istanza dell'app è un'istanza autonoma, in modo che non interagisca mai con altre istanze autonome. Ogni istanza dell'app ha un solo tenant e pertanto necessita di un solo database. Il database è specifico del tenant.
Ogni istanza dell'app viene installata in un gruppo di risorse di Azure distinto. Il gruppo di risorse può appartenere a una sottoscrizione di proprietà del fornitore del software o del tenant. In entrambi i casi, il fornitore può gestire il software per il tenant. Ogni istanza dell'applicazione è configurata per connettersi al database corrispondente.
Ogni database tenant viene distribuito come database singolo. Questo modello fornisce il livello maggiore di isolamento del database. Tuttavia, l'isolamento richiede l'allocazione di risorse sufficienti in ogni database per gestire i carichi di picco. In questo caso è importante sottolineare che i pool elastici non possono essere usati per i database implementati in gruppi di risorse o in sottoscrizioni diverse. Questa limitazione rende questo modello di app autonoma a tenant singolo la soluzione più costosa dal punto di vista dei costi generali del database.
Gestione fornitori
Il fornitore può accedere a tutti i database in tutte le istanze di app autonome, anche se sono installate in sottoscrizioni tenant diverse. L'accesso avviene tramite connessioni SQL. Questo accesso tra istanze consente al fornitore di centralizzare la gestione degli schemi e le query tra database per scopi di report o analisi. Per ottenere questo tipo di gestione centralizzata, è necessario implementare un catalogo che esegua il mapping degli identificatori dei tenant agli Uniform Resource Identifier (URI) del database. Il database SQL di Azure fornisce una libreria di partizionamento orizzontale usata per fornire un catalogo. La libreria di partizionamento orizzontale è denominata formalmente Libreria client dei database elastici.
D. App multi-tenant con database per tenant
Questo criterio successivo usa un'applicazione multi-tenant con vari database, tutti a tenant singolo. Viene eseguito il provisioning di un nuovo database per ogni nuovo tenant. Il livello applicazione viene aumentato verticalmente mediante l'aggiunta di altre risorse per ogni nodo. In alternativa, l'app viene scalata orizzontalmente aggiungendo altri nodi. Il ridimensionamento è basato sul carico di lavoro ed è indipendente dal numero o dalla scalabilità dei singoli database.
Personalizzazione per un tenant
Come per il criterio delle app autonome, l'uso di database a tenant singolo conferisce un livello elevato di isolamento dei tenant. In qualsiasi app il cui modello specifichi solo database a tenant singolo, lo schema per ogni singolo database specificato può essere personalizzato e ottimizzato per il relativo tenant. Questa personalizzazione non influisce sugli altri tenant nell'app. Un tenant potrebbe necessitare di altri dati rispetto ai campi dati di base richiesti da tutti i tenant. Il campo dati aggiuntivo potrebbe a sua volta richiedere un indice.
Grazie alla funzione di database per tenant, è semplice personalizzare lo schema per uno o più tenant singoli. Il fornitore dell'applicazione deve definire procedure per gestire con attenzione le personalizzazioni dello schema su larga scala.
Pool elastici
Quando vengono distribuiti nello stesso gruppo di risorse, i database possono essere raggruppati in pool elastici. I pool forniscono un modo economico per condividere le risorse tra più database. Questa opzione di pool è più economica rispetto alla necessità per ogni database di contenere i picchi di utilizzo che si trova a gestire. Anche se i database in pool condividono l'accesso alle risorse, possono comunque conseguire un elevato livello di isolamento delle prestazioni.
Il database SQL di Azure fornisce gli strumenti necessari per configurare, monitorare e gestire la condivisione. Nel portale di Azure e nei log di Monitoraggio di Azure, sono disponibili le metriche delle prestazioni a livello di pool e di database. Le metriche possono fornire dettagli sulle prestazioni aggregate e specifiche del tenant. I singoli database possono essere spostati tra i pool per fornire risorse riservate a un tenant specifico. Questi strumenti garantiscono prestazioni ottimali in modo conveniente.
Scalabilità delle operazioni per la funzione di database per tenant
Il database SQL di Azure offre numerose funzionalità di gestione progettate per gestire un numero elevato di database su larga scala, ad esempio ben più di 100.000 database. Queste funzionalità rendono plausibile il criterio di database per tenant.
Si supponga ad esempio un sistema con un database di 1.000 tenant come unico database. Il database potrebbe avere 20 indici. Se il sistema esegue una conversione per ottenere 1.000 database a tenant singolo, la quantità degli indici aumenta a 20.000. Nel database SQL di Azure, nell'ambito dell'ottimizzazione automatica, le funzionalità di indicizzazione automatica sono abilitate per impostazione predefinita. L'indicizzazione automatica gestisce tutti i 20.000 indici e le ottimizzazioni costanti di creazione ed eliminazione. Queste azioni automatizzate si verificano all'interno di un singolo database e non vengono coordinate o limitate da azioni simili in altri database. L'indicizzazione automatica considera gli indici in modo diverso in un database occupato rispetto a un database meno occupato. Questo tipo di personalizzazione della gestione degli indici potrebbe risultare poco pratico a livello di database per tenant se questa significativa attività di gestione deve essere eseguita manualmente.
Altre funzionalità di gestione facilmente scalabili includono quanto segue:
- Backup predefiniti.
- Disponibilità elevata.
- Crittografia su disco.
- Dati di telemetria relativi alle prestazioni.
Automation
Le operazioni di gestione possono essere eseguite tramite script e offerte mediante un modello devops. Le operazioni possono anche essere automatizzate ed esposte nell'applicazione.
Ad esempio, è possibile automatizzare un ripristino temporizzato di un tenant singolo. Il ripristino prevede soltanto il recupero del database a tenant singolo che archivia il tenant. Questo ripristino non ha alcun impatto su altri tenant, a conferma del fatto che le operazioni di gestione si verificano a livello di granularità di ogni singolo tenant.
E. app multi-tenant con database multi-tenant
Un altro criterio disponibile permette di archiviare diversi tenant in un database multi-tenant. L'istanza dell'applicazione può avere un numero qualsiasi di database multi-tenant. Lo schema di un database multi-tenant deve contenere una o più colonne di identificatori dei tenant, in modo che i dati di un determinato tenant possano essere recuperati in modo selettivo. Lo schema potrebbe anche richiedere alcune tabelle o colonne utilizzate solo da un subset di tenant. Tuttavia, codice statico e dati di riferimento vengono archiviati una sola volta e condivisi da tutti i tenant.
L'isolamento dei tenant viene ignorato
Dati: un database multi-tenant comporta necessariamente che venga ignorato l'isolamento dei tenant. I dati di più tenant vengono archiviati insieme in un database. Durante lo sviluppo, verificare che le query non espongano mai i dati di più tenant. Il database SQL supporta la sicurezza a livello di riga, in base alla quale i dati restituiti da una query possono rientrare nell'ambito di un singolo tenant.
Elaborazione: un database multi-tenant condivide le risorse di calcolo e archiviazione tra tutti i suoi tenant. È possibile monitorare l'intero database per verificare che le prestazioni siano accettabili. Tuttavia, il sistema Azure non è in grado di monitorare o gestire l'uso di queste risorse da un singolo tenant per impostazione predefinita. Il database multi-tenant rischia quindi maggiormente di incontrare elementi che potrebbero influire negativamente sulle prestazioni, in cui il carico di lavoro di un tenant iperattivo influisce sulle prestazioni di altri tenant nello stesso database. Un livello ulteriore di monitoraggio a livello di applicazione potrebbe monitorare le prestazioni a livello di tenant.
Costi ridotti
In generale, i database multi-tenant sono caratterizzati dal costo minimo per tenant. I costi delle risorse per un database singolo sono inferiori rispetto a quelli per un pool elastico di dimensioni equivalenti. Inoltre, per i casi in cui i tenant necessitano di risorse di archiviazione limitate, è possibile archiviare milioni di tenant in un singolo database. Nessun pool elastico può contenere milioni di database. Tuttavia, una soluzione contenente 1.000 database per pool, con 1.000 pool, può raggiungere una scala di milioni, al rischio di comprometterne la gestibilità.
Di seguito vengono discusse due varianti di un modello di database multi-tenant, in cui il modello multi-tenant partizionato rappresenta la soluzione più flessibile e scalabile.
F. App multi-tenant con un singolo database multi-tenant
Il criterio di database multi-tenant più semplice usa un database singolo per ospitare i dati di tutti i tenant. Con l'aggiunta di più tenant, il database viene aumentato con maggiori risorse di archiviazione e calcolo. Questo aumento potrebbe essere sufficiente, sebbene esista sempre un limite di ridimensionamento. Tuttavia, molto prima che venga raggiunto questo limite, il database diventa complesso da gestire.
Le operazioni di gestione incentrate sui singoli tenant sono più complesse da implementare, in un database multi-tenant. Su larga scala, queste operazioni potrebbero diventare inaccettabilmente lente. Un esempio è rappresentato da un ripristino temporizzato dei dati per un solo tenant.
G. App multi-tenant con database multi-tenant partizionati
La maggior parte delle applicazioni SaaS accede ai dati di un solo tenant alla volta. Questo criterio di accesso consente di distribuire i dati in più database o partizioni, in cui tutti i dati di ogni tenant sono contenuti in una sola partizione. In combinazione con un criterio di database multi-tenant, un modello partizionato consente un livello quasi illimitato di scalabilità.
Gestire le partizioni
Il partizionamento orizzontale aggiunge complessità a livello di progettazione e di gestione operativa. È necessario un catalogo in cui gestire il mapping tra i tenant e i database. Sono anche necessarie procedure di gestione per gestire le partizioni e il popolamento dei tenant. Ad esempio, è necessario progettare procedure per aggiungere e rimuovere le partizioni e per spostare i dati dei tenant tra le partizioni. Una procedura di scalabilità consiste nell'aggiungere una nuova partizione e popolarla con nuovi tenant. In altri casi si potrebbe suddividere una partizione densamente popolata in due partizioni con minore densità. Dopo aver spostato o sospeso diversi tenant, si potrebbero unire le partizioni meno densamente popolate. L'unione comporterebbe un uso delle risorse più economico. Per bilanciare i carichi di lavoro, è possibile spostare anche i tenant tra le partizioni.
Il database SQL offre uno strumento di divisione/unione che opera insieme alla libreria di partizionamento orizzontale e al database del catalogo. L'app fornita consente di dividere e unire le partizioni e di spostare i dati dei tenant tra le partizioni. L'app gestisce anche il catalogo, durante queste operazioni, contrassegnando i tenant interessati come offline prima di spostarli. Dopo lo spostamento, l'app aggiornerà di nuovo il catalogo con il nuovo mapping, contrassegnando il tenant come online.
Database di dimensioni ridotte più facili da gestire
Distribuendo i tenant tra più database, la soluzione multi-tenant partizionata determina una maggiore facilità di gestione dei database di dimensioni ridotte. Ad esempio, il ripristino temporizzato di un tenant specifico prevede ora il ripristino di un singolo database di dimensioni ridotte da un backup anziché da un database di dimensioni maggiori che contiene tutti i tenant. È possibile scegliere la dimensione del database e il numero di tenant per database per bilanciare il carico di lavoro e gli impegni di gestione.
Identificatore di tenant nello schema
In base all'approccio di partizionamento orizzontale usato, potrebbero essere imposti ulteriori vincoli sullo schema di database. L'applicazione di divisione/unione del database SQL richiede che lo schema includa la chiave di partizionamento orizzontale, che in genere corrisponde all'identificatore del tenant. L'identificatore del tenant è l'elemento iniziale nella chiave primaria di tutte le tabelle partizionate. L'identificatore del tenant consente all'applicazione di divisione/unione di individuare e spostare rapidamente i dati associati a un tenant specifico.
Pool elastico per partizioni
I database multi-tenant partizionati possono essere inseriti in pool elastici. In generale, includere molti database a tenant singolo in un pool è vantaggioso tanto quanto includere più tenant in alcuni database multi-tenant. I database multi-tenant risultano vantaggiosi in presenza di un numero elevato di tenant relativamente inattivi.
H. Modello di database multi-tenant partizionato ibrido
Nel modello ibrido tutti i database presentano l'identificatore del tenant nello schema. I database sono tutti in grado di archiviare più tenant e possono essere partizionati. A livello di schema, sono quindi tutti database multi-tenant. In pratica, però, alcuni database contengono un solo tenant. Indipendentemente da ciò, la quantità di tenant archiviati in un determinato database non ha effetto sullo schema del database.
Spostamento dei tenant
È possibile spostare in qualsiasi mo.ento un tenant specifico nel relativo database multi-tenant. E sempre in qualsiasi momento è possibile cambiare idea e ripristinare il tenant in un database contenente più tenant. È anche possibile assegnare un tenant a un nuovo database a tenant singolo quando si esegue il provisioning del nuovo database.
Il modello ibrido risulta particolarmente indicato se sussistono grandi differenze tra le esigenze di risorse dei gruppi identificabili di tenant. Si supponga ad esempio che ai tenant che fanno parte di una versione di valutazione gratuita non venga garantito lo stesso livello di prestazioni elevate dei tenant che fanno parte di una sottoscrizione. I criteri per i tenant nella fase della versione di valutazione gratuita potrebbero prevedere l'archiviazione in un database multi-tenant condiviso tra tutti i tenant della versione di valutazione gratuita. Quando un tenant di una versione di valutazione gratuita esegue la sottoscrizione al livello di servizio di base, può essere spostato in un altro database multi-tenant che potrebbe avere un numero inferiore di tenant. Un sottoscrittore che ha acquistato il livello di servizio Premium potrebbe essere spostato nel nuovo database a tenant singolo corrispondente.
Pool
In questo modello ibrido i database a tenant singolo per i tenant con sottoscrizione possono essere posizionati in pool di risorse per ridurre i costi di database per ogni tenant. Questa situazione si verifica anche nel modello di database per tenant.
I. Modelli di tenancy a confronto
La tabella seguente riepiloga le differenze tra i modelli di tenancy principali.
| Misura | App autonoma | Database per tenant | Multi-tenant partizionato |
|---|---|---|---|
| Ridimensiona | Medio (1-100 s) | Alta (1-100.000 s) | Illimitato (1-1.000.000 s) |
| Isolamento dei tenant | Alto | Alta | Basso, ad eccezione di eventuali tenant singoli (soli in un database MT). |
| Costo di database per tenant | Alto; dimensionato per i picchi. | Basso; vengono usati i pool. | Minimo, per tenant di piccole dimensioni nei database MT. |
| Monitoraggio e gestione delle prestazioni | Solo per singolo tenant | Aggregati + per singolo tenant | Aggregati, ma per singolo tenant solo per i database singoli. |
| Complessità di sviluppo | Basso | Basso | Media, a causa del partizionamento orizzontale. |
| Complessità operativa | Bassa-alta. Semplice a livello individuale, complessa su larga scala. | Bassa-media. I criteri gestiscono la complessità su larga scala. | Bassa-alta. La gestione dei singoli tenant è complessa. |
Contenuto correlato
Welcome to the Wingtip Tickets sample SaaS Azure SQL Database tenancy app (Introduzione all'app SaaS Wingtip Tickets del tenancy del database SQL di Azure di esempio)