Modifica

Condividi tramite

SaaS multitenant in Azure

Microsoft Entra ID
Servizio app di Azure
DNS di Azure
Frontdoor di Azure
Servizio Azure Kubernetes

Quando si identifica una parte della soluzione software dell'azienda che è possibile annullare il marchio e il mercato ad altre aziende, aggiunge un intero nuovo flusso di ricavi per un'azienda. La configurazione della soluzione in modo che possa gestire il carico dovuto a un numero elevato di tenant spesso rappresenta, tuttavia, un ostacolo difficile da affrontare. Questa soluzione guida una suite di tecnologie di Azure che proteggono e bilanciano il traffico.

Architettura

Diagramma che mostra un'architettura SaaS multi-tenant configurata in Azure in due aree diverse.

Scaricare un file di Visio di questa architettura.

Workflow

Una suite di tecnologie di Azure protegge e bilancia il carico del traffico.

  1. Frontdoor di Microsoft Azure gestisce alcune attività iniziali:

    • Elaborazione della richiesta iniziale

    • Bilanciamento del carico tra le aree

    • Terminazione e offload SSL (HTTPS)

    • Failover in caso di interruzione a livello di area

  2. DNS di Azure gestisce i record DNS e garantisce il routing all'endpoint frontdoor di Azure corretto.

  3. L'architettura usa Microsoft Entra ID come provider di identità per l'autenticazione.

  4. Una volta indirizzati all'area appropriata, gateway applicazione route e bilanciamenti del carico, indirizzando le richieste al servizio app Azure appropriato.

  5. Per questa architettura, il servizio app rappresenta la scelta preferita per:

    • Qualsiasi applicazione basata su HTTP.

    • Gestire il contenuto Web.

    • Esporre le API RESTful.

    • Implementare la logica di business dietro l'applicazione front-end.

    È possibile configurare il servizio app per ridimensionarlo automaticamente. In questo modo, il servizio app risulterà l'opzione ottimale per il ridimensionamento di un host di richieste tenant guidate da HTTP su richiesta.

  6. Anche i servizi livello di accesso ai dati vengono ridimensionati in modo indipendente in base al carico. I servizi dati gestiscono modelli di dati, client di connessione e driver. I servizi offrono anche un'interfaccia dati coerente per tutti i servizi di livello superiore che vogliono utilizzare i dati nell'applicazione. È possibile distribuire e ridimensionare questi servizi dati usando il servizio Azure Kubernetes. Ogni cluster del servizio Azure Kubernetes è responsabile di un set di funzionalità correlate nel livello. Il servizio Azure Kubernetes può implementare un'architettura di microservizi, che include una serie di contenitori che incapsulano funzionalità specifiche all'interno del cluster. Ciò consente un elevato grado di astrazione e de-accoppiamento all'interno del codice. Consente inoltre ai cluster di aumentare il numero di istanze singolarmente per favorire un aumento del carico da più tenant. Ogni cluster può aumentare le prestazioni se il carico aumenta nel cluster. L'aumento delle prestazioni non influisce sugli altri cluster nel gruppo di risorse purché non si verifichi lo stesso aumento.

  7. Archiviare e gestire dati relazionali all'esterno del framework dell'applicazione. In questo modo, viene fornito un singolo punto di immissione dati per entrambe le aree. È possibile ottenere la replica, la disponibilità, la scalabilità e la sicurezza sfruttando la forza dei pool elastici SQL di Azure. Effettuare il provisioning di ogni tenant di un database in un pool. Allocare le risorse disponibili nel pool ai database su richiesta quando arrivano il carico e le richieste. In questo modo si ottimizzano le risorse del database disponibili per i tenant rispetto al budget.

Componenti

I componenti principali sono quelli suggeriti per l'architettura in questa soluzione. Se uno dei componenti principali non è adatto all'architettura, vedere l'elenco dei componenti alternativi.

