Share via

Approcci architetturali per il calcolo in soluzioni multi-tenant

  • Articolo

La maggior parte delle soluzioni basate sul cloud è costituita da risorse di calcolo di qualche tipo, ad esempio livelli web e applicazioni, processori batch, processi pianificati e anche risorse specializzate come GPU e calcolo ad alte prestazioni (HPC). Le soluzioni multi-tenant spesso possono trarre vantaggio dalle risorse di calcolo condivise, perché una maggiore densità di tenant per l'infrastruttura riduce i costi operativi e la gestione. È consigliabile considerare i requisiti di isolamento e le implicazioni dell'infrastruttura condivisa.

Questo articolo fornisce indicazioni sulle considerazioni e sui requisiti essenziali per gli architetti della soluzione da considerare durante la pianificazione di un livello di calcolo multi-tenant. Ciò include alcuni modelli comuni per l'applicazione di multitenancy ai servizi di calcolo, insieme ad alcuni antipattern per evitare.

Considerazioni e requisiti principali

Multitenancy e il modello di isolamento selezionato influisce sul ridimensionamento, sulle prestazioni, sulla gestione dello stato e sulla sicurezza delle risorse di calcolo. In questa sezione vengono esaminate alcune delle decisioni principali da prendere quando si pianifica una soluzione di calcolo multi-tenant.

Scalabilità

I sistemi devono eseguire in modo adeguato in base al cambiamento della domanda. Poiché il numero di tenant e la quantità di traffico aumentano, potrebbe essere necessario aumentare la capacità delle risorse, per mantenere il numero crescente di tenant e mantenere un tasso di prestazioni accettabile. Analogamente, quando il numero di utenti attivi o la quantità di traffico diminuisce, è necessario ridurre automaticamente la capacità di calcolo per ridurre i costi, ma è necessario ridurre la capacità con un impatto minimo sugli utenti.

Se si distribuiscono risorse dedicate per ogni tenant, è possibile ridimensionare in modo indipendente le risorse di ogni tenant. In una soluzione in cui le risorse di calcolo vengono condivise tra più tenant, se si ridimensionano tali risorse, tutti questi tenant possono usare la nuova scala. Tuttavia, tutti soffriranno quando la scalabilità non è sufficiente per gestire il carico complessivo. Per altre informazioni, vedere il problema Del vicino rumoroso.

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

I problemi di prestazioni rimangono spesso non rilevati finché un'applicazione non è in carico. È possibile usare un servizio completamente gestito, ad esempio Test di carico di Azure, per informazioni sul comportamento dell'applicazione sotto stress.

Scalabilità dei trigger

Qualsiasi approccio usato per ridimensionare, in genere è necessario pianificare i trigger che causano la scalabilità dei componenti. Quando si hanno componenti condivisi, prendere in considerazione i modelli di carico di lavoro di ogni tenant che usa le risorse, per garantire che la capacità di cui è stato effettuato il provisioning possa soddisfare la capacità totale necessaria e ridurre al minimo la possibilità di un tenant che riscontra il problema Del vicino rumoroso. È anche possibile pianificare la capacità di ridimensionamento considerando il numero di tenant. Ad esempio, se si misurano le risorse usate per il servizio di 100 tenant, è possibile pianificare l'onboarding di più tenant, in modo che le risorse siano doppie per ogni tenant aggiuntivo di 100.

State

Le risorse di calcolo possono essere senza stato oppure possono essere con stato. I componenti senza stato non gestiscono dati 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 e possono iniziare immediatamente a elaborare le richieste. Se l'architettura lo consente, è anche possibile riutilizzare le istanze assegnate a un tenant e assegnarle a un altro tenant.

Le risorse con stato possono essere ulteriormente suddivise, in base al tipo di stato gestito. Lo stato persistente è dati che devono essere archiviati in modo permanente. Nelle soluzioni cloud è consigliabile evitare di archiviare uno stato persistente nel livello di calcolo. Usare invece servizi di archiviazione come database o account di archiviazione. Lo stato temporaneo è dati archiviati temporaneamente e include cache in memoria di sola lettura e archiviazione di file temporanei nei 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, è possibile gestire le richieste di lettura, senza connettersi a un database e senza eseguire una query intensa eseguita di recente quando è stata eseguita un'altra richiesta.

