Progettare un'architettura dell'applicazione distribuita a livello geografico
Quando i componenti di rete instradano le richieste in più aree per mitigare gli effetti di un'interruzione a livello di area, è necessario progettare servizi dell'applicazione in grado di rispondere a tali richieste sia nell'area primaria che in quella di standby.
Come illustrato in precedenza, si intende configurare Frontdoor di Azure anche con l'assegnazione di back-end prioritari. L'area Stati Uniti orientali viene assegnata come area primaria e l'area Stati Uniti occidentali come area di standby. Quando si verifica un errore a livello di area, le richieste vengono instradate al servizio app nell'area senza errore. È necessario configurare le risorse in ogni area per supportare questi failover per l'accesso utente, l'archiviazione replicata e il codice dell'applicazione.
In questo caso vengono esaminati i servizi applicazione nella soluzione e si determina se devono essere modificati per funzionare in un'architettura multi-area. In particolare, si esaminano Active Directory, archiviazione contenuto statico, app Web, API Web, code, funzioni di Azure e cache dei dati.
Microsoft Entra ID
Nel portale di monitoraggio delle spedizioni gli utenti possono tenere traccia delle consegne dei propri acquisti immettendo un numero di tracciabilità. Gli utenti possono tuttavia effettuare la registrazione per accedere a funzionalità avanzate, ad esempio la puntualità delle consegne e altre statistiche. È stato sviluppato il portale di rilevamento per archiviare gli account utente in Microsoft Entra ID.
Microsoft Entra ID è progettato come sistema globale per impostazione predefinita. Di conseguenza, non è vulnerabile agli errori a livello di area e non è necessario modificare questo componente del sistema.
Archiviazione BLOB di Azure
Il contenuto statico, ad esempio immagini e video, viene archiviato negli account di archiviazione di Azure sotto forma di BLOB (oggetto binario di grandi dimensioni) e distribuito agli utenti tramite Rete CDN di Azure.
Nella progettazione originale, l'account di archiviazione si trova in una singola area perché si è scelto di usare l'archiviazione con ridondanza locale. I dati vengono replicati solo all'interno di un singolo data center con archiviazione con ridondanza locale. L'account di archiviazione non è quindi disponibile se si verifica un'interruzione a livello di area in questa configurazione. Il contenuto statico già memorizzato nella cache dalla rete CDN rimane disponibile per gli utenti.
Lo stesso vale per l'archiviazione con ridondanza della zona. Anche se in questa configurazione i dati vengono replicati in data center diversi, tutti i data center si trovano comunque nella stessa area. Un'interruzione a livello di area in questa configurazione influisce anche sull'account di archiviazione.
Nella nuova progettazione, si fa affidamento sulla configurazione della rete CDN per memorizzare nella cache il contenuto statico. È possibile che, durante un'interruzione, un utente richieda un file statico che non si trova ancora nella cache della rete CDN. In questo caso, il grafico o il video non può essere visualizzato.
È possibile eliminare questa possibilità eseguendo la replica dell'account di archiviazione in più aree quando si sceglie un'opzione di archiviazione con ridondanza geografica. È disponibile anche un'opzione di replica di sola lettura se si vuole impedire di aggiungere contenuto statico durante un'interruzione a livello di area.
Quando è necessario abilitare la ridondanza geografica, è possibile scegliere tra due opzioni. Queste opzioni sono archiviazione con ridondanza geografica e accesso in lettura (RA-GRS) e archiviazione con ridondanza geografica della zona e accesso in lettura (RA-GZRS). La scelta effettuata dipende dal budget e dalla percentuale di tempo di attività necessaria.
Servizio app di Azure e app per le funzioni di Azure
Il portale di monitoraggio delle spedizioni implementa due servizi app di Azure. Il primo servizio app ospita un'app Web che implementa l'interfaccia Web per gli utenti, mentre il secondo ospita un'API Web usata dalle app per dispositivi mobili per monitorare i dati delle spedizioni. Tutte le attività in background vengono eseguite come app per le funzioni di Azure.
Nella progettazione originale ogni servizio app di Azure si trova in una singola area di Azure. Viene creato un secondo servizio app nell'area secondaria (Stati Uniti occidentali) dove si distribuirà il progetto Web per supportare la nuova architettura in più aree. Viene configurata la modalità di routing con priorità di Frontdoor di Azure per inviare le richieste all'area secondaria quando l'area primaria non è disponibile.
Per garantire che il failover avvenga nel modo più lineare possibile, assicurarsi che l'applicazione Web non archivi in memoria informazioni sullo stato della sessione. Il sito Web viene modificato per fare in modo che non si verifichino perdite di dati. Se ad esempio il codice archiviasse in memoria un elenco di spedizioni degli utenti, questo elenco andrebbe perso in caso di failover.
Ogni richiesta Web viene gestita senza alcun effetto sulle altre quando non viene archiviato alcuno stato della sessione. Se si verifica un failover durante una sessione di un utente, questo deve avvenire in modo trasparente per l'utente.
Viene apportata una modifica simile alle app per le funzioni di Azure. Viene creata un'istanza separata della funzione di Azure nell'area secondaria e verrà distribuito lo stesso codice personalizzato eseguito nell'area primaria.
Importante
Quando si distribuisce un aggiornamento al codice personalizzato nel servizio app o nell'app per le funzioni, ricordarsi di distribuirlo a tutte le istanze del servizio app. Se si vuole automatizzare questo processo, è possibile usare gli strumenti offerti da Azure DevOps.
Code di Archiviazione di Azure
Nell'architettura a singola area originale è stata usata una coda in un account di archiviazione di Azure per gestire le comunicazioni tra il servizio app e l'app per le funzioni. Quando l'app Web o l'API Web deve eseguire un'attività in background, inserisce un messaggio con tutte le informazioni necessarie nella coda. L'app per le funzioni monitora la coda per rilevare i nuovi messaggi e svolge l'attività in background eseguendo le query necessarie sugli archivi dati.
Usando una coda in questo modo, è possibile gestire un picco di richieste Web in modo ordinato. Quando ci sono molte attività in background da eseguire, la coda può accumularsi, ma le attività non vengono abbandonate. Rimangono nella coda finché non vengono elaborate. Le app per le funzioni gestiscono la coda riducendone le dimensioni quando le richieste diminuiscono. Se la domanda rimane alta, è possibile aumentare il numero di istanze dell'app per le funzioni.
Per la versione del portale di monitoraggio delle spedizioni in più aree, è necessario assicurarsi che gli elementi della coda non vadano persi quando si verifica il failover. La coda è definita in Archiviazione di Azure ed è possibile usare un'opzione di ridondanza per la replica geografica.
Tenere presente che non è possibile usare un'opzione di ridondanza con accesso in lettura perché la coda supporta operazioni di lettura e scrittura. Il servizio app deve aggiungere elementi alla coda e l'app per le funzioni deve rimuovere gli elementi completati dalla coda. Usare invece l'archiviazione con ridondanza geografica o l'archiviazione con ridondanza geografica della zona.
Cache Redis di Azure
SI usa Cache Redis di Azure per ottimizzare le prestazioni dell'archiviazione dati. Redis memorizza nella cache tutti i risultati delle query generati dalle app quando vengono richiesti dati dal database. Le altre query per dati simili non necessitano di una query sul database e i risultati vengono recuperati dalla cache Redis.
Per l'architettura in più aree, viene creata un'istanza della cache Redis sia nell'area primaria che in quella di standby. Tenere presente che quando si verifica un failover, la cache Redis nell'area di standby è probabilmente vuota. La cache vuota non provoca alcun errore, ma può verificarsi un temporaneo peggioramento delle prestazioni mentre i dati riempiono la nuova cache.