Modello di app Web affidabile per Java

Servizio app di Azure
Frontdoor di Azure

Questo articolo fornisce indicazioni sull'implementazione del modello di app Web Reliable. Questo modello illustra come modificare (ripiattaforma) le app Web per la migrazione cloud. Offre un'architettura prescrittiva, codice e linee guida di configurazione allineate ai principi di Well-Architected Framework.

Perché il modello Reliable Web App per Java?

Il modello Reliable Web App è un set di principi e tecniche di implementazione che definiscono come riformare le app Web durante la migrazione al cloud. È incentrato sugli aggiornamenti minimi del codice che è necessario apportare per avere successo nel cloud. Le indicazioni seguenti usano l'implementazione di riferimento come esempio in tutto e seguono il percorso di ripiattaforma dell'azienda fittizia, Contoso Fiber, per fornire il contesto aziendale per il percorso. Prima di implementare il modello Reliable Web App per Java, Contoso Fiber aveva un sistema di gestione degli account cliente (CAMS) monolitico locale che usava il framework Spring Boot.

Suggerimento

Logo di GitHub.È disponibile un'implementazione di riferimento (esempio) del modello Reliable Web App. Rappresenta lo stato finale dell'implementazione di Reliable Web App. Si tratta di un'app Web di livello di produzione che include tutti gli aggiornamenti di codice, architettura e configurazione descritti in questo articolo. Distribuire e usare l'implementazione di riferimento per guidare l'implementazione del modello di app Web Reliable.

Come implementare il modello di app Web Reliable

Questo articolo include le linee guida per l'architettura, il codice e la configurazione per implementare il modello Reliable Web App. Usare i collegamenti seguenti per passare alle indicazioni specifiche necessarie:

  • Contesto aziendale: allineare queste linee guida al contesto aziendale e imparare a definire obiettivi immediati e a lungo termine che determinano decisioni di riformatura.
  • Indicazioni sull'architettura: informazioni su come selezionare i servizi cloud corretti e progettare un'architettura che soddisfi i requisiti aziendali.
  • Linee guida sul codice: implementare tre modelli di progettazione per migliorare l'affidabilità e l'efficienza delle prestazioni dell'app Web nel cloud: ripetizione dei tentativi, interruttore e modelli cache-aside
  • Indicazioni sulla configurazione: configurare l'autenticazione e l'autorizzazione, le identità gestite, gli ambienti con diritti, l'infrastruttura come codice e il monitoraggio.

Contesto aziendale

Il primo passaggio per ripiattaformare un'app Web consiste nel definire gli obiettivi aziendali. È consigliabile definire obiettivi immediati, ad esempio obiettivi del livello di servizio e obiettivi di ottimizzazione dei costi, nonché obiettivi futuri per l'applicazione Web. Questi obiettivi influenzano la scelta dei servizi cloud e l'architettura dell'applicazione Web nel cloud. Definire uno SLO di destinazione per l'app Web, ad esempio il tempo di attività del 99,9%. Calcolare il contratto di servizio composito per tutti i servizi che influiscono sulla disponibilità dell'app Web.

Ad esempio, Contoso Fiber voleva espandere l'app Web cams (Customer Account Management System) locale per raggiungere altre aree.For example, Contoso Fiber, wanted to expand their on-premises Customer Account Management System (CAMS) web app to reach other regions. Per soddisfare la maggiore domanda sull'app Web, hanno stabilito gli obiettivi seguenti:

  • Applicare modifiche al codice a basso costo e alto valore
  • Raggiungere un obiettivo del livello di servizio (SLO) del 99,9%
  • Adottare procedure DevOps
  • Creare ambienti ottimizzati per i costi
  • Migliorare l'affidabilità e la sicurezza

Contoso Fiber ha determinato che l'infrastruttura locale non era una soluzione conveniente per il ridimensionamento dell'applicazione. Quindi, hanno deciso che la migrazione dell'applicazione Web CAMS ad Azure è stata il modo più conveniente per raggiungere gli obiettivi immediati e futuri.

Linee guida per l'architettura

Il modello Reliable Web App include alcuni elementi architetturali essenziali. È necessario dns per gestire la risoluzione degli endpoint, un web application firewall per bloccare il traffico HTTP dannoso e un servizio di bilanciamento del carico per proteggere e instradare le richieste degli utenti in ingresso. La piattaforma dell'applicazione ospita il codice dell'app Web e effettua chiamate a tutti i servizi back-end tramite endpoint privati in una rete virtuale. Uno strumento di monitoraggio delle prestazioni dell'applicazione acquisisce metriche e log per comprendere l'app Web.

Diagramma che mostra gli elementi architetturali essenziali del modello Reliable Web App.

Figura 1. Elementi architetturali essenziali del modello Reliable Web App.

Progettare l'architettura

