Prospettiva di Azure Well-Architected Framework sul servizio app Azure (App Web)
app Azure Service è una soluzione di calcolo PaaS (Platform as a Service) che è possibile usare per ospitare il carico di lavoro nella piattaforma Azure. Si tratta di un servizio completamente gestito che astrae il calcolo sottostante e scarica la responsabilità di creare, distribuire e ridimensionare la piattaforma. Un servizio app viene sempre eseguito in un piano di servizio app. Il piano di servizio scelto determina l'area in cui viene eseguito il carico di lavoro, le configurazioni di calcolo e il sistema operativo. Sono disponibili più modelli di fatturazione per servizio app.
Questo articolo presuppone che come architetto sia stato esaminato l'albero delle decisioni di calcolo e sia stato scelto servizio app come calcolo per il carico di lavoro. Le linee guida contenute in questo articolo forniscono raccomandazioni sull'architettura mappate ai principi dei pilastri di Azure Well-Architected Framework.
Importante
Come usare questa guida
Ogni sezione include un elenco di controllo di progettazione che presenta le aree di interesse dell'architettura insieme alle strategie di progettazione localizzate nell'ambito della tecnologia.
Sono incluse anche raccomandazioni sulle funzionalità tecnologiche che possono aiutare a materializzare tali strategie. Le raccomandazioni non rappresentano un elenco completo di tutte le configurazioni disponibili per la funzionalità App Web del servizio app Azure e delle relative dipendenze. Vengono invece elencate le raccomandazioni principali mappate alle prospettive di progettazione. Usare i consigli per creare il modello di verifica o ottimizzare gli ambienti esistenti.
Architettura di base che illustra le raccomandazioni principali: servizio app architettura di base.
Ambito della tecnologia
Questa revisione è incentrata sulle decisioni correlate per le risorse di Azure seguenti:
- Piani del servizio app
- App Web
Altre offerte di Azure sono associate a servizio app, ad esempio Funzioni di Azure, App per la logica di Azure e ambiente del servizio app. Queste offerte non rientrano nell'ambito di questo articolo. ambiente del servizio app viene fatto riferimento occasionalmente per chiarire le funzionalità o le opzioni delle offerte di base servizio app.
Affidabilità
Lo scopo del pilastro Affidabilità è fornire funzionalità continue creando una resilienza sufficiente e la possibilità di recuperare rapidamente dagli errori.
I principi di progettazione dell'affidabilità forniscono una strategia di progettazione di alto livello applicata per singoli componenti, flussi di sistema e il sistema nel suo complesso.
Elenco di controllo della progettazione
Avviare la strategia di progettazione in base all'elenco di controllo di revisione della progettazione per l'affidabilità. Determinare la rilevanza per i requisiti aziendali tenendo presenti i livelli e le funzionalità di servizio app e le relative dipendenze. Estendere la strategia per includere altri approcci in base alle esigenze.
Classificare in ordine di priorità i flussi utente: non tutti i flussi sono ugualmente critici. Assegnare priorità a ogni flusso per guidare le decisioni di progettazione. La progettazione del flusso utente può influenzare i livelli di servizio e il numero di istanze scelte per un piano e una configurazione servizio app.
Ad esempio, l'applicazione potrebbe includere livelli front-end e back-end che comunicano tramite un broker di messaggi. È possibile scegliere di segmentare i livelli in più app Web per consentire scalabilità indipendente, gestione del ciclo di vita e manutenzione. L'inserimento di un'applicazione di grandi dimensioni in un singolo piano può causare problemi di memoria o CPU e influire sull'affidabilità.
Potrebbero essere necessarie più istanze sul front-end per ottenere prestazioni ottimali sul lato interfaccia utente. Tuttavia, il back-end potrebbe non richiedere lo stesso numero di istanze.
Prevedere potenziali errori: pianificare strategie di mitigazione per potenziali errori. La tabella seguente mostra esempi di analisi della modalità di errore.
Errore Strategia di riduzione del rischio Errore dei componenti servizio app sottostanti o astratti Avere ridondanza dei componenti in istanze e dipendenze. Monitorare l'integrità delle istanze, delle prestazioni di rete e delle prestazioni di archiviazione. Errore di dipendenze esterne Usare modelli di progettazione, ad esempio il modello Di ripetizione dei tentativi e il modello interruttore. Monitorare le dipendenze esterne e impostare i timeout appropriati. Errore dovuto al traffico indirizzato a istanze non integre Monitorare l'integrità dell'istanza. Prendere in considerazione la velocità di risposta ed evitare l'invio di richieste a istanze non integre. Per altre informazioni, vedere Analisi della modalità di errore per le applicazioni Azure.
Ridondanza della compilazione: creare ridondanza nell'applicazione e nell'infrastruttura di supporto. Distribuire le istanze tra zone di disponibilità per migliorare la tolleranza di errore. Il traffico viene instradato ad altre zone in caso di errore di una zona. Distribuire l'applicazione in più aree per assicurarsi che l'app rimanga disponibile, anche se si verifica un'interruzione dell'intera area.
Creare livelli simili di ridondanza nei servizi dipendenti. Ad esempio, le istanze dell'applicazione si associano all'archivio BLOB. Valutare la possibilità di configurare l'account di archiviazione associato con l'archiviazione con ridondanza della zona se un'applicazione usa una distribuzione con ridondanza della zona.
Avere ridondanza nei componenti di rete. Ad esempio, usare indirizzi IP con ridondanza della zona e servizi di bilanciamento del carico.
Avere una strategia di scalabilità affidabile: il carico imprevisto in un'applicazione può renderlo inaffidabile. Prendere in considerazione l'approccio di ridimensionamento corretto in base alle caratteristiche del carico di lavoro. A volte è possibile aumentare le prestazioni per gestire il carico. Tuttavia, se il carico continua ad aumentare, aumentare il numero di istanze in nuove istanze. Preferisce il ridimensionamento automatico rispetto a approcci manuali. Mantenere sempre un buffer di capacità aggiuntiva durante le operazioni di ridimensionamento per evitare una riduzione delle prestazioni.
Il livello di piano servizio app scelto influisce sul ridimensionamento in termini di numero di istanze e unità di calcolo.
Assicurarsi che l'inizializzazione dell'app sia corretta in modo che le nuove istanze vengano aggiornate rapidamente e possano ricevere richieste.
Cercare applicazioni senza stato quando possibile. Il ridimensionamento affidabile dello stato con nuove istanze può aumentare la complessità. Prendere in considerazione un archivio dati esterno che è possibile ridimensionare in modo indipendente se è necessario archiviare lo stato dell'applicazione. L'archiviazione dello stato della sessione in memoria può provocare la perdita dello stato della sessione quando si verifica un problema con l'applicazione o il servizio app. Limita inoltre la possibilità di distribuire il carico tra altre istanze.
Testare regolarmente le regole di scalabilità automatica. Simulare scenari di caricamento per verificare che l'app sia ridimensionata come previsto. È consigliabile registrare gli eventi di ridimensionamento in modo da poter risolvere i problemi che possono verificarsi e ottimizzare la strategia di scalabilità nel tempo.
servizio app presenta una limitazione per il numero di istanze all'interno di un piano, che può influire sull'affidabilità del ridimensionamento. Una strategia consiste nell'usare indicatori di distribuzione identici, ognuno dei quali esegue servizio app'istanza del piano con il proprio endpoint. È essenziale far fronte a tutti gli stamp con un servizio di bilanciamento del carico esterno per distribuire il traffico tra di essi. Usare app Azure lication Gateway per distribuzioni a zona singola e Frontdoor di Azure per distribuzioni in più aree. Questo approccio è ideale per applicazioni cruciali in cui l'affidabilità è fondamentale. Per altre informazioni, vedere Baseline mission-critical con servizio app.
Un piano di servizio app distribuisce il traffico tra istanze e monitora l'integrità. Si noti che il servizio di bilanciamento del carico esterno potrebbe non rilevare immediatamente se un'istanza ha esito negativo.
Pianificare la ripristinabilità: la ridondanza è fondamentale per la continuità aziendale. Eseguire il failover in un'altra istanza se un'istanza non è raggiungibile. Esplorare le funzionalità di correzione automatica in servizio app, ad esempio il ripristino automatico delle istanze.
Implementare modelli di progettazione per gestire una riduzione normale delle prestazioni per entrambi gli errori temporanei, ad esempio problemi di connettività di rete e eventi su larga scala, ad esempio interruzioni a livello di area. Considerare i modelli di progettazione seguenti:
Il modello Bulkhead segmenta l'applicazione in gruppi isolati per evitare che un errore influisca sull'intero sistema.
Il modello di modello di livellamento del carico basato su coda accoda elementi di lavoro che fungono da buffer per attenuare i picchi di traffico.
Il modello Di ripetizione dei tentativi gestisce gli errori temporanei a causa di errori di rete, connessioni di database eliminate o servizi occupati.
Il modello interruttore impedisce a un'applicazione di tentare ripetutamente di eseguire un'operazione che potrebbe non riuscire.
È possibile usare Processi Web per eseguire attività in background nell'app Web. Per eseguire tali attività in modo affidabile, assicurarsi che l'app che ospita il processo venga eseguita continuamente in base a una pianificazione o basata su trigger basati su eventi.
Per altre informazioni, vedere Modelli di affidabilità.
Eseguire test di affidabilità: eseguire test di carico per valutare l'affidabilità e le prestazioni dell'applicazione sotto carico. I piani di test devono includere scenari che convalidano le operazioni di ripristino automatizzato.
Usare l'inserimento di errori per introdurre intenzionalmente errori e convalidare i meccanismi di auto-riparazione e conservazione automatica. Esplorare la libreria di errori fornita da Azure Chaos Studio.
servizio app impone limiti di risorse alle app ospitate. Il piano di servizio app determina questi limiti. Assicurarsi che i test confermino che l'app venga eseguita entro i limiti delle risorse. Per altre informazioni, vedere Sottoscrizione di Azure e limiti, quote e vincoli dei servizi.
Usare i probe di integrità per identificare i ruoli di lavoro che non rispondono: servizio app include funzionalità predefinite che eseprendono periodicamente un percorso specifico dell'applicazione Web. Le istanze che non rispondono vengono rimosse dal servizio di bilanciamento del carico e sostituite con una nuova istanza.
Consigli
| Elemento consigliato | Vantaggio |
|---|---|
| (piano servizio app) Scegliere il livello Premium di un piano di servizio app per i carichi di lavoro di produzione. Impostare il numero massimo e minimo di ruoli di lavoro in base alla pianificazione della capacità. Per altre informazioni, vedere panoramica del piano servizio app. |
Un piano di servizio app Premium offre funzionalità di scalabilità avanzate e garantisce la ridondanza in caso di errori. |
| (piano servizio app) Abilitare la ridondanza della zona. Prendere in considerazione il provisioning di più di tre istanze per migliorare la tolleranza di errore. Controllare il supporto a livello di area per la ridondanza della zona perché non tutte le aree offrono questa funzionalità. |
L'applicazione può resistere agli errori in una singola zona quando più istanze vengono distribuite tra zone. Il traffico passa automaticamente a istanze integre in altre zone e mantiene l'affidabilità dell'applicazione se una zona non è disponibile. |
| (servizio app) Valutare la possibilità di disabilitare la funzionalità di affinità di routing delle richieste di applicazione (ARR). L'affinità ARR crea sessioni permanenti che reindirizzano gli utenti al nodo che ha gestito le richieste precedenti. | Le richieste in ingresso vengono distribuite uniformemente in tutti i nodi disponibili quando si disabilita l'affinità ARR. Le richieste distribuite in modo uniforme impediscono al traffico di sovraccaricare qualsiasi nodo singolo. Le richieste possono essere reindirizzate senza problemi ad altri nodi integri se un nodo non è disponibile. Evitare l'affinità di sessione per assicurarsi che l'istanza di servizio app rimanga senza stato. Un servizio app senza stato riduce la complessità e garantisce un comportamento coerente tra i nodi. Rimuovere sessioni permanenti in modo che servizio app possibile aggiungere o rimuovere istanze per ridimensionare orizzontalmente. |
| (servizio app) Definire regole di correzione automatica in base al numero di richieste, alle richieste lente, ai limiti di memoria e ad altri indicatori che fanno parte della baseline delle prestazioni. Prendere in considerazione questa configurazione come parte della strategia di scalabilità. | Le regole di correzione automatica consentono all'applicazione di eseguire automaticamente il ripristino da problemi imprevisti. Le regole configurate attivano azioni di correzione quando vengono superate le soglie. La correzione automatica abilita la manutenzione proattiva automatica. |
| (servizio app) Abilitare la funzionalità di controllo integrità e fornire un percorso che risponde alle richieste di controllo integrità. | I controlli di integrità possono rilevare i problemi in anticipo. Il sistema può quindi eseguire automaticamente azioni correttive quando una richiesta di controllo integrità ha esito negativo. Il servizio di bilanciamento del carico instrada il traffico da istanze non integre, che indirizza gli utenti a nodi integri. |
Sicurezza
Lo scopo del pilastro Sicurezza è fornire garanzie di riservatezza, integrità e disponibilità al carico di lavoro.
I principi di progettazione della sicurezza forniscono una strategia di progettazione di alto livello per raggiungere tali obiettivi applicando approcci alla progettazione tecnica intorno all'hosting su servizio app.
Elenco di controllo della progettazione
Avviare la strategia di progettazione in base all'elenco di controllo di revisione della progettazione per sicurezza e identificare vulnerabilità e controlli per migliorare il comportamento di sicurezza. Estendere la strategia per includere altri approcci in base alle esigenze.
Esaminare le baseline di sicurezza: per migliorare il comportamento di sicurezza dell'applicazione ospitata in un piano di servizio app, esaminare la baseline di sicurezza per servizio app.
Usare il runtime e le librerie più recenti: testare accuratamente le compilazioni dell'applicazione prima di eseguire aggiornamenti per rilevare i problemi in anticipo e garantire una transizione senza problemi alla nuova versione. servizio app supporta i criteri di supporto del runtime del linguaggio per aggiornare gli stack esistenti e ritirare gli stack di fine supporto.
Creare la segmentazione attraverso i limiti di isolamento per contenere violazioni: applicare la segmentazione delle identità. Ad esempio, implementare il controllo degli accessi in base al ruolo per assegnare autorizzazioni specifiche in base ai ruoli. Seguire il principio dei privilegi minimi per limitare i diritti di accesso solo a ciò che è necessario. Creare anche la segmentazione a livello di rete. Inserire servizio app app in una rete virtuale di Azure per l'isolamento e definire gruppi di sicurezza di rete (NSG) per filtrare il traffico.
servizio app piani offrono il livello di ambiente del servizio app che offre un livello di isolamento elevato. Con ambiente del servizio app si ottengono risorse di calcolo e rete dedicate.
Applicare controlli di accesso alle identità: limitare sia l'accesso interno all'app Web che l'accesso esterno dall'app Web ad altre risorse. Questa configurazione applica i controlli di accesso alle identità e consente di mantenere il comportamento di sicurezza complessivo del carico di lavoro.
Usare Microsoft Entra ID per tutte le esigenze di autenticazione e autorizzazione. Usare ruoli predefiniti, ad esempio Collaboratore piano Web, Collaboratore sito Web e Collaboratore generico, Lettore e Proprietario.
Controllare il traffico di rete da e verso l'applicazione: non esporre gli endpoint dell'applicazione alla rete Internet pubblica. Aggiungere invece un endpoint privato nell'app Web inserita in una subnet dedicata. Eseguire il front-end dell'applicazione con un proxy inverso che comunica con tale endpoint privato. Per questo scopo, è consigliabile usare gateway applicazione o Frontdoor di Azure.
Distribuire un web application firewall (WAF) per proteggersi da vulnerabilità comuni. Sia gateway applicazione che Frontdoor di Azure hanno funzionalità WAF integrate.
Configurare le regole del proxy inverso e le impostazioni di rete in modo appropriato per ottenere il livello di sicurezza e controllo desiderato. Ad esempio, aggiungere regole del gruppo di sicurezza di rete nella subnet dell'endpoint privato per accettare solo il traffico dal proxy inverso.
Il traffico in uscita dall'applicazione ad altri servizi PaaS deve essere su endpoint privati. Prendere in considerazione l'inserimento di un componente firewall per limitare il traffico in uscita verso Internet pubblico. Entrambi gli approcci impediscono l'esfiltrazione dei dati.
Per una visualizzazione completa, vedere servizio app funzionalità di rete.
Crittografare i dati: proteggere i dati in transito con TLS (Transport Layer Security) end-to-end. Usare le chiavi gestite dal cliente per la crittografia completa dei dati inattivi. Per altre informazioni, vedere Crittografia dei dati inattivi tramite chiavi gestite dal cliente.
Non usare protocolli legacy come TLS 1.0 e 1.1. servizio app abilita 1.2 per impostazione predefinita. Per altre informazioni, vedere servizio app panoramica di TLS.
Tutte le istanze del servizio app hanno un nome di dominio predefinito. Usare un dominio personalizzato e proteggere il dominio con i certificati.
Ridurre la superficie di attacco: rimuovere le configurazioni predefinite non necessarie. Ad esempio, disabilitare il debug remoto, l'autenticazione locale per i siti di Gestione controllo del codice sorgente e l'autenticazione di base. Disabilitare protocolli non sicuri come HTTP e FTP (File Transfer Protocol). Applicare le configurazioni tramite i criteri di Azure. Per altre informazioni, vedere Criteri di Azure.
Implementare criteri CORS (Cross-Origin Resource Sharing) restrittivi: usare criteri CORS restrittivi nell'app Web per accettare solo le richieste provenienti da domini, intestazioni e altri criteri consentiti. Applicare i criteri CORS con definizioni di criteri di Azure predefinite.
Proteggere i segreti dell'applicazione: è necessario gestire informazioni riservate, ad esempio chiavi API o token di autenticazione. Invece di impostare come hardcoding questi segreti direttamente nel codice dell'applicazione o nei file di configurazione, è possibile usare i riferimenti di Azure Key Vault nelle impostazioni dell'app. All'avvio dell'applicazione, servizio app recupera automaticamente i valori dei segreti da Key Vault usando l'identità gestita dell'app.
Abilitare i log delle risorse per l'applicazione: abilitare i log delle risorse per l'applicazione per creare percorsi di attività completi che forniscono dati preziosi durante le indagini che seguono gli eventi imprevisti di sicurezza.
Prendere in considerazione la registrazione come parte del processo di modellazione delle minacce quando si valutano le minacce.
Consigli
| Elemento consigliato | Vantaggio |
|---|---|
| (servizio app) Assegnare identità gestite all'app Web. Per mantenere i limiti di isolamento, non condividere o riutilizzare le identità tra le applicazioni. Assicurarsi di connettersi in modo sicuro al registro contenitori se si usano contenitori per la distribuzione. |
L'applicazione recupera i segreti da Key Vault per autenticare la comunicazione esterna dall'applicazione. Azure gestisce l'identità e non richiede il provisioning o la rotazione di segreti. Si dispone di identità distinte per la granularità del controllo. Le identità distinte semplificano la revoca se un'identità viene compromessa. |
| (servizio app) Configurare domini personalizzati per le applicazioni. Disabilitare HTTP e accettare solo le richieste HTTPS. |
I domini personalizzati consentono la comunicazione sicura tramite HTTPS usando il protocollo TLS (Transport Layer Security), che garantisce la protezione dei dati sensibili e crea una relazione di trust utente. |
| (servizio app) valutare se servizio app'autenticazione predefinita è il meccanismo corretto per autenticare gli utenti che accedono all'applicazione. servizio app'autenticazione predefinita si integra con Microsoft Entra ID. Questa funzionalità gestisce la convalida dei token e la gestione delle identità utente tra più provider di accesso e supporta openID Connessione. Con questa funzionalità non si dispone dell'autorizzazione a un livello granulare e non si dispone di un meccanismo per testare l'autenticazione. | Quando si usa questa funzionalità, non è necessario usare le librerie di autenticazione nel codice dell'applicazione, riducendo la complessità. L'utente è già autenticato quando una richiesta raggiunge l'applicazione. |
| (servizio app) Configurare l'applicazione per l'integrazione della rete virtuale. Usare endpoint privati per servizio app app. Blocca tutto il traffico pubblico. Instradare l'immagine del contenitore tramite l'integrazione della rete virtuale. Tutto il traffico in uscita dall'applicazione passa attraverso la rete virtuale. |
Ottenere i vantaggi della sicurezza dell'uso di una rete virtuale di Azure. Ad esempio, l'applicazione può accedere in modo sicuro alle risorse all'interno della rete. Aggiungere un endpoint privato per proteggere l'applicazione. Gli endpoint privati limitano l'esposizione diretta alla rete pubblica e consentono l'accesso controllato tramite il proxy inverso. |
| (servizio app) Per implementare la protezione avanzata: - Disabilitare l'autenticazione di base che usa un nome utente e una password a favore dell'autenticazione basata su ID di Microsoft Entra. - Disattivare il debug remoto in modo che le porte in ingresso non siano aperte. - Abilitare i criteri CORS per rafforzare le richieste in ingresso. - Disabilitare i protocolli, ad esempio FTP. |
Non è consigliabile usare l'autenticazione di base come metodo di distribuzione sicura. Microsoft Entra ID usa l'autenticazione basata su token OAuth 2.0, che offre numerosi vantaggi e miglioramenti che risolgono le limitazioni associate all'autenticazione di base. I criteri limitano l'accesso alle risorse dell'applicazione, consentono solo le richieste da domini specifici e proteggono le richieste tra aree. |
| (servizio app) Usare sempre i riferimenti a Key Vault come impostazioni dell'app. |
I segreti vengono mantenuti separati dalla configurazione dell'app. Le impostazioni dell'app vengono crittografate inattive. servizio app gestisce anche le rotazioni dei segreti. |
| (piano servizio app) Abilitare Microsoft Defender per il cloud per servizio app. | Ottenere la protezione in tempo reale per le risorse eseguite in un piano servizio app. Proteggersi dalle minacce e migliorare il comportamento di sicurezza complessivo. |
| (piano servizio app) Abilitare la registrazione diagnostica e aggiungere strumentazione all'app. I log vengono inviati a Archiviazione di Azure account, Hub eventi di Azure e Log Analytics. Per altre informazioni sui tipi di log di controllo, vedere Tipi di log supportati. | La registrazione acquisisce i modelli di accesso. Registra eventi rilevanti che forniscono informazioni dettagliate preziose sul modo in cui gli utenti interagiscono con un'applicazione o una piattaforma. Queste informazioni sono fondamentali per motivi di responsabilità, conformità e sicurezza. |
Ottimizzazione dei costi
L'ottimizzazione dei costi è incentrata sul rilevamento dei modelli di spesa, sulla definizione delle priorità degli investimenti in aree critiche e sull'ottimizzazione in altri casi in modo da soddisfare il budget dell'organizzazione rispettando i requisiti aziendali.
I principi di progettazione di Ottimizzazione costi forniscono una strategia di progettazione di alto livello per raggiungere questi obiettivi e fare compromessi in base alle esigenze nella progettazione tecnica relativa alle app Web e all'ambiente in cui vengono eseguiti.
Elenco di controllo della progettazione
Avviare la strategia di progettazione in base all'elenco di controllo della revisione della progettazione per l'ottimizzazione dei costi per gli investimenti e ottimizzare la progettazione in modo che il carico di lavoro sia allineato al budget allocato per il carico di lavoro. La progettazione deve usare le funzionalità di Azure appropriate, monitorare gli investimenti e trovare opportunità per ottimizzare nel tempo.
Stimare il costo iniziale: come parte dell'esercizio di modellazione dei costi, usare il calcolatore prezzi di Azure per valutare i costi approssimativi associati a vari livelli in base al numero di istanze che si prevede di eseguire. Ogni livello di servizio app offre diverse opzioni di calcolo.
Monitorare continuamente il modello di costo per tenere traccia delle spese.
Valutare le opzioni scontate: i livelli superiori includono istanze di calcolo dedicate. È possibile applicare uno sconto per la prenotazione se il carico di lavoro ha un modello di utilizzo prevedibile e coerente. Assicurarsi di analizzare i dati di utilizzo per determinare il tipo di prenotazione più adatto al carico di lavoro. Per altre informazioni, vedere Risparmiare sui costi con servizio app istanze riservate.
Informazioni sui contatori di utilizzo: Azure addebita una tariffa oraria, ripartita al secondo, in base al piano tariffario del piano servizio app. Gli addebiti si applicano a ogni istanza con scalabilità orizzontale nel piano, in base al tempo di allocazione dell'istanza della macchina virtuale. Prestare attenzione alle risorse di calcolo sottoutilate che potrebbero aumentare i costi a causa della sovrassegnazione a causa della selezione dello SKU non ottimale o della configurazione con scalabilità ridotta.
Funzionalità aggiuntive servizio app, ad esempio la registrazione del dominio personalizzato e i certificati personalizzati, potrebbero aggiungere costi. Altre risorse, ad esempio reti virtuali per isolare la soluzione o gli insiemi di credenziali delle chiavi per proteggere i segreti del carico di lavoro, che si integrano con le risorse servizio app possono anche aggiungere costi. Per altre informazioni, vedere servizio app modello di fatturazione.
Prendere in considerazione i compromessi tra densità e isolamento: è possibile usare servizio app piani per ospitare più applicazioni nello stesso calcolo, risparmiando così costi con ambienti condivisi. Per altre informazioni, vedere Compromessi.
Valutare l'effetto della strategia di ridimensionamento sui costi: è necessario progettare, testare e configurare correttamente l'aumento delle prestazioni e il ridimensionamento quando si implementa la scalabilità automatica. Stabilire limiti massimi e minimi precisi per la scalabilità automatica.
Inizializzare in modo proattivo l'applicazione per una scalabilità affidabile. Ad esempio, non attendere che la CPU raggiunga il 95% di utilizzo. Al contrario, il ridimensionamento dei trigger a circa il 65% consente di allocare e inizializzare le nuove istanze durante il processo di ridimensionamento. Tuttavia, questa strategia potrebbe portare a capacità inutilizzata.
È consigliabile combinare e bilanciare i meccanismi per aumentare e aumentare le prestazioni. Ad esempio, un'app può aumentare le prestazioni per un certo periodo di tempo e quindi aumentare il numero di istanze in base alle esigenze. Esplorare i livelli elevati che offrono capacità elevata e un utilizzo efficiente delle risorse. In base ai modelli di utilizzo, i livelli Premium più elevati sono spesso più convenienti perché sono più capaci.
Ottimizzare i costi dell'ambiente: considerare il livello Basic o Gratuito per l'esecuzione di ambienti di pre-produzione. Questi livelli sono a basso costo e prestazioni ridotte. Se si usa il livello Basic o Gratuito, usare la governance per applicare il livello, vincolare il numero di istanze e CPU, limitare il ridimensionamento e limitare la conservazione dei log.
Implementare modelli di progettazione: questa strategia riduce il volume di richieste generate dal carico di lavoro. Prendere in considerazione l'uso di modelli come il modello Back-end per i front-end e il modello di aggregazione del gateway, che può ridurre al minimo il numero di richieste e ridurre i costi.
Controllare regolarmente i costi correlati ai dati: i periodi di conservazione dei dati estesi o i livelli di archiviazione costosi possono comportare costi di archiviazione elevati. Più spese possono accumularsi a causa dell'utilizzo della larghezza di banda e della conservazione prolungata dei dati di registrazione.
Valutare la possibilità di implementare la memorizzazione nella cache per ridurre al minimo i costi di trasferimento dei dati. Iniziare con la memorizzazione nella cache in memoria locale e quindi esplorare le opzioni di memorizzazione nella cache distribuita per ridurre il numero di richieste al database back-end. Prendere in considerazione i costi del traffico della larghezza di banda associati alla comunicazione tra aree se il database si trova in un'area diversa.
Ottimizzare i costi di distribuzione: sfruttare i vantaggi degli slot di distribuzione per ottimizzare i costi. Lo slot viene eseguito nello stesso ambiente di calcolo dell'istanza di produzione. Usarli in modo strategico per scenari come distribuzioni blu-verde che passano da uno slot all'altro. Questo approccio riduce al minimo i tempi di inattività e garantisce transizioni uniformi.
Usare gli slot di distribuzione con cautela. È possibile introdurre problemi, ad esempio eccezioni o perdite di memoria, che potrebbero influire sulle istanze esistenti e sulle nuove istanze. Assicurarsi di testare accuratamente le modifiche. Per indicazioni operative, vedere Eccellenza operativa.
Consigli
| Elemento consigliato | Vantaggio |
|---|---|
| (piano servizio app) Scegliere Livelli Gratuito o Basic per ambienti inferiori. È consigliabile usare questi livelli per l'uso sperimentale. Rimuovere i livelli quando non sono più necessari. | I livelli Gratuito e Basic sono convenienti rispetto ai livelli più elevati. Offrono una soluzione conveniente per ambienti non di produzione che non necessitano delle funzionalità complete e delle prestazioni dei piani Premium. |
| (servizio app piano) Sfruttare gli sconti ed esplorare i prezzi preferiti per: - Ambienti inferiori con piani di sviluppo/test. - Prenotazioni di Azure e piani di risparmio di Azure per il calcolo dedicato di cui è stato effettuato il provisioning nel livello Premium V3 e ambiente del servizio app. Usare istanze riservate per carichi di lavoro stabili con modelli di utilizzo prevedibili. |
I piani di sviluppo/test offrono tariffe ridotte per i servizi di Azure, rendendoli convenienti per gli ambienti non di produzione. Usare le istanze riservate per pagare in anticipo le risorse di calcolo e ottenere sconti significativi. |
| (servizio app) Monitorare i costi che servizio app risorse comportano. Eseguire lo strumento di analisi dei costi nella portale di Azure. Creare budget e avvisi per notificare agli stakeholder. |
È possibile identificare i picchi di costo, le inefficienze o le spese impreviste all'inizio. Questo approccio proattivo consente di fornire controlli di budget per evitare sovraccariche. |
| (piano servizio app) Ridimensionare quando la domanda diminuisce. Per aumentare le prestazioni, definire regole di scalabilità per ridurre il numero di istanze in Monitoraggio di Azure. | Evitare wastage e ridurre le spese non necessarie. |
Eccellenza operativa
L'eccellenza operativa si concentra principalmente sulle procedure per le procedure di sviluppo, l'osservabilità e la gestione del rilascio.
I principi di progettazione dell'eccellenza operativa forniscono una strategia di progettazione di alto livello per raggiungere questi obiettivi verso i requisiti operativi del carico di lavoro.
Elenco di controllo della progettazione
Avviare la strategia di progettazione in base all'elenco di controllo della revisione della progettazione per l'eccellenza operativa per definire i processi per l'osservabilità, i test e la distribuzione correlati a App Web.
Gestire le versioni: usare gli slot di distribuzione per gestire in modo efficace le versioni. È possibile distribuire l'applicazione in uno slot, eseguire test e convalidarne la funzionalità. Dopo la verifica, è possibile spostare facilmente l'app nell'ambiente di produzione. Questo processo non comporta costi aggiuntivi perché lo slot viene eseguito nello stesso ambiente di macchina virtuale (VM) dell'istanza di produzione.
Eseguire test automatizzati: prima di alzare di livello una versione dell'app Web, testarne accuratamente le prestazioni, le funzionalità e l'integrazione con altri componenti. Usare Test di carico di Azure, che si integra con Apache JMeter, uno strumento diffuso per i test delle prestazioni. Esplorare gli strumenti automatizzati per altri tipi di test, ad esempio Phantom per i test funzionali.
Distribuire unità non modificabili: implementare il modello Stamp di distribuzione per compartimentare servizio app in un timbro non modificabile. servizio app supporta l'uso di contenitori, intrinsecamente non modificabili. Prendere in considerazione i contenitori personalizzati per l'app Web servizio app.
Ogni stamp rappresenta un'unità autonoma che è possibile aumentare o aumentare rapidamente le prestazioni. Le unità basate su questo stamp sono temporanee e senza stato. La progettazione senza stato semplifica le operazioni e la manutenzione. Questo approccio è ideale per le applicazioni cruciali. Per un esempio, vedere Baseline mission-critical con servizio app.
Usare una tecnologia IaC (Infrastructure as Code), ad esempio Bicep, per eliminare le unità con ripetibilità e coerenza.
Mantenere sicuri gli ambienti di produzione: creare piani di servizio app separati per eseguire ambienti di produzione e pre-produzione. Non apportare modifiche direttamente nell'ambiente di produzione per garantire stabilità e affidabilità. Le istanze separate consentono flessibilità nello sviluppo e nei test prima di promuovere le modifiche all'ambiente di produzione.
Usare ambienti bassi per esplorare nuove funzionalità e configurazioni in modo isolato. Mantenere temporanei gli ambienti di sviluppo e test.
Gestire i certificati: per i domini personalizzati è necessario gestire i certificati TLS.
Disporre di processi per acquistare, rinnovare e convalidare i certificati. Eseguire l'offload di questi processi per servizio app, se possibile. Se si usa il proprio certificato, è necessario gestirlo. Scegliere un approccio più adatto ai requisiti di sicurezza.
| Elemento consigliato | Vantaggio |
|---|---|
| (servizio app) Monitorare l'integrità delle istanze e attivare probe di integrità dell'istanza. Configurare un percorso specifico per la gestione delle richieste di probe di integrità. |
È possibile rilevare tempestivamente i problemi ed eseguire azioni necessarie per mantenere la disponibilità e le prestazioni. |
| (servizio app) Abilitare i log di diagnostica per l'applicazione e l'istanza. La registrazione frequente può rallentare le prestazioni del sistema, aggiungere ai costi di archiviazione e introdurre rischi se si ha accesso non sicuro ai log. Seguire queste procedure consigliate: - Registrare il livello di informazioni corretto. - Impostare i criteri di conservazione. - Mantenere un audit trail di accesso autorizzato e tentativi non autorizzati. - Considera i log come dati e applica i controlli di protezione dei dati. |
I log di diagnostica forniscono informazioni dettagliate preziose sul comportamento dell'app. Monitorare i modelli di traffico e identificare le anomalie. |
| (servizio app) Sfruttare i vantaggi servizio app certificati gestiti per l'offload della gestione della certificazione in Azure. | servizio app gestisce automaticamente processi come l'approvvigionamento dei certificati, la verifica del certificato, il rinnovo del certificato e l'importazione di certificati da Key Vault. In alternativa, caricare il certificato in Key Vault e autorizzare il provider di risorse servizio app ad accedervi. |
| (piano servizio app) Convalidare le modifiche dell'app nello slot di staging prima di scambiarla con lo slot di produzione. | Evitare tempi di inattività ed errori. Ripristinare rapidamente l'ultimo stato valido noto se si rileva un problema dopo uno scambio. |
Efficienza delle prestazioni
L'efficienza delle prestazioni riguarda la gestione dell'esperienza utente anche quando si verifica un aumento del carico gestendo la capacità. La strategia include il ridimensionamento delle risorse, l'identificazione e l'ottimizzazione dei potenziali colli di bottiglia e l'ottimizzazione delle prestazioni massime.
I principi di progettazione dell'efficienza delle prestazioni forniscono una strategia di progettazione di alto livello per raggiungere tali obiettivi di capacità rispetto all'utilizzo previsto.
Elenco di controllo della progettazione
Avviare la strategia di progettazione in base all'elenco di controllo della revisione della progettazione per l'efficienza delle prestazioni per definire una linea di base basata su indicatori di prestazioni chiave per App Web.
Identificare e monitorare gli indicatori di prestazioni: impostare le destinazioni per gli indicatori chiave per l'applicazione, ad esempio il volume delle richieste in ingresso, il tempo impiegato dall'applicazione per rispondere alle richieste, alle richieste in sospeso e agli errori nelle risposte HTTP. Prendere in considerazione gli indicatori chiave come parte della baseline delle prestazioni per il carico di lavoro.
Acquisire servizio app metriche che costituiscono la base degli indicatori di prestazioni. Raccogliere i log per ottenere informazioni dettagliate sull'utilizzo delle risorse e sulle attività. Usare gli strumenti di monitoraggio delle prestazioni delle applicazioni, ad esempio Application Insights, per raccogliere e analizzare i dati sulle prestazioni dall'applicazione. Per altre informazioni, vedere servizio app riferimento ai dati di monitoraggio.
Includere la strumentazione a livello di codice, la traccia delle transazioni e la profilatura delle prestazioni.
Valutare la capacità: simulare vari scenari utente per determinare la capacità ottimale necessaria per gestire il traffico previsto. Usare Test di carico per comprendere il comportamento dell'applicazione con livelli di carico diversi.
Selezionare il livello corretto: usare il calcolo dedicato per i carichi di lavoro di produzione. I livelli Premium offrono SKU più grandi con maggiore capacità di memoria e CPU, più istanze e altre funzionalità, ad esempio la ridondanza della zona. Per altre informazioni, vedere Piano tariffario Premium V3.
Ottimizzare la strategia di scalabilità: quando possibile, usare la scalabilità automatica anziché regolare manualmente il numero di istanze quando cambia il carico dell'applicazione. Con la scalabilità automatica, servizio app regola la capacità del server in base a regole o trigger predefiniti. Assicurarsi di eseguire test delle prestazioni adeguati e impostare le regole corrette per i trigger corretti.
Se si assegna la priorità alla semplicità durante l'installazione iniziale, usare un'opzione di scalabilità automatica che non richiede di definire regole e di dover impostare solo i limiti.
Disporre di risorse sufficienti prontamente disponibili per garantire prestazioni ottimali. Allocare le risorse in modo appropriato per mantenere gli obiettivi di prestazioni, ad esempio il tempo di risposta o la velocità effettiva. Quando necessario, valutare la sovrasocazione delle risorse.
Quando si definiscono le regole di scalabilità automatica, tenere conto del tempo necessario per l'inizializzazione dell'applicazione. Prendere in considerazione questo sovraccarico quando si prendono tutte le decisioni di ridimensionamento.
Usare la memorizzazione nella cache: il recupero di informazioni da una risorsa che non cambia frequentemente ed è costoso per l'accesso influisce sulle prestazioni. Le query complesse, inclusi i join e più ricerche, contribuiscono al runtime. Eseguire la memorizzazione nella cache per ridurre al minimo il tempo di elaborazione e la latenza. Memorizzare nella cache i risultati delle query per evitare round trip ripetuti al database o al back-end e ridurre il tempo di elaborazione per le richieste successive.
Per altre informazioni sull'uso della cache locale e distribuita nel carico di lavoro, vedere Memorizzazione nella cache.
Esaminare gli antipattern delle prestazioni: per assicurarsi che l'applicazione Web esegua le prestazioni e le scalabilità in base ai requisiti aziendali, evitare gli antipattern tipici. Ecco alcuni antipattern che servizio app corretti.
Antipattern Descrizione Front-end occupato Le attività a elevato utilizzo di risorse possono allungare i tempi di risposta per le richieste utente e generare una latenza elevata.
Trasferire i processi con uso intensivo di risorse in un back-end separato. Usare un broker di messaggi per accodare attività a elevato utilizzo di risorse che il back-end preleva per elaborare in modo asincrono.Nessuna memorizzazione nella cache Gestire le richieste da una cache intermedia davanti al database back-end per ridurre la latenza. Vicino rumoroso I sistemi multi-tenant condividono le risorse tra i tenant. L'attività di un tenant può avere un effetto negativo sull'uso del sistema da parte di un altro tenant. ambiente del servizio app offre un ambiente completamente isolato e dedicato per l'esecuzione di app servizio app.
Consigli
| Elemento consigliato | Vantaggio |
|---|---|
| Abilitare l'impostazione Always On quando le applicazioni condividono un singolo piano di servizio app. servizio app le app scaricano automaticamente quando sono inattive per salvare le risorse. La richiesta successiva attiva un avvio a freddo, che può causare timeout delle richieste. | L'applicazione non viene mai scaricata con Always On abilitato. |
| Prendere in considerazione l'uso di HTTP/2 per le applicazioni per migliorare l'efficienza del protocollo. | Scegliere HTTP/2 su HTTP/1.1 perché http/2 esegue completamente connessioni multiplex, riutilizza le connessioni per ridurre il sovraccarico e comprime le intestazioni per ridurre al minimo il trasferimento dei dati. |
Svantaggi
Potrebbe essere necessario fare compromessi di progettazione se si usano gli approcci negli elenchi di controllo dei pilastri. Ecco alcuni esempi di vantaggi e svantaggi.
Densità e isolamento
Densità più elevata: colocare più app all'interno della stessa servizio app piano per ridurre al minimo le risorse. Tutte le app condividono risorse come CPU e memoria, che possono risparmiare denaro e ridurre la complessità operativa. Questo approccio ottimizza anche l'utilizzo delle risorse. Le app possono usare risorse inattive da un'altra app se i modelli di carico cambiano nel tempo.
Considerare anche gli svantaggi. Ad esempio, i picchi di utilizzo o instabilità di un'app possono influire sulle prestazioni di altre app. Gli eventi imprevisti in un'app possono anche permeare ad altre app all'interno dell'ambiente condiviso, che possono influire sulla sicurezza.
Isolamento più elevato: l'isolamento consente di evitare interferenze. Questa strategia si applica alla sicurezza, alle prestazioni e anche alla separazione degli ambienti di sviluppo, test e produzione.
ambiente del servizio app offre un migliore controllo sulla sicurezza e sulla protezione dei dati perché ogni app può avere impostazioni di sicurezza proprie. L'ambiente può contenere violazioni perché l'isolamento limita il raggio dell'esplosione. La contesa delle risorse viene ridotta a icona dal punto di vista delle prestazioni. L'isolamento consente una scalabilità indipendente in base a una specifica richiesta e alla pianificazione della capacità individuale.
Come svantaggio, questo approccio è più costoso e richiede rigore operativo.
Strategia di scalabilità affidabile
Una strategia di scalabilità ben definita garantisce che l'applicazione possa gestire vari carichi senza compromettere le prestazioni. Tuttavia, ci sono compromessi sui costi. Le operazioni di ridimensionamento richiedono tempo. Quando vengono allocate nuove risorse, l'applicazione deve essere inizializzata correttamente prima di poter elaborare in modo efficace le richieste. È possibile effettuare l'overprovisioning delle risorse (istanze prewarm) per fornire una rete di sicurezza. Senza tale capacità aggiuntiva, durante la fase di inizializzazione, potrebbe verificarsi un ritardo nella gestione delle richieste, che influisce sull'esperienza utente. Le operazioni di scalabilità automatica possono essere attivate in anticipo per abilitare l'inizializzazione corretta delle risorse da parte dei clienti che usano le risorse.
Come svantaggio, le risorse con provisioning eccessivo costano di più. Vengono addebitati costi al secondo per ogni istanza, incluse le istanze preavvise. I livelli più elevati includono istanze preavvise. Determinare se le funzionalità con livelli più costosi valgono l'investimento.
Creazione della ridondanza
La ridondanza offre resilienza, ma comporta anche costi. Gli obiettivi del livello di servizio per il carico di lavoro determinano soglie di prestazioni accettabili. Diventa sprecato se la ridondanza supera i requisiti SLO. Valutare se la ridondanza in eccesso migliora i contratti di servizio o aggiunge complessità non necessarie.
Considerare anche gli svantaggi. Ad esempio, la ridondanza in più aree offre disponibilità elevata, ma aggiunge complessità e costi a causa della sincronizzazione dei dati, dei meccanismi di failover e della comunicazione tra aree. Determinare se la ridondanza della zona può soddisfare i contratti di servizio.
Criteri di Azure
Azure offre un set completo di criteri predefiniti correlati a servizio app e alle relative dipendenze. Un set di criteri di Azure può controllare alcune delle raccomandazioni precedenti. Ad esempio, è possibile verificare se:
Sono presenti controlli di rete appropriati. Ad esempio, è possibile incorporare la segmentazione di rete inserendo servizio app in Azure Rete virtuale tramite l'inserimento della rete virtuale per avere un maggiore controllo sulla configurazione di rete. L'applicazione non dispone di endpoint pubblici e si connette ai servizi di Azure tramite endpoint privati.
Sono presenti controlli di identità. Ad esempio, l'applicazione usa le identità gestite per autenticarsi con altre risorse. servizio app'autenticazione predefinita (Easy Auth) verifica le richieste in ingresso.
Le funzionalità come il debug remoto e l'autenticazione di base sono disabilitate per ridurre la superficie di attacco.
Per una governance completa, esaminare i Criteri di Azure definizioni predefinite e altri criteri che potrebbero influire sulla sicurezza del livello di calcolo.
Consigli di Azure Advisor
Azure Advisor è un consulente cloud personalizzato che facilita l'applicazione delle procedure consigliate per ottimizzare le distribuzioni di Azure. Ecco alcuni consigli che consentono di migliorare l'affidabilità, la sicurezza, l'efficacia dei costi, le prestazioni e l'eccellenza operativa delle istanze dell'applicazione Web.
Passaggi successivi
Considerare gli articoli seguenti come risorse che illustrano le raccomandazioni evidenziate in questo articolo.
Usare queste architetture di riferimento come esempi di come applicare queste raccomandazioni a un carico di lavoro.
Se non è mai stata distribuita un'app Web, vedere Applicazione Web di base.
Per un'architettura di base come punto di partenza per una distribuzione di livello di produzione, vedere Applicazione Web con ridondanza della zona a disponibilità elevata di base.
Usare la documentazione del prodotto seguente per creare le proprie competenze di implementazione: