Modelli di tenancy per una soluzione multi-tenant

Esistono molti modi per considerare come usare i tenant nella soluzione. L'approccio dipende 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 considerare innanzitutto come definire 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 necessario definire un tenant per l'organizzazione. Prendere in considerazione chi è il cliente o chi riceve i servizi. Esistono due modelli comuni:

• Business to business (B2B): Se i clienti sono altre organizzazioni, di solito i tenant vengono mappati a tali clienti aziendali. Valutare tuttavia se i clienti hanno divisioni, ad esempio team o reparti, e se hanno una presenza in più paesi o 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 l'uno dall'altro gli ambienti di sviluppo e produzione. Un singolo tenant ha in genere 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 consumatori, è spesso più complicato associare clienti, affittuari 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 i tipi di tenant seguenti:

• Se i tenant sono singole persone o famiglie, potrebbe essere necessario riflettere su come gestire i dati personali e sulle leggi sulla sovranità dei dati in ogni giurisdizione in cui operi.

• Se i tenant sono aziende, potrebbe essere necessario tenere presenti i requisiti dei clienti per la conformità alle normative e l'isolamento dei dati. Assicurarsi di soddisfare un obiettivo del livello di servizio (SLO) specificato, ad esempio il tempo di attività o la disponibilità del servizio.

Decidere quale modello usare

La selezione di un modello di tenancy non è solo una decisione tecnica. È anche una decisione commerciale. È necessario considerare le domande seguenti:

• Obiettivi aziendali: Valutare se ridurre i costi per ogni tenant o ottimizzare l'esperienza del tenant si allinea più strettamente agli obiettivi strategici.

• Conformità: Valutare se 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?

• Scala: Valutare se una soluzione a tenant singolo può essere scalabile in base alle aspirazioni di crescita future.

• Automazione: Prendere in considerazione le dimensioni del team operativo e la quantità di gestione dell'infrastruttura che è possibile automatizzare.

• Accordi sul livello di servizio (SLA): Considerare se i clienti si aspettano che voi raggiungiate gli SLA, o se avete obiettivi di livello di servizio (SLO) su cui puntare.

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 possono 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 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 persino decine di migliaia di utenti. Tuttavia, man mano che l'organizzazione continua a crescere, potrebbe essere necessario duplicare la soluzione o alcuni dei relativi componenti per adattarsi alla nuova domanda dei clienti. Per eseguire questa attività, è necessario determinare come assegnare clienti specifici a istanze specifiche della soluzione. Puoi assegnare i clienti in modo casuale, geografico o riempiendo una singola istanza per poi avviare un'altra istanza, nota anche come ottimizzazione del contenitore. Tuttavia, probabilmente è necessario mantenere un record dei clienti e dell'infrastruttura in cui risiedono i dati e le applicazioni in modo da indirizzare il traffico alla posizione corretta. In questo esempio, è possibile rappresentare ogni cliente come tenant separato ed eseguire il mapping degli utenti alla distribuzione che contiene i dati. Questo approccio crea una relazione uno-a-molti tra tenant e distribuzioni ed è possibile spostare i tenant tra distribuzioni secondo necessità.

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 la conformità ai requisiti normativi. 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 i tenant hanno distribuzioni dedicate, hanno una propria infrastruttura, quindi potrebbe essere meno importante per il codice tenere conto di 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 nel diagramma seguente:

Per altre informazioni, vedere Eseguire il mapping delle richieste ai tenant.

Isolamento degli inquilini

Una delle considerazioni più importanti nella progettazione dell'architettura multi-tenant è il livello di isolamento necessario per ogni tenant. L'isolamento può fare riferimento alle configurazioni seguenti:

• Avere una singola infrastruttura condivisa che include 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 scenari estremi, può anche richiedere di distribuire un'infrastruttura fisica separata usando host dedicati.

Invece di visualizzare l'isolamento come proprietà discreta, considerarlo uno spettro. È possibile distribuire componenti dell'architettura più isolati o meno isolati rispetto ad altri componenti nella stessa architettura, a seconda dei requisiti. Il diagramma seguente illustra un continuum di isolamento:

Il livello di isolamento influisce su molti aspetti dell'architettura:

• Sicurezza: Se si condivide l'infrastruttura tra più tenant, prestare attenzione a non accedere ai dati da un tenant quando si restituiscono risposte a un'altra. È 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: Più tenant possono usare l'infrastruttura condivisa, quindi è meno costosa.

• Prestazione: Se si condivide l'infrastruttura, le prestazioni del sistema potrebbero peggiorare man mano che più clienti lo usano perché le risorse potrebbero essere utilizzate più velocemente. I tenant con modelli di utilizzo insoliti possono peggiorare i problemi di prestazioni.

• 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 considerare questa funzionalità nel modello di determinazione prezzi per consentire 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'applicazione web multi-tenant condivisa. Tutti i tenant accedono a un unico hostname.

• Il livello intermedio può essere un livello dell'applicazione condiviso, con code di messaggi comuni.

• I livelli di dati possono essere costituiti da database isolati, tabelle o contenitori BLOB.

È possibile usare diversi livelli di isolamento per ogni livello. È necessario basare la decisione su cosa condividere e su cosa isolare su diversi fattori, tra cui costi, complessità, requisiti dei clienti e il numero di risorse che è possibile distribuire prima di raggiungere quote e 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 nell'esempio seguente:

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 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.

Benefici: 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 i clienti che hanno un sovraccarico di conformità alle normative elevato. Inoltre, è improbabile che i tenant influiscano sulle prestazioni del sistema dell'altro, noto anche come 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 costo di infrastruttura specifico, è probabile che 100 tenant richiedano 100 volte tale costo. Inoltre, la manutenzione continua, come l'applicazione di nuovi aggiornamenti di configurazione o software, può richiedere 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. Pianificare come 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:

Benefici: Questo modello è interessante perché l'uso 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. Potrebbe anche essere necessario considerare gli 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 queste informazioni sono importanti per l'utente.

• È possibile semplificare la manutenzione usando una singola distribuzione perché è necessario aggiornare solo un 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 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.

• Probabilmente esiste un limite per quanto è possibile ridimensionare una singola distribuzione e i costi di ridimensionamento potrebbero aumentare in modo non lineare. Ad esempio, se si dispone di un singolo database condiviso eseguito 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 partizionare verticalmente i tenant adottando l'approccio seguente:

• Usare una combinazione di distribuzioni a tenant singolo e multi-tenant. Ad esempio, si potrebbe avere la maggior parte dei dati e dei livelli applicazione dei clienti in infrastrutture multi-tenant, ma si distribuiscono 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 è 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:

Benefici: Poiché si condividono ancora alcune delle infrastrutture, è possibile ottenere alcuni dei vantaggi derivanti dall'uso di distribuzioni multi-tenant condivise. È possibile distribuire risorse condivise meno costose per clienti specifici, ad esempio i clienti che valutano il servizio usando una versione di valutazione. È anche possibile addebitare ai clienti una tariffa più elevata per l'uso di 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 partizionare orizzontalmente le 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:

Benefici: Le distribuzioni partizionate orizzontalmente consentono di attenuare un problema rumoroso adiacente. Se si identifica che i componenti specifici causano la maggior parte del carico nel sistema, è 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 e i componenti condivisi di altri tenant, ad esempio il livello applicazione, rimangono invariati.

Rischi: Con una distribuzione partizionata orizzontalmente, è comunque necessario prendere in considerazione 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 persi a un altro e che i risultati dei vicini rumorosi 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.

Contributori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autore principale:

• John Downs | Principal Software Engineer, Azure Patterns & Practices

Altri collaboratori:

• Chad Kittel | Principal Software Engineer, Azure Patterns & Practices
• Paolo Salvatori | Principal Customer Engineer, FastTrack per Azure
• Arsen Vladimirskiy | Ingegnere principale per i clienti, FastTrack per Azure

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

Passo successivo

Prendere in considerazione il ciclo di vita dei tenant.