Esistono molti modi per considerare come usare i tenant nella soluzione. La scelta dell'approccio dipende in modo importante dal fatto che e come si condividono le risorse tra i tenant. In modo intuitivo, è possibile evitare di condividere qualsiasi risorsa, ma questo approccio diventa rapidamente costoso quando le scalabilità aziendali vengono ridimensionate e si esegue l'onboarding di più tenant.
Quando si considerano i vari modelli di multitenancy, è utile prendere in considerazione prima di tutto il modo in cui si definiscono i tenant per l'organizzazione, quali sono i driver aziendali e come si prevede di ridimensionare la soluzione. Questo articolo fornisce indicazioni per aiutare i responsabili delle decisioni tecniche a valutare i modelli di tenancy e i relativi compromessi.
Definire un tenant
Prima di tutto, è necessario definire un tenant per l'organizzazione. Prendere in considerazione chi è il cliente. In altre parole, chi fornisce i propri servizi? I due modelli più comuni sono:
- Business to business (B2B). Se i clienti sono altre organizzazioni, è probabile che i tenant vengano mappati a tali clienti. Tuttavia, valutare se i clienti hanno divisioni (team o reparti) e se hanno una presenza in più paesi/aree geografiche. Potrebbe essere necessario eseguire il mapping di un singolo cliente a più tenant se sono presenti requisiti diversi per questi sottogruppi. Analogamente, un cliente potrebbe voler mantenere due istanze del servizio in modo che possano mantenere separati tra loro gli ambienti di sviluppo e produzione. In genere, un singolo tenant ha più utenti. Ad esempio, tutti i dipendenti del cliente saranno utenti all'interno di un singolo tenant.
- Business to consumer (B2C). Se i clienti sono consumer, spesso è più complicato correlare clienti, tenant e utenti. In alcuni scenari, ogni consumer potrebbe essere un tenant separato. Tuttavia, valutare se la soluzione potrebbe essere usata da famiglie, gruppi di amici, club, associazioni o altri gruppi che potrebbero dover accedere e gestire i dati insieme. Ad esempio, un servizio di streaming musicale può supportare sia utenti singoli che famiglie e può trattare ognuno di questi tipi di account in modo diverso quando li separa in tenant.
La definizione del tenant influisce su alcune delle cose che è necessario prendere in considerazione o sottolineare quando si progetta la soluzione. Si considerino ad esempio questi tipi di tenant:
- Se i tenant sono singoli utenti o famiglie, potrebbe essere necessario essere particolarmente preoccupati della modalità di gestione dei dati personali e delle leggi sulla sovranità dei dati all'interno di ogni giurisdizione usata.
- Se i tenant sono aziende, potrebbe essere necessario tenere presente i requisiti dei clienti per la conformità alle normative, l'isolamento dei dati e la garanzia di soddisfare un obiettivo di livello di servizio (SLO) specificato, ad esempio la disponibilità del tempo di attività o del servizio.
Come si decide quale modello usare?
La selezione di un modello di tenancy non è solo una decisione tecnica. È anche una decisione commerciale. È necessario prendere in considerazione domande come queste:
- Quali sono gli obiettivi aziendali?
- I clienti accettano tutte le forme di multitenancy? In che modo ogni modello multitenancy influisce sui requisiti di conformità o sui requisiti di conformità del cliente?
- Una soluzione a tenant singolo verrà ridimensionata in base alle aspirazioni di crescita future?
- Quanto è grande il team operativo e quanto è possibile automatizzare la gestione dell'infrastruttura?
- I clienti si aspettano di soddisfare i contratti di servizio (CONTRATTI di servizio) o si hanno contratti di servizio a cui si punta?
Se si prevede che l'azienda venga ridimensionata a un numero elevato di clienti, è importante distribuire l'infrastruttura condivisa. In caso contrario, sarà necessario mantenere una grande e crescente flotta di istanze. La distribuzione di singole risorse di Azure per ogni cliente è probabilmente insostenibile, a meno che non si effettua il provisioning e non si usi una sottoscrizione dedicata per ogni tenant. Quando si condivide la stessa sottoscrizione di Azure in più tenant, le quote e i limiti delle risorse di Azure potrebbero iniziare a essere applicati e i costi operativi per distribuire e riconfigurare queste risorse aumentano con ogni nuovo cliente.
Al contrario, se si prevede che l'azienda avrà solo pochi clienti, è consigliabile considerare l'uso di risorse a tenant singolo dedicate a ogni cliente. Inoltre, se i requisiti di isolamento dei clienti sono elevati, un'infrastruttura a tenant singolo potrebbe essere appropriata.
Tenant e distribuzioni
È quindi necessario determinare il tenant che significa per la soluzione specifica e se è necessario distinguere tra tenant logici e distribuzioni.
Si consideri ad esempio un servizio di streaming musicale. Inizialmente, è possibile creare una soluzione che può gestire facilmente migliaia (o anche decine di migliaia) di utenti. Quando si continua a crescere, tuttavia, si potrebbe trovare che è necessario duplicare la soluzione o alcuni dei relativi componenti per aumentare la domanda dei clienti. Ciò significa che è necessario determinare come assegnare clienti specifici a istanze specifiche della soluzione. È possibile assegnare i clienti in modo casuale o geografico oppure riempiendo una singola istanza e quindi avviando un'altra. Tuttavia, è probabile che sia necessario mantenere un record dei clienti e dell'infrastruttura in cui sono disponibili i dati e le applicazioni in modo che sia possibile instradare il traffico all'infrastruttura corretta. In questo esempio è possibile rappresentare ogni cliente come tenant separato e quindi eseguire il mapping degli utenti alla distribuzione che contiene i dati. È disponibile un mapping uno-a-molti tra tenant e distribuzioni e è possibile spostare i tenant tra le distribuzioni a propria discrezione.
Si consideri invece un'azienda che crea software cloud per le società legali. I clienti potrebbero insistere sulla disponibilità di un'infrastruttura dedicata per mantenere gli standard di conformità. Pertanto, è necessario essere preparati per distribuire e gestire molte istanze diverse della soluzione dall'inizio. In questo esempio una distribuzione contiene sempre un singolo tenant e un tenant viene mappato alla propria distribuzione dedicata.
Una differenza fondamentale tra tenant e distribuzioni è il modo in cui viene applicato l'isolamento. Quando più tenant condividono una singola distribuzione (un set di infrastruttura), in genere si basa sul codice dell'applicazione e su un identificatore del tenant presente in un database per mantenere separati i dati di ogni tenant. Quando si dispone di tenant con le proprie distribuzioni dedicate, hanno una propria infrastruttura, quindi potrebbe essere meno importante per il codice essere consapevoli che è operativo in un ambiente multi-tenant.
Le distribuzioni vengono talvolta definite supertenenti o francobolli.
Quando si riceve una richiesta per un tenant specifico, è necessario eseguirne il mapping alla distribuzione che contiene i dati del tenant, come illustrato di seguito:
Isolamento dei tenant
Una delle principali considerazioni sulla progettazione di un'architettura multi-tenant è il livello di isolamento necessario per ogni tenant. L'isolamento può significare cose diverse:
- Avere un'unica infrastruttura condivisa, con istanze separate dell'applicazione e database separati per ogni tenant.
- Condivisione di alcune risorse comuni, ma mantenendo separate altre risorse per ogni tenant.
- Mantenere i dati in un'infrastruttura fisica separata. Nel cloud questa configurazione potrebbe richiedere risorse di Azure separate per ogni tenant. Potrebbe anche significare la distribuzione di un'infrastruttura fisica separata usando host dedicati.
Invece di pensare all'isolamento come una proprietà discreta, è consigliabile considerarla come in un continuum. È possibile distribuire componenti dell'architettura più o meno isolati rispetto ad altri componenti nella stessa architettura, in base ai propri requisiti. Il diagramma seguente illustra un continuum di isolamento:
Il livello di isolamento influisce su molti aspetti dell'architettura, tra cui quanto segue:
- Sicurezza. Se si condivide l'infrastruttura tra più tenant, è necessario prestare particolare attenzione a non accedere ai dati da un tenant quando si restituiscono risposte a un altro. È necessaria una base solida per la strategia di identità e è necessario considerare sia il tenant che l'identità utente nel processo di autorizzazione.
- Costi. L'infrastruttura condivisa può essere usata da più tenant, quindi è meno costoso.
- Prestazioni. Se si condivide l'infrastruttura, le prestazioni del sistema potrebbero soffrire in quanto più clienti lo usano, perché le risorse potrebbero essere usate più velocemente.
- Affidabilità Se si usa un singolo set di infrastruttura condivisa, un problema con i componenti di un tenant può causare un'interruzione per tutti.
- Risposta alle singole esigenze del tenant. Quando si distribuisce l'infrastruttura dedicata a un tenant, potrebbe essere possibile adattare la configurazione per le risorse ai requisiti di tale tenant specifico. È anche possibile considerare questa funzionalità nel modello di prezzi, consentendo ai clienti di pagare di più per le distribuzioni isolate.
L'architettura della soluzione può influenzare le opzioni disponibili per l'isolamento. Si consideri ad esempio un'architettura di soluzione a tre livelli:
- Il livello dell'interfaccia utente potrebbe essere un'app Web multi-tenant condivisa, con tutti i tenant che accedono a un singolo nome host.
- Il livello intermedio potrebbe essere un livello applicazione condiviso, con code di messaggi condivisi.
- Il livello dati può essere isolato di database, tabelle o contenitori BLOB.
È possibile prendere in considerazione l'uso di diversi livelli di isolamento in ogni livello. È consigliabile basare la decisione su ciò che è condiviso e su ciò che è isolato in molte considerazioni, tra cui costi, complessità, requisiti dei clienti e numero di risorse che è possibile distribuire prima di raggiungere quote e limiti di Azure.
Modelli comuni di tenancy
Dopo aver stabilito i requisiti, valutarli in base a alcuni modelli comuni di tenancy e ai modelli di distribuzione corrispondenti.
Distribuzioni a tenant singolo automatizzate
In un modello di distribuzione a tenant singolo automatizzato si distribuisce un set dedicato di infrastruttura per ogni tenant, come illustrato in questo esempio:
L'applicazione è responsabile dell'avvio e del coordinamento della distribuzione delle risorse di ogni tenant. In genere, le soluzioni che usano questo modello usano l'infrastruttura come codice (IaC) o le API di Azure Resource Manager ampiamente. È possibile usare questo approccio quando è necessario effettuare il provisioning di infrastrutture completamente separate per ognuno dei clienti. Prendere in considerazione il modello Deployment Stamps quando si pianifica la distribuzione.
Benefici: Un vantaggio fondamentale di questo approccio è che i dati per ogni tenant sono isolati, riducendo il rischio di perdite accidentali. Questa protezione può essere importante per alcuni clienti che hanno un sovraccarico di conformità alle normative elevato. Inoltre, è improbabile che i tenant influiscano sulle prestazioni del sistema, un problema che a volte viene chiamato problema del vicino rumoroso . Aggiornamenti e le modifiche possono essere implementate progressivamente tra i tenant, riducendo la probabilità di un'interruzione a livello di sistema.
Rischi: Se si usa questo approccio, l'efficienza dei costi è bassa perché non si condivide l'infrastruttura tra i tenant. Se un singolo tenant richiede un determinato costo dell'infrastruttura, è probabile che 100 tenant richiedano 100 volte tale costo. Inoltre, la manutenzione continua (ad esempio l'applicazione di nuove configurazioni o aggiornamenti software) richiederà molto tempo. Prendere in considerazione l'automazione dei processi operativi e valutare la possibilità di applicare le modifiche progressivamente tramite gli ambienti. È anche consigliabile prendere in considerazione altre operazioni di distribuzione incrociata, ad esempio la creazione di report e l'analisi nell'intero patrimonio. Analogamente, assicurarsi di pianificare come è possibile eseguire query e modificare i dati in più distribuzioni.
Distribuzioni completamente multi-tenant
Al contrario, è possibile considerare una distribuzione completamente multi-tenant, in cui tutti i componenti sono condivisi. È disponibile un solo set di infrastruttura da distribuire e gestire e tutti i tenant lo usano, come illustrato nel diagramma seguente:
Benefici: Questo modello è interessante perché la gestione di una soluzione con componenti condivisi è meno costosa. Anche se è necessario distribuire livelli o SKU di risorse superiori, il costo complessivo della distribuzione è spesso ancora inferiore al costo di un set di risorse a tenant singolo. Inoltre, se un utente o un tenant deve spostare i dati in un altro tenant, potrebbe essere possibile aggiornare gli identificatori e le chiavi del tenant e potrebbe non essere necessario eseguire la migrazione dei dati tra due distribuzioni separate.
Rischi:
Assicurarsi di separare i dati per ogni tenant e di non perdere dati tra i tenant. Potrebbe essere necessario gestire i dati di partizionamento orizzontale. Inoltre, potrebbe essere necessario preoccuparsi degli effetti che i singoli tenant possono avere nel sistema complessivo. Ad esempio, se un tenant di grandi dimensioni tenta di eseguire una query o un'operazione intensa, potrebbe influire su altri tenant.
Determinare come tenere traccia e associare i costi di Azure ai tenant, se necessario.
La manutenzione può essere più semplice con una singola distribuzione, perché è necessario aggiornare solo un set di risorse. Tuttavia, è anche più rischioso, perché le modifiche potrebbero influire sull'intera base di clienti.
Potrebbe anche essere necessario prendere in considerazione la scalabilità. È più probabile che si raggiungano i limiti di scalabilità delle risorse di Azure quando si dispone di un set condiviso di infrastruttura. Ad esempio, se si usa un account di archiviazione come parte della soluzione, man mano che la scalabilità aumenta, il numero di richieste a tale account di archiviazione potrebbe raggiungere il limite di ciò che l'account di archiviazione può gestire. Per evitare di raggiungere un limite di quota di risorse, è possibile valutare la possibilità di distribuire più istanze delle risorse, ad esempio più cluster del servizio Azure Kubernetes o account di archiviazione. È anche possibile valutare la possibilità di distribuire i tenant tra le risorse distribuite in più sottoscrizioni di Azure.
Probabilmente esiste un limite alla scalabilità di una singola distribuzione e i costi di questa operazione potrebbero aumentare in modo non lineare. Ad esempio, se si dispone di un singolo database condiviso, quando si esegue su larga scala, è possibile esaurirne la velocità effettiva e dover pagare sempre di più per aumentare la velocità effettiva per mantenere il passo con la domanda.
Distribuzioni partizionate verticalmente
Non è necessario scegliere uno degli estremi di queste scale. È invece possibile prendere in considerazione il partizionamento verticale dei tenant adottando questo approccio:
- Usare una combinazione di distribuzioni a tenant singolo e multi-tenant. Ad esempio, la maggior parte dei dati e dei livelli applicazione dei clienti nelle infrastrutture multi-tenant può essere disponibile, ma distribuire infrastrutture a tenant singolo per i clienti che richiedono prestazioni o isolamento dei dati più elevati.
- Distribuire più istanze della soluzione geograficamente ed eseguire il mapping di ogni tenant a una distribuzione specifica. Questo approccio è particolarmente efficace quando si hanno tenant in aree geografiche diverse.
Ecco un esempio che illustra una distribuzione condivisa per alcuni tenant e una distribuzione a tenant singolo per un'altra:
Benefici: Poiché si condivide ancora l'infrastruttura, è possibile ottenere alcuni dei vantaggi economici derivanti dall'uso di distribuzioni multi-tenant condivise. È possibile distribuire risorse condivise più economiche per determinati clienti, ad esempio i clienti che valutano il servizio con una versione di valutazione. È anche possibile fatturare ai clienti una tariffa più elevata per usare una distribuzione a tenant singolo, ripristinando così alcuni dei costi.
Rischi: La codebase dovrà probabilmente essere progettata per supportare sia distribuzioni multi-tenant che a tenant singolo. Se si prevede di consentire la migrazione tra infrastrutture, è necessario considerare come eseguire la migrazione dei clienti da una distribuzione multi-tenant alla propria distribuzione a tenant singolo. È anche necessario sapere quali tenant si trovano in ogni distribuzione, in modo da poter comunicare informazioni sui problemi di sistema o sugli aggiornamenti ai clienti pertinenti.
Distribuzioni partizionate orizzontalmente
È anche possibile prendere in considerazione il partizionamento orizzontale delle distribuzioni. In una distribuzione orizzontale sono presenti alcuni componenti condivisi, ma si gestiscono altri componenti con distribuzioni a tenant singolo. Ad esempio, è possibile creare un singolo livello applicazione e quindi distribuire singoli database per ogni tenant, come illustrato in questo diagramma:
Benefici: Le distribuzioni partizionate orizzontalmente consentono di ridurre un problema adiacente rumoroso, se si identifica che la maggior parte del carico nel sistema è causata da componenti specifici che è possibile distribuire separatamente per ogni tenant. Ad esempio, i database potrebbero assorbire la maggior parte del carico del sistema, perché il carico delle query è elevato. Se un singolo tenant invia un numero elevato di richieste alla soluzione, le prestazioni di un database potrebbero essere influenzate negativamente, ma i database di altri tenant (e i componenti condivisi, ad esempio il livello applicazione) rimangono invariati.
Rischi: Con una distribuzione partizionata orizzontalmente, è comunque necessario considerare la distribuzione e la gestione automatizzati dei componenti, in particolare i componenti usati da un singolo tenant.
Testare il modello di isolamento
Indipendentemente dal modello di isolamento scelto, assicurarsi di testare la soluzione per verificare che i dati di un tenant non vengano accidentalmente persi a un altro e che gli effetti di un vicino rumoroso siano accettabili. Prendere in considerazione l'uso di Azure Chaos Studio per introdurre intenzionalmente errori che simulano interruzioni reali e verificare la resilienza della soluzione anche quando i componenti non funzionano correttamente.
Autori di contributi
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai collaboratori seguenti.
Autore principale:
- John Downs | Principal Customer Engineer, FastTrack per Azure
Altri collaboratori:
- Chad Kittel | Principal Software Engineer
- Paolo Salvatori | Principal Customer Engineer, FastTrack per Azure
- Arsen Vladimir | Principal Customer Engineer, FastTrack per Azure
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.
Passaggi successivi
Prendere in considerazione il ciclo di vita dei tenant