Progettare un'architettura distribuita a livello geografico
Azure è un sistema globale. Progettando un'architettura presente in più di un'area di Azure, è possibile creare un'applicazione resiliente alle emergenze anche a livello di area.
Il portale di monitoraggio delle spedizioni è scalabile perché è stato creato usando diverse risorse di Azure che è possibile ridimensionare. È anche resiliente a numerosi errori, perché i relativi componenti possono avere più istanze. Il consiglio di amministrazione è tuttavia preoccupato che un'emergenza su larga scala possa causare un'interruzione perché il portale si trova interamente nell'area di Azure Stati Uniti orientali. Si vuole proporre un'architettura modificata in grado di eseguire il failover in una seconda area in caso di errore nell'area Stati Uniti orientali.
In questa unità si apprende come modificare l'architettura dell'applicazione per supportare un'applicazione distribuita a livello geografico. Si esamina anche il motivo per cui tale architettura è vantaggiosa per le applicazioni critiche.
Architettura dell'app Web originale
Si esamineranno ora la progettazione dell'architettura del portale di monitoraggio e i componenti usati nella soluzione. Una volta compreso il modo in cui vengono usate tutte le parti, è possibile esaminare come supportare ognuno dei componenti in scenari con ridondanza geografica.
La progettazione del portale di monitoraggio è basata sull'architettura di riferimento illustrata nel diagramma riportato di seguito.
Si noti che l'applicazione usa un singolo gruppo di risorse di Azure. Questo gruppo di risorse consente di raggruppare e gestire tutte le risorse in modo logico e semplifica la gestione. È stato scelto di distribuire il gruppo di risorse nell'area Stati Uniti orientali. Anche se il gruppo di risorse non richiede di usare la stessa area di Azure per le risorse incluse, si è deciso di usare l'area Stati Uniti orientali per tutte le risorse distribuite nell'applicazione.
L'applicazione usa tre categorie di risorse di Azure. Si esaminerà ogni categoria e si vedranno le risorse in uso.
Componenti di rete
Il portale di monitoraggio usa i servizi di rete seguenti.
| Servizio | Descrizione |
|---|---|
| DNS Azure | Il servizio DNS di Azure è stato configurato per ospitare i record DNS in Azure. Il servizio DNS di Azure consente di gestire i record DNS usando le proprie credenziali di Azure nel portale di Azure. |
| Gateway applicazione | Il servizio di bilanciamento del carico del gateway applicazione è stato configurato per bilanciare il traffico tra più istanze del front-end Web. Questo servizio si trova in un'area di Azure. |
| Rete CDN di Azure | Il servizio Rete CDN di Azure è stato configurato per ottimizzare la distribuzione di contenuto statico non protetto, ad esempio grafica per il contenuto del sito Web. Questo servizio globale memorizza nella cache il contenuto statico in corrispondenza di POP (Point of Presence ) in tutto il mondo. |
Componenti dell'applicazione
Il portale di monitoraggio usa i servizi seguenti per supportare i requisiti di codice, cache e archiviazione intermedia.
| Servizio | Descrizione |
|---|---|
| Microsoft Entra ID | Gli utenti accedono al portale di rilevamento usando gli account Microsoft Entra. La directory e l'account vengono replicati automaticamente a livello globale. |
| Servizio app di Azure | Il portale di monitoraggio usa due servizi app di Azure. Il primo esegue un set di pagine Web dinamiche e il secondo un'API Web. |
| App per le funzioni di Azure | Il portale di monitoraggio usa le app per le funzioni di Azure per eseguire tutte le attività in background. Alcune di queste attività vengono eseguite in base a una pianificazione regolare, mentre altre attività operano sui messaggi in una coda. |
| Code di Archiviazione di Azure | Il portale di monitoraggio usa le code di Archiviazione di Azure con App per le funzioni di Azure. Il portale di monitoraggio inserisce i messaggi generati nella coda, da dove le app per le funzioni li elaborano. |
| Cache Redis | Il portale di monitoraggio usa una cache Redis tra il servizio app front-end e i sistemi di archiviazione dei dati per ottimizzare le prestazioni delle query. |
| Archiviazione BLOB di Azure | Il contenuto statico, ad esempio file grafici e video, viene conservato sotto forma di BLOB (oggetto binario di grandi dimensioni) in un account di archiviazione di Azure e viene distribuito tramite rete CDN di Azure. |
| Ricerca di Azure | Nel portale di monitoraggio è stato abilitato il servizio Ricerca di Azure. Ricerca di Azure consente di eseguire ricerche in tutto il contenuto e fornisce agli utenti suggerimenti per la ricerca e corrispondenze fuzzy per i risultati della ricerca. |
Componenti di archiviazione dati
Il portale di monitoraggio usa i servizi di archiviazione permanente seguenti.
| Servizio | Descrizione |
|---|---|
| Database SQL di Microsoft Azure | Nel database SQL di Azure vengono archiviati dati relazionali, ad esempio i dettagli relativi agli ordini e ai clienti. |
| Cosmos DB | In Cosmos DB vengono archiviati i dati semistrutturati, tra cui il catalogo dei prodotti. |
Problemi relativi all'architettura originale
L'architettura esistente per il portale di monitoraggio è progettata per garantire scalabilità e disponibilità.
Se ad esempio la richiesta è elevata e le risposte alle richieste Web degli utenti sono lente, è possibile considerare l'aggiunta di altre istanze dell'app Web front-end nel servizio app. Il gateway applicazione può quindi instradare le richieste alle nuove istanze create.
Ci sono tuttavia scenari in cui la progettazione dell'architettura deve superare alcune sfide o può addirittura presentare errori. Si esaminerà ogni scenario per comprendere meglio l'impatto sul portale di monitoraggio.
Errori a livello di area
Alcuni eventi significativi possono causare l'interruzione di un'intera area di Azure. I data center di Azure sono progettati per offrire elevata resilienza, ma un evento meteorologico grave, ad esempio un uragano o un'alluvione, può interrompere il servizio nell'area.
Si tratta di eventi insoliti e molte aziende ritengono di poter correre un tale rischio. Tuttavia, la conseguenza di un errore a livello di area che disabilita il portale di monitoraggio è un rischio troppo elevato e il team dirigente della società ha deciso di non volerlo correre.
Contratti di servizio
La maggior parte dei servizi di Azure offre un contratto di servizio o una garanzia di tempo di attività. Quando si progetta l'architettura di un'applicazione costituita da più servizi di Azure, viene calcolato il contratto di servizio complessivo per l'app come valore composto da tutti gli altri contratti di servizio.
Il contratto di servizio viene calcolato moltiplicando i contratti di servizio dei servizi componenti. Si supponga, ad esempio, che l'app sia costituita dal servizio app di Azure (contratto di servizio del 99,95%) e da Microsoft Entra ID (contratto di servizio del 99,9%). Il contratto di servizio finale calcolato è pari al 99,85%.
Se questa percentuale di tempo di attività non è sufficiente per l'applicazione, è possibile predisporre il failover dell'applicazione in un'altra area.
Componenti globali, a livello di area e configurabili
Nella progettazione scelta alcuni componenti sono globali per impostazione predefinita e non sono vulnerabili a un errore a livello di area.
Alcuni componenti sono limitati a una singola area, ad esempio il gateway applicazione. Per questi tipi di componenti, è necessario selezionare un servizio alternativo.
Alcuni componenti possono essere configurati per supportare più aree. È ad esempio possibile usare l'opzione di archiviazione con ridondanza geografica nell'account di archiviazione di Azure in cui è archiviato il contenuto statico. L'archiviazione con ridondanza geografica replica i BLOB in un'altra area.
La tabella seguente indica quali componenti sono globali, a livello di area e configurabili.
| Componente | Supporto per più aree | Commenti |
|---|---|---|
| DNS di Azure | Generale | Non sono necessarie modifiche. |
| Gateway applicazione | A livello di area | Ogni istanza del gateway applicazione si trova in una singola area. |
| Rete CDN di Azure | Generale | Non sono necessarie modifiche. Il contenuto viene memorizzato nella cache a livello globale per impostazione predefinita. |
| Microsoft Entra ID | Generale | Non sono necessarie modifiche. |
| Servizio app di Azure | A livello di area | Ogni istanza dell'app si trova in una singola area. |
| App per le funzioni di Azure | A livello di area | Ogni istanza dell'app per le funzioni si trova in una singola area. |
| Code di Archiviazione di Azure | Configurabile | È possibile scegliere di eseguire la replica di un account di Archiviazione di Azure in più aree. |
| Cache Redis di Azure | A livello di area | Ogni istanza della cache si trova in una singola area. |
| Archiviazione BLOB di Azure | Configurabile | È possibile scegliere di eseguire la replica di un account di Archiviazione di Azure in più aree. |
| Ricerca di Azure | A livello di area | Ogni istanza del servizio di ricerca si trova in una singola area. |
| database SQL di Azure | Configurabile | È possibile usare la replica geografica per sincronizzare i dati in più aree. |
| Azure Cosmos DB | Configurabile | È possibile usare la replica geografica per sincronizzare i dati in più aree. |
Architettura distribuita proposta
Dopo alcune indagini, si propone l'architettura, come illustrato nel diagramma seguente.
In questa progettazione sono presenti un'area attiva (Stati Uniti orientali) e un'area di standby (Stati Uniti occidentali). L'area Stati Uniti orientali gestisce tutte le richieste dei componenti in circostanze normali. Se un'emergenza causa un errore a livello di area, viene eseguito il failover dell'applicazione nell'area Stati Uniti occidentali.
Si esaminerà ora a livello generale come è stata modificata l'architettura originale. Queste modifiche vengono analizzate in modo più dettagliato nelle unità successive.
Rete
DNS di Azure e Rete CDN di Azure sono sistemi globali per impostazione predefinita e sono già resilienti agli errori a livello di area. Vengono lasciati invariati.
Quando si crea un gateway applicazione di Azure, il servizio viene assegnato a una singola area. Questa vulnerabilità viene rimossa sostituendo questo servizio con Frontdoor di Azure. Frontdoor può eseguire il polling di più servizi app e gestire il failover del servizio app dall'area Stati Uniti orientali all'area Stati Uniti occidentali.
Servizi per le applicazioni
Microsoft Entra ID è un sistema globale e non richiede alcuna modifica.
Gli account di archiviazione di Azure possono essere configurati per la replica del contenuto in più aree. Per modificare la configurazione si usa una delle opzioni di archiviazione con ridondanza geografica.
Gli altri componenti, tra cui il servizio app, le app per le funzioni, la cache Redis e Ricerca di Azure, sono a livello di area. Vengono create istanze duplicate di questi componenti nell'area Stati Uniti occidentali nella nuova progettazione dell'architettura. In questa progettazione la nuova area può assumere il controllo quando si verifica un failover.
Archiviazione di dati
Il database SQL di Azure e Azure Cosmos DB supportano entrambi la replica geografica dei dati in altre aree. Questi servizi vengono configurati per la replica dei dati dell'area Stati Uniti orientali in servizi equivalenti nell'area Stati Uniti occidentali.
Coppie di aree
Un'area di Azure si trova all'interno di una singola area geografica e include uno o più data center di Azure. Tutte le aree sono associate ad altre aree nella stessa area geografica. All'interno di queste coppie, gli aggiornamenti e gli interventi di manutenzione pianificata vengono eseguiti in una sola area alla volta. Se si verifica un errore che interessa più aree, viene assegnata ad almeno un'area per ogni coppia la priorità per un rapido ripristino.
La procedura consigliata consiste nell'usare un'architettura a due aree per l'app nelle due aree di una coppia. Ad esempio, l'area Stati Uniti orientali viene associata con l'area Stati Uniti occidentali. La progettazione proposta usa l'area Stati Uniti orientali come area attiva e l'area Stati Uniti occidentali come area di standby.