Distribuire App Azure Spring in più aree

Questa architettura di riferimento descrive un approccio per l'esecuzione di più istanze di Azure Spring Apps tra aree in una configurazione attiva-attiva.

Questa progettazione si basa sull'architettura di base di Azure Spring Apps. La baseline distribuisce un'applicazione Java Spring Boot in più zone di disponibilità all'interno di una singola area. Le più zone distribuiscono il carico di lavoro dell'applicazione in posizioni separate in modo che il carico di lavoro possa tollerare gli errori locali all'interno dell'area di Azure.

Tuttavia, se si verifica un'interruzione dell'intera area, la baseline non sarà più disponibile per l'utente. Lo scopo di questa progettazione è quello di creare disponibilità elevata in grado di resistere a un'interruzione a livello di area.

Questa architettura è utile per soddisfare gli obiettivi seguenti:

• Aumentare la resilienza complessiva e l'obiettivo del livello di servizio (SLO) dell'applicazione.
• Abilitare la copertura globale per l'applicazione.
• Avvicinare il carico di lavoro all'utente finale e rendere la latenza il più bassa possibile.
• Usare un'area secondaria come sito di failover per l'area primaria e scegliere una progettazione attiva-passiva.

Per aumentare la resilienza e l'affidabilità delle applicazioni, è possibile distribuire l'applicazione in più aree. Per questa progettazione, è necessario un router globale per bilanciare il carico delle richieste alle applicazioni in più aree. Il router globale in questa architettura soddisfa anche altri obiettivi.

La sfida principale con una configurazione in più aree consiste nel replicare i dati per l'applicazione tra più aree. Questo problema non riguarda la configurazione a più zone. Le zone di disponibilità di Azure sono connesse da una rete ad alte prestazioni con una latenza di round trip inferiore a 2 ms. Questo periodo di latenza è sufficiente per la maggior parte delle applicazioni.

Architettura

Il diagramma seguente illustra l'architettura per questo approccio:

Componenti

I componenti di questa architettura sono gli stessi dell'architettura di base. Nell'elenco seguente vengono evidenziate solo le modifiche apportate all'architettura di base. Per la documentazione del prodotto sui servizi di Azure, vedere la sezione Risorse correlate .

• Frontdoor di Azure funge da servizio di bilanciamento del carico globale. Questo servizio viene usato a causa della sua capacità di offrire una maggiore disponibilità con bassa latenza, maggiore scalabilità e memorizzazione nella cache nella rete perimetrale.

Workflow

L'architettura di riferimento implementa il flusso di lavoro seguente:

1. L'utente invia una richiesta al nome host HTTP dell'applicazione, ad esempio www.contoso.com. DNS di Azure risolve la richiesta di questo nome host in Frontdoor di Azure.

2. Frontdoor di Azure usa varie configurazioni di bilanciamento del carico per inoltrare le richieste in ingresso all'endpoint pubblico di app Azure lication Gateway in ogni area. Le istanze di gateway applicazione vengono configurate con lo stesso nome di dominio personalizzato e il nome del certificato TLS di Frontdoor di Azure.

3. gateway applicazione con web application firewall di Azure integrato controlla la richiesta. Web Application Firewall consente le richieste in ingresso solo dal profilo frontdoor di Azure specificato.

4. gateway applicazione inoltra il traffico consentito all'indirizzo IP del servizio di bilanciamento del carico nell'istanza di Spring Apps di cui è stato effettuato il provisioning.

5. Il servizio di bilanciamento del carico interno indirizza solo il traffico da gateway applicazione ai servizi back-end. Questi servizi sono ospitati nell'istanza di Spring Apps all'interno di una rete virtuale in ogni area.

6. Nell'ambito dell'elaborazione della richiesta, l'applicazione comunica con altri servizi di Azure all'interno della rete virtuale. Ad esempio, l'applicazione che comunica con Azure Key Vault per i segreti e il database per l'archiviazione dello stato.

Distribuzione globale

Se si sta progettando per la disponibilità elevata, è possibile configurare questa architettura in un attivo-attivo,attivo-passivo con hot standby o attivo-passivo con modalità standby a freddo.

La scelta dipende dai requisiti di disponibilità per l'applicazione. Questa architettura usa la distribuzione attiva-attiva in due aree perché l'organizzazione di esempio vuole avere una presenza globale con contratto di servizio con tempi di attività elevati (Contratto di servizio). Se si eseguono applicazioni cruciali e si vuole una disponibilità più elevata, è necessario usare più di due aree.

Modalità attiva-attiva

In modalità attiva-attiva, tutte le aree elaborano le richieste contemporaneamente. La sfida più importante con la modalità attiva-attiva è mantenere la sincronizzazione dei dati tra le aree. Questa modalità è un approccio costoso perché si paga due volte per quasi tutti i componenti.