Progettare l'infrastruttura per supportare le metriche di ripristino, ad esempio l'obiettivo del tempo di ripristino (RTO) e l'obiettivo del punto di ripristino (RPO). L'obiettivo RTO influisce sulla disponibilità e deve supportare lo SLO. Determinare un obiettivo del punto di ripristino (RPO) e configurare la ridondanza dei dati per soddisfare l'obiettivo rpo.

  • Scegliere l'affidabilità dell'infrastruttura. Determinare il numero di aree e zone di disponibilità necessarie per soddisfare le esigenze di disponibilità. Aggiungere zone di disponibilità e aree fino a quando il contratto di servizio composito non soddisfa lo SLO. Il modello Reliable Web App supporta più aree per una configurazione attiva-attiva o attiva-passiva. Ad esempio, l'implementazione di riferimento usa una configurazione attiva-passiva per soddisfare un SLO pari al 99,9%.

    Per un'app Web in più aree, configurare il servizio di bilanciamento del carico per instradare il traffico alla seconda area per supportare una configurazione attiva-attiva o passiva attiva a seconda delle esigenze aziendali. Le due aree richiedono gli stessi servizi ad eccezione di un'area con una rete virtuale hub che connette le aree. Adottare una topologia di rete hub-spoke per centralizzare e condividere risorse, ad esempio un firewall di rete. Se si dispone di macchine virtuali, aggiungere un bastion host alla rete virtuale hub per gestirli in modo sicuro (vedere la figura 2).

    Diagramma che mostra il modello Reliable Web App con una seconda area e una topologia hub-spoke.

    Figura 2. Modello Reliable Web App con una seconda area e una topologia hub-spoke.

  • Scegliere una topologia di rete. Scegliere la topologia di rete appropriata per i requisiti web e di rete. Se si prevede di avere più reti virtuali, usare una topologia di rete hub-spoke. Offre vantaggi in termini di costi, gestione e sicurezza con opzioni di connettività ibrida alle reti locali e virtuali.

Scegliere i servizi di Azure corretti

Quando si sposta un'app Web nel cloud, è necessario selezionare i servizi di Azure che soddisfano i requisiti aziendali e allinearsi alle funzionalità correnti dell'app Web locale. L'allineamento consente di ridurre al minimo lo sforzo di ripiattaforma. Ad esempio, usare i servizi che consentono di mantenere lo stesso motore di database e supportare il middleware e i framework esistenti. Le sezioni seguenti forniscono indicazioni per selezionare i servizi di Azure corretti per l'app Web.

Ad esempio, prima del passaggio al cloud, l'app Web CAMS di Contoso Fiber era un'app Web Java monolitica locale. Si tratta di un'app Spring Boot con un database PostgreSQL. L'app Web è un'app di supporto line-of-business. È rivolto ai dipendenti. I dipendenti contoso Fiber usano l'applicazione per gestire i casi di supporto dei clienti. L'app Web ha subito problemi comuni di scalabilità e distribuzione delle funzionalità. Questo punto di partenza, i loro obiettivi aziendali e SLO hanno guidato le loro scelte di servizio.

  • Piattaforma dell'applicazione: usare app Azure Service come piattaforma dell'applicazione. Contoso Fiber ha scelto app Azure Servizio come piattaforma applicativa per i motivi seguenti:

    • Progressione naturale: Contoso Fiber ha distribuito un file Spring Boot jar nel server locale e ha voluto ridurre al minimo la quantità di riprogettazione per il modello di distribuzione. servizio app offre un supporto affidabile per l'esecuzione di app Spring Boot ed è stato un progresso naturale per Contoso Fiber per l'uso di servizio app. App Azure Container è anche un'alternativa interessante per questa app. Per altre informazioni, vedere Panoramica di Azure Spring Apps e Java in App Azure Container.
    • Contratto di servizio elevato: ha un contratto di servizio elevato che soddisfa i requisiti per l'ambiente di produzione.
    • Riduzione del sovraccarico di gestione: si tratta di una soluzione di hosting completamente gestita.
    • Funzionalità di containerizzazione: servizio app funziona con registri di immagini del contenitore privato come Registro Azure Container. Contoso Fiber può usare questi registri per inserire in contenitori l'app Web in futuro.
    • Scalabilità automatica: l'app Web può aumentare, ridurre e ridurre rapidamente le prestazioni in base al traffico utente.
  • Gestione delle identità: usare Microsoft Entra ID come soluzione di gestione delle identità e degli accessi. Contoso Fiber ha scelto Microsoft Entra ID per i motivi seguenti:

    • Autenticazione e autorizzazione: l'applicazione deve autenticare e autorizzare i dipendenti del call center.
    • Scalabile: è scalabile per supportare scenari di dimensioni maggiori.
    • Controllo dell'identità utente: i dipendenti del call center possono usare le identità aziendali esistenti.
    • Supporto del protocollo di autorizzazione: supporta OAuth 2.0 per le identità gestite.
  • Database: usare un servizio che consente di mantenere lo stesso motore di database. Usare l'albero delle decisioni dell'archivio dati. Contoso Fiber ha scelto Database di Azure per PostgreSQL e l'opzione flexible-server per i motivi seguenti:

    • Affidabilità: il modello di distribuzione flessibile-server supporta la disponibilità elevata con ridondanza della zona in più zone di disponibilità. Questa configurazione gestisce un server warm standby in una zona di disponibilità diversa all'interno della stessa area di Azure. La configurazione replica i dati in modo sincrono nel server di standby.
    • Replica tra aree: include una funzionalità di replica in lettura che consente di replicare in modo asincrono i dati in un database di replica di sola lettura in un'altra area.
    • Prestazioni: offre prestazioni prevedibili e ottimizzazione intelligente per migliorare le prestazioni del database usando dati di utilizzo reali.
    • Riduzione del sovraccarico di gestione: si tratta di un servizio di Azure completamente gestito che riduce gli obblighi di gestione.
    • Supporto per la migrazione: supporta la migrazione del database dai database PostgreSQL a server singolo locali. Possono usare lo strumento di migrazione per semplificare il processo di migrazione.
    • Coerenza con le configurazioni locali: supporta diverse versioni della community di PostgreSQL, inclusa la versione attualmente usata da Contoso Fiber.
    • Resilienza. La distribuzione flessibile del server crea automaticamente backup del server e li archivia usando l'archiviazione con ridondanza della zona (ZRS) all'interno della stessa area. Possono ripristinare il database in qualsiasi momento entro il periodo di conservazione dei backup. La funzionalità di backup e ripristino crea un RPO migliore (quantità accettabile di perdita di dati) rispetto a Contoso Fiber potrebbe creare in locale.
  • Monitoraggio delle prestazioni dell'applicazione: usare Application Insights per analizzare i dati di telemetria nell'applicazione. Contoso Fiber ha scelto di usare Application Insights per i motivi seguenti:

    • Integrazione con Monitoraggio di Azure: offre la migliore integrazione con Monitoraggio di Azure.
    • Rilevamento anomalie: rileva automaticamente le anomalie delle prestazioni.
    • Risoluzione dei problemi: consente di diagnosticare i problemi nell'app in esecuzione.
    • Monitoraggio: raccoglie informazioni sul modo in cui gli utenti usano l'app e consente di tenere traccia facilmente degli eventi personalizzati.
    • Gap di visibilità: la soluzione locale non ha una soluzione di monitoraggio delle prestazioni dell'applicazione. Application Insights offre un'integrazione semplice con la piattaforma e il codice dell'applicazione.
  • Cache: scegliere se aggiungere cache all'architettura dell'app Web. cache di Azure per Redis è la soluzione di cache primaria di Azure. Si tratta di un archivio dati gestito in memoria basato sul software Redis. Contoso Fiber ha aggiunto cache di Azure per Redis per i motivi seguenti:

    • Velocità e volume: ha velocità effettiva elevata dei dati e letture a bassa latenza per i dati a modifica lenta e di accesso comune.
    • Supporto diversificato: si tratta di un percorso unificato della cache che tutte le istanze dell'app Web possono usare.
    • Archivio dati esterno. I server applicazioni locali hanno eseguito la memorizzazione nella cache locale della macchina virtuale. Questa configurazione non ha scaricato dati molto frequenti e non è stato possibile invalidare i dati.
    • Sessioni non di tiposticky: la cache consente all'app Web di esternalizzare lo stato della sessione e di usare sessioni non di tiposticky. La maggior parte delle app Web Java in esecuzione in locale usa la memorizzazione nella cache sul lato client in memoria. La memorizzazione nella cache sul lato client non viene ridimensionata correttamente e aumenta il footprint di memoria nell'host. Usando cache di Azure per Redis, Contoso Fiber dispone di un servizio cache completamente gestito e scalabile per migliorare la scalabilità e le prestazioni delle applicazioni. Contoso Fiber usava un framework di astrazione della cache (Spring Cache) e richiedeva solo modifiche minime di configurazione per scambiare il provider di cache. Ha consentito loro di passare da un provider Ehcache al provider Redis.
  • Bilanciamento del carico: le applicazioni Web che usano soluzioni PaaS devono usare Frontdoor di Azure, app Azure lication Gateway o entrambi in base all'architettura e ai requisiti dell'app Web. Usare l'albero delle decisioni del servizio di bilanciamento del carico per selezionare il bilanciamento del carico corretto. Contoso Fiber necessita di un servizio di bilanciamento del carico di livello 7 che potrebbe instradare il traffico tra più aree. Contoso Fiber aveva bisogno di un'app Web in più aree per soddisfare lo SLO del 99,9%. Contoso Fiber ha scelto Frontdoor di Azure per i motivi seguenti:

    • Bilanciamento del carico globale: si tratta di un servizio di bilanciamento del carico di livello 7 in grado di instradare il traffico tra più aree.
    • Web application firewall: si integra in modo nativo con Web application firewall di Azure.
    • Flessibilità di routing: consente al team dell'applicazione di configurare l'ingresso deve supportare le modifiche future nell'applicazione.
    • Accelerazione del traffico: usa anycast per raggiungere il punto di presenza di Azure più vicino e trovare la route più veloce per l'app Web.
    • Domini personalizzati: supporta nomi di dominio personalizzati con convalida del dominio flessibile.
    • Probe di integrità: l'applicazione richiede il monitoraggio intelligente dei probe di integrità. Frontdoor di Azure usa le risposte del probe per determinare l'origine migliore per il routing delle richieste client.
    • Supporto per il monitoraggio: supporta i report predefiniti con un dashboard all-in-one per frontdoor e modelli di sicurezza. È possibile configurare avvisi che si integrano con Monitoraggio di Azure. Consente al registro applicazioni di ogni richiesta e probe di integrità non riusciti.
    • Protezione DDoS: include protezione DDoS di livello 3-4 incorporata.
    • Rete per la distribuzione di contenuti: posiziona Contoso Fiber per l'uso di una rete per la distribuzione di contenuti. La rete per la distribuzione di contenuti fornisce l'accelerazione del sito.
  • Web application firewall: usare Web application firewall di Azure per fornire protezione centralizzata da exploit Web e vulnerabilità comuni. Contoso Fiber ha usato Web application firewall di Azure per i motivi seguenti:

    • Protezione globale: offre una migliore protezione globale delle app Web senza sacrificare le prestazioni.
    • Protezione botnet: il team può monitorare e configurare le impostazioni per risolvere i problemi di sicurezza correlati alle botnet.
    • Parità con l'ambiente locale: la soluzione locale era in esecuzione dietro un web application firewall gestito dall'IT.
    • Facilità d'uso: Web Application Firewall si integra con Frontdoor di Azure.
  • Gestione segreti: usare Azure Key Vault se si hanno segreti da gestire in Azure. Contoso Fiber ha usato Key Vault per i motivi seguenti:

    • Crittografia: supporta la crittografia dei dati inattivi e in transito.
    • Supporto delle identità gestite: i servizi dell'applicazione possono usare le identità gestite per accedere all'archivio segreto.
    • Monitoraggio e registrazione: facilita l'accesso di controllo e genera avvisi quando cambiano i segreti archiviati.
    • Integrazione: offre l'integrazione nativa con l'archivio di configurazione di Azure (Configurazione app) e la piattaforma di hosting Web (servizio app).
  • Sicurezza degli endpoint: usare collegamento privato di Azure per accedere alle soluzioni platform-as-a-service tramite un endpoint privato nella rete virtuale. Il traffico tra la rete virtuale e il servizio passa attraverso la rete backbone Microsoft. Contoso Fiber ha scelto collegamento privato per i motivi seguenti:

    • Comunicazione di sicurezza avanzata: consente all'applicazione di accedere privatamente ai servizi nella piattaforma Azure e riduce il footprint di rete degli archivi dati per proteggersi dalla perdita di dati.
    • Sforzo minimo: gli endpoint privati supportano la piattaforma dell'app Web e la piattaforma di database usata dall'app Web. Entrambe le piattaforme rispecchiano le configurazioni locali esistenti per modifiche minime.
  • Sicurezza di rete: usare Firewall di Azure per controllare il traffico in ingresso e in uscita a livello di rete. Usare Azure Bastion per connettersi alle macchine virtuali in modo sicuro senza esporre porte RDP/SSH. Contoso Fiber ha adottato una topologia di rete hub-spoke e voleva inserire i servizi di sicurezza di rete condivisi nell'hub. Firewall di Azure migliora la sicurezza controllando tutto il traffico in uscita dagli spoke per aumentare la sicurezza di rete. Contoso Fiber ha bisogno di Azure Bastion per le distribuzioni sicure da un jump host nella subnet DevOps.

