Questo articolo illustra come applicare il modello Reliable Web App. Il modello Reliable Web App è un set di principi e tecniche di implementazione che definiscono come modificare le app Web (replatform) durante la migrazione al cloud. È incentrato sugli aggiornamenti minimi del codice che è necessario apportare per avere successo nel cloud.
Per facilitare l'applicazione di queste linee guida, è disponibile un'implementazione di riferimento del modello Reliable Web App che è possibile distribuire.
Architettura dell'implementazione di riferimento. Scaricare un file di Visio di questa architettura.
Le indicazioni seguenti usano l'implementazione di riferimento come esempio in tutto. Per pianificare un'implementazione del modello Reliable Web App, seguire questa procedura:
Definire gli obiettivi aziendali
Il passaggio iniziale per la transizione al cloud computing consiste nell'articolato degli obiettivi aziendali. Il modello Reliable Web App evidenzia l'importanza di impostare obiettivi immediati e futuri per l'applicazione Web. Questi obiettivi influenzano la scelta dei servizi cloud e l'architettura dell'applicazione Web nel cloud.
Esempio: l'azienda fittizia Relecloud vende ticket tramite l'applicazione Web locale. Relecloud ha una previsione di vendita positiva e prevede un aumento della domanda sull'app Web di creazione di ticket. Per soddisfare questa domanda, hanno definito gli obiettivi per l'applicazione Web:
- 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
L'infrastruttura locale di Relecloud non era una soluzione conveniente per raggiungere questi obiettivi. Quindi, hanno deciso che la migrazione dell'applicazione Web ad Azure è stata il modo più conveniente per raggiungere gli obiettivi immediati e futuri.
Scegliere i servizi gestiti 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.
Esempio: prima del passaggio al cloud, l'app Web di ticketing di Relecloud era un'app locale monolitica ASP.NET. È stato eseguito in due macchine virtuali e aveva un database di Microsoft SQL Server. 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 applicativa
Scegliere la piattaforma di hosting dell'applicazione migliore per l'app Web. Azure offre molte opzioni di calcolo diverse per soddisfare un'ampia gamma di requisiti delle app Web. Per informazioni sulle opzioni di restringimento, vedere l'albero delle decisioni di calcolo di Azure.
Esempio: Relecloud ha scelto app Azure Servizio come piattaforma dell'applicazione per i motivi seguenti:
Contratto di servizio elevato: ha un contratto di servizio elevato che soddisfa lo SLO dell'ambiente di produzione del 99,9%.
Riduzione del sovraccarico di gestione: si tratta di una soluzione completamente gestita che gestisce il ridimensionamento, i controlli di integrità e il bilanciamento del carico.
Supporto .NET: supporta la versione di .NET in cui è scritta l'applicazione.
Funzionalità di containerizzazione: l'app Web può convergere nel cloud senza contenitori, ma la piattaforma dell'applicazione supporta anche la containerizzazione senza modificare i servizi di Azure
Scalabilità automatica: l'app Web può aumentare, ridurre e ridurre automaticamente le prestazioni in base al traffico e alle impostazioni dell'utente.
Gestione delle identità
Scegliere la soluzione di gestione delle identità migliore per l'app Web. Per altre informazioni, vedere Confrontare le soluzioni di gestione delle identità e i metodi di autenticazione.
Esempio: Relecloud 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
Scegliere il database migliore per l'app Web. Per informazioni su come restringere le opzioni, vedere l'albero delle decisioni dell'archivio dati di Azure.
Esempio: l'app Web ha usato SQL Server locale e Relecloud voleva usare lo schema del database, le stored procedure e le funzioni esistenti. Diversi prodotti SQL sono disponibili in Azure, ma Relecloud ha scelto database SQL di Azure per i motivi seguenti:
Affidabilità: il livello per utilizzo generico offre un contratto di servizio elevato e ridondanza in più aree. Può supportare un carico utente elevato.
Riduzione del sovraccarico di gestione: fornisce un'istanza del database SQL gestita.
Supporto per la migrazione: supporta la migrazione del database da SQL Server locale.
Coerenza con le configurazioni locali: supporta le stored procedure, le funzioni e le viste esistenti.
Resilienza: supporta i backup e il ripristino temporizzato.
Esperienza e rielaborazione minima: database SQL sfrutta le competenze interne e richiede un lavoro minimo da adottare.
Monitoraggio delle prestazioni delle applicazioni
Scegliere un monitoraggio delle prestazioni dell'applicazione per l'app Web. Application Insights è la soluzione di gestione delle prestazioni delle applicazioni (APM) nativa di Azure. Si tratta di una funzionalità della soluzione di monitoraggio di Azure, Monitoraggio di Azure.
Esempio: Relecloud 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.
Esempio: il carico dell'app Web di Relecloud è fortemente asimmetrico rispetto alla visualizzazione dei concerti e dei dettagli delle sedi. È stato aggiunto cache di Azure per Redis per i motivi seguenti:
Riduzione del sovraccarico di gestione: si tratta di un servizio completamente gestito.
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 per tutte le istanze dell'app Web da 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: l'esternalizzazione dello stato della sessione supporta sessioni non di tipostick.
Bilanciamento del carico
Scegliere il servizio di bilanciamento del carico migliore per l'app Web. Azure offre diversi servizi di bilanciamento del carico. Per informazioni su come restringere le opzioni, vedi Scegliere il servizio di bilanciamento del carico migliore per l'app.
Esempio: Relecloud necessita di un servizio di bilanciamento del carico di livello 7 che potrebbe instradare il traffico tra più aree. Relecloud aveva bisogno di un'app Web in più aree per soddisfare lo SLO del 99,9%. Relecloud 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 Relecloud per usare una rete per la distribuzione di contenuti. La rete per la distribuzione di contenuti fornisce l'accelerazione del sito.
Web application firewall
Scegliere un web application firewall per proteggere l'app Web da attacchi Web. Web application firewall (WAF) di Azure è web application firewall di Azure e offre una protezione centralizzata da exploit Web e vulnerabilità comuni.
Esempio: Relecloud necessario per proteggere l'app Web da attacchi Web. Sono stati usati 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 per risolvere i problemi di sicurezza delle 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.
Archiviazione della configurazione
Scegliere se aggiungere l'archiviazione di configurazione dell'app all'app Web. app Azure Configurazione è un servizio per la gestione centralizzata delle impostazioni dell'applicazione e dei flag di funzionalità. Esaminare Configurazione app procedure consigliate per decidere se questo servizio è adatto per l'app.
Esempio: Relecloud voleva sostituire la configurazione basata su file con un archivio di configurazione centrale che si integra con la piattaforma e il codice dell'applicazione. Sono stati aggiunti Configurazione app all'architettura per i motivi seguenti:
Flessibilità: supporta i flag di funzionalità. I flag di funzionalità consentono agli utenti di acconsentire esplicitamente alle funzionalità di anteprima anticipata in un ambiente di produzione senza ridistribuire l'app.
Supporta la pipeline Git: origine della verità per i dati di configurazione necessari per essere un repository Git. Pipeline necessaria per aggiornare i dati nell'archivio di configurazione centrale.
Supporta le identità gestite: supporta le identità gestite per semplificare e proteggere la connessione all'archivio di configurazione.
Gestione segreti
Usare Azure Key Vault se si hanno segreti da gestire in Azure. È possibile incorporare Key Vault nelle app .NET usando l'oggetto ConfigurationBuilder.
Esempio: l'app Web locale di Relecloud archivia i segreti nei file di configurazione del codice, ma è una procedura di sicurezza migliore per esternalizzare i segreti. Sebbene le identità gestite siano la soluzione preferita per la connessione alle risorse di Azure, Relecloud aveva segreti dell'applicazione necessari per la gestione. Relecloud ha usato Key Vault per i motivi seguenti:
Crittografia: supporta la crittografia dei dati inattivi e in transito.
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).
Archiviazione soluzione
Scegliere la soluzione di archiviazione migliore per l'app Web. Per altre informazioni, vedere Esaminare le opzioni di archiviazione.
Esempio: in locale, l'app Web aveva l'archiviazione su disco montata in ogni server Web, ma il team voleva usare una soluzione di archiviazione dati esterna. Relecloud ha scelto Archiviazione BLOB di Azure per i motivi seguenti:
Accesso sicuro: l'app Web può eliminare gli endpoint per l'accesso all'archiviazione esposta alla rete Internet pubblica con accesso anonimo.
Crittografia: crittografa i dati inattivi e in transito.
Resilienza: supporta l'archiviazione con ridondanza della zona. L'archiviazione con ridondanza della zona replica i dati in modo sincrono tra tre zone di disponibilità di Azure nell'area primaria. Ogni zona di disponibilità si trova in una posizione fisica separata con alimentazione, raffreddamento e rete indipendenti. Questa configurazione deve rendere resilienti le immagini di creazione di ticket contro la perdita.
Sicurezza degli endpoint
Scegliere di abilitare l'accesso privato solo ai servizi di Azure. collegamento privato di Azure fornisce l'accesso 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.
Esempio: Relecloud usato 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
Scegliere se aggiungere servizi di sicurezza di rete alle reti virtuali. Firewall di Azure è con stato, firewall di rete che controlla il traffico di rete. Azure Bastion consente di connettersi in modo sicuro alle macchine virtuali senza esporre porte RDP/SSH.
Esempio: Relecloud 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. Relecloud ha richiesto Azure Bastion per le distribuzioni sicure da un jump host nella subnet DevOps.
Scegliere l'architettura corretta
Dopo aver definito i mezzi disponibili per l'app Web e aver selezionato i servizi cloud migliori, è necessario determinare l'architettura migliore per l'app Web. L'architettura deve supportare i requisiti aziendali, i requisiti tecnici e lo SLO.
Scegliere la ridondanza dell'architettura
Gli obiettivi aziendali determinano il livello di ridondanza dell'infrastruttura e dei dati necessari per l'app Web. Lo SLO dell'app Web offre una buona baseline per comprendere i requisiti di ridondanza. Calcolare il contratto di servizio composito per tutte le dipendenze nel percorso critico di disponibilità. Le dipendenze devono includere servizi di Azure e soluzioni non Microsoft.
Assegnare una stima della disponibilità per ogni dipendenza. I contratti di servizio forniscono un buon punto di partenza, ma i contratti di servizio non sono responsabili del codice, delle strategie di distribuzione e delle decisioni di connettività dell'architettura.
Esempio: Relecloud ha identificato i servizi nel percorso critico di disponibilità. Sono stati usati contratti di servizio di Azure per le stime della disponibilità. In base al calcolo del contratto di servizio composito, Relecloud aveva bisogno di un'architettura in più aree per soddisfare lo SLO del 99,9%.
Scegliere una topologia di rete
Scegliere la topologia di rete appropriata per i requisiti web e di rete. Una topologia di rete hub-spoke è una configurazione standard in Azure. Offre vantaggi in termini di costi, gestione e sicurezza. Supporta anche opzioni di connettività ibrida alle reti locali.
Esempio: Relecloud ha scelto una topologia di rete hub-spoke per aumentare la sicurezza della distribuzione in più aree a costi ridotti e sovraccarico di gestione.
Scegliere la ridondanza dei dati
Garantire l'affidabilità dei dati distribuendola tra aree e zone di disponibilità di Azure; maggiore è la loro separazione geografica, maggiore è l'affidabilità.
Impostare un obiettivo del punto di ripristino (RPO). RPO definisce la perdita massima di dati tollerabile durante un'interruzione, guidando la frequenza di replica dei dati. Ad esempio, un RPO di un'ora significa accettare fino a un'ora di perdita di dati recente.
Implementare la replica dei dati. Allineare la replica dei dati con l'architettura e l'RPO. Azure supporta in genere la replica sincrona all'interno delle zone di disponibilità. Usare più zone per migliorare facilmente l'affidabilità. Per le app Web in più aree in una configurazione attiva-passiva, replicare i dati nell'area passiva in base all'RPO dell'app Web, assicurando che la frequenza di replica superi l'RPO. Le configurazioni attive-attive richiedono la sincronizzazione dei dati quasi in tempo reale tra aree, che potrebbero richiedere modifiche al codice.
Creare un piano di failover. Sviluppare un piano di failover (ripristino di emergenza) che delinea le strategie di risposta alle interruzioni, determinate da tempi di inattività o perdita di funzionalità. Specificare gli obiettivi del tempo di ripristino (RTO) per il tempo di inattività massimo accettabile. Verificare che il processo di failover sia più rapido di RTO. Decidere i meccanismi di failover automatizzati o manuali per coerenza e controllo e descrivere in dettaglio il ritorno al processo di operazioni normali. Testare il piano di failover per garantire l'efficacia.
Passaggio successivo
Questo articolo ha illustrato come pianificare un'implementazione del modello di app Web Reliable. Il passaggio successivo consiste nell'applicare le tecniche di implementazione del modello Reliable Web App.