Componenti principali

  • Frontdoor di Azure: servizio di bilanciamento del carico a livello di area che indirizza il traffico client all'area corretta. Può eseguire il failover nella seconda area se si verifica un errore a livello di area e può proteggere il punto di ingresso con connessione Internet tramite Web application firewall di Azure.

  • Microsoft Entra ID: funge da provider di identità per l'intera applicazione, applicando l'autenticazione e l'autorizzazione end-to-end della richiesta nell'applicazione.

  • DNS di Azure: servizio di hosting in Azure per la risoluzione dei nomi di dominio. In una soluzione multi-tenant più client accedono alla soluzione tramite singoli domini. Usare DNS di Azure per configurare e risolvere le richieste client nel relativo stack di applicazioni corretto.

  • Gateway applicazione: indirizza e bilancia il carico del traffico internamente nell'applicazione ai vari servizi che soddisfano le esigenze aziendali dei client. Mentre Frontdoor di Azure si occupa del bilanciamento del carico tra aree di alto livello, il gateway applicazione gestisce il carico sui singoli servizi all'interno di un gruppo. Frontdoor di Azure e il gateway applicazione si combinano per fornire un bilanciamento del carico complesso a tutti i livelli in una soluzione multi-tenant. Per altre informazioni sulle opzioni di bilanciamento del carico in Azure, vedere questa panoramica sul bilanciamento del carico di Azure.

  • Servizio app: il servizio Premier di Azure per le applicazioni Web e le API basate sul Web. La sicurezza si integra con servizi come Microsoft Entra ID e Azure Key Vault. È possibile configurare il ridimensionamento automatico. Inoltre, la quantità di risorse disponibili per la scalabilità a è flessibile tra i vari piani di servizio app su cui l'app può essere eseguita. Il servizio app può anche sfruttare le funzionalità DevOps integrate per la distribuzione e l'integrazione continue in più ambienti. Queste e altre funzionalità di supporto della piattaforma Azure consentono agli sviluppatori di concentrarsi sullo sviluppo delle proprie applicazioni.

  • servizio Azure Kubernetes: orchestra le istanze delle immagini del contenitore distribuite in un cluster. La gestione dei dati di più client comporta spesso l'implementazione di una suite di componenti per gestire:

    • Modellazione dei dati

    • Connettività dell'origine dati

    • Estrazione, trasformazione, caricamento (ETL)

    • Attività di importazione/esportazione

    Lo sviluppo di questi numerosi componenti più piccoli come microservizi basati su contenitori crea uno scenario ideale per la distribuzione in un cluster del servizio Azure Kubernetes. Gli strumenti per la scalabilità automatica, il bilanciamento del carico e l'aggiornabilità sono integrati nel framework. Il servizio Azure Kubernetes si integra perfettamente con una strategia di integrazione continua e recapito continuo (CI/CD) usando le funzionalità DevOps disponibili e il Registro Azure Container.

  • Pool elastici di Azure SQL: offre una soluzione per la gestione flessibile di un set di database con un pool di risorse. Il servizio alloca le risorse su richiesta ai database. Offre allo sviluppatore di un'architettura SaaS multi-tenant la potenza necessaria per distribuire le risorse di database ai client in base alle esigenze. Il servizio riduce anche il budget e il sovraccarico della gestione di più server SQL con grandi blocchi di risorse di calcolo non utilizzate.

  • Ricerca cognitiva di Azure (precedentemente noto come Ricerca di Azure): servizio che aggiunge all'applicazione un potente motore di indicizzazione e query. Consente ai client di accedere a funzionalità di query avanzate. Possono anche usare le funzionalità di intelligenza artificiale di Azure per arricchire e migliorare la funzionalità di query. Ricerca cognitiva di Azure può eseguire la multi-tenancy usando una strategia di indice per tenant o servizio per tenant.

  • Cache di Azure per Redis: applica alla soluzione un livello di memorizzazione nella cache come servizio, fornendo una cache gestita in memoria per ridurre la latenza e aumentare le prestazioni per i client. Una velocità effettiva elevata consente un volume elevato di richieste per gestire più tenant che accedono al sistema. È possibile aumentare in modo flessibile le prestazioni del servizio con l'aumentare del carico dell'applicazione. Supporta anche la crittografia dei dati inattivi per proteggere e isolare i dati del tenant memorizzati nella cache.

