Approcci architetturali per il calcolo in soluzioni multi-tenant

La maggior parte delle soluzioni basate sul cloud è costituita da risorse di calcolo. Queste risorse possono includere livelli Web e applicazione, processori batch, processi pianificati o risorse specializzate come GPU e calcolo ad alte prestazioni. Le soluzioni multi-tenant spesso traggono vantaggio dalle risorse di calcolo condivise perché una maggiore densità di tenant per ogni infrastruttura riduce i costi operativi e semplifica la gestione. È consigliabile considerare i requisiti di isolamento e le implicazioni dell'infrastruttura condivisa.

Questo articolo fornisce indicazioni su considerazioni e requisiti cruciali per gli architetti di soluzioni da considerare quando pianificano un livello di calcolo multi-tenant. Queste linee guida includono modelli comuni per l'applicazione della multitenancy ai servizi di calcolo e antipattern da evitare.

Considerazioni e requisiti chiave

Sia la multi-tenancy che il modello di isolamento scelto influiscono sul ridimensionamento, sulle prestazioni, sulla gestione dello stato e sulla sicurezza delle risorse di calcolo. Le sezioni seguenti esaminano le decisioni chiave da prendere quando si pianifica una soluzione di calcolo multi-tenant.

Scala

I sistemi devono essere eseguiti in modo adeguato man mano che la domanda cambia. Man mano che il numero di tenant e il traffico aumentano, potrebbe essere necessario ridimensionare le risorse per soddisfare la domanda crescente e mantenere prestazioni accettabili. Analogamente, quando il numero di utenti attivi o la quantità di traffico diminuisce, è consigliabile ridurre automaticamente la capacità di calcolo per ridurre i costi. Tuttavia, è consigliabile ridurre al minimo eventuali interruzioni per gli utenti quando si regola la capacità.

Se si distribuiscono risorse dedicate per ogni tenant, è possibile ridimensionare le risorse di ogni tenant in modo indipendente. In una soluzione in cui le risorse di calcolo vengono condivise tra più tenant, il ridimensionamento di tali risorse consente a tutti i tenant di trarre vantaggio dall'aumento della capacità. Tuttavia, tutti i tenant soffrono quando la scalabilità non è sufficiente per gestire il carico complessivo. Per ulteriori informazioni, vedere antipattern Noisy Neighbor.

Quando si creano soluzioni cloud, è possibile scegliere se ridimensionare orizzontalmente o verticalmente. In una soluzione multi-tenant con un numero crescente di tenant, la scalabilità orizzontale offre in genere una maggiore flessibilità e un limite complessivo di scalabilità superiore.

I problemi di prestazioni rimangono spesso non rilevati fino a quando non viene caricata un'applicazione. È possibile usare un servizio completamente gestito, ad esempio Test di carico di Azure, per informazioni sul funzionamento dell'applicazione sotto stress.

Attivatori di scalabilità

Indipendentemente dall'approccio usato per la scalabilità, in genere è necessario pianificare i trigger che determinano la scalabilità dei componenti. Quando sono presenti componenti condivisi, prendere in considerazione i modelli di carico di lavoro di ogni tenant per assicurarsi che la capacità provisionata soddisfi la domanda totale richiesta. Questo approccio consente di evitare conflitti di risorse e di ridurre la probabilità che i tenant riscontrano il problema del vicino rumoroso. Potresti anche essere in grado di pianificare la capacità di ridimensionamento considerando il numero di inquilini. Ad esempio, se si misurano le risorse usate per gestire 100 tenant, quando si esegue l'onboarding di più tenant, è possibile pianificare la scalabilità in modo che le risorse siano raddoppiate per ogni tenant aggiuntivo di 100.

stato

Le risorse di calcolo possono essere senza stato oppure con stato. I componenti senza stato non mantengono alcun dato tra le richieste. Dal punto di vista della scalabilità, i componenti senza stato sono spesso facili da aumentare perché è possibile aggiungere rapidamente nuovi ruoli di lavoro, istanze o nodi. I componenti senza stato possono anche iniziare immediatamente a elaborare le richieste. Se l'architettura supporta il riutilizzo dell'istanza, è anche possibile riassegnare istanze da un tenant a un altro tenant.

Le risorse con stato possono essere ulteriormente suddivise in base al tipo di stato gestito. Lo stato persistente è costituito dai dati che devono essere archiviati in modo permanente. Nelle soluzioni cloud evitare di archiviare uno stato persistente nel livello di calcolo. Usare invece servizi di archiviazione come database o account di archiviazione. Lo stato temporaneo è costituito dai dati archiviati temporaneamente. Include cache in memoria di sola lettura e archiviazione di file temporanei su dischi locali.

Lo stato temporaneo è spesso utile per migliorare le prestazioni del livello applicazione riducendo il numero di richieste ai servizi di archiviazione back-end. Ad esempio, quando si usa una cache in memoria, potrebbe essere possibile gestire le richieste di lettura senza connettersi a un database e senza eseguire una query intensa eseguita di recente quando è stata servita un'altra richiesta.

Nelle applicazioni sensibili alla latenza, il costo dell'idratazione della cache può diventare significativo. Una soluzione multi-tenant può peggiorare questo problema se ogni tenant richiede dati diversi da memorizzare nella cache. Per attenuare questo problema, alcune soluzioni applicano l'affinità di sessione. Questo approccio garantisce che lo stesso nodo di lavoro di calcolo elabori tutte le richieste per un utente o un tenant specifico. L'affinità di sessione può migliorare la capacità del livello applicazione di usare la cache in modo efficace. Tuttavia, l'affinità di sessione complica anche il ridimensionamento e il bilanciamento del carico del traffico tra i ruoli di lavoro. Prendi in considerazione questo compromesso con attenzione. Per molte applicazioni, l'affinità di sessione non è necessaria.

È anche possibile archiviare i dati in cache esterne, ad esempio Cache Redis di Azure. Le cache esterne sono ottimizzate per il recupero dei dati a bassa latenza, isolando lo stato dalle risorse di calcolo in modo che possano essere ridimensionate e gestite separatamente. In molte soluzioni, le cache esterne consentono di migliorare le prestazioni dell'applicazione, mantenendo il livello di calcolo senza stato.

Isolamento

Quando si progetta un livello di calcolo multi-tenant, sono disponibili diverse opzioni per l'isolamento del tenant. È possibile distribuire risorse di calcolo condivise per tutti i tenant, risorse di calcolo dedicate per singoli tenant o un approccio semi-isolato che rientra tra questi estremi. Ogni opzione ha compromessi. Per decidere l'opzione più adatta alla soluzione, prendere in considerazione i requisiti per l'isolamento.

È possibile preoccuparsi dell'isolamento logico dei tenant e di come separare le responsabilità o i criteri di gestione applicati a ogni tenant. In alternativa, potrebbe essere necessario distribuire configurazioni di risorse distinte per tenant specifici, ad esempio la distribuzione di uno SKU di macchina virtuale (VM) specifico per soddisfare il carico di lavoro di un tenant.

A seconda del modello di isolamento scelto, assicurarsi che i dati del tenant rimangano isolati correttamente, anche in caso di guasti o interruzioni dei componenti. Prendere in considerazione l'uso di Azure Chaos Studio nel normale processo di test automatizzato per introdurre errori che simulano interruzioni reali. Questo test consente di verificare che la tua soluzione mantenga il corretto isolamento del tenant e continui a funzionare sotto pressione.

Approcci e modelli da considerare

Scalabilità automatica

I servizi di calcolo di Azure offrono varie funzionalità che ridimensionano i carichi di lavoro. Molti servizi di calcolo supportano la scalabilità automatica, che richiede di determinare quando ridimensionare e impostare livelli di scalabilità minimi e massimi. Le opzioni di ridimensionamento specifiche dipendono dai servizi di calcolo usati. Vedere i servizi o i componenti di esempio seguenti:

• Servizio app di Azure:specificare le regole di scalabilità automatica che ridimensionano l'infrastruttura in base alle esigenze.

• Funzioni di Azure: Scegliere tra più opzioni di scalabilità, tra cui un modello di ridimensionamento basato su eventi che viene ridimensionato automaticamente in base al lavoro eseguito dalle funzioni.

• App contenitore di Azure: Usare la scalabilità automatica basata su eventi per ridimensionare l'applicazione in base al lavoro eseguito e al carico corrente.

• Servizio Azure Kubernetes: Per mantenere il passo con le esigenze dell'applicazione, potrebbe essere necessario modificare il numero di nodi che eseguono i carichi di lavoro. Per ridimensionare rapidamente i carichi di lavoro delle applicazioni in un cluster del servizio Azure Kubernetes, è possibile usare i nodi virtuali.

• Vm: Un set di scalabilità di macchine virtuali può aumentare o ridurre automaticamente il numero di istanze di macchine virtuali che eseguono l'applicazione.

Modello dei timbri di distribuzione

Per altre informazioni su come usare il modello Deployment Stamps per supportare una soluzione multi-tenant, vedere Approcci architetturali per una soluzione multi-tenant.

Modello di consolidamento delle risorse di calcolo

Il modello di consolidamento delle risorse di calcolo aiuta a raggiungere una maggiore densità di utenti per l'infrastruttura di calcolo condividendo le risorse computazionali sottostanti. Condividendo le risorse di calcolo, è possibile ridurre il costo diretto di tali risorse. Inoltre, i costi di gestione sono spesso inferiori perché ci sono meno componenti da gestire.

Tuttavia, il consolidamento delle risorse di calcolo aumenta la probabilità del problema del vicino rumoroso. Il carico di lavoro di qualsiasi tenant potrebbe usare una quantità sproporzionata della capacità di calcolo disponibile. Spesso è possibile ridurre questo rischio assicurandosi di ridimensionare la soluzione in modo appropriato e applicando controlli come quote e limiti api per evitare tenant che utilizzano più della loro equa quota di capacità.

Questo modello viene ottenuto in modi diversi, a seconda del servizio di calcolo usato. Vedere i servizi o i componenti di esempio seguenti:

• Servizio app e Funzioni di Azure: Distribuire piani di servizio app condivisi, che rappresentano l'infrastruttura del server di hosting.

• App contenitore: Distribuisci ambienti condivisi.

• AKS: Distribuire pod condivisi con un'applicazione compatibile con multitenancy.

• VM: Distribuire un singolo set di macchine virtuali per tutti i locatari da utilizzare.

Risorse di calcolo dedicate per ogni tenant

È anche possibile distribuire risorse di calcolo dedicate per ogni tenant. Le risorse dedicate attenuano il rischio del problema del vicino rumoroso assicurandosi che le risorse di calcolo per ogni tenant siano isolate dalle altre. Consente anche di distribuire una configurazione distinta per le risorse di ogni tenant in base alle proprie esigenze. Tuttavia, le risorse dedicate comportano in genere un costo più elevato perché si ha una densità inferiore di utenti rispetto alle risorse.

A seconda dei servizi di calcolo di Azure usati, potrebbe essere necessario distribuire risorse dedicate diverse:

• Servizio app e Funzioni di Azure: Distribuire piani di servizio app separati per ogni tenant.

• Container Apps: Distribuisci ambienti separati per ogni tenant.

• AKS: Distribuire cluster dedicati per ogni tenant.

• Vm: Distribuire macchine virtuali dedicate per ogni tenant.

L'isolamento a livello di host fisico può essere fornito anche eseguendo macchine virtuali tenant in host dedicati di Azure, che riservano un intero server fisico per un singolo cliente. Tuttavia, questo approccio è in genere più costoso rispetto all'uso di host condivisi.

Risorse di calcolo semi isolate

Gli approcci semi-isolati richiedono la distribuzione di aspetti della soluzione in una configurazione isolata mentre si condividono gli altri componenti.

Quando si usa Il servizio app e Funzioni di Azure, è possibile distribuire applicazioni distinte per ogni tenant e ospitare le applicazioni nei piani di servizio app condivisi. Questo approccio riduce il costo del livello di calcolo perché i piani di App Service rappresentano l'unità di fatturazione. Consente anche di applicare configurazioni e criteri distinti a ogni applicazione. Tuttavia, questo approccio introduce il rischio del problema dei vicini rumorosi.

È possibile usare App contenitore per distribuire più applicazioni in un ambiente condiviso e quindi usare Dapr e altri strumenti per configurare ogni applicazione separatamente.

AKS e Kubernetes, più in generale, offrono diverse opzioni per la multitenancy.

• Spazi dei nomi specifici del tenant che possono fornire l'isolamento logico delle risorse specifiche del tenant, distribuite in cluster condivisi e pool di nodi.

• Nodi o pool di nodi dedicati al tenant in un cluster condiviso.

• Pod specifici per il tenant che potrebbero usare lo stesso pool di nodi.

È anche possibile usare AKS per applicare la governance a livello di pod e ridurre il problema del vicino rumoroso. Per altre informazioni, vedere Procedure consigliate per gli sviluppatori di applicazioni per gestire le risorse nel servizio Azure Kubernetes.

È anche importante essere consapevoli dei componenti condivisi in un cluster Kubernetes e del modo in cui la multi-tenancy potrebbe influire su questi componenti. Ad esempio, il server API Kubernetes è un servizio condiviso usato in tutto il cluster. Anche se si forniscono pool di nodi specifici del tenant per isolare i carichi di lavoro dell'applicazione dei tenant, il server API potrebbe riscontrare conflitti da un numero elevato di richieste tra i tenant.