Linee guida per il codice

Per spostare correttamente un'app Web nel cloud, è necessario aggiornare il codice dell'app Web con il modello retry, circuit-breaker e lo schema di progettazione Cache-Aside.

Diagramma che mostra il ruolo dei modelli di progettazione nell'architettura essenziale dell'app Web affidabile.

Figura 3. Ruolo dei modelli di progettazione.

Ogni modello di progettazione offre vantaggi di progettazione del carico di lavoro allineati a uno degli altri pilastri del framework ben progettato. Ecco una panoramica dei modelli da implementare:

  1. Modello di ripetizione dei tentativi: il modello di ripetizione dei tentativi gestisce gli errori temporanei ritentando le operazioni che potrebbero non riuscire in modo intermittente. Implementare questo modello in tutte le chiamate in uscita ad altri servizi di Azure.

  2. Modello di interruttore: il modello interruttore impedisce a un'applicazione di ripetere le operazioni che non sono temporanee. Implementare questo modello in tutte le chiamate in uscita ad altri servizi di Azure.

  3. Modello Cache-Aside: il modello Cache-Aside aggiunge e recupera da una cache più frequentemente di un archivio dati. Implementare questo modello per le richieste al database.

Schema progettuale Affidabilità (RE) Sicurezza (SE) Ottimizzazione costi (CO) Eccellenza operativa (OE) Efficienza delle prestazioni (PE) Supporto dei principi WAF
Modello di ripetizione dei tentativi RE:07
Modello a interruttore RE:03
RE:07
PE:07
PE:11
Modello Cache Aside RE:05
PE:08
PE:12

Implementare il modello di ripetizione dei tentativi

Aggiungere il modello Di ripetizione dei tentativi al codice dell'applicazione per risolvere le interruzioni temporanee del servizio. Queste interruzioni sono denominate errori temporanei. Gli errori temporanei si risolvono in genere entro pochi secondi. Il modello Di ripetizione dei tentativi consente di inviare di nuovo richieste non riuscite. Consente inoltre di configurare i ritardi delle richieste e il numero di tentativi prima che venga concesso l'errore.

Usare Resilience4j, una libreria leggera e di tolleranza di errore, per implementare il modello Di ripetizione dei tentativi in Java. Ad esempio, l'implementazione di riferimento aggiunge il modello Retry decorating the Service Plan Controller's listServicePlans method with Retry annotations .For example, the reference implementation adds the Retry pattern by decorating the Service Plan Controller's listServicePlans method with Retry annotations. Il codice ritenta la chiamata a un elenco di piani di servizio dal database se la chiamata iniziale ha esito negativo. L'implementazione di riferimento configura i criteri di ripetizione dei tentativi, inclusi i tentativi massimi, la durata dell'attesa e le eccezioni da ritentare. I criteri di ripetizione dei tentativi sono configurati in application.properties.

    @GetMapping("/list")
    @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
    @CircuitBreaker(name = SERVICE_PLAN)
    @Retry(name = SERVICE_PLAN)
    public String listServicePlans(Model model) {
        List<serviceplandto> servicePlans = planService.getServicePlans();
        model.addAttribute("servicePlans", servicePlans);
        return "pages/plans/list";
    }

Implementazione dello schema Circuit Breaker