Componenti alternativi

  • Azure set di scalabilità di macchine virtuali: consente la distribuzione dei servizi in un ambiente di macchine virtuali (VM) che ridimensiona e aumenta automaticamente in base alle esigenze. set di scalabilità di macchine virtuali integrarsi bene con un Load Balancer o gateway applicazione per ribilanciare automaticamente il carico man mano che aumenta il set di scalabilità. I set di scalabilità di macchine virtuali forniscono la scalabilità richiesta da questa soluzione. In molti casi, tuttavia, non è necessario gestire l'intero ambiente di macchine virtuali ed è possibile rinviare tale livello dello stack al servizio app o al servizio Azure Kubernetes.

  • Database SQL di Azure: consente di implementare come singole istanze dedicate in sostituzione dei pool elastici. Il database SQL di Azure aggiunge un sovraccarico maggiore nella gestione diretta dell'istanza e comporta un costo maggiore per le risorse allocate. Detto questo, è un'alternativa accettabile quando il tenant richiede un server dedicato. In particolare, il client potrebbe richiedere un maggiore controllo sull'istanza e sulle risorse disponibili dedicate. I tenant che richiedono un'istanza dedicata di SQL Server possono esistere affiancati ai tenant in una configurazione del pool elastico. È possibile impostare un livello di database SQL come una delle opzioni di prezzo disponibili per i tenant quando si acquistano licenze per SaaS.

  • SQL Server nelle macchine virtuali: un'altra opzione per la distribuzione di database SQL. Il tenant potrebbe avere un'infrastruttura IT preesistente e sql Server esistenti in locale. In tal caso, il tenant potrebbe voler usare le licenze correnti, come migrazione completa o in uno scenario ibrido. La natura separata di SaaS consente al livello dati dell'applicazione di impostare come destinazione qualsiasi database SQL tramite configurazione.

Dettagli dello scenario

Quando si identifica una parte della soluzione software dell'azienda che è possibile annullare il marchio e il mercato ad altre aziende, aggiunge un intero nuovo flusso di ricavi per un'azienda. La configurazione della soluzione in modo che possa gestire il carico dovuto a un numero elevato di tenant spesso rappresenta, tuttavia, un ostacolo difficile da affrontare.

Azure offre una gamma di servizi per la gestione di una soluzione software che:

  • Gestisce in modo flessibile i database per tutti i client.

  • Ridimensiona il livello di business e logica della soluzione per evitare colli di bottiglia a livello di calcolo.

  • Integra la disponibilità e il failover a livello di area.

  • Offre sicurezza end-to-end a tutti i livelli della soluzione.

Potenziali casi d'uso

Questi casi d'uso hanno modelli di progettazione che possono trarre vantaggio da una soluzione SaaS multi-tenant ospitata in Azure:

  • Sviluppare una soluzione di gestione dei rapporti con il cliente (CRM, Customer Relationship Management) che i client possano commercializzare e vendere ai clienti.

  • Implementare un sistema di gestione dei contenuti (CMS, Content Management System) e renderlo disponibile per più utenti usando questa architettura.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.

Multi-tenancy

Una soluzione multi-tenant è la considerazione chiave in questa soluzione. La soluzione gestisce contemporaneamente diversi client. Alloca anche risorse sufficienti per elaborare tutte le richieste client in modo efficace. Durante l'elaborazione delle richieste, la soluzione protegge il traffico proveniente da endpoint globali e isola i dati client per evitare violazioni e contaminazioni incrociate. Distribuire i client in una coppia di gruppi di risorse regionali in base alla posizione primaria. In questo modo, si ottimizza la disponibilità a livello di area.

È possibile distribuire molti client in un singolo gruppo di calcolo perché il sistema isola le richieste in base all'autenticazione e alle chiavi client, che differenziano le richieste in base a questi identificatori univoci. Il sistema può crittografare separatamente tutte le richieste client in base alle relative chiavi in modo che nessun client possa decrittografare i dati di altri client. La gestione di più client in un singolo stack di calcolo consente di ottimizzare l'allocazione delle risorse per fornire ai client la velocità di risposta necessaria al costo previsto.