Schemi negativi da evitare

Antipattern noisy neighbor

Quando si distribuiscono componenti condivisi dai tenant, il problema del vicino rumoroso è un rischio potenziale. Assicurarsi di includere la governance delle risorse e il monitoraggio per ridurre il rischio di attività di altri tenant che influiscono sul carico di lavoro di calcolo di un tenant.

Perdita di dati trasversale tra tenant

I livelli di calcolo possono essere soggetti a perdite di dati tra tenant se non vengono gestiti correttamente. Questo rischio non è in genere un elemento da considerare quando si usa un servizio multi-tenant in Azure perché Microsoft fornisce protezioni a livello di piattaforma. Tuttavia, quando si sviluppa un'applicazione multi-tenant, valutare se qualsiasi risorsa condivisa, ad esempio cache del disco locale, RAM e cache esterne, potrebbe contenere dati che un altro tenant può visualizzare o modificare accidentalmente.

Antipattern occupato del Front End

Per evitare l'antipattern Front End occupato, assicurati che il livello front-end non svolga la maggior parte del lavoro che possono essere gestiti da altri componenti o livelli dell'architettura. Questo antipattern è particolarmente importante quando si creano front-end condivisi per una soluzione multi-tenant perché un front-end occupato riduce l'esperienza per tutti i tenant.

Invece, considera l'uso dell'elaborazione asincrona attraverso code o altri servizi di messaggistica. Questo approccio consente anche di applicare controlli qualitativi dei servizi per tenant diversi in base ai requisiti. Ad esempio, tutti i tenant possono condividere un livello front-end comune, ma i tenant che pagano per un livello di servizio superiore potrebbero avere un set più elevato di risorse dedicate per elaborare il lavoro dai messaggi della coda.

Scalabilità inelastica o insufficiente

Le soluzioni multi-tenant sono spesso soggette a modelli di scalabilità improvvisi. I componenti condivisi sono molto vulnerabili a questo problema perché la possibilità di picchi di utilizzo è più elevata, e l'effetto è maggiore quando si dispone di più clienti con schemi di utilizzo diversi.

Assicurarsi di sfruttare l'elasticità e la scalabilità del cloud. Valutare se è consigliabile usare il ridimensionamento orizzontale o verticale e usare la scalabilità automatica per gestire automaticamente i picchi di carico. Testare la soluzione per comprendere il funzionamento con livelli di carico diversi. Assicurarsi di includere i volumi di carico previsti nell'ambiente di produzione e la crescita prevista. È possibile usare un servizio completamente gestito, ad esempio Test di carico, per informazioni sul funzionamento dell'applicazione sotto stress.

Antipattern Nessuna memorizzazione nella cache

L'antipattern Nessuna memorizzazione nella cache si verifica quando le prestazioni della tua soluzione peggiorano perché il livello dell'applicazione richiede ripetutamente o ricalcola informazioni che potrebbero essere riutilizzate tra diverse richieste. Se si dispone di dati che possono essere condivisi, tra tenant o tra utenti all'interno di un singolo tenant, è probabile che valga la pena memorizzarli nella cache per ridurre il carico sul livello back-end o di database.

Stato inutile

L'implicazione dell'antipattern Nessuna memorizzazione nella cache è che dovresti anche evitare di archiviare uno stato non necessario nel livello di elaborazione. Siate espliciti su dove mantenete lo stato e perché. I livelli front-end o applicativi con stato possono ridurre la scalabilità. I livelli di calcolo con stato richiedono in genere anche l'affinità di sessione, che può ridurre la capacità di ripartire efficacemente il carico del traffico tra i lavoratori o i nodi.

Considerare i compromessi per ogni elemento di stato gestito nel livello di calcolo e se influisce sulla capacità di scalare man mano che cambiano i modelli di carico di lavoro dei tuoi affittuari. È anche possibile archiviare lo stato in una cache esterna, ad esempio Cache Redis di Azure.

Contributori

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

Autori principali:

• Dixit Arora | Senior Customer Engineer, FastTrack per Azure
• John Downs | Principal Software Engineer

Altri collaboratori:

• ** Arsen Vladimirskiy | Ingegnere Clienti Principale, FastTrack per Azure

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

Passaggi successivi

Esaminare le linee guida specifiche del servizio per i servizi di calcolo:

• Considerazioni sul servizio app e funzioni di Azure per la multi-tenancy
• Considerazioni sull'uso di app contenitore in una soluzione multi-tenant
• Considerazioni sul servizio Azure Kubernetes per la multi-tenancy