Usare il modello interruttore per gestire le interruzioni del servizio che non sono errori temporanei. Il modello interruttore impedisce a un'applicazione di tentare continuamente di accedere a un servizio non rispondente. Rilascia l'applicazione ed evita di sprecare cicli di CPU in modo che l'applicazione mantenga l'integrità delle prestazioni per gli utenti finali.

Usare Spring Circuit Breaker e la documentazione di Resilience4j per implementare il modello Circuit-Breaker. Ad esempio, l'implementazione di riferimento implementa il pattern Circuit Breaker decorando i metodi con l'attributo Circuit Breaker.

Implementare il modello Cache-Aside

Aggiungere il modello Cache-Aside all'app Web per migliorare la gestione dei dati in memoria. Il modello assegna all'applicazione la responsabilità di gestire le richieste di dati e garantire la coerenza tra la cache e un archivio permanente, ad esempio un database. Riduce i tempi di risposta, migliora la velocità effettiva e riduce la necessità di aumentare la scalabilità. Riduce anche il carico nell'archivio dati primario, migliorando l'affidabilità e l'ottimizzazione dei costi. Per implementare il modello Cache-Aside, seguire queste indicazioni:

  • Configurare l'applicazione per l'uso di una cache. Per abilitare la memorizzazione nella cache, aggiungere il spring-boot-starter-cache pacchetto come dipendenza nel pom.xml file. Questo pacchetto fornisce configurazioni predefinite per la cache Redis.

  • Memorizzare nella cache i dati con esigenze elevate. Applicare il modello Cache-Aside ai dati di necessità elevata per amplificarne l'efficacia. Usare Monitoraggio di Azure per tenere traccia della CPU, della memoria e dell'archiviazione del database. Queste metriche consentono di determinare se è possibile usare uno SKU di database più piccolo dopo aver applicato il modello Cache-Aside. Per memorizzare nella cache dati specifici nel codice, aggiungere l'annotazione @Cacheable . Questa annotazione indica a Spring quali metodi devono avere i risultati memorizzati nella cache.

  • Mantenere aggiornati i dati della cache. Pianificare gli aggiornamenti regolari della cache per la sincronizzazione con le modifiche più recenti del database. Determinare la frequenza di aggiornamento ottimale in base alla volatilità dei dati e alle esigenze degli utenti. Questa procedura garantisce che l'applicazione usi il modello Cache-Aside per fornire sia l'accesso rapido che le informazioni correnti. Le impostazioni predefinite della cache potrebbero non essere adatte all'applicazione Web. È possibile personalizzare queste impostazioni nel application.properties file o nelle variabili di ambiente. Ad esempio, è possibile modificare il spring.cache.redis.time-to-live valore (espresso in millisecondi) per controllare per quanto tempo i dati devono rimanere nella cache prima che vengano rimossi.

  • Garantire la coerenza dei dati. Implementare meccanismi per aggiornare la cache immediatamente dopo qualsiasi operazione di scrittura del database. Usare aggiornamenti basati su eventi o classi di gestione dei dati dedicate per garantire la coerenza della cache. La sincronizzazione coerente della cache con le modifiche del database è fondamentale per il modello Cache-Aside.

Linee guida per la configurazione

Le sezioni seguenti forniscono indicazioni sull'implementazione degli aggiornamenti delle configurazioni. Ogni sezione è allineata a uno o più pilastri del framework ben progettato.

Impostazione Affidabilità (RE) Sicurezza (SE) Ottimizzazione costi (CO) Eccellenza operativa (OE) Efficienza delle prestazioni (PE) Supporto dei principi WAF
Configurare l'autenticazione utente e l'autorizzazione SE:05
OE:10
Implementare le identità gestite SE:05
OE:10
Ambienti di dimensioni corrette CO:05
CO:06
Implementare la scalabilità automatica RE:06
CO:12
PE:05
Automatizzare la distribuzione delle risorse OE:05
Implementare il monitoraggio OE:07
PE:04

Configurare l'autenticazione e l'autorizzazione degli utenti