Nelle applicazioni sensibili alla latenza, il costo dell'idratazione della cache può diventare significativo. Una soluzione multi-tenant può esacerbare questo problema, se ogni tenant richiede dati diversi da memorizzare nella cache. Per attenuare questo problema, alcune soluzioni usano l'affinità di sessione per garantire che tutte le richieste per un utente o un tenant specifico vengano elaborate dallo stesso nodo di lavoro di calcolo. Anche se l'affinità di sessione può migliorare la capacità del livello applicazione di usare la cache in modo efficace, rende anche più difficile ridimensionare e bilanciare il carico del traffico tra i lavoratori. Questo compromesso deve essere considerato attentamente. Per molte applicazioni, l'affinità di sessione non è necessaria.

È anche possibile archiviare i dati in cache esterne, ad esempio cache di Azure per Redis. Le cache esterne sono ottimizzate per il recupero dei dati a bassa latenza, mantenendo lo stato isolato 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.

Importante

Evitare la perdita di dati tra i tenant, ogni volta che si usano cache in memoria o altri componenti che mantengono lo stato. Si consideri, ad esempio, la pre-attesa di un identificatore tenant a tutte le chiavi della cache, per assicurarsi che i dati siano separati per ogni tenant.

Isolamento

Quando si progetta un livello di calcolo multi-tenant, spesso sono disponibili molte opzioni da considerare per il livello di isolamento tra i tenant, inclusa la distribuzione di risorse di calcolo condivise, da usare da tutti i tenant, dalle risorse di calcolo dedicate per ogni tenant o da un elemento tra questi estremi. Ogni opzione include compromessi. Per decidere quale opzione si adatta meglio alla soluzione, prendere in considerazione i requisiti per l'isolamento.

Si potrebbe essere interessati all'isolamento logico dei tenant e a 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 specifico per soddisfare il carico di lavoro di un tenant.

Indipendentemente dal modello di isolamento selezionato, verificare che i dati del tenant rimangano isolati in modo appropriato anche quando i componenti non sono disponibili o non funzionano correttamente. Prendere in considerazione l'uso di Azure Chaos Studio come parte del processo di test automatizzato regolare per introdurre intenzionalmente errori che simulano interruzioni reali e verificare che la soluzione non tra i tenant e funzioni correttamente anche sotto pressione.

Approcci e modelli da prendere in considerazione

Autoscale

I servizi di calcolo di Azure offrono funzionalità diverse per ridimensionare i carichi di lavoro. Molti servizi di calcolo supportano la scalabilità automatica, che richiede di considerare quando è necessario ridimensionare e i livelli minimi e massimi di scalabilità. Le opzioni specifiche disponibili per il ridimensionamento dipendono dai servizi di calcolo usati. Vedere i servizi di esempio seguenti:

Modello degli stamp di distribuzione

Per altre informazioni sul modo in cui è possibile usare il modello Stamp di distribuzione per supportare una soluzione multi-tenant, vedere Panoramica.

Modello di consolidamento delle risorse di calcolo

Il modello di consolidamento risorse di calcolo consente di ottenere una densità più elevata di tenant per l'infrastruttura di calcolo, condividendo le risorse di calcolo sottostanti. Condividendo le risorse di calcolo, spesso è possibile ridurre il costo diretto di tali risorse. Inoltre, i costi di gestione sono spesso inferiori perché sono presenti 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 utilizzare una quantità sproporzionata della capacità di calcolo disponibile. È spesso possibile attenuare 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 quota equa della capacità.

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

  • Servizio app di Azure e Funzioni di Azure: distribuire piani di servizio app condivisi, che rappresentano l'infrastruttura del server di hosting.
  • App Azure Container: distribuire ambienti condivisi.
  • servizio Azure Kubernetes (Servizio Azure Kubernetes): distribuire pod condivisi con un'applicazione con riconoscimento multitenancy.
  • Macchine virtuali: distribuire un singolo set di macchine virtuali per tutti i tenant da usare.

Risorse di calcolo dedicate per 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 dagli altri. Consente inoltre di distribuire una configurazione distinta per le risorse di ogni tenant, in base ai requisiti. Tuttavia, le risorse dedicate vengono in genere con un costo maggiore, perché si dispone di una densità inferiore di tenant alle risorse.

A seconda dei servizi di calcolo di Azure usati, è necessario distribuire risorse dedicate diverse, come indicato di seguito:

  • Servizio app di Azure e Funzioni di Azure: distribuire piani di servizio app separati per ogni tenant.
  • App Azure Container: distribuire ambienti separati per ogni tenant.
  • servizio Azure Kubernetes (Servizio Azure Kubernetes): distribuire cluster dedicati per ogni tenant.
  • Macchine virtuali: distribuire macchine virtuali dedicate per ogni tenant.

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 lavora con 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 servizio app rappresentano l'unità di fatturazione. Consente inoltre di applicare configurazioni e criteri distinti a ogni applicazione. Tuttavia, questo approccio introduce il rischio del problema Del vicino rumoroso.

