Questo articolo descrive come distribuire applicazioni Web cruciali usando il servizio app di Azure. L'architettura usa il modello di app Web affidabile come punto di partenza. Usare questa architettura se si ha un carico di lavoro legacy e si vuole adottare servizi PaaS (Platform as a Service).
modello di app Web Reliable per .NET fornisce indicazioni per l'aggiornamento o la ripiattaformazione delle app Web spostate nel cloud. Questo approccio consente di ridurre al minimo le modifiche al codice necessarie e di specificare come destinazione un obiettivo del livello di servizio (SLO) di 99.9%. I carichi di lavoro cruciali hanno requisiti di affidabilità e disponibilità elevati. Per raggiungere uno SLO di 99,95%, 99,99%o superiore, è necessario applicare modelli di progettazione cruciali supplementari e rigore operativo. Questo articolo descrive le principali aree tecniche e come introdurre e implementare procedure di progettazione cruciali.
Nota
Le linee guida contenute in questo articolo si basano sulla metodologia di progettazione e sulle procedure consigliate nella serie di di carico di lavoro cruciali diWell-Architected Framework.
Le sezioni seguenti descrivono come:
- Esaminare un carico di lavoro esistente per comprendere i componenti, i flussi utente e di sistema e i requisiti di disponibilità e scalabilità.
- Sviluppare e implementare un'architettura di unità di scala per ottimizzare la scalabilità end-to-end tramite la compartimentazione e standardizzare il processo di aggiunta e rimozione della capacità.
- Implementare unità di scala temporanee senza stato o indicatori di distribuzione per abilitare la scalabilità e le distribuzioni senza tempi di inattività.
- Determinare se è possibile suddividere il carico di lavoro in componenti per prepararsi alla scalabilità. I singoli componenti sono necessari per la scalabilità e la disaccoppiamento dei flussi.
- Prepararsi per distribuzione globale distribuendo un carico di lavoro in più aree di Azure per migliorare la prossimità al cliente e prepararsi a potenziali interruzioni a livello di area.
- Separare i componenti e implementare un'architettura basata su eventi.
Architettura
Il diagramma seguente applica le considerazioni precedenti al modello di app Web affidabile .
Scaricare un file di Visio di questa architettura.
La casella rossa rappresenta un'unità di scala con servizi che si adattano insieme. Per ridimensionarli in modo efficace, ottimizzare le dimensioni, lo SKU e gli indirizzi IP disponibili di ogni servizio. Ad esempio, il numero massimo di richieste fornite da Configurazione app di Azure è correlato al numero di richieste al secondo fornite da un'unità di scala. Quando si aggiunge più capacità in un'area, è necessario aggiungere anche altre unità di scala singole.
Queste singole unità di scala non hanno dipendenze l'una dall'altra e comunicano solo con i servizi condivisi all'esterno della singola unità di scala. È possibile usare queste unità di scala in un distribuzione blu-verde implementando nuove unità di scala, verificando che funzionino correttamente e spostando gradualmente il traffico di produzione su di essi.
In questo scenario si considerano le unità di scala come temporanee, che ottimizzano i processi di implementazione e offrono scalabilità all'interno e tra aree. Quando si usa questo approccio, è consigliabile archiviare i dati solo nel database perché il database viene replicato nell'area secondaria. Se è necessario archiviare i dati nell'unità di scala, è consigliabile usare Cache Redis di Azure per l'archiviazione nell'unità di scala. Se un'unità di scala deve essere abbandonata, il ripopolamento della cache potrebbe aumentare la latenza, ma non causa interruzioni.
Application Insights viene escluso dall'unità di scala. Escludere i servizi che archiviano o monitorano i dati. Separarli nel proprio gruppo di risorse con il proprio ciclo di vita.
Quando si sostituisce un'unità di scala o ne si distribuisce una nuova, mantenere i dati cronologici e usare un'istanza per ogni area.
Per altre informazioni, vedere Progettazione di applicazioni di carichi di lavoro cruciali in Azure.
Componenti
Questa architettura usa i componenti seguenti.
- servizio app è la piattaforma di hosting dell'applicazione.
- Cache Redis di Azure memorizza nella cache le richieste.
- Configurazione app archivia le impostazioni di configurazione.
- SQL di Azure è il database back-end.
- di Application Insights ottiene i dati di telemetria dall'applicazione.
Alternative
Nel modello di app Web affidabile è possibile:
- usare il servizio Azure Kubernetes anziché il servizio app. Questa opzione funziona bene per carichi di lavoro complessi con un numero elevato di microservizi. Il servizio Azure Kubernetes offre un maggiore controllo sull'infrastruttura sottostante e consente configurazioni multilitte complesse.
- Containerizzare il carico di lavoro. Il servizio app supporta la containerizzazione, ma in questo esempio il carico di lavoro non è in contenitori. Usare i contenitori per aumentare l'affidabilità e la portabilità.
Per altre informazioni, vedere considerazioni sulla piattaforma dell'applicazione per carichi di lavoro cruciali in Azure.
Considerazioni sulla disponibilità elevata
Indipendentemente dalla piattaforma dell'applicazione scelta, è consigliabile classificare in ordine di priorità l'uso delle zone di disponibilità per i carichi di lavoro di produzione.
set di disponibilità distribuire le distribuzioni tra più domini di errore e di aggiornamento all'interno di un data center. zone di disponibilità distribuire distribuzioni tra singoli data center all'interno di un'area di Azure. Le zone di disponibilità vengono spesso classificate in ordine di priorità, ma la strategia usata dipende dal carico di lavoro. Ad esempio, i carichi di lavoro con distinzione tra latenza o chatty possono trarre vantaggio dalla definizione delle priorità dei set di disponibilità. Se si distribuisce il carico di lavoro tra zone di disponibilità, può aumentare la latenza e i costi per il traffico tra zone. Quando si usano le zone di disponibilità, assicurarsi che tutti i servizi in un'unità di scala li supportino. Tutti i servizi nel modello di app Web reliable supportano le zone di disponibilità.
Scegliere la piattaforma dati
La piattaforma di database scelta influisce sull'architettura complessiva del carico di lavoro, in particolare sul supporto della configurazione attiva-attiva o passiva attiva della piattaforma. Il modello di app Web affidabile usa Azure SQL, che non supporta in modo nativo le distribuzioni attive-attive con operazioni di scrittura in più di un'istanza. In questa configurazione la piattaforma dati è limitata a una strategia attiva-passiva. Una strategia attiva-attiva (parziale) a livello di applicazione è possibile se sono presenti repliche di sola lettura in tutte le aree e si scrive solo in una singola area.
Più database sono comuni in architetture complesse, ad esempio architetture di microservizi che dispongono di un database per ogni servizio. Più database consentono l'adozione di un database di scrittura multi-primario, ad esempio Azure Cosmos DB, che migliora la disponibilità elevata e la bassa latenza. La latenza tra aree può creare limitazioni. È fondamentale considerare requisiti non funzionali e fattori come coerenza, operabilità, costi e complessità. Consentire ai singoli servizi di usare archivi dati separati e tecnologie di dati specializzate per soddisfare i requisiti specifici. Per altre informazioni, vedere considerazioni sulla piattaforma dati per carichi di lavoro cruciali in Azure.
Definire un modello di integrità
In carichi di lavoro multilitieri complessi distribuiti in più data center e aree geografiche, è necessario definire un modello di integrità.
Per definire un modello di integrità:
- Definire flussi utente e di sistema
- Specificare e comprendere le dipendenze tra i servizi
- Comprendere l'effetto che le interruzioni o una riduzione delle prestazioni su uno dei servizi possono avere sul carico di lavoro complessivo
- Monitorare e visualizzare l'esperienza dei clienti per abilitare il monitoraggio appropriato e migliorare le azioni manuali e automatizzate.
Il diagramma precedente mostra come un'interruzione o una riduzione delle prestazioni di un singolo componente, ad esempio Configurazione app, può causare un potenziale calo delle prestazioni per il cliente. Quando si separano i componenti in unità di scala, è possibile interrompere l'invio del traffico alla parte interessata dell'applicazione, ad esempio un'unità di scala interessata o l'area completa.
I criteri per determinare l'integrità di un'unità di scala sono definiti nel modello di integrità. Questo modello viene quindi connesso all'endpoint di integrità dell'unità di scala, che consente al servizio di bilanciamento del carico globale di eseguire query sullo stato di integrità di un'unità di scala e di usare tali informazioni per le decisioni di routing.
Per altre informazioni, vedere modellazione dell'integrità e osservabilità dei carichi di lavoro cruciali in Azure.
Sicurezza e rete
I carichi di lavoro cruciali hanno requisiti di rete e sicurezza rigorosi. Applicare la diligenza soprattutto ai carichi di lavoro migrati da un ambiente locale perché non tutte le procedure di sicurezza locali stabilite si traducono in un ambiente cloud. È consigliabile valutare nuovamente i requisiti di sicurezza durante la migrazione dell'applicazione.
L'identità è spesso il perimetro di sicurezza principale per i modelli nativi del cloud. I clienti aziendali potrebbero avere bisogno di misure di sicurezza più sostanziali. Per soddisfare i requisiti di sicurezza di rete, i servizi PaaS di Azure possono usare il collegamento privato di Azure per implementare la rete come perimetro di sicurezza. Collegamento privato consente di garantire che i servizi siano accessibili solo dall'interno di una rete virtuale. Tutti i servizi sono quindi accessibili solo tramite endpoint privati. Il diagramma seguente mostra come l'unico endpoint pubblico con connessione Internet sia Frontdoor di Azure.
Affinché il modello di app Web affidabile configuri una rete come perimetro di sicurezza, deve usare:
- Collegamento privato per tutti i servizi che lo supportano.
- Frontdoor di Azure Premium come unico endpoint pubblico con connessione Internet.
- Jumpbox per accedere ai servizi tramite Azure Bastion.
- Agenti di compilazione self-hosted che possono accedere ai servizi.
Un altro requisito di rete comune per le applicazioni cruciali consiste nel limitare il traffico in uscita per impedire l'esfiltrazione dei dati. Limitare il traffico in uscita instradando un firewall di Azure tramite un dispositivo firewall appropriato. Filtrare quindi il traffico usando il dispositivo. L'architettura di base mission-critical di Azure con i controlli di rete usa un firewall e un collegamento privato.
Distribuzione e test
Il tempo di inattività causato da versioni errate o da errori umani può essere un problema per un carico di lavoro che deve essere sempre disponibile. Ecco alcune aree chiave da considerare:
- Distribuzioni senza tempi di inattività
- Distribuzioni temporanee blu-verde
- Analisi del ciclo di vita di singoli componenti e raggruppati
- Convalida continua
distribuzioni senza tempi di inattività sono fondamentali per i carichi di lavoro cruciali. Un carico di lavoro che deve essere sempre attivo e in esecuzione non può avere una finestra di manutenzione per implementare versioni più recenti. Per ovviare a questa limitazione, l'architettura mission-critical di Azure segue il modello di distribuzioni senza tempi di inattività. Le modifiche vengono implementate come nuove unità di scala o timbri testati end-to-end prima che il traffico venga instradato in modo incrementale. Dopo che tutto il traffico viene instradato al nuovo timbro, i vecchi timbri vengono disabilitati e rimossi.
Per altre informazioni, vedere Distribuzione e test per carichi di lavoro cruciali in Azure.
Passaggi successivi
- percorso di apprendimento : Creare carichi di lavoro cruciali in Azure
- progetto Challenge: Progettare un'applicazione Web cruciale
- modulo Learn: Progettare un modello di integrità per il carico di lavoro cruciale