È possibile gestire i database client in modo simile all'esterno dello stack di calcolo, perché una richiesta client potrebbe arrivare da uno degli stack a livello di area. Molti database client possono esistere nello stesso pool elastico, isolati e protetti da Transparent Data Encryption (TDE). È possibile configurare ogni database per crittografare i dati usando una chiave gestita dal client e decrittografare i dati just-in-time (JIT). La decrittografia JIT protegge i dati client sia dallo sviluppatore che da altri client. Il sistema sfrutta il pool elastico per fornire risorse su richiesta ai client assegnati, mantenendo i costi bassi per l'utente. È possibile assegnare criteri di replica a ogni pool elastico per fornire il backup e il failover per i dati client. Portare online più pool elastici durante l'onboarding di più client nel sistema.

Per altre informazioni sulle soluzioni multi-tenant, vedere Progettare soluzioni multi-tenant in Azure.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Panoramica del pilastro dell'affidabilità."

Disponibilità e scalabilità

Questa soluzione è progettata per la gestione di un numero elevato di tenant che usano SaaS. Sfrutta l'elevato numero di componenti e servizi scalabili che aumentano in base al carico. Questa architettura non è progettata per le soluzioni che gestiscono pochi tenant o per un carico ridotto di richieste e dati. Potrebbe infatti incidere sul budget di una soluzione che ha come destinazione un singolo client o un carico inferiore. Non è inoltre necessario che il sovraccarico di multiregion in cui la disponibilità globale elevata non sia un requisito, perché aggiunge complessità e costi non necessari.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

Il sistema si rivolge alla sicurezza end-to-end a ogni livello dell'applicazione:

  • Frontdoor di Azure fornisce supporto HTTPS integrato per i relativi domini. Ciò significa che il sistema può crittografare tutto il traffico verso l'applicazione SaaS. Frontdoor di Azure implementa anche Web application firewall di Azure, proteggendo lo stack SaaS dagli attacchi sul perimetro, prima che il sistema instradi le richieste all'applicazione.

  • Ogni stack di applicazioni in ogni area si trova all'interno di una rete virtuale di Azure. Il sistema limita il traffico nella rete virtuale accettando richieste da Frontdoor di Azure, proteggendo tutti i servizi dell'applicazione dal traffico esterno. Una volta all'interno del firewall sicuro, il gateway applicazione può terminare SSL e fornire bilanciamento del carico e routing ottimali all'interno dell'applicazione.

  • È possibile gestire in modo sicuro tutte le credenziali, i segreti e le stringa di connessione usando Azure Key Vault. Gestendo questi dati sensibili come segreti, gli sviluppatori possono inserire credenziali nell'applicazione al momento della distribuzione. In questo modo, si assicura che il codice non sia inquinato da informazioni riservate. L'uso dei segreti protegge i dati client assicurando che una violazione del codice o un attacco man-in-the-middle non ottenga accesso ai database tenant.

  • In questo scenario, i dati di più tenant potrebbero esistere side-by-side sullo stesso server di database, se non lo stesso database. L'uso della decrittografia TDE e JIT consente di proteggere i dati nel database. Il sistema crittografa tutti i dati inattivi del database e li decrittografa solo quando richiesto dal tenant. I client possono fornire le proprie chiavi ed è possibile archiviare tutte le chiavi client in Azure Key Vault per gestire la crittografia per più tenant. Protegge i dati client end-to-end, impedisce allo sviluppatore di avere accesso ai dati client, isola i dati tra tenant e aiuta a soddisfare i requisiti di conformità per la sicurezza e i dati.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.

app Azure Servizio offre molti piani tariffari in base alle risorse di calcolo previste necessarie. Per un sistema SaaS multi-tenant, la disponibilità elevata e le funzionalità di scalabilità orizzontale sono componenti chiave nella scelta del piano di servizio. Se si prevede di ospitare molti tenant, la scelta di un livello Premium o isolato potrebbe essere necessaria per fornire le risorse di calcolo necessarie per tenere conto del traffico elevato. I livelli Standard, Premium e Isolato sono tutte istanze di macchina virtuale dedicate. È possibile calcolare il costo per unità di tempo in base al numero di macchine virtuali del livello specificato. Per altre informazioni, vedere Panoramica dei piani tariffari del servizio app.

Il servizio Azure Kubernetes offre un servizio contenitore conveniente. Il costo dei nodi del servizio Azure Kubernetes viene addebitato solo in base all'utilizzo, è quindi previsto l'addebito solo per:

  • Macchine virtuali

  • Risorse di archiviazione e di rete utilizzate

  • Costo di ridimensionamento direttamente correlato all'utilizzo