Attivo-passivo con hot standby

In modalità attivo-passivo con hot standby, l'area secondaria non riceve richieste da Frontdoor di Azure purché l'area primaria sia attiva. Assicurarsi di replicare i dati dell'applicazione dall'area primaria all'area secondaria. Se si verifica un errore nell'area primaria, è necessario modificare i ruoli dei database back-end ed eseguire il failover di tutto il traffico attraverso Frontdoor di Azure all'area secondaria.

In modalità attiva-passiva, il failover dovrebbe richiedere del tempo, semplificando la sincronizzazione di tutti i dati. Tuttavia, la modalità attiva-passiva con hot standby è costosa come l'uso della modalità attiva-attiva.

Attivo-passivo con standby a freddo

In modalità attivo-passivo con standby a freddo, l'area primaria ha tutte le risorse e gestisce il traffico. L'area secondaria potrebbe avere meno componenti o componenti con risorse di calcolo inferiori. Le scelte tecnologico dipendono dalla quantità di tempo di inattività accettabile in base ai requisiti aziendali. L'estensione della configurazione dell'area secondaria influisce anche sui costi. Assicurarsi che almeno i dati dell'applicazione siano presenti nell'area secondaria.

Come accennato, la modalità attiva-passiva include il failover richiede tempo, quindi è più facile mantenere sincronizzati tutti i dati. La modalità attivo-passivo con cold standby è l'approccio più conveniente perché non si distribuiscono tutte le risorse in entrambe le aree.

Se l'intera configurazione della soluzione usa modelli, è possibile distribuire facilmente un'area secondaria di standby sporadico creandone le risorse in base alle esigenze. È possibile usare i modelli Terraform, Bicep o Azure Resource Manager e automatizzare la configurazione dell'infrastruttura in una pipeline di integrazione continua/distribuzione continua (CI/CD). È consigliabile testare regolarmente la configurazione ricreando l'area secondaria per assicurarsi che i modelli siano distribuibili in caso di emergenza.

Il modello di stamp di distribuzione è consigliato perché è possibile distribuire più copie indipendenti di un'applicazione o di un componente da un singolo modello a più aree.

Confronto tra modalità

La tabella seguente riepiloga il lavoro richiesto per sincronizzare i dati per ogni modalità e confronta il costo.

Routing tra aree

Questa architettura di riferimento usa nodi geografici (Geodes) in cui qualsiasi area può supportare qualsiasi richiesta.

Frontdoor di Azure è configurato con routing uguale tra le due aree di distribuzione. Frontdoor di Azure fornisce anche altri metodi di routing del traffico all'origine. Se si vuole instradare i client all'origine più vicina, il routing basato sulla latenza ha più senso. Se si sta progettando per una soluzione attiva-passiva, il routing basato su priorità è più appropriato.

Nell'esempio di architettura di riferimento viene usata una regola di bilanciamento del carico uguale tra le due aree. Frontdoor di Azure è configurato con:

• Un dominio personalizzato e un certificato TLS (Transport-Layer Security) con lo stesso nome del nome host dell'applicazione, www.contoso.comad esempio .

• Un'origine per area in cui viene distribuita l'applicazione, in cui ogni origine è un'istanza del gateway di app Azure.

Layout del gruppo di risorse

Usare i gruppi di risorse di Azure per gestire le risorse distribuite in ogni area come singola raccolta. Prendere in considerazione l'inserimento dell'area primaria, dell'area secondaria e di Frontdoor di Azure in gruppi di risorse separati, come illustrato nel diagramma seguente:

Il diagramma mostra la configurazione seguente dei gruppi di risorse:

• Frontdoor di Azure viene distribuito nel Application-shared gruppo di risorse.
• Tutte le risorse ospitate nell'area Europa occidentale (weu) vengono distribuite nel Application-weu gruppo di risorse.
• Le risorse ospitate nell'area Stati Uniti orientali (eus) sono ospitate nel Application-eus gruppo di risorse.
• Le risorse ospitate nell'area Giappone orientale (jae) sono ospitate nel Application-jae gruppo di risorse.

Le risorse nello stesso gruppo di risorse condividono lo stesso ciclo di vita e possono essere facilmente create ed eliminate insieme. Ogni area ha un proprio set di risorse in un gruppo di risorse dedicato che segue una convenzione di denominazione basata sul nome dell'area. Frontdoor di Azure si trova nel proprio gruppo di risorse perché deve esistere anche se altre aree vengono aggiunte o rimosse.

Configurazione del proxy inverso

Frontdoor di Azure esegue il bilanciamento del carico globale tra aree. Questo proxy inverso consente di distribuire il traffico se si distribuisce un carico di lavoro in più aree. In alternativa, è possibile usare Gestione traffico di Azure. Gestione traffico è un servizio di bilanciamento del carico del traffico basato su DNS che bilancia il carico solo a livello di dominio.

Frontdoor di Azure ha reti di distribuzione di contenuti integrate (CDN) che forniscono contenuti dalla rete perimetrale globale di Microsoft con punti di presenza (PoP) distribuiti in tutto il mondo.

La soluzione corrente usa due proxy inversi per mantenere la coerenza con l'architettura di base. Frontdoor di Azure è il router globale. gateway applicazione funge da servizio di bilanciamento del carico per area. Nella maggior parte dei casi, questa configurazione non è necessaria. È possibile rimuovere gateway applicazione se si soddisfa i requisiti seguenti:

• Poiché Web application firewall di Azure è collegato a gateway applicazione, è invece necessario collegare Web Application Firewall al servizio Frontdoor di Azure.
• È necessario un modo per assicurarsi che le chiamate in ingresso provengano solo dall'istanza di Frontdoor di Azure. È possibile aggiungere il X-Azure-FDID header controllo e l'archiviazione degli intervalli IP di Frontdoor di Azure nell'applicazione Spring Cloud Gateway. Per altre informazioni, vedere Usare Frontdoor di Azure come proxy inverso con Spring Cloud Gateway.

Per informazioni su diversi scenari di proxy inverso, su come configurarli e sulle relative considerazioni sulla sicurezza, vedere Esporre Azure Spring Apps tramite un proxy inverso.

Database back-end

Per la distribuzione in più aree, è necessario avere una strategia di replica dei dati. Quando l'applicazione è disponibile in più aree, i dati devono essere sincronizzati in modo che gli utenti non visualizzino dati non aggiornati.

L'architettura corrente usa un database MySQL per il database back-end, ma questa configurazione non risolve la sincronizzazione dei dati. Quando si sceglie una tecnologia di database, verificare come replicare e sincronizzare meglio i dati tra aree. Un'opzione è la database SQL di Azure, con una funzionalità di replica geografica attiva che fornisce un database secondario leggibile e sincronizzato continuamente per un database primario.

È possibile usare questa funzionalità negli scenari seguenti:

• Se l'area secondaria è un cold standby che non riceve richieste attive
• Per eseguire il failover se l'area primaria ha esito negativo
• Per configurare database primari e secondari con connessioni di collegamento privato alle rispettive aree tramite peering di rete virtuale tra le due aree.

Un altro approccio consiste nell'usare Azure Cosmos DB. Questo servizio può distribuire i dati a livello globale replicando in modo trasparente i dati in tutte le aree nell'account Azure Cosmos DB. È anche possibile configurare Azure Cosmos DB con più aree di scrittura. Per altre informazioni, vedere Modello Geode.

Distribuzione automatica

Automatizzare la distribuzione dell'infrastruttura e le distribuzioni del codice dell'applicazione il più possibile.

L'automazione delle distribuzioni dell'infrastruttura garantisce che l'infrastruttura sia configurata in modo identico, evitando la deviazione della configurazione, ad esempio tra aree. L'automazione dell'infrastruttura può anche testare le operazioni di failover.

Per la distribuzione di applicazioni, assicurarsi che i sistemi di distribuzione siano destinati a più aree in cui devono essere distribuite. È anche possibile usare più aree in una strategia di distribuzione blu-verde o canary. Con queste strategie di distribuzione, le nuove versioni delle applicazioni vengono implementate in un'area per il test e in altre aree dopo il completamento del test.

Prestazioni e scalabilità

Questa architettura è più adatta rispetto all'architettura di base per soddisfare le esigenze dell'applicazione perché distribuisce il carico tra aree. Se si configura Frontdoor di Azure per instradare le richieste in base alla latenza, gli utenti ottengono tempi di risposta migliori perché le richieste vengono instradate alle aree più vicine.

A seconda della configurazione del database, è possibile che si verifichi una latenza aggiuntiva quando i dati devono essere sincronizzati tra aree. È possibile superare questa latenza usando Azure Cosmos DB con un livello di coerenza più rilassato.

Questa architettura di riferimento include diversi componenti che possono essere ridimensionati automaticamente in base alle metriche:

• Frontdoor di Azure può essere ridimensionato automaticamente in base alla richiesta. È possibile usare altre funzionalità di Frontdoor di Azure, ad esempio l'accelerazione del traffico e le funzionalità di memorizzazione nella cache, per avvicinare gli asset agli utenti finali.
• gateway applicazione supporta la scalabilità automatica. Per altre informazioni, vedere Ridimensionare gateway applicazione v2 e Web Application Firewall v2.
• Azure Spring Apps supporta anche la scalabilità automatica. Per altre informazioni, vedere Configurare la scalabilità automatica per le applicazioni.

