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 risorse , ma questo approccio diventa rapidamente costoso man mano che l'azienda si ridimensiona e si esegue l'onboarding di più tenant.
Quando si considerano i vari modelli di multi-tenancy, è 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 decision maker tecnici 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, a chi stai fornendo i tuoi 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 gestire due istanze del servizio in modo che possano mantenere separati gli ambienti di sviluppo e produzione. In genere, un singolo tenant ha più utenti. Ad esempio, tutti i dipendenti del cliente sono 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 insieme i dati. Ad esempio, un servizio di streaming musicale può supportare singoli utenti e famiglie e può trattare ognuno di questi tipi di account in modo diverso quando li separa in tenant.
La definizione del tenant influisce su alcuni aspetti 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 preoccuparsi in particolare del modo in cui si gestiscono i dati personali e delle leggi sulla sovranità dei dati all'interno di ogni giurisdizione gestita.
- Se i tenant sono aziende, potrebbe essere necessario tenere presenti i requisiti dei clienti per la conformità alle normative, l'isolamento dei dati e assicurarsi di soddisfare un obiettivo del livello di servizio (SLO) specificato, ad esempio tempi di attività o disponibilità 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 le seguenti:
- Quali sono i tuoi obiettivi aziendali?
- I clienti accetteranno tutte le forme di multi-tenancy? In che modo ogni modello multi-tenancy influisce sui requisiti di conformità o sui requisiti di conformità dei clienti?
- Una soluzione a tenant singolo verrà ridimensionata in base alle future aspirazioni di crescita?
- Quanto è grande il team operativo e quanto è possibile automatizzare la gestione dell'infrastruttura?
- I clienti si aspettano di soddisfare i contratti di servizio o i contratti di servizio previsti per i contratti di servizio?
Se si prevede che l'azienda possa essere ridimensionata a un numero elevato di clienti, è importante distribuire l'infrastruttura condivisa. In caso contrario, è necessario mantenere una flotta di istanze di risorse di grandi dimensioni e in crescita. La distribuzione di singole risorse di Azure per ogni cliente è probabilmente insostenibile, a meno che non si esegua il provisioning e non si usi una sottoscrizione dedicata per ogni tenant. Quando si condivide la stessa sottoscrizione di Azure tra 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.
Viceversa, se si prevede che l'azienda abbia solo pochi clienti, è possibile prendere in considerazione l'uso di risorse a tenant singolo dedicate a ogni cliente. Inoltre, se i requisiti di isolamento dei clienti sono elevati, un approccio all'infrastruttura a tenant singolo potrebbe essere appropriato anche se è più costoso.
Tenant e distribuzioni
Successivamente, è necessario determinare il significato del tenant 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 in grado di gestire facilmente migliaia (o anche decine di migliaia) di utenti. Man mano che si continua a crescere, tuttavia, si potrebbe scoprire che è necessario duplicare la soluzione o alcuni dei relativi componenti per ridimensionare la nuova 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 altro (imballaggio bin). Tuttavia, è probabile che sia necessario mantenere un record dei clienti e dell'infrastruttura in cui sono disponibili i dati e le applicazioni per indirizzare 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 ed è possibile spostare i tenant tra le distribuzioni a propria discrezione.
Al contrario, prendere in considerazione un'azienda che crea software cloud per le aziende legali. I clienti potrebbero insistere sulla disponibilità di un'infrastruttura dedicata per mantenere gli standard di conformità. Pertanto, è necessario essere pronti per distribuire e gestire molte istanze diverse della soluzione fin 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 fa affidamento sul codice dell'applicazione e su un identificatore di 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 tenere presente che il codice opera in un ambiente multi-tenant.
Le distribuzioni vengono talvolta definite supertenenti o timbri.
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:
Per altre informazioni, vedere Eseguire il mapping delle richieste ai tenant.
Isolamento dei tenant
Una delle considerazioni principali per la progettazione di un'architettura multi-tenant è il livello di isolamento necessario per ogni tenant. L'isolamento può significare cose diverse:
- Una singola 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. In situazioni estreme, potrebbe anche significare la distribuzione di un'infrastruttura fisica separata usando host dedicati.
Anziché pensare all'isolamento come a una proprietà discreta, è consigliabile considerarlo come 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 i seguenti:
- Protezione. 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 solida base per la strategia di gestione delle identità ed è necessario considerare sia il tenant che l'identità utente nel processo di autorizzazione.
- Costo. L'infrastruttura condivisa può essere usata da più tenant, quindi è meno costosa.
- Prestazioni. Se si condivide l'infrastruttura, le prestazioni del sistema potrebbero risentire dell'uso di più clienti, perché le risorse potrebbero essere utilizzate più velocemente. I problemi di prestazioni possono essere esacerbati dai tenant con modelli di utilizzo insoliti.
- Affidabilità. Se si usa un singolo set di infrastruttura condivisa, un problema con un solo componente può causare un'interruzione per tutti i tenant.
- Velocità di risposta alle esigenze dei singoli 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 prendere in considerazione questa funzionalità nel modello di determinazione 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 può essere un livello applicazione condiviso, con code di messaggi condivise.
- 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 cosa è condiviso e su cosa è isolato in molte considerazioni, tra cui costi, complessità, requisiti dei clienti e il numero di risorse che è possibile distribuire prima di raggiungere le quote e i limiti di Azure.
Modelli di tenancy comuni
Dopo aver stabilito i requisiti, valutarli rispetto ad alcuni modelli di tenancy comuni 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 in modo esteso. È possibile usare questo approccio quando è necessario effettuare il provisioning di infrastrutture completamente separate per ognuno dei clienti. Prendere in considerazione l'uso del modello Deployment Stamps quando si pianifica la distribuzione.
Vantaggi: un vantaggio fondamentale di questo approccio è che i dati per ogni tenant sono isolati, riducendo così 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 dell'altro, un problema che a volte viene chiamato problema del vicino rumoroso. Gli aggiornamenti e le modifiche possono essere implementati 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 in corso (ad esempio l'applicazione di nuove configurazioni o aggiornamenti software) probabilmente richiederà molto tempo. Prendere in considerazione l'automazione dei processi operativi e valutare la possibilità di applicare le modifiche in modo progressivo tramite gli ambienti. È anche consigliabile prendere in considerazione altre operazioni di distribuzione incrociata, ad esempio la creazione di report e l'analisi nell'intera flotta. Analogamente, assicurarsi di pianificare come è possibile eseguire query e modificare i dati tra più distribuzioni.
Distribuzioni completamente multi-tenant
All'estrema estremità opposta, è 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:
Vantaggi: questo modello è interessante perché il funzionamento di una soluzione con componenti condivisi è meno costoso rispetto all'uso di singole risorse per ogni tenant. Anche se è necessario distribuire livelli o SKU di risorse superiori per tenere conto dell'aumento del carico, 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 un solo set di risorse. Tuttavia, è anche più rischioso, perché le modifiche potrebbero influire sull'intera base dei clienti.
Potrebbe anche essere necessario prendere in considerazione la scalabilità. È più probabile raggiungere 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 quote di risorse, è possibile valutare la possibilità di distribuire un pool di 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.
È probabile che esista un limite a quanto è possibile ridimensionare 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 pagare sempre 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, è possibile che la maggior parte dei dati e dei livelli applicazione dei clienti si trovi in infrastrutture multi-tenant, 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.
Di seguito è riportato un esempio che illustra una distribuzione condivisa per alcuni tenant e una distribuzione a tenant singolo per un'altra:
Vantaggi: poiché si condivide ancora parte dell'infrastruttura, è possibile ottenere alcuni dei vantaggi 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, che consente di recuperare alcuni dei costi.
Rischi: la codebase deve essere progettata per supportare distribuzioni multi-tenant e a tenant singolo. Se si prevede di consentire la migrazione tra distribuzioni, è necessario considerare come eseguire la migrazione dei clienti da una distribuzione multi-tenant alla propria distribuzione a tenant singolo. È anche necessario conoscere 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 mantengono altri componenti con distribuzioni a tenant singolo. Ad esempio, è possibile compilare un singolo livello applicazione e quindi distribuire singoli database per ogni tenant, come illustrato in questo diagramma:
Vantaggi: le distribuzioni partizionate orizzontalmente consentono di attenuare un problema di rumore adiacente: se si identifica che la maggior parte del carico nel sistema è causata da componenti specifici, è possibile distribuire componenti separati 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 automatizzata 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 trapelati in un altro e che gli effetti rumorosi dei vicini 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.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autore principale:
- John Downs | Principal Software Engineer
Altri contributori:
- Chad Kittel | Principal Software Engineer
- Paolo Salvatori | Principal Customer Engineer, FastTrack per Azure
- Arsen Vladimirintune | 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