Quando si esegue la migrazione di applicazioni Web ad Azure, configurare i meccanismi di autenticazione e autorizzazione degli utenti. Seguire questi elementi consigliati:

  • Usare una piattaforma di gestione delle identità. Usare Microsoft Identity Platform per configurare l'autenticazione dell'app Web. Questa piattaforma supporta applicazioni che usano una singola directory di Microsoft Entra, più directory di Microsoft Entra di organizzazioni diverse e identità Microsoft o account di social networking.

    Spring Boot Starter per Microsoft Entra ID semplifica questo processo, usando Spring Security e Spring Boot per semplificare la configurazione. Offre diversi flussi di autenticazione, gestione automatica dei token e criteri di autorizzazione personalizzabili, insieme alle funzionalità di integrazione con i componenti spring cloud. Ciò consente un'integrazione semplice di Microsoft Entra ID e OAuth 2.0 nelle applicazioni Spring Boot senza configurazione manuale della libreria o delle impostazioni.

    Ad esempio, l'implementazione di riferimento usa Microsoft Identity Platform (MICROSOFT Entra ID) come provider di identità per l'app Web. Usa la concessione del codice di autorizzazione OAuth 2.0 per accedere a un utente con un account Microsoft Entra. Il frammento XML seguente definisce le due dipendenze necessarie del flusso di concessione del codice di autorizzazione OAuth 2.0. La dipendenza com.azure.spring: spring-cloud-azure-starter-active-directory abilita l'autenticazione e l'autorizzazione di Microsoft Entra in un'applicazione Spring Boot. La dipendenza org.springframework.boot: spring-boot-starter-oauth2-client supporta l'autenticazione e l'autorizzazione OAuth 2.0 in un'applicazione Spring Boot.

    <dependency>
        <groupid>com.azure.spring</groupid>
        <artifactid>spring-cloud-azure-starter-active-directory</artifactid>
    </dependency>
    <dependency>
        <groupid>org.springframework.boot</groupid>
        <artifactid>spring-boot-starter-oauth2-client</artifactid>
    </dependency>
    
  • Crea una registrazione dell'app. Microsoft Entra ID richiede una registrazione dell'applicazione nel tenant primario. La registrazione dell'applicazione garantisce che gli utenti che ottengono l'accesso all'app Web abbiano identità nel tenant primario. Ad esempio, l'implementazione di riferimento usa Terraform per creare una registrazione dell'app Microsoft Entra ID insieme a un ruolo di Account Manager specifico dell'app.

    resource "azuread_application" "app_registration" {
      display_name     = "${azurecaf_name.app_service.result}-app"
      owners           = [data.azuread_client_config.current.object_id]
      sign_in_audience = "AzureADMyOrg"  # single tenant
    
      app_role {
        allowed_member_types = ["User"]
        description          = "Account Managers"
        display_name         = "Account Manager"
        enabled              = true
        id                   = random_uuid.account_manager_role_id.result
        value                = "AccountManager"
      }
    }
    
  • Applicare l'autorizzazione nell'applicazione. Usare i controlli degli accessi in base al ruolo per assegnare privilegi minimi ai ruoli dell'applicazione. Definire ruoli specifici per azioni utente diverse per evitare sovrapposizioni e garantire chiarezza. Eseguire il mapping degli utenti ai ruoli appropriati e assicurarsi di avere accesso solo alle risorse e alle azioni necessarie. Configurare Spring Security per l'uso di Spring Boot Starter per Microsoft Entra ID. Questa libreria consente l'integrazione con Microsoft Entra ID e consente di assicurarsi che gli utenti siano autenticati in modo sicuro. La configurazione e l'abilitazione di Microsoft Authentication Library (MSAL) fornisce l'accesso a più funzionalità di sicurezza. Queste funzionalità includono la memorizzazione nella cache dei token e l'aggiornamento automatico dei token.

    Ad esempio, l'implementazione di riferimento crea ruoli dell'app che riflettono i tipi di ruoli utente nel sistema di gestione degli account di Contoso Fiber. I ruoli si traducono in autorizzazioni durante l'autorizzazione. Esempi di ruoli specifici dell'app in CAMS includono il responsabile dell'account, il rappresentante del supporto di Livello 1 (L1) e il rappresentante di Field Service. Il ruolo Account Manager ha le autorizzazioni per aggiungere nuovi utenti e clienti di app. Un rappresentante di Field Service può creare ticket di supporto. L'attributo limita l'accesso PreAuthorize a ruoli specifici.

        @GetMapping("/new")
        @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
        public String newAccount(Model model) {
            if (model.getAttribute("account") == null) {
                List<ServicePlan> servicePlans = accountService.findAllServicePlans();
                ServicePlan defaultServicePlan = servicePlans.stream().filter(sp -> sp.getIsDefault() == true).findFirst().orElse(null);
                NewAccountRequest accountFormData = new NewAccountRequest();
                accountFormData.setSelectedServicePlanId(defaultServicePlan.getId());
                model.addAttribute("account", accountFormData);
                model.addAttribute("servicePlans", servicePlans);
            }
            model.addAttribute("servicePlans", accountService.findAllServicePlans());
            return "pages/account/new";
        }
        ...
    

    Per l'integrazione con Microsoft Entra ID, l'implementazione di riferimento usa il flusso di concessione del codice di autorizzazione OAuth 2.0. Questo flusso consente a un utente di accedere con un account Microsoft. Il frammento di codice seguente illustra come configurare per l'uso dell'ID SecurityFilterChain Entra Di Microsoft per l'autenticazione e l'autorizzazione.

    @Configuration(proxyBeanMethods = false)
    @EnableWebSecurity
    @EnableMethodSecurity
    public class AadOAuth2LoginSecurityConfig {
        @Bean
        SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
            http.apply(AadWebApplicationHttpSecurityConfigurer.aadWebApplication())
                .and()
                    .authorizeHttpRequests()
                .requestMatchers(EndpointRequest.to("health")).permitAll()
                .anyRequest().authenticated()
                .and()
                    .logout(logout -> logout
                                .deleteCookies("JSESSIONID", "XSRF-TOKEN")
                                .clearAuthentication(true)
                                .invalidateHttpSession(true));
            return http.build();
        }
    }
    ...
    
  • Preferisce l'accesso temporaneo all'archiviazione. Usare le autorizzazioni temporanee per proteggersi da accessi non autorizzati e violazioni, ad esempio firme di accesso condiviso (SASs). Usare sas di delega utente per ottimizzare la sicurezza quando si concede l'accesso temporaneo. Si tratta dell'unica firma di accesso condiviso che usa le credenziali di Microsoft Entra ID e non richiede una chiave dell'account di archiviazione permanente.

  • Applicare l'autorizzazione in Azure. Usare il controllo degli accessi in base al ruolo di Azure per assegnare privilegi minimi alle identità utente. Il controllo degli accessi in base al ruolo di Azure determina quali identità delle risorse di Azure possono accedere, cosa possono fare con queste risorse e quali aree hanno accesso.

  • Evitare autorizzazioni con privilegi elevati permanenti. Usare Microsoft Entra Privileged Identity Management per concedere l'accesso JIT per le operazioni con privilegi. Ad esempio, gli sviluppatori spesso necessitano dell'accesso a livello di amministratore per creare/eliminare database, modificare gli schemi di tabella e modificare le autorizzazioni utente. Con l'accesso JIT, le identità utente ricevono autorizzazioni temporanee per eseguire attività con privilegi.