L'uso del servizio Azure Kubernetes come servizio livello dati è ideale se si vuole ridurre i costi. Per una stima dei prezzi relativi a un livello delle istanze del servizio Azure Kubernetes, visitare il calcolatore del servizio Kubernetes.

Per impostazione predefinita, i prezzi del Pool elastico di Azure SQL sono altamente convenienti in uno scenario multi-tenant. I database tenant in un pool elastico condivideranno le risorse disponibili. Quando la domanda passa da un tenant all'altro nel tempo, anche le risorse vengono spostate. Pool elastico di Azure SQL fornisce il numero massimo di risorse disponibili per i database richiesti senza la necessità di sovraccarico delle risorse in tutti i database. Il servizio mantiene bassi i costi per lo sviluppatore di SaaS e dei tenant. Usare il calcolatore dei prezzi del database SQL di Azure per determinare il livello e la quantità di risorse necessarie per gestire i tenant e i relativi dati.

  • L'uso di un modello tariffario della memoria centrale virtuale (vCore) offre una maggiore flessibilità in termini di ridimensionamento per soddisfare le risorse necessarie. È anche possibile sfruttare i vantaggi di Vantaggio Azure Hybrid. Le licenze esistenti di SQL Server offrono uno sconto per le risorse SQL vCore nel cloud. Pertanto, in un'istanza quando i server locali fanno già parte dell'infrastruttura di sviluppo, è possibile gestire i costi ancora di più usando questi sconti. È possibile stimare i potenziali risparmi usando il calcolatore di risparmio Vantaggio Azure Hybrid.

  • È anche possibile risparmiare sui costi delle risorse di SQL Server acquistando la capacità riservata del database SQL di Azure. L'acquisto di capacità riservata contrassegna un impegno di utilizzo a lungo termine database SQL. Il termine è in genere compreso tra uno e tre anni. In cambio, si ottengono sconti sui costi di calcolo delle risorse nella prenotazione. Ad esempio, è possibile riservare 32 vCore per utilizzo generico per un anno, riducendo così il costo di questi 32 vCore per quell'anno. Avere più tenant che acquistano licenze per un SaaS è un forte indicatore che l'uso della capacità riservata si adatta alla soluzione e un risparmio di costi ideale in questo carico di lavoro.

È possibile trovare la struttura dei prezzi relativa a cache di Azure per Redis nella pagina Prezzi di cache di Azure per Redis. Modificare il livello di cache in qualsiasi momento scegliendo tra un livello Basic, Standard e Premium in base alle necessità. Verranno visualizzati prezzi più elevati per i limiti della cache più ampi e funzionalità aggiuntive, ad esempio la replica e il ripristino di emergenza. Cache di Azure per Redis offre anche i prezzi relativi alla capacità riservata per gli impegni di utilizzo a lungo termine.

I prezzi di Frontdoor di Azure dipendono dalla quantità di trasferimento dei dati all'interno e all'esterno del servizio. Per i dati in uscita, i prezzi sono diversi in base alle zone. Diverse aree comportano costi diversi. Se si verifica un differenziale di prezzo, stimare il costo separatamente. Il prezzo include alcune capacità di routing e dominio, ma il sistema comporta costi oltre i limiti iniziali. Web application firewall di Azure comporta un piccolo addebito aggiuntivo per ogni criterio o regola applicata. È possibile trovare i dettagli dei prezzi per Frontdoor di Azure nella pagina Prezzi di Frontdoor di Azure.

I prezzi relativi a Ricerca cognitiva di Azure sono definiti da un sistema a livelli completo. È disponibile un livello gratuito per lo sviluppo e l'esecuzione di test. Successivamente, ogni livello comporta un costo all'ora per ogni istanza di Ricerca cognitiva allocata. Con l'aumentare dei livelli, aumentano anche lo spazio di archiviazione totale, il numero di indici e i limiti di scalabilità orizzontale. Ricerca cognitiva di Azure l'estrazione di immagini come servizio alla stessa tariffa per tutti i livelli a pagamento.

Passaggi successivi