Questo articolo descrive come distribuire applicazioni Web cruciali usando app Azure Service. L'architettura usa il modello di app Web affidabile come punto di partenza. Usare questa architettura se si dispone di un carico di lavoro legacy e si vuole adottare servizi PaaS (Platform-as-a-Service).
Il modello di app Web affidabile per .NET fornisce indicazioni per l'aggiornamento o la ripiattaformazione delle app Web spostate nel cloud, la riduzione al minimo delle modifiche al codice necessarie e la destinazione di un obiettivo a livello di servizio (SLO) del 99,9%. I carichi di lavoro cruciali hanno requisiti di affidabilità e disponibilità elevati. Per raggiungere un SLO pari al 99,95%, al 99,99% o superiore, è necessario applicare modelli di progettazione cruciali supplementari e rigore operativo. Questo articolo descrive le principali aree tecniche e come implementare e introdurre 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 carichi di lavoro cruciali di Well-Architected Framework.
Nelle sezioni successive viene descritto come effettuare le seguenti operazioni:
- Esaminare il 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 la 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 che app Azure Configuration gestisce è 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 alcuna interdipendenza e comunicano solo con i servizi condivisi all'esterno della singola unità di scala. È possibile testare unità di scala indipendenti iniziali. Per evitare di influire su altre aree di distribuzione, implementare unità di scala indipendenti e introdurre l'opzione per sostituire i servizi in una nuova versione.
Per i carichi di lavoro cruciali, le unità di scala indipendenti sono temporanee, che ottimizzano i processi di implementazione e offrono scalabilità all'interno e tra aree. Evitare di archiviare lo stato in unità di scala indipendenti. È consigliabile usare cache di Azure per Redis per l'archiviazione nell'unità di scala e archiviare solo lo stato critico o i dati archiviati anche nel database. Se si verifica un'interruzione dell'unità di scala o si passa a un'altra unità di scala, potrebbe verificarsi un rallentamento o un nuovo accesso necessario, ma cache di Azure per Redis ancora in esecuzione.
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 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 delle applicazioni.
- cache di Azure per Redis memorizza nella cache le richieste.
- Configurazione app archivia le impostazioni di configurazione.
- Azure SQL è il database back-end.
- Application Insights ottiene i dati di telemetria dall'applicazione.
Alternative
Nel modello di app Web affidabile è possibile:
- Usare servizio Azure Kubernetes (servizio Azure Kubernetes) anziché 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. 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 delle applicazioni per carichi di lavoro cruciali in Azure.
Scegliere la piattaforma dell'applicazione
Il livello di disponibilità dipende dalla scelta e dalla configurazione della piattaforma dell'applicazione. Considerare le indicazioni cruciali seguenti:
- Usare le zone di disponibilità quando possibile.
- Selezionare il servizio piattaforma appropriato per il carico di lavoro.
- Containerizzare il carico di lavoro.
I set di disponibilità distribuiscono le distribuzioni tra più domini di errore e di aggiornamento all'interno di un data center. Le zone di disponibilità distribuiscono le 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. Pertanto, il livello del database è limitato a una strategia attiva-passiva. Una strategia attiva-attiva a livello di applicazione è possibile se sono presenti repliche di sola lettura e si scrive solo in una singola area.
Scaricare un file di Visio di questa architettura.
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à. Definire i 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 e 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.
Per altre informazioni, vedere Modellazione dell'integrità e osservabilità dei carichi di lavoro cruciali in Azure.
Sicurezza e rete
Esistono requisiti di rete e sicurezza rigorosi per i carichi di lavoro di cui viene eseguita la migrazione da una distribuzione aziendale locale. Non tutti i processi locali stabiliti si traducono in un ambiente cloud. Valutare questi requisiti se sono applicabili negli ambienti cloud.
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, la maggior parte dei servizi PaaS di Azure può usare collegamento privato di Azure per implementare la rete come perimetro di sicurezza. collegamento privato può garantire che i servizi siano accessibili solo dall'interno di una rete virtuale. Tutti i servizi sono accessibili solo tramite endpoint privati. Il diagramma seguente mostra come l'unico endpoint pubblico con connessione Internet sia Frontdoor di Azure.
Scaricare un file di Visio di questa architettura.
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 e filtrandolo con il dispositivo. L'architettura di base cruciale 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 dei singoli componenti e raggruppamento
- Convalida continua
Le distribuzioni senza tempi di inattività sono fondamentali per 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 francobolli 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 mission-critical
- Modulo Learn: Progettare un modello di integrità per il carico di lavoro cruciale