Prospettiva di Azure Well-Architected Framework sul servizio app Azure (App Web)

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.

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.

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.

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.

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.

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.