App Azure Container consente di distribuire più applicazioni in un ambiente condiviso e quindi di usare Dapr e altri strumenti per configurare ogni applicazione separatamente.

servizio Azure Kubernetes (servizio Azure Kubernetes) e Kubernetes in modo più ampio, offrono diverse opzioni per la multitenancy, tra cui quanto segue:

  • Spazi dei nomi specifici del tenant, per l'isolamento logico delle risorse specifiche del tenant, distribuite in cluster e pool di nodi condivisi.
  • Nodi o pool di nodi specifici del tenant in un cluster condiviso.
  • Pod specifici del tenant che potrebbero usare lo stesso pool di nodi.

Il servizio Azure Kubernetes consente inoltre di applicare la governance a livello di pod per attenuare il problema Di prossimità rumoroso. Per altre informazioni, vedere Procedure consigliate per gli sviluppatori di applicazioni per gestire le risorse in servizio Azure Kubernetes (servizio Azure Kubernetes).

È anche importante essere consapevoli dei componenti condivisi in un cluster Kubernetes e del modo in cui questi componenti potrebbero essere interessati dalla multitenancy. 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 avere un numero elevato di richieste tra i tenant.

Antipattern da evitare

Antipattern noisy neighbor

Ogni volta che si distribuiscono i componenti condivisi tra i tenant, il problema Del vicino rumoroso è un rischio potenziale. Assicurarsi di includere la governance delle risorse e il monitoraggio per ridurre il rischio del carico di lavoro di calcolo di un tenant interessato dall'attività di altri tenant.

Perdita di dati tra tenant

I livelli di calcolo possono essere soggetti a perdita di dati tra tenant, se non vengono gestiti correttamente. Questo non è in genere qualcosa 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 le risorse condivise (ad esempio cache dei dischi locali, RAM e cache esterne) potrebbero contenere dati che un altro tenant può visualizzare o modificare inavvertitamente.

Antipattern Front End occupato

Per evitare l'antipattern Front End occupato, evitare il livello front-end eseguendo molte operazioni che potrebbero essere gestite 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 degraderà l'esperienza per tutti i tenant.

Si consideri invece di usare l'elaborazione asincrona usando code o altri servizi di messaggistica. Questo approccio consente anche di applicare controlli di qualità del servizio (QoS) per tenant diversi, in base ai propri requisiti. Ad esempio, tutti i tenant possono condividere un livello front-end comune, ma i tenant che pagano un livello di servizio superiore potrebbero avere un set superiore 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à scoppiati. I componenti condivisi sono particolarmente sensibili a questo problema, perché l'ambito per il burst è maggiore e l'impatto è maggiore quando si hanno più tenant con modelli di utilizzo distinti.

Assicurarsi di usare bene l'elasticità e la scalabilità del cloud. Valutare se è necessario usare il ridimensionamento orizzontale o verticale e usare la scalabilità automatica per gestire automaticamente i picchi di carico. Testare la soluzione per comprendere il comportamento in 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 di Azure, per informazioni sul comportamento dell'applicazione sotto stress.

Nessun antipattern della memorizzazione nella cache

L'antipattern di memorizzazione nella cache è quando le prestazioni della soluzione soffrono perché il livello applicazione richiede ripetutamente o ricompila le informazioni che possono essere riutilizzate tra le richieste. Se si dispone di dati che possono essere condivisi, tra tenant o tra utenti all'interno di un singolo tenant, è probabile che sia consigliabile memorizzare nella cache il carico nel livello back-end/database.

Stato non necessario

La corollario dell'antipattern di memorizzazione nella cache è che è anche consigliabile evitare l'archiviazione dello stato non necessario nel livello di calcolo. Essere espliciti sulla posizione in cui si mantiene lo stato e sul motivo. I livelli front-end o applicazioni con stato possono ridurre la capacità di ridimensionare. I livelli di calcolo con stato richiedono in genere affinità di sessione, che possono ridurre la capacità di bilanciare efficacemente il traffico, tra i ruoli di lavoro o i nodi.

Prendere in considerazione i compromessi per ogni parte dello stato gestito nel livello di calcolo e se influisce sulla capacità di ridimensionare o aumentare come cambiano i modelli di carico di lavoro dei tenant. È anche possibile archiviare lo stato in una cache esterna, ad esempio cache di Azure per Redis.

Autori di contributi

Questo articolo viene gestito da Microsoft. È stato originariamente scritto dai collaboratori seguenti.

Autori principali:

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

Altri collaboratori:

Passaggi successivi

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