Approcci architetturali per la distribuzione e la configurazione di soluzioni multi-tenant

Indipendentemente dall'architettura e dai componenti usati per implementarlo, è necessario distribuire e configurare i componenti della soluzione. In un ambiente multi-tenant è importante considerare come distribuire le risorse di Azure, soprattutto quando si distribuiscono risorse dedicate per ogni tenant o quando si riconfigurano le risorse in base al numero di tenant nel sistema. In questa pagina vengono forniti agli architetti delle soluzioni indicazioni sulla distribuzione di soluzioni multi-tenant e vengono illustrati alcuni approcci da considerare quando si pianifica la strategia di distribuzione.

Considerazioni e requisiti principali

È importante avere un'idea chiara dei requisiti prima di pianificare la strategia di distribuzione. Le considerazioni specifiche includono quanto segue:

• Scalabilità prevista: si prevede di supportare un numero ridotto di tenant (ad esempio cinque o meno) o si crescerà fino a un numero elevato di tenant?
• Onboarding automatizzato o supportato: quando un tenant è pronto per l'onboarding, sarà in grado di completare il processo stesso seguendo una procedura automatizzata? In alternativa, i nuovi tenant avviano una richiesta e li si esegue manualmente dopo aver ricevuto la richiesta? Sono necessari passaggi di approvazione manuali del team, ad esempio per evitare l'abuso del servizio?
• Tempo di provisioning: quando un tenant è pronto per l'onboarding, quanto è necessario completare il processo di onboarding? Se non si ha una risposta chiara, valutare se deve essere misurato in secondi, minuti, ore o giorni.
• Azure Marketplace: si prevede di usare Azure Marketplace per avviare la distribuzione? In questo caso, è necessario soddisfare i requisiti per aggiungere nuovi tenant.

È anche consigliabile prendere in considerazione i passaggi di onboarding e provisioning, l'automazione e la responsabilità della gestione delle risorse.

Passaggi di onboarding e provisioning

Prendere in considerazione tutto ciò che è necessario eseguire durante l'onboarding di un tenant e documentare questo elenco e flusso di lavoro, anche se viene eseguito manualmente. Il flusso di lavoro di onboarding include in genere quanto segue:

• Accettazione di accordi commerciali.
• Raccolta delle informazioni necessarie per configurare il sistema per il nuovo tenant.
• Passaggi di approvazione manuali, ad esempio, per evitare frodi o abusi del servizio.
• Provisioning delle risorse in Azure.
• Creazione o configurazione di nomi di dominio.
• Eseguire attività di configurazione post-distribuzione, ad esempio la creazione del primo account utente per il tenant e la trasmissione sicura delle credenziali al tenant.
• Modifiche alla configurazione manuale, ad esempio modifiche ai record DNS.

Documentare chiaramente il flusso di lavoro necessario per eseguire l'onboarding di un nuovo tenant.

Prendere in considerazione anche le risorse di Azure specifiche di cui è necessario eseguire il provisioning per un tenant. Anche se non si effettua il provisioning di risorse dedicate per ogni tenant, valutare se a volte è necessario distribuire le risorse quando viene eseguito l'onboarding di un nuovo tenant. Questo problema può verificarsi quando un tenant richiede che i dati vengano archiviati in un'area specifica o quando si avvicinano i limiti di un timbro o di un componente nella soluzione ed è necessario creare un'altra istanza per il batch successivo di tenant.

Valutare se è probabile che il processo di onboarding sia problematico per altri tenant, in particolare per coloro che condividono la stessa infrastruttura. Ad esempio, se è necessario modificare i database condivisi, questo processo potrebbe causare un impatto sulle prestazioni che altri tenant potrebbero notare? Valutare se è possibile evitare questi effetti o attenuarli eseguendo il processo di onboarding al di fuori delle normali ore operative.

Automazione

Le distribuzioni automatizzate sono sempre consigliate per le soluzioni ospitate nel cloud. Quando si lavora con soluzioni multi-tenant, l'automazione della distribuzione diventa ancora più importante per i motivi seguenti:

• Scalabilità: i processi di distribuzione manuali diventano sempre più complessi e dispendiosi in termini di tempo, man mano che aumenta la popolazione dei tenant. Un approccio di distribuzione automatizzato è più semplice da ridimensionare man mano che aumenta il numero di tenant.
• Ripetibile: in un ambiente multi-tenant usare un processo coerente per le distribuzioni in tutti i tenant. I processi manuali introducono la possibilità di errore o di passaggi eseguiti per alcuni tenant e non per altri. Questi processi manuali lasciano l'ambiente in uno stato incoerente, che rende più difficile per il team gestire la soluzione.
• Impatto delle interruzioni: le distribuzioni manuali sono notevolmente più rischiose e soggette a interruzioni rispetto alle distribuzioni automatizzate. In un ambiente multi-tenant l'impatto di un'interruzione a livello di sistema (a causa di un errore di distribuzione) può essere elevato, perché ogni tenant potrebbe essere interessato.

Quando si esegue la distribuzione in un ambiente multi-tenant, è consigliabile usare le pipeline di distribuzione e usare tecnologie di infrastruttura come codice (IaC), ad esempio Bicep, modelli ARM JSON, Terraform o Azure SDK.

Se si prevede di offrire la soluzione tramite Azure Marketplace, è necessario fornire un processo di onboarding completamente automatizzato per i nuovi tenant. Questo processo è descritto nella documentazione delle API di evasione SaaS.

Capacità massima delle risorse

Quando si distribuiscono risorse tenant a livello di codice in risorse condivise, prendere in considerazione il limite di capacità per ogni risorsa. Quando si avvicina tale limite, potrebbe essere necessario creare un'altra istanza della risorsa per supportare un'ulteriore scalabilità. Prendere in considerazione i limiti di ogni risorsa distribuita e le condizioni che attiveranno la distribuzione di un'altra istanza.

Si supponga, ad esempio, che la soluzione includa un server logico SQL di Azure e che la soluzione effettua il provisioning di un database dedicato in tale server per ogni tenant. Un singolo server logico ha limiti, che includono un numero massimo di database supportati da un server logico. Quando si avvicinano questi limiti, potrebbe essere necessario effettuare il provisioning di nuovi server in modo da poter continuare a eseguire l'onboarding dei tenant. Valutare se automatizzare questo processo o monitorare manualmente la crescita.

Responsabilità della gestione delle risorse

In alcune soluzioni multi-tenant si distribuiscono risorse di Azure dedicate per ogni tenant, ad esempio un database per ogni tenant. In alternativa, è possibile scegliere un numero set di tenant da ospitare in una singola istanza di una risorsa, quindi il numero di tenant che si dispone determina il set di risorse distribuite in Azure. In altre soluzioni si distribuisce un singolo set di risorse condivise e si riconfigura quindi le risorse durante l'onboarding di nuovi tenant.

Ognuno di questi modelli richiede di distribuire e gestire le risorse in modi diversi ed è necessario considerare come distribuire e gestire il ciclo di vita delle risorse di cui si effettua il provisioning. Di seguito sono riportati due approcci comuni:

• Per considerare i tenant come configurazione delle risorse distribuite e usare le pipeline di distribuzione per distribuire e configurare tali risorse.
• Per considerare i tenant come dati e avere un piano di controllo di provisioning e configurare l'infrastruttura per i tenant.

Di seguito è riportata una discussione più approfondita di questi approcci.

Test

Pianificare un test completo della soluzione durante e dopo ogni distribuzione. È possibile usare test automatizzati per verificare il comportamento funzionale e non funzionale della soluzione. Assicurarsi di testare il modello di isolamento del tenant e prendere in considerazione l'uso di strumenti come Azure Chaos Studio per introdurre intenzionalmente errori che simulano interruzioni reali e verificare che le funzioni della soluzione anche quando un componente non è disponibile o non funziona correttamente.

Approcci e modelli da prendere in considerazione

Diversi modelli di progettazione del Centro architetture di Azure e della community più ampia sono rilevanti per la distribuzione e la configurazione di soluzioni multi-tenant.

Modello degli stamp di distribuzione

Il modello Deployment Stamps prevede la distribuzione di un'infrastruttura dedicata per un tenant o un gruppo di tenant. Un singolo timbro può contenere più tenant oppure può essere dedicato a un singolo tenant. È possibile scegliere di distribuire un singolo timbro oppure coordinare una distribuzione tra più francobolli. Se si distribuiscono stamp dedicati per ogni tenant, è anche possibile valutare la possibilità di distribuire interi stamp a livello di codice.

Anelli di distribuzione

I circuiti di distribuzione consentono di implementare gli aggiornamenti a gruppi diversi di infrastruttura in momenti diversi. Questo approccio viene comunemente usato con il modello Stamp di distribuzione e i gruppi di timbri possono essere assegnati a anelli distinti in base alle preferenze del tenant, ai tipi di carico di lavoro e ad altre considerazioni. Per altre informazioni, vedere Anelli di distribuzione.

Flag di funzionalità

