La multi-tenancy non è solo una caratteristica—è la base architettonica che determina come scalare, proteggere e monetizzare la vostra applicazione. Azure fornisce un ricco ecosistema di servizi per aiutarvi a implementare l'isolamento, l'elasticità e i controlli dei costi, ma l'architettura giusta dipende dai requisiti dei vostri inquilini, dalla vostra sensibilità dei dati e dalla vostra capacità operativa di core.

Comprendere Multi-Tenancy in SaaS

Multi-tenancy è un'architettura software in cui un'unica istanza dell'applicazione serve più inquilini (clienti, organizzazioni o gruppi di utenti). Ogni inquilino sperimenta l'applicazione come se fosse dedicata a loro, ma l'infrastruttura sottostante, la computazione e lo storage sono condivisi. Questo approccio riduce il costo per-customer, semplifica la manutenzione (una base di codice, una distribuzione), e consente rapidi rollout delle funzionalità.

I fornitori di Azure SaaS affrontano tipicamente tre decisioni: il grado di isolamento, il modello di calcolo (PaaS vs. IaaS vs. container), e l'architettura di storage. Capire questi trade-off previene in anticipo la ri-architettura costosa in seguito.

Principi fondamentali per applicazioni multi-tenant su Azure

Il design multi-tenant efficace su Azure poggia su quattro pilastri: isolamento, scalabilità, sicurezza e gestione dei costi.

Isolamento

I dati e la configurazione non devono mai trapelare tra gli inquilini. L'isolamento può essere logico (ID di inquilino di livello di freccia in un database condiviso) o fisico (badi di base dati separati, account di archiviazione o anche abbonamenti separati). Azure SQL Database e Azure Cosmos DB supportano entrambi gli approcci con politiche di sicurezza delle righe di livello inquilino e chiavi a livello di contenitore.

Scalabilità

I carichi di lavoro multi-tenant sperimentano i picchi imprevedibili in quanto alcuni inquilini crescono rapidamente mentre altri rimangono stabili. Le capacità di auto-scaling di Azure—come le regole di scala di App Service, AKS cluster autoscaler, e Azure SQL Database elastici pools— consentono di assorbire la crescita senza intervento manuale.

Sicurezza

Ogni inquilino deve essere isolato da ogni altro inquilino, e l'autenticazione inquilino deve essere solida. Utilizzare Azure Active Directory (Azure AD) con caratteristiche B2C specifiche inquilino o B2B per la federazione di identità. Per la comunicazione di servizio-servizio, fare affidamento su identità gestite e Azure Key Vault per evitare segreti di indurimento.

Gestione dei costi

L'infrastruttura condivisa riduce i costi per-tenant, ma l'utilizzo non ottimizzato può sprecare denaro. Utilizzare Azure Cost Management per tag risorse da inquilino e track spend. Combinare istanze riservate con auto-scaling per gestire il carico base a buon mercato e scalare le istanze premium per i picchi.

Strategie di isolamento dei dati

La scelta di come memorizzare i dati inquilini è la decisione architettonica più conseguente. Azure supporta più modelli, ciascuno con distinti trade-off in isolamento, gestione e costi.

Database singolo, schema condiviso

In questo modello, tutti gli inquilini sono memorizzati in un database con una colonna identificativa inquilina su ogni tabella. È il più semplice da gestire (un backup, una stringa di connessione) e il più conveniente per i piccoli inquilini. Tuttavia, l'isolamento è puramente logico: un bug nel codice di filtraggio inquilino potrebbe esporre i dati di un altro inquilino.

Database separati (Database per Tenant)

Ogni inquilino ottiene il proprio database (e facoltativamente il proprio server o il proprio pool elastico), che garantisce il più forte isolamento, la separazione dei dati fisici, e facilita la conformità (ad esempio, la residenza dei dati del GDPR).

Approfondimenti ibridi

Molti fornitori di SaaS adottano una strategia tiered: gli inquilini liberi o di prova condividono un database comune, mentre i inquilini premium ricevono database dedicati. In alternativa, alcuni dati (ad esempio, i cataloghi pubblici, i dati di riferimento) possono essere condivisi, mentre i dati privati sono isolati.

Servizi Azure in corso per Multi-Tenancy

Oltre alla memorizzazione dei dati, Azure offre una piattaforma completa per l'operazione multi-tenant SaaS. I seguenti servizi sono particolarmente rilevanti.

Compute e Hosting

Azure App Service è il punto di ingresso per molti fornitori SaaS. Supporta lo scaling automatico, le distribuzioni basate su slot e l'autenticazione integrata.Per un maggior controllo sull'ambiente di runtime, Azure Kubernetes Service (AKS) consente di isolare gli inquilini tramite namespace, policy di rete e quote di risorse.

Deposito e Database

Abbiamo già discusso Azure SQL Database e Cosmos DB. Per lo storage blob o file, Azure Blob Storage supporta l'isolamento inquilino a livello dei container. È possibile generare token SAS specifici per inquilino e far rispettare le politiche di accesso con Azure RBAC. Azure Storage account per inquilino è anche un'opzione per un alto isolamento, ma aumenta la gestione in testa. Azure Cache per Redis può essere diviso per inquilino utilizzando database separati.

Gestione dell'identità e dell'accesso

Azure AD B2C (business-to-consumer) è progettato per SaaS con inquilini esterni. Supporta politiche personalizzate, fornitori di identità sociale e autenticazione multi-fattore per inquilino. Per enterprise SaaS dove gli inquilini sono organizzazioni, Azure AD B2B (business-to-business) consente agli utenti di accedere con le proprie credenziali di organizzazione.

Sicurezza e segreti

Azure Key Vault memorizza segreti specifici per gli inquilini, stringhe di connessione e certificati. È possibile concedere l'accesso a servizi selezionati o sviluppatori utilizzando le politiche di accesso a volta e RBAC. Per la crittografia a riposo, Azure SQL Database supporta la crittografia trasparente dati (TDE) con i tasti gestiti dal cliente memorizzati in Key Vault—le chiavi possono essere per-tenant se necessario.

Monitoraggio e Osservabilità

Tag tutti i telemetri con un ID inquilino—sia in proprietà personalizzate o attraverso un processore di arricchimento. Crea regole di avviso che fuoco per-tenant quando le soglie sono violate (ad esempio, CPU del database > 80% per un determinato inquilino). Utilizzare Azure Log Analytics e KQL per indagare le prestazioni specifiche in inquilino senza perdite di dati cross-tenant Azure.

Attuazione di modelli multi-tanzia

Hai diversi modelli architettonici tra cui scegliere, che vanno da completamente condivisi a completamente dedicati. Il modello giusto dipende dalle dimensioni dei tuoi inquilini, dalle esigenze di conformità e dalla tua maturità DevOps.

Tutto condiviso (Single Application instance, Database condiviso)

Tutti gli inquilini condividono lo stesso codice di applicazione, risorse di calcolo e database. L'isolamento è puramente logica- o RLS-enforced. Questo modello massimizza l'utilizzo delle risorse e semplifica l'implementazione. È ideale per SaaS di fase precoce o inquilini ad alta volume, bassa complessità applicazione. Il rischio principale è che un affittuoso inquilino vicino può degradare le prestazioni per gli altri.

Database condiviso, schemi separati

Gli inquilini condividono un singolo database ma hanno schemi separati (ad esempio, inquilino 123.orders invece di una colonna inquilina). Questo fornisce un migliore isolamento logico e consente backup per-schema (anche se Azure SQL Database non supporta in modo nativo il backup di livello degli schemi – si potrebbe eseguire il backup dell'intero database).

Database separati (Database per Tenant)

Ogni inquilino ha un proprio database, e potenzialmente il proprio pool elastico o server. Questo modello offre il più forte isolamento, la più flessibilità per la configurazione specifica dell'inquilino, e la più semplice conformità (solo rimuovere un inquilino cancellando il suo database). Il lato negativo è la gestione in testa – è necessario script provisioning, backup e operazioni di migrazione per molti database.

Modelli ibridi e a bordo piscina

Molti fornitori di SaaS maturi combinano modelli. Ad esempio, utilizzare un database condiviso per metadati inquilini, configurazione e registri di audit, e dedicare database per inquilini sopra una certa soglia di reddito. O pool di piccoli inquilini insieme in piscine elastiche e posizionare grandi inquilini in piscine dedicate.

Migliori Pratiche per applicazioni multi-tenant Azure SaaS

Oltre al design iniziale, le operazioni in corso rendono o rompono un'offerta SaaS multi-tenant. Segui queste pratiche per garantire affidabilità, sicurezza e efficienza dei costi.

  • Progetto per la scalabilità fin dall'inizio.] Usa l'auto-scaling integrato di Azure per il servizio App, AKS e database. Prova con la crescita simulata dell'inquilino per garantire che la tua logica di scalatura funzioni.
  • Prioritizzare l'isolamento inquilino in ogni strato. La vostra autenticazione, autorizzazione, accesso ai dati e registrazione devono includere tutti un contesto inquilino esplicito. Mai fare affidamento esclusivamente su controlli di livello di codice, rafforzare l'isolamento tramite la sicurezza del livello di database, Azure RBAC, o le politiche API.
  • Monitor e ottimizzare continuamente.[] Utilizzare Azure Monitor per monitorare le prestazioni, i costi e i tassi di errore pertinenti. Impostare l'avviso per un comportamento anomalo che potrebbe indicare un vicino rumoroso o un problema di sicurezza.
  • Gestione automatica del ciclo di vita degli inquilini. Provvedere nuovi inquilini con modelli ARM, Bicep, o Terraform. Automatizza la creazione di database, l'impostazione dell'identità e la visualizzazione dei dati iniziali.
  • Plan per il backup e il recupero dei dati. Per i modelli di database condivisi, il backup dell'intero database e la garanzia di ripristino puntuale di tutti gli inquilini.Per i database per-tenant, implementare le politiche di backup automatizzate (Azure SQL Database lo fa automaticamente con le politiche di conservazione).
  • Implementare il tracciamento dei costi per inquilino.[] Tag tutte le risorse Azure con un ID inquilino. Utilizzare Azure Cost Management per generare report dei costi per tenant. Considerare la carica inquilini basati su consumo effettivo (CPU, storage, trasferimento dati) per allineare i costi con le entrate.
  • Seguite il processo CI/CD.] Utilizzare slot di distribuzione separate o namespace AKS per la messa in scena. Eseguire test di integrazione che simulano più inquilini. Non esporre mai i dati inquilini nei registri o nelle uscite di prova.

Conclusioni

La giusta architettura bilancia l'isolamento, la scalabilità, la sicurezza e il costo basato sul tuo profilo inquilino specifico e sul modello di business.