Considerazioni su Servizio app di Azure e Funzioni di Azure per la multi-tenancy

app Azure Service è una potente piattaforma di hosting di applicazioni Web. Funzioni di Azure, basato sull'infrastruttura servizio app, consente di creare facilmente carichi di lavoro di calcolo serverless e basati su eventi. Entrambi i servizi vengono spesso usati nelle soluzioni multi-tenant.

Funzionalità del servizio app Azure e Funzioni di Azure che supportano la multi-tenancy

app Azure Servizio e Funzioni di Azure includono molte funzionalità che supportano la multi-tenancy.

Nomi di dominio personalizzati

app Azure Servizio consente di usare il DNS con caratteri jolly e di aggiungere certificati TLS con caratteri jolly. Quando si usano sottodomini specifici del tenant, i certificati DNS e TLS con caratteri jolly consentono di ridimensionare facilmente la soluzione in un numero elevato di tenant, senza richiedere una riconfigurazione manuale per ogni nuovo tenant.

Quando usi nomi di dominio personalizzati specifici del tenant, potresti avere un numero elevato di nomi di dominio personalizzati che devono essere aggiunti all'app. Può diventare complesso gestire molti nomi di dominio personalizzati, soprattutto quando richiedono singoli certificati TLS. servizio app fornisce certificati TLS gestiti, riducendo il lavoro necessario quando si lavora con domini personalizzati. Esistono tuttavia limiti da considerare, ad esempio il numero di domini personalizzati che possono essere applicati a una singola app.

Integrazione con Frontdoor di Azure

servizio app e Funzioni di Azure l'integrazione con Frontdoor di Azure, per fungere da componente con connessione Internet della soluzione. Frontdoor di Azure consente di aggiungere un web application firewall (WAF) e la memorizzazione nella cache perimetrale e offre altre ottimizzazioni delle prestazioni. È possibile riconfigurare facilmente i flussi di traffico per indirizzare il traffico a back-end diversi, in base ai requisiti aziendali o tecnici mutevoli.

Quando si usa Frontdoor di Azure con un'app multi-tenant, è possibile usarla per gestire i nomi di dominio personalizzati e per terminare le connessioni TLS. L'applicazione servizio app viene quindi configurata con un singolo nome host e tutto il traffico passa attraverso tale applicazione, evitando così di gestire i nomi di dominio personalizzati in più posizioni.

Come nell'esempio precedente, Frontdoor di Azure può essere configurato per modificare l'intestazione della Host richiesta. L'intestazione originale Host inviata dal client viene propagata tramite l'intestazione X-Forwarded-Host e il codice dell'applicazione può usare questa intestazione per eseguire il mapping della richiesta al tenant corretto.

È possibile usare endpoint privati o servizio app restrizioni di accesso per assicurarsi che il traffico sia passato attraverso Frontdoor prima di raggiungere l'app.

Per altre informazioni sull'uso di Frontdoor di Azure in una soluzione multi-tenant, vedere Usare Frontdoor di Azure in una soluzione multi-tenant

Autenticazione e autorizzazione

app Azure Servizio può convalidare i token di autenticazione per conto dell'app. Quando servizio app riceve una richiesta, verifica se vengono soddisfatte ognuna delle condizioni seguenti:

• La richiesta contiene un token.
• Il token è valido.
• La richiesta è autorizzata.

Se una delle condizioni non viene soddisfatta, servizio app può bloccare la richiesta oppure reindirizzare l'utente al provider di identità in modo che possa eseguire l'accesso.

Se i tenant usano Microsoft Entra ID come sistema di identità, è possibile configurare app Azure Service per usare l'endpoint /common per convalidare i token utente. Ciò garantisce che, indipendentemente dal tenant di Microsoft Entra dell'utente, i relativi token vengano convalidati e accettati.

È anche possibile integrare app Azure Service con Azure AD B2C per l'autenticazione dei consumer.

Ulteriori informazioni:

• autorizzazione servizio app
• Configurare l'autenticazione in un'app Web di esempio usando Azure AD B2C
• Uso delle identità multi-tenant di Microsoft Entra

Restrizioni di accesso

È possibile limitare il traffico all'app usando le restrizioni di accesso. Possono essere usati per specificare gli intervalli di indirizzi IP o le reti virtuali autorizzate a connettersi all'app.

Quando si usa una soluzione multi-tenant, tenere presente il numero massimo di regole di restrizione di accesso. Ad esempio, se è necessario creare una regola di restrizione di accesso per ogni tenant, è possibile superare il numero massimo di regole consentite. Se è necessario un numero maggiore di regole, valutare la possibilità di distribuire un proxy inverso, ad esempio Frontdoor di Azure.

Modelli di isolamento

Quando si usa un sistema multi-tenant usando app Azure Servizio o Funzioni di Azure, è necessario prendere una decisione sul livello di isolamento da usare. Fare riferimento ai modelli di tenancy da considerare per una soluzione multi-tenant e alle indicazioni fornite negli approcci architetturali per il calcolo nelle soluzioni multi-tenant, per consentire di selezionare il modello di isolamento migliore per lo scenario in uso.

Quando si lavora con app Azure Servizio e Funzioni di Azure, è necessario tenere presenti i concetti chiave seguenti:

• In app Azure Servizio un piano rappresenta l'infrastruttura di hosting. Un'app rappresenta una singola applicazione in esecuzione in tale infrastruttura. È possibile distribuire più app in un singolo piano.
• In Funzioni di Azure anche l'hosting e l'applicazione sono separati, ma sono disponibili opzioni di hosting aggiuntive per l'hosting elastico, in cui Funzioni di Azure gestisce automaticamente il ridimensionamento. Per semplicità, si fa riferimento all'infrastruttura di hosting come piano in questo articolo, perché i principi descritti di seguito si applicano sia a servizio app che a Funzioni di Azure, indipendentemente dal modello di hosting usato.

La tabella seguente riepiloga le differenze tra i principali modelli di isolamento tenancy per app Azure Service e Funzioni di Azure:

App condivise

È possibile distribuire un'applicazione condivisa in un singolo piano e usare l'applicazione condivisa per tutti i tenant.

Ciò tende a essere l'opzione più conveniente e richiede il minor sovraccarico operativo perché sono presenti meno risorse da gestire. È possibile ridimensionare il piano complessivo in base al carico o alla domanda e tutti i tenant che condividono il piano trarranno vantaggio dall'aumento della capacità.

È importante tenere presente le quote e i limiti servizio app, ad esempio il numero massimo di domini personalizzati che possono essere aggiunti a una singola app e il numero massimo di istanze di un piano di cui è possibile eseguire il provisioning.

Per poter usare questo modello, il codice dell'applicazione deve essere compatibile con più tenancy.

App per tenant con piani condivisi

È anche possibile scegliere di condividere il piano tra più tenant, ma distribuire app separate per ogni tenant. Ciò offre l'isolamento logico tra ogni tenant e questo approccio offre i vantaggi seguenti:

• Efficienza dei costi: condividendo l'infrastruttura di hosting, in genere è possibile ridurre i costi complessivi per tenant.
• Separazione della configurazione: l'app di ogni tenant può avere un nome di dominio, un certificato TLS, restrizioni di accesso e criteri di autorizzazione del token applicati.
• Separazione degli aggiornamenti: i file binari dell'applicazione di ogni tenant possono essere aggiornati indipendentemente da altre app nello stesso piano.

Tuttavia, poiché le risorse di calcolo del piano sono condivise, le app potrebbero essere soggette al problema Noisy Neighbor. Esistono inoltre limiti al numero di app che possono essere distribuite in un singolo piano.

Piani per tenant

Il livello di isolamento più elevato consiste nel distribuire un piano dedicato per un tenant. Questo piano dedicato garantisce che il tenant disponga dell'uso completo di tutte le risorse server allocate a tale piano.

Questo approccio consente di ridimensionare la soluzione per fornire l'isolamento delle prestazioni per ogni tenant ed evitare il problema Noisy Neighbor. Tuttavia, ha anche un costo più elevato perché le risorse non vengono condivise con più tenant. È anche necessario considerare il numero massimo di piani che possono essere distribuiti in un singolo gruppo di risorse di Azure.

API host

È possibile ospitare API sia nel servizio app Azure che in Funzioni di Azure. La scelta della piattaforma dipenderà dal set di funzionalità e dalle opzioni di ridimensionamento specifiche necessarie.

Indipendentemente dalla piattaforma usata per ospitare l'API, prendere in considerazione l'uso di Azure Gestione API davanti all'applicazione API. Gestione API offre molte funzionalità che possono essere utili per le soluzioni multi-tenant, tra cui le seguenti:

• Punto centralizzato per tutte le autenticazioni. Ciò può includere la determinazione dell'identificatore del tenant da un'attestazione di token o da altri metadati della richiesta.
• Routing delle richieste a back-end API diversi, che potrebbero essere basati sull'identificatore del tenant della richiesta. Questo può essere utile quando si ospitano più stamp di distribuzione, con le proprie applicazioni API indipendenti, ma è necessario avere un singolo URL API per tutte le richieste.

Rete e multi-tenancy

Indirizzi IP

Molte applicazioni multi-tenant devono connettersi alle reti locali dei tenant per inviare dati.

Se è necessario inviare il traffico in uscita da un indirizzo IP statico noto o da un set di indirizzi IP statici noti, è consigliabile usare un gateway NAT. Per altre informazioni su come usare il gateway NAT nelle soluzioni multi-tenant, vedere Considerazioni sul gateway NAT di Azure per la multi-tenancy. servizio app fornisce indicazioni su come eseguire l'integrazione con un gateway NAT.

Se non è necessario un indirizzo IP statico in uscita, ma è necessario controllare occasionalmente l'indirizzo IP usato dall'applicazione per il traffico in uscita, è possibile eseguire una query negli indirizzi IP correnti della distribuzione servizio app.

Obiettivi di vendita

Poiché servizio app è un servizio multi-tenant, è necessario occuparsi del modo in cui si usano le risorse condivise. La rete è un'area a cui è necessario prestare particolare attenzione, perché esistono limiti che influiscono sul funzionamento dell'applicazione con connessioni di rete in ingresso e in uscita, inclusi i limiti di rete di rete di origine (SNAT) e tcp.

Se l'applicazione si connette a un numero elevato di database o servizi esterni, l'app potrebbe essere a rischio di esaurimento delle porte SNAT. In generale, l'esaurimento delle porte SNAT indica che il codice non riutilizza correttamente le connessioni TCP e anche in una soluzione multi-tenant, è necessario assicurarsi di seguire le procedure consigliate per il riutilizzo delle connessioni.

Tuttavia, in alcune soluzioni multi-tenant, il numero di connessioni in uscita a indirizzi IP distinti può comportare l'esaurimento delle porte SNAT, anche quando si seguono le procedure di codifica consigliate. In questi scenari, prendere in considerazione una delle opzioni seguenti:

• Distribuire il gateway NAT per aumentare il numero di porte SNAT disponibili per l'uso dell'applicazione. Per altre informazioni su come usare il gateway NAT nelle soluzioni multi-tenant, vedere Considerazioni sul gateway NAT di Azure per la multi-tenancy.
• Usare gli endpoint di servizio quando ci si connette ai servizi di Azure per ignorare i limiti del servizio di bilanciamento del carico.

Anche con questi controlli sul posto, è possibile avvicinarsi ai limiti con un numero elevato di tenant, quindi è consigliabile pianificare la scalabilità a piani di servizio app aggiuntivi o indicatori di distribuzione.

Collaboratori

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

Autore principale:

• John Downs | Principal Customer Engineer, FastTrack per Azure

Altri contributori:

• Thiago Almeida | Principal Program Manager, Funzioni di Azure
• Arsen Vladimirintune | Principal Customer Engineer, FastTrack per Azure

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

Passaggi successivi

Vedere Risorse per architetti e sviluppatori di soluzioni multi-tenant.