Implementare le identità gestite

Usare identità gestite per tutti i servizi di Azure che supportano le identità gestite. Un'identità gestita consente alle risorse di Azure (identità del carico di lavoro) di eseguire l'autenticazione e interagire con altri servizi di Azure senza gestire le credenziali. I sistemi ibridi e legacy possono mantenere le soluzioni di autenticazione locali per semplificare la migrazione, ma devono passare alle identità gestite il prima possibile. Per implementare le identità gestite, seguire queste indicazioni:

  • Selezionare il tipo corretto di identità gestita. Preferisce le identità gestite assegnate dall'utente quando si hanno due o più risorse di Azure che necessitano dello stesso set di autorizzazioni. Questa configurazione è più efficiente rispetto alla creazione di identità gestite assegnate dal sistema per ognuna di queste risorse e l'assegnazione delle stesse autorizzazioni a tutte. In caso contrario, usare le identità gestite assegnate dal sistema.

  • Configurare i privilegi minimi. Usare il controllo degli accessi in base al ruolo di Azure per concedere solo le autorizzazioni critiche per le operazioni, ad esempio le azioni CRUD nei database o l'accesso ai segreti. Le autorizzazioni di identità del carico di lavoro sono persistenti, quindi non è possibile fornire autorizzazioni JUST-In-Time o a breve termine per le identità del carico di lavoro. Se il controllo degli accessi in base al ruolo di Azure non copre uno scenario specifico, integrare il controllo degli accessi in base al ruolo di Azure con i criteri di accesso a livello di servizio di Azure.

  • Proteggere i segreti rimanenti. Archiviare eventuali segreti rimanenti in Azure Key Vault. Caricare i segreti da Key Vault all'avvio dell'applicazione anziché durante ogni richiesta HTTP. L'accesso ad alta frequenza all'interno delle richieste HTTP può superare i limiti delle transazioni di Key Vault. Archiviare le configurazioni dell'applicazione nella configurazione di app Azure.

Ambienti di dimensioni corrette

Usare i livelli di prestazioni (SKU) dei servizi di Azure che soddisfano le esigenze di ogni ambiente senza eccesso. Per adattare le dimensioni degli ambienti, seguire queste indicazioni:

  • Stimare i costi. Usare il calcolatore prezzi di Azure per stimare il costo di ogni ambiente.

  • Ottimizzare i costi per gli ambienti di produzione. Gli ambienti di produzione necessitano di SKU che soddisfino i contratti di servizio (SLA), le funzionalità e la scalabilità necessarie per la produzione. Monitorare continuamente l'utilizzo delle risorse e regolare gli SKU per allinearsi alle esigenze di prestazioni effettive.

  • Ottimizzare i costi per gli ambienti di preproduzione. Gli ambienti di preproduzione devono usare risorse a basso costo, disabilitare i servizi non necessarie e applicare sconti come i prezzi di sviluppo/test di Azure. Assicurarsi che gli ambienti di preproduzione siano sufficientemente simili alla produzione per evitare di introdurre rischi. Questo equilibrio garantisce che i test rimangano efficaci senza incorrere in costi non necessari.

  • Definire GLI SKU usando l'infrastruttura come codice (IaC). Implementare IaC per selezionare e distribuire dinamicamente gli SKU corretti in base all'ambiente. Questo approccio migliora la coerenza e semplifica la gestione.

Ad esempio, l'implementazione di riferimento ha un parametro facoltativo che distribuisce SKU diversi. Un parametro di ambiente indica al modello Terraform di selezionare gli SKU di sviluppo.

azd env set APP_ENVIRONMENT prod

Implementare la scalabilità automatica

La scalabilità automatica garantisce che un'app Web rimanga resiliente, reattiva e in grado di gestire in modo efficiente i carichi di lavoro dinamici. Per implementare la scalabilità automatica, seguire queste indicazioni:

  • Automatizzare la scalabilità orizzontale. Usare la scalabilità automatica di Azure per automatizzare la scalabilità orizzontale negli ambienti di produzione. Configurare le regole di scalabilità automatica per aumentare il numero di istanze in base alle metriche delle prestazioni chiave, in modo che l'applicazione possa gestire carichi variabili.

  • Perfezionare i trigger di ridimensionamento. Iniziare con l'utilizzo della CPU come trigger di ridimensionamento iniziale se non si ha familiarità con i requisiti di ridimensionamento dell'applicazione. Perfezionare i trigger di ridimensionamento per includere altre metriche, ad esempio RAM, velocità effettiva di rete e I/O del disco. L'obiettivo è corrispondere al comportamento dell'applicazione Web per ottenere prestazioni migliori.

  • Fornire un buffer di scalabilità orizzontale. Impostare le soglie di ridimensionamento da attivare prima di raggiungere la capacità massima. Ad esempio, configurare il ridimensionamento in modo che si verifichi con un utilizzo della CPU dell'85% anziché attendere fino a raggiungere il 100%. Questo approccio proattivo consente di mantenere le prestazioni ed evitare potenziali colli di bottiglia.

Automatizzare la distribuzione delle risorse

Usare l'automazione per distribuire e aggiornare le risorse e il codice di Azure in tutti gli ambienti. Seguire questi elementi consigliati:

  • Usare l'infrastruttura come codice. Distribuire l'infrastruttura come codice tramite pipeline di integrazione continua e recapito continuo (CI/CD). Azure include modelli Bicep, ARM (JSON) e Terraform predefiniti per ogni risorsa di Azure.

  • Usare una pipeline di integrazione continua/distribuzione continua (CI/CD). Usare una pipeline CI/CD per distribuire il codice dal controllo del codice sorgente ai vari ambienti, ad esempio test, gestione temporanea e produzione. Usare Azure Pipelines se si usa Azure DevOps o GitHub Actions per i progetti GitHub.

  • Integrare unit test. Classificare in ordine di priorità l'esecuzione e il passaggio di tutti gli unit test all'interno della pipeline prima di qualsiasi distribuzione alle servizio app. Incorporare strumenti di qualità del codice e copertura come SonarQube per ottenere una copertura completa dei test.

  • Adottare un framework fittizio. Per i test che coinvolgono endpoint esterni, usare framework fittizi. Questi framework consentono di creare endpoint simulati. Eliminano la necessità di configurare endpoint esterni reali e garantire condizioni di test uniformi in ambienti diversi.

  • Eseguire analisi di sicurezza. Usare test di sicurezza delle applicazioni statici (SAST) per individuare i difetti di sicurezza e gli errori di codifica nel codice sorgente. Inoltre, eseguire l'analisi della composizione software (SCA) per esaminare librerie e componenti di terze parti per individuare i rischi per la sicurezza. Gli strumenti per queste analisi sono facilmente integrati sia in GitHub che in Azure DevOps.

Configurare il monitoraggio

Implementare il monitoraggio delle applicazioni e della piattaforma per migliorare l'eccellenza operativa e l'efficienza delle prestazioni dell'app Web. Per implementare il monitoraggio, seguire queste raccomandazioni:

  • Raccogliere i dati di telemetria dell'applicazione. Usare l'strumentazione automatica in app Azure lication Insights per raccogliere dati di telemetria dell'applicazione, ad esempio velocità effettiva delle richieste, durata media delle richieste, errori e monitoraggio delle dipendenze, senza modifiche al codice. Spring Boot registra diverse metriche di base in Application Insights, ad esempio java virtual machine (JVM), CPU, Tomcat e altri. Application Insights raccoglie automaticamente dai framework di registrazione, ad esempio Log4j e Logback. Ad esempio, l'implementazione di riferimento usa Application Insights abilitato tramite Terraform come parte della configurazione del app_settings servizio app. (vedere il codice seguente).

    app_settings = {
        APPLICATIONINSIGHTS_CONNECTION_STRING = var.app_insights_connection_string
        ApplicationInsightsAgent_EXTENSION_VERSION = "~3"
        ...
    }
    

    Per altre informazioni, vedi:

  • Creare metriche dell'applicazione personalizzate. Implementare la strumentazione basata su codice per acquisire dati di telemetria dell'applicazione personalizzati aggiungendo Application Insights SDK e usando la relativa API.

  • Monitorare la piattaforma. Abilitare la diagnostica per tutti i servizi supportati e inviare la diagnostica alla stessa destinazione dei log applicazioni per la correlazione. I servizi di Azure creano automaticamente i log della piattaforma, ma li archivia solo quando si abilita la diagnostica. Abilitare le impostazioni di diagnostica per ogni servizio che supporta la diagnostica. L'implementazione di riferimento usa Terraform per abilitare la diagnostica di Azure in tutti i servizi supportati. Il codice Terraform seguente configura le impostazioni di diagnostica per il servizio app.

    # Configure Diagnostic Settings for App Service
    resource "azurerm_monitor_diagnostic_setting" "app_service_diagnostic" {
      name                           = "app-service-diagnostic-settings"
      target_resource_id             = azurerm_linux_web_app.application.id
      log_analytics_workspace_id     = var.log_analytics_workspace_id
      #log_analytics_destination_type = "AzureDiagnostics"
    
      enabled_log {
        category_group = "allLogs"
    
      }
    
      metric {
        category = "AllMetrics"
        enabled  = true
      }
    }
    

Distribuire l'implementazione di riferimento

L'implementazione di riferimento guida gli sviluppatori attraverso una migrazione simulata da un'applicazione Java locale ad Azure, evidenziando le modifiche necessarie durante la fase di adozione iniziale. In questo esempio viene usata un'applicazione di app Web CAMS (Customer Account Management System) per la società fittizia Contoso Fiber. Contoso Fiber ha impostato gli obiettivi seguenti per l'applicazione Web:

  • Implementare modifiche al codice a basso costo e alto valore
  • Raggiungere un obiettivo del livello di servizio (SLO) del 99,9%
  • Adottare procedure DevOps
  • Creare ambienti ottimizzati per i costi
  • Migliorare l'affidabilità e la sicurezza

Contoso Fiber ha determinato che l'infrastruttura locale non era una soluzione conveniente per soddisfare questi obiettivi. Hanno deciso che la migrazione dell'applicazione Web CAMS ad Azure è stata il modo più conveniente per raggiungere gli obiettivi immediati e futuri. L'architettura seguente rappresenta lo stato finale dell'implementazione del modello Reliable Web App di Contoso Fiber.

Diagramma che mostra l'architettura dell'implementazione di riferimento.Figura 4. Architettura dell'implementazione di riferimento. Scaricare un file di Visio di questa architettura.