I flag di funzionalità consentono di esporre progressivamente nuove funzionalità o versioni della soluzione a tenant diversi, mantenendo una singola codebase. È consigliabile usare app Azure Configurazione per gestire i flag di funzionalità. Per altre informazioni, vedere Flag di funzionalità.

A volte è necessario abilitare in modo selettivo funzionalità specifiche per determinati clienti. Ad esempio, potrebbero essere presenti piani tariffari diversi che consentono l'accesso a determinate funzionalità. I flag di funzionalità non sono in genere la scelta giusta per questi scenari. Prendere invece in considerazione la creazione di un processo per tenere traccia e applicare i diritti di licenza di ogni cliente.

Antipattern da evitare

Quando si distribuiscono e si configurano soluzioni multi-tenant, è importante evitare situazioni che impediscono la scalabilità. Di seguito sono elencate le quattro opzioni disponibili.

• Distribuzione e test manuali. Come descritto in precedenza, i processi di distribuzione manuale aggiungono rischi e rallentano la distribuzione. È consigliabile usare le pipeline per le distribuzioni automatizzate, la creazione a livello di codice delle risorse dal codice della soluzione o una combinazione di entrambe.
• Personalizzazioni specializzate per i tenant. Evitare di distribuire funzionalità o una configurazione applicabile solo a un singolo tenant. Questo approccio aggiunge complessità alle distribuzioni e ai processi di test. Usare invece gli stessi tipi di risorse e codebase per ogni tenant e usare strategie come flag di funzionalità per le modifiche temporanee o per le funzionalità implementate progressivamente oppure usare piani tariffari diversi con diritti di licenza per abilitare in modo selettivo le funzionalità per i tenant che li richiedono. Usare un processo di distribuzione coerente e automatizzato, anche per i tenant con risorse isolate o dedicate.

Elenchi di tenant come dati o configurazione

Quando si distribuiscono risorse in una soluzione multi-tenant, è possibile considerare i due approcci seguenti:

• Usare una pipeline di distribuzione automatica per distribuire ogni risorsa. Man mano che vengono aggiunti nuovi tenant, riconfigurare la pipeline per effettuare il provisioning delle risorse per ogni tenant.
• Usare una pipeline di distribuzione automatica per distribuire risorse condivise che non dipendono dal numero di tenant. Per le risorse distribuite per ogni tenant, crearle all'interno dell'applicazione.

Quando si considerano i due approcci, è necessario distinguere tra la gestione dell'elenco di tenant come configurazione o come dati. Questa distinzione è importante anche quando si considera come creare un piano di controllo per il sistema.

Elenco di tenant come configurazione

Quando si considera l'elenco di tenant come configurazione, si distribuiscono tutte le risorse da una pipeline di distribuzione centralizzata. Quando viene eseguito l'onboarding dei nuovi tenant, si riconfigura la pipeline o i relativi parametri. In genere, la riconfigurazione avviene tramite modifiche manuali, come illustrato nel diagramma seguente.

Il processo di onboarding di un nuovo tenant potrebbe essere simile al seguente:

1. Aggiornare l'elenco di tenant. Questo avviene in genere manualmente configurando la pipeline stessa o modificando un file di parametri incluso nella configurazione della pipeline.
2. Attivare l'esecuzione della pipeline.
3. La pipeline ridistribuisce il set completo di risorse di Azure, incluse le nuove risorse specifiche del tenant.

Questo approccio tende a funzionare correttamente per un numero ridotto di tenant e per le architetture in cui tutte le risorse sono condivise. Si tratta di un approccio semplice perché tutte le risorse di Azure possono essere distribuite e configurate usando un singolo processo.

Tuttavia, quando si avvicina un numero maggiore di tenant, ad esempio da 5 a 10 o più, diventa complesso riconfigurare la pipeline man mano che si aggiungono tenant. Il tempo necessario per eseguire la pipeline di distribuzione aumenta spesso in modo significativo. Questo approccio non supporta facilmente la creazione di tenant self-service e il lead time prima dell'onboarding di un tenant può essere più lungo perché è necessario attivare l'esecuzione della pipeline.

Elenco di tenant come dati

Quando si considera l'elenco di tenant come dati, si distribuiscono comunque i componenti condivisi usando una pipeline. Tuttavia, per le risorse e le impostazioni di configurazione che devono essere distribuite per ogni tenant, distribuire o configurare le risorse in modo imperativo. Ad esempio, il piano di controllo può usare gli SDK di Azure per creare una risorsa specifica o per avviare la distribuzione di un modello con parametri.

Il processo di onboarding di un nuovo tenant potrebbe essere simile al seguente e si verificherebbe in modo asincrono:

1. Richiedere l'onboarding di un tenant, ad esempio avviando una richiesta API al piano di controllo del sistema.
2. Un componente del flusso di lavoro riceve la richiesta di creazione e orchestra i passaggi rimanenti.
3. Il flusso di lavoro avvia la distribuzione di risorse specifiche del tenant in Azure. A tale scopo, è possibile usare un modello di programmazione imperativo, ad esempio usando gli SDK di Azure o attivando in modo imperativo la distribuzione di un modello Bicep o Terraform.
4. Al termine della distribuzione, il flusso di lavoro salva i dettagli del nuovo tenant nel catalogo tenant centrale. I dati archiviati per ogni tenant possono includere l'ID tenant e gli ID risorsa per tutte le risorse specifiche del tenant create dal flusso di lavoro.

In questo modo, è possibile effettuare il provisioning delle risorse per i nuovi tenant senza ridistribuire l'intera soluzione. È probabile che il tempo necessario per il provisioning di nuove risorse per ogni tenant sia più breve, perché è necessario distribuire solo tali risorse.

Questo approccio, tuttavia, spesso richiede molto più tempo per la compilazione e il lavoro che si spende deve essere giustificato dal numero di tenant o dagli intervalli di tempo di provisioning che è necessario soddisfare.

Per altre informazioni su questo approccio, vedere Considerazioni per i piani di controllo multi-tenant.

Esempio

Contoso esegue una soluzione multi-tenant per i clienti. Attualmente, hanno sei tenant e si aspettano di aumentare fino a 300 tenant entro i prossimi 18 mesi. Contoso segue l'app Multitenant con database dedicati per ogni approccio al tenant . Hanno distribuito un singolo set di risorse servizio app e un server logico SQL di Azure condiviso tra tutti i tenant e distribuiscono un database SQL di Azure dedicato per ogni tenant, come illustrato nel diagramma seguente.

Contoso usa Bicep per distribuire le risorse di Azure.

Opzione 1- Usare le pipeline di distribuzione per tutti gli elementi

Contoso potrebbe valutare la possibilità di distribuire tutte le risorse usando una pipeline di distribuzione. La pipeline distribuisce un file Bicep che include tutte le risorse di Azure, inclusi i database SQL di Azure per ogni tenant. Un file di parametri definisce l'elenco dei tenant e il file Bicep usa un ciclo di risorse per distribuire un database per ognuno dei tenant elencati, come illustrato nel diagramma seguente.

Se Contoso segue questo modello, è necessario aggiornare il file dei parametri come parte dell'onboarding di un nuovo tenant. È quindi necessario eseguire di nuovo la pipeline. Inoltre, è necessario tenere traccia manualmente del fatto che si trovino vicino a limiti, ad esempio se aumentano a una frequenza imprevistamente elevata e si avvicinano al numero massimo di database supportati in un singolo server logico SQL di Azure.

Opzione 2: usare una combinazione di pipeline di distribuzione e creazione di risorse imperative

In alternativa, Contoso potrebbe considerare la possibilità di separare la responsabilità per le distribuzioni di Azure.

Contoso usa un file Bicep che definisce le risorse condivise da distribuire. Le risorse condivise supportano tutti i tenant e includono un database mappa tenant, come illustrato nel diagramma seguente.

Il team contoso crea quindi un piano di controllo che include un'API di onboarding del tenant. Quando il team di vendita ha completato la vendita a un nuovo cliente, Microsoft Dynamics attiva l'API per avviare il processo di onboarding. Contoso offre anche un'interfaccia Web self-service che i clienti possono usare e che attivano anche l'API.

L'API avvia in modo asincrono un flusso di lavoro che esegue l'onboarding dei nuovi tenant. Il flusso di lavoro avvia la distribuzione di un nuovo database SQL di Azure, che può essere eseguito da uno degli approcci seguenti:

• Usare Azure SDK per avviare la distribuzione di un secondo file Bicep che definisce il database SQL di Azure.
• Usare Azure SDK per creare in modo imperativo un database SQL di Azure usando la libreria di gestione.

Dopo la distribuzione del database, il flusso di lavoro aggiunge il tenant al database dell'elenco di tenant, come illustrato nel diagramma seguente.

Gli aggiornamenti continui dello schema del database vengono avviati dal livello applicazione.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

• John Downs | Principal Software Engineer

Altri contributori:

• Bohdan Cherchyk | Senior 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

• Esaminare le considerazioni per l'aggiornamento di una soluzione multi-tenant.
• Prendere in considerazione gli approcci architetturali per l'archiviazione e i dati.
• Si consideri come usare Azure Resource Manager in una soluzione multi-tenant.