Considerazioni sui costi

Questa soluzione raddoppia efficacemente le stime dei costi dell'architettura di base.

I principali driver per i costi associati alla soluzione in più aree includono:

• I database primari e secondari devono usare lo stesso livello di servizio; in caso contrario, il database secondario potrebbe non rimanere aggiornato con le modifiche alla replica.
• Il traffico tra più aree aumenta significativamente i costi. Il traffico di rete tra aree di Azure comporta addebiti.

Per gestire questi costi, prendere in considerazione queste raccomandazioni per l'implementazione:

• Usare versioni con scalabilità ridotta di risorse come Azure Spring Apps e gateway applicazione nell'area di standby e aumentare le risorse solo quando lo standby diventa attivo.
• Se gli scenari aziendali consentono, creare una configurazione attiva-passiva per risparmiare sui costi.
• Implementare una configurazione a più zone in una singola area per soddisfare le esigenze aziendali di disponibilità e resilienza. Questa opzione può essere più conveniente perché si paga solo una volta per la maggior parte delle risorse.
• Scegliere la configurazione alternativa che usa un solo proxy inverso per risparmiare sui costi. Tenere presente che è necessario applicare una configurazione aggiuntiva per mantenere la sicurezza di questa alternativa.

Il costo dei servizi in questa architettura è stato stimato con il calcolatore prezzi di Azure usando valori predefiniti ragionevoli per un'applicazione su scala ridotta. È possibile aggiornare questa stima in base ai valori di velocità effettiva previsti per l'applicazione.

Altre considerazioni

Le considerazioni di progettazione per l'architettura di base per più zone si applicano anche alla soluzione in più aree descritta in questo articolo. Esaminare i punti seguenti nel contesto dell'architettura a più aree:

• Sicurezza di rete. È importante controllare la comunicazione attraverso la rete. Questa soluzione consente solo le chiamate in ingresso da Frontdoor di Azure, in cui le chiamate vengono instradate a gateway applicazione in ogni area. Da gateway applicazione, la route chiama al servizio Azure Spring Apps back-end. La comunicazione da Azure Spring Apps ai servizi di supporto come Key Vault è controllata anche tramite endpoint privati. Per altre informazioni, vedere Architettura di base: Sicurezza di rete.

• Gestione delle identità e degli accessi. Implementare un accesso più sicuro usando le identità gestite per connettersi tra componenti diversi. Un esempio è il modo in cui Azure Spring Apps usa un'identità gestita per connettersi a Key Vault. Per altre informazioni, vedere Architettura di base: gestione delle identità e degli accessi.

• Monitoraggio. È possibile aggiungere la strumentazione e abilitare la traccia distribuita per raccogliere dati dall'applicazione. Combinare l'origine dati con la diagnostica della piattaforma per ottenere informazioni dettagliate end-to-end sull'applicazione. Per altre informazioni, vedere Architettura di base: Monitoraggio.

• Gestione dei segreti. La soluzione in più aree archivia i segreti e i certificati dell'applicazione in un singolo insieme di credenziali delle chiavi. Per altre informazioni, vedere Architettura di base: Gestione dei segreti.

Distribuzione dello scenario

Una distribuzione per questa architettura di riferimento è disponibile nell'architettura di riferimento a più aree di Azure Spring Apps in GitHub. La distribuzione usa i modelli Terraform.

Per distribuire l'architettura, seguire le istruzioni dettagliate.

Collaboratori

Microsoft gestisce questo contenuto. Il collaboratore seguente ha sviluppato il contenuto originale.

Autore principale:

• Gitte Vermeiren | FastTrack per tecnico di Azure

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

Passaggi successivi

Per integrare questo carico di lavoro con i servizi condivisi gestiti dai team centrali dell'organizzazione, distribuirlo in una zona di destinazione dell'applicazione Azure.

Risorse correlate

Per la documentazione sui servizi e le funzionalità di Azure usati in questa architettura, vedere gli articoli seguenti:

• Azure Spring Apps
• Frontdoor di Azure
• gateway app Azure lication v2
• Database di Azure per MySQL
• Azure Key Vault
• DNS Azure
• Web application firewall di Azure
• Collegamento privato di Azure
• Identità gestite di Microsoft Entra per le risorse di Azure

Per una conoscenza più approfondita delle scelte di configurazione coinvolte in questa architettura, è consigliabile usare le guide seguenti:

• Esporre Azure Spring Apps tramite un proxy inverso
• Distribuzione blu/verde a disponibilità elevata per le applicazioni
• Mantenere il nome host HTTP originale tra un proxy inverso e l'applicazione Web back-end

Questa architettura è progettata in linea con i pilastri di Microsoft Azure Well-Architected Framework. È consigliabile esaminare i principi di progettazione per ogni pilastro.