Migliori pratiche di architettura per Azure Front Door
Frontdoor di Azure è un servizio di bilanciamento del carico globale e una rete per la distribuzione di contenuti (CDN) che instrada il traffico HTTP e HTTPS. Azure Front Door distribuisce il traffico più vicino agli utenti dell'applicazione.
Questo articolo presuppone che come architetto siano state esaminate le opzioni di bilanciamento del carico e abbia scelto Frontdoor di Azure come servizio di bilanciamento del carico per il carico di lavoro. Si presuppone anche che l'applicazione venga distribuita in più aree in un modello attivo-attivo o attivo-passivo. 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 e le strategie di progettazione dell'architettura localizzate nell'ambito della tecnologia.
Questo articolo include anche raccomandazioni sulle funzionalità tecnologiche che consentono di materializzare tali strategie. Le raccomandazioni non rappresentano un elenco completo di tutte le configurazioni disponibili per Frontdoor di Azure e le relative dipendenze. Vengono invece elencate le raccomandazioni principali mappate alle prospettive di progettazione. Utilizzare le raccomandazioni per sviluppare il prototipo o ottimizzare gli ambienti esistenti.
Architettura di base che illustra le raccomandazioni principali: architettura mission-critical di base con controlli di rete.
Ambito della tecnologia
Questa revisione è incentrata sulle decisioni correlate per le risorse di Azure seguenti:
- Frontdoor di Azure
Affidabilità
Lo scopo del pilastro Affidabilità è fornire funzionalità continue la creazione di resilienza sufficienti e la possibilità di recuperare rapidamente dagli errori.
I principi di progettazione affidabilità forniscono una strategia di progettazione di alto livello applicata per singoli componenti, flussi di sistema e sistema nel suo complesso.
Elenco di controllo per la progettazione
Avvia la strategia di progettazione in base alla lista di controllo per la revisione del design per l'affidabilità. Determinare la pertinenza per i requisiti aziendali tenendo presente i livelli e le funzionalità della rete CDN. Estendere la strategia per includere altri approcci in base alle esigenze.
Scegliere la strategia di distribuzione. Gli approcci fondamentali alla distribuzione sono attivo-attivo e attivo-passivo. La distribuzione attiva-attiva significa che più ambienti o indicatori che eseguono il carico di lavoro servono il traffico. La distribuzione attiva-passiva significa che solo l'area primaria gestisce tutto il traffico, ma esegue il failover nell'area secondaria quando necessario. In una distribuzione con più aree, stampi o istanze dell'applicazione vengono eseguiti in aree diverse per una maggiore disponibilità grazie a un servizio di bilanciamento del carico globale, come Azure Front Door, che distribuisce il traffico. È quindi importante configurare il bilanciatore di carico per il corretto approccio di distribuzione.
Frontdoor di Azure supporta diversi metodi di routing, che è possibile configurare per distribuire il traffico in un modello attivo-attivo o attivo-passivo.
I modelli precedenti presentano molte varianti. Ad esempio, è possibile distribuire il modello attivo-passivo con una riserva a caldo. In questo caso, il servizio ospitato secondario viene distribuito con le risorse di calcolo e il dimensionamento dei dati minimi possibili e funziona senza carico. In caso di failover, le risorse di calcolo e di dati si espandono per gestire il carico proveniente dall'area primaria. Per altre informazioni, vedere Strategie di progettazione chiave per la progettazione di più aree.
Alcune applicazioni necessitano delle connessioni utente per rimanere nello stesso server di origine durante la sessione utente. Dal punto di vista dell'affidabilità, non è consigliabile mantenere le connessioni utente nello stesso server di origine. Evitare l'affinità di sessione il più possibile.
Usare lo stesso nome host in ogni livello. Per assicurarsi che i cookie o gli URL di reindirizzamento funzionino correttamente, mantenere il nome host HTTP originale quando si usa un proxy inverso, ad esempio Frontdoor di Azure, davanti a un'applicazione Web.
Implementare il modello di monitoraggio degli endpoint di salute. L'applicazione dovrebbe esporre degli endpoint di monitoraggio della salute, che aggregano lo stato dei servizi critici e delle dipendenze di cui l'applicazione ha bisogno per servire le richieste. Le sonde di integrità di Azure Front Door usano l'endpoint per rilevare l'integrità dei server di origine. Per altre informazioni, vedere modello di monitoraggio degli endpoint di integrità.
Memorizzare nella cache il contenuto statico. La funzionalità di distribuzione del contenuto di Frontdoor di Azure include centinaia di posizioni perimetrali e può aiutare a resistere a picchi di traffico e attacchi DDoS (Distributed Denial of Service). Queste funzionalità consentono di migliorare l'affidabilità.
Prendere in considerazione un'opzione di gestione del traffico ridondante. Azure Front Door è un servizio distribuito su scala globale che viene eseguito come singleton in un ambiente specifico. Frontdoor di Azure è un potenziale punto di errore nel sistema. Se il servizio non riesce, i client non possono accedere all'applicazione durante il tempo di inattività.
Le implementazioni ridondanti possono essere complesse e costose. Considerarli solo per carichi di lavoro cruciali con una tolleranza molto bassa all'interruzione. Considera attentamente i compromessi .
- Se è assolutamente necessaria la ridondanza globale del routing, vedere .
- Se è necessaria la ridondanza solo per gestire il contenuto memorizzato nella cache, vedere distribuzione di contenuti globali.
Consigli
Raccomandazione | Beneficio |
---|---|
Scegliere un metodo di routing che supporta la strategia di distribuzione. Il metodo ponderato, che distribuisce il traffico in base al coefficiente di peso configurato, supporta i modelli attivi-attivi. Valore basato su priorità che configura l'area primaria per ricevere tutto il traffico e inviare traffico all'area secondaria come backup supporta modelli attivi-passivi. Integrare i metodi precedenti con configurazioni di sensibilità alla latenza in modo che l'origine con la latenza più bassa riceva il traffico. |
È possibile selezionare la risorsa di origine migliore usando una serie di passaggi decisionali e la progettazione. L'origine selezionata gestisce il traffico all'interno dell'intervallo di latenza consentito nel rapporto di pesi specificato. |
Supportare la ridondanza avendo più origini in uno o più gruppi di origine. Avere sempre istanze ridondanti dell'applicazione e assicurarsi che ogni istanza esponga un'origine. È possibile inserire tali origini in uno o più gruppi di origine. |
Più origini supportano la ridondanza distribuendo il traffico tra più istanze dell'applicazione. Se un'istanza non è disponibile, altre origini possono comunque ricevere traffico. |
Configurare le sonde di integrità sull'origine. Configurare Frontdoor di Azure per eseguire controlli di integrità per determinare se l'istanza di origine è disponibile e pronta per continuare a ricevere le richieste. Per ulteriori informazioni, vedere Buone pratiche sui sonde di salute. |
Le sonde di integrità attivate fanno parte dell'implementazione del modello di monitoraggio della salute. Le sonde di integrità assicurano che Azure Front Door instradi il traffico solo verso le istanze in buone condizioni per gestire le richieste. |
Impostare un timeout sull'inoltro delle richieste all'origine ed evitare richieste di lunga durata. Modificare l'impostazione di timeout in base alle esigenze degli endpoint. In caso contrario, Frontdoor di Azure potrebbe chiudere la connessione prima che l'origine invii la risposta. È anche possibile ridurre il timeout predefinito per Frontdoor di Azure se tutte le origini hanno un timeout più breve. Per altre informazioni, vedere Risoluzione dei problemi relativi alle richieste che non rispondono. |
Le richieste con esecuzione prolungata utilizzano le risorse di sistema. I timeout consentono di evitare problemi di prestazioni e disponibilità terminando le richieste che richiedono più tempo del previsto. |
Usare lo stesso nome host su Azure Front Door e la vostra origine. Frontdoor di Azure può riscrivere l'intestazione host delle richieste in ingresso, utile quando si hanno più nomi di dominio personalizzati che instradano a un'origine. Tuttavia, la riscrittura dell'intestazione host potrebbe causare problemi con i cookie di richiesta e il reindirizzamento url. Per altre informazioni, vedere [Mantenere il nome host HTTP originale](/azure/architecture/best-practices/host-name-preservation tra un proxy inverso e l'applicazione Web di origine). |
Impostare lo stesso nome host per evitare malfunzionamenti con affinità di sessione, autenticazione e autorizzazione. |
Decidi se la tua applicazione richiede affinità di sessione. Se si hanno requisiti di affidabilità elevata, è consigliabile disabilitare l'affinità di sessione. | Con l'affinità di sessione, le connessioni utente rimangono sulla stessa origine durante la sessione utente. In alcune situazioni, una singola origine potrebbe diventare sovraccaricata con richieste mentre altre origini sono inattive. Se tale origine non è più disponibile, l'esperienza utente potrebbe essere interrotta. |
Sfruttare le regole di limitazione della frequenza incluse in un web application firewall (WAF). | Limitare le richieste per impedire ai client di inviare troppo traffico all'applicazione. La limitazione della velocità di richiesta può aiutarti a evitare problemi come una tempesta di richieste ripetute. |
Sicurezza
Lo scopo del Pilastro di 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 per limitare il traffico proveniente da Frontdoor di Azure.
Elenco di controllo per la progettazione
Avvia la strategia di progettazione basata sull'elenco di controllo della revisione della progettazione per Sicurezza. Identificare vulnerabilità e controlli per migliorare il comportamento di sicurezza. Estendere la strategia per includere altri approcci in base alle esigenze.
Esaminare la baseline di sicurezza per Azure Front Door.
Proteggere i server di origine. Frontdoor di Azure è il front-end ed è il singolo punto di ingresso dell'applicazione.
Frontdoor di Azure usa il collegamento privato di Azure per accedere all'origine di un'applicazione. Il collegamento privato crea la segmentazione in modo che le origini non debbano esporre gli indirizzi IP pubblici e gli endpoint. Per ulteriori informazioni, consulta Proteggere l'origine con Collegamento Privato in Azure Front Door Premium.
Configurare i servizi back-end per accettare solo le richieste con lo stesso nome host usato da Frontdoor di Azure esternamente.
Consenti solo l'accesso autorizzato al piano di controllo. Usare Azure Front Door controllo degli accessi in base al ruolo (RBAC) per limitare l'accesso solo alle identità che ne hanno bisogno.
Bloccare le minacce comuni nelperimetrale. WAF è integrato con Frontdoor di Azure. Abilitare le regole WAF nei front-end per proteggere le applicazioni da exploit e vulnerabilità comuni nella rete perimetrale, più vicina all'origine degli attacchi. Prendere in considerazione il filtro geografico per limitare l'accesso all'applicazione Web in base a paesi o aree geografiche.
Per ulteriori informazioni, vedere il Web Application Firewall di Azure su Azure Front Door.
Proteggere dal traffico imprevisto. L'architettura di Frontdoor di Azure offre una protezione DDoS predefinita per proteggere gli endpoint dell'applicazione da attacchi DDoS. Se è necessario esporre altri indirizzi IP pubblici dall'applicazione, è consigliabile aggiungere il piano standard protezione DDoS di Azure per tali indirizzi per le funzionalità avanzate di protezione e rilevamento.
Sono inoltre disponibili set di regole WAF che rilevano il traffico del bot o volumi imprevisti di traffico di grandi dimensioni che potrebbero essere potenzialmente dannosi.
Proteggere i dati in transito. Abilitare TLS (Transport Layer Security) end-to-end, reindirizzamento da HTTP a HTTPS e certificati TLS gestiti, se applicabile. Per ulteriori informazioni, vedere procedure consigliate per TLS per Azure Front Door.
Monitorare le attività anomale. Esaminare regolarmente i log per verificare la presenza di attacchi e falsi positivi. Invia i log WAF da Azure Front Door al sistema centralizzato di gestione delle informazioni e degli eventi di sicurezza (SIEM) della tua organizzazione, ad esempio Microsoft Sentinel, per rilevare i modelli di minaccia e incorporare misure preventive nella progettazione dell'architettura.
Consigli
Raccomandazione | Beneficio |
---|---|
Abilitare i set di regole WAF che rilevano e bloccano il traffico potenzialmente dannoso. Questa funzionalità è disponibile nel livello Premium. È consigliabile usare questi set di regole: - predefinita - protezione bot - restrizione IP - filtro geografico - Limitazione della frequenza |
I set di regole predefiniti vengono aggiornati frequentemente in base ai tipi di attacco OWASP top-10 e alle informazioni fornite da Microsoft Threat Intelligence. I set di regole specializzati rilevano determinati casi d'uso. Ad esempio, le regole del bot classificano i bot come validi, non validi o sconosciuti in base agli indirizzi IP client. Bloccano anche bot non valido e indirizzi IP noti e limitano il traffico in base alla posizione geografica dei chiamanti. Usando una combinazione di set di regole, è possibile rilevare e bloccare gli attacchi con varie finalità. |
Creare esclusioni per i set di regole gestite. Testare un criterio WAF in modalità di rilevamento per alcune settimane e modificare eventuali falsi positivi prima di distribuirlo. |
Ridurre i falsi positivi e consentire richieste legittime per l'applicazione. |
Inviare l'intestazione host all'origine. | I servizi back-end devono essere a conoscenza del nome host in modo che possano creare regole per accettare il traffico solo da tale host. |
Proteggere le connessioni da Frontdoor di Azure alle origini.
Abilitare la connettività del collegamento privato alle origini supportate. Se l'origine non supporta la connettività Private Link, usare i service tags e l'intestazione X-Azure-FDID per verificare che l'origine della richiesta sia il profilo Azure Front Door. |
Assicurarsi che tutto il traffico passa attraverso Frontdoor di Azure e ottenga i vantaggi della sicurezza, ad esempio la protezione DDoS e l'ispezione WAF. |
Abilitare TLS end-to-end, il reindirizzamento da HTTP a HTTPS e i certificati TLS gestiti, se applicabile. Esaminare le migliori pratiche TLS per Azure Front Door. Usare TLS versione 1.2 come versione minima consentita con crittografie rilevanti per l'applicazione. I certificati gestiti di Frontdoor di Azure devono essere la scelta predefinita per semplificare le operazioni. Tuttavia, se si vuole gestire il ciclo di vita dei certificati, usare i propri certificati nei endpoint del dominio personalizzato di Front Door di Azure e archiviarli in Key Vault. |
TLS garantisce che gli scambi di dati tra il browser, Frontdoor di Azure e le origini siano crittografati per evitare manomissioni. Key Vault offre supporto per certificati gestiti e rinnovo e rotazione di certificati semplici. |
Ottimizzazione costi
L'ottimizzazione dei costi è incentrata su rilevare modelli di spesa, assegnare priorità agli investimenti in aree critiche e ottimizzare in altre per soddisfare sia il budget dell'organizzazione che i requisiti aziendali.
I principi di progettazione di Ottimizzazione costi forniscono una strategia di alto livello per raggiungere gli obiettivi e fare compromessi quando necessario nella progettazione tecnica relativa ad Azure Front Door e al suo ambiente.
Elenco di controllo per la progettazione
Avvia la strategia di design basata sulla checklist della revisione del design per l'ottimizzazione dei costi negli investimenti. 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.
Esaminare i livelli di servizio e i prezzi. Usare il calcolatore prezzi per stimare i costi realistici per ogni livello di Frontdoor di Azure. Confrontare le funzionalità e l'idoneità di ogni livello per lo scenario. Ad esempio, solo il livello Premium supporta la connessione all'origine tramite collegamento privato.
Lo SKU Standard è più conveniente e adatto per scenari di traffico moderato. Nello SKU Premium si paga una tariffa unitaria superiore, ma si ottiene l'accesso a vantaggi di sicurezza e funzionalità avanzate, come le regole gestite nel WAF e il Private Link. Considerare i compromessi tra l'affidabilità e la sicurezza in base ai requisiti aziendali.
Prendere in considerazione i costi della larghezza di banda. I costi della larghezza di banda di Frontdoor di Azure dipendono dal livello scelto e dal tipo di trasferimento dei dati. Per informazioni sulla fatturazione di Frontdoor di Azure, vedere Informazioni sulla fatturazione di Frontdoor di Azure.
Frontdoor di Azure offre report predefiniti per le metriche fatturabili. Per valutare i costi correlati alla larghezza di banda e dove è possibile concentrare le attività di ottimizzazione, vedere report di Frontdoor di Azure.
Ottimizzare le richieste in ingresso. Frontdoor di Azure fattura le richieste in ingresso. È possibile impostare restrizioni nella configurazione di progettazione.
Ridurre il numero di richieste utilizzando design pattern come Backend for Frontends e Gateway Aggregation. Questi modelli possono migliorare l'efficienza delle operazioni.
Le regole WAF limitano il traffico in ingresso, che può ottimizzare i costi. Ad esempio, usare la limitazione della frequenza per impedire livelli anomali di traffico o usare il filtro geografico per consentire l'accesso solo da aree o paesi specifici.
Usare le risorse in modo efficiente. Frontdoor di Azure usa un metodo di routing che consente di ottimizzare le risorse. A meno che il carico di lavoro non sia estremamente sensibile alla latenza, distribuire il traffico in modo uniforme in tutti gli ambienti per usare in modo efficace le risorse distribuite.
Gli endpoint frontdoor di Azure possono gestire molti file. Un modo per ridurre i costi della larghezza di banda consiste nell'usare la compressione.
Usare la memorizzazione nella cache in Frontdoor di Azure per il contenuto che non cambia spesso. Poiché il contenuto viene fornito da una cache, è possibile risparmiare sui costi di larghezza di banda sostenuti quando la richiesta viene inoltrata alle origini.
Prendere in considerazione l'uso di un'istanza condivisa fornita dall'organizzazione. I costi sostenuti dai servizi centralizzati vengono condivisi tra i carichi di lavoro. Tuttavia, si consideri il compromesso con l'affidabilità . Per le applicazioni cruciali con requisiti di disponibilità elevata, è consigliabile un'istanza autonoma.
prestare attenzione alla quantità di dati registrati. I costi correlati alla larghezza di banda e all'archiviazione possono accumularsi se determinate richieste non sono necessarie o se i dati di registrazione vengono conservati per un lungo periodo di tempo.
Consigli
Raccomandazione | Beneficio |
---|---|
Usa il caching per gli endpoint che lo supportano. | La memorizzazione nella cache ottimizza i costi di trasferimento dei dati perché riduce il numero di chiamate dall'istanza di Frontdoor di Azure all'origine. |
Valutare la possibilità di abilitare la compressione dei file. Per questa configurazione, l'applicazione deve supportare la compressione e la memorizzazione nella cache. |
La compressione riduce il consumo di larghezza di banda e migliora le prestazioni. |
Disabilitare i controlli di integrità nei gruppi di origine con una singola origine. Se nel gruppo di origine di Frontdoor di Azure è configurata una sola origine, queste chiamate non sono necessarie. |
È possibile risparmiare sui costi della larghezza di banda disabilitando le richieste di controllo integrità che non sono necessarie per prendere decisioni di routing. |
Eccellenza operativa
L'eccellenza operativa si concentra principalmente sulle pratiche di sviluppo , l'osservabilità e la gestione dei rilasci.
I principi di progettazione dell'eccellenza operativa forniscono una strategia di progettazione di alto livello per raggiungere tali obiettivi dei requisiti operativi del carico di lavoro.
Elenco di controllo per la progettazione
Inizia la tua strategia progettuale basata sull'elenco di controllo della revisione del design per l'Eccellenza Operativa, definendo i processi per l'osservabilità, il testing e la distribuzione relativi ad Azure Front Door.
Usare tecnologie IaC (Infrastructure as Code). Usare tecnologie IaC come i modelli Bicep e i modelli di Azure Resource Manager per effettuare il provisioning dell'istanza di Azure Front Door. Questi approcci dichiarativi offrono coerenza e manutenzione semplice. Ad esempio, usando le tecnologie IaC, è possibile adottare facilmente nuove versioni del set di regole. Usare sempre la versione più recente dell'API.
Semplificare le configurazioni. Usare Frontdoor di Azure per gestire facilmente le configurazioni. Si supponga, ad esempio, che l'architettura supporti i microservizi. Frontdoor di Azure supporta funzionalità di reindirizzamento, quindi è possibile usare il reindirizzamento basato sul percorso per indirizzare i singoli servizi. Un altro caso d'uso è la configurazione dei domini wildcard.
Gestire l'esposizione progressiva. Front Door di Azure offre diversi metodi di instradamento. Per un approccio di bilanciamento del carico ponderato , è possibile utilizzare un canary deployment per inviare una percentuale specifica di traffico verso l'origine. Questo approccio consente di testare nuove funzionalità e versioni in un ambiente controllato prima di implementarle.
Raccogliere e analizzare i dati operativi come parte del monitoraggio del carico di lavoro. Acquisire i log e le metriche pertinenti di Azure Front Door con i log di Azure Monitor. Questi dati consentono di risolvere i problemi, comprendere i comportamenti degli utenti e ottimizzare le operazioni.
la gestione dei certificati offload in Azure. Ridurre il carico operativo associato alla rotazione e ai rinnovi della certificazione.
Consigli
Raccomandazione | Beneficio |
---|---|
Usare reindirizzamento da HTTP a HTTPS per supportare la compatibilità futura. | Quando il reindirizzamento è abilitato, Frontdoor di Azure reindirizza automaticamente i client che usano il protocollo precedente per usare HTTPS per un'esperienza sicura. |
Acquisire log e metriche. Includere i log delle attività delle risorse, i log di accesso, i log delle sonde di integrità e i log WAF. Configurare gli avvisi. |
Il monitoraggio del flusso di ingresso è una parte fondamentale del monitoraggio di un'applicazione. Si vogliono tenere traccia delle richieste e apportare miglioramenti alle prestazioni e alla sicurezza. Sono necessari dati per eseguire il debug della configurazione di Frontdoor di Azure. Con gli avvisi sul posto, è possibile ricevere notifiche istantanee di eventuali problemi operativi critici. |
Esaminare i rapporti di analisi integrati . | Una visualizzazione olistica del profilo frontdoor di Azure consente di migliorare il traffico e i report di sicurezza tramite le metriche WAF. |
Usare certificati TLS gestiti quando possibile. | Frontdoor di Azure può rilasciare e gestire automaticamente i certificati. Questa funzionalità elimina la necessità di rinnovi dei certificati e riduce al minimo il rischio di interruzione a causa di un certificato TLS non valido o scaduto. |
Usare certificati TLS wildcard. | Non è necessario modificare la configurazione per aggiungere o specificare ogni sottodominio separatamente. |
Efficienza delle prestazioni
L'efficienza delle prestazioni riguarda mantenere l'esperienza utente anche quando si verifica un aumento del carico attraverso la gestione della capacità. Le strategie includono il ridimensionamento delle risorse, l'identificazione e l'ottimizzazione dei potenziali colli di bottiglia, e l'ottimizzazione delle prestazioni al massimo livello.
I principi di progettazione efficienza delle prestazioni forniscono una strategia di progettazione di alto livello per raggiungere tali obiettivi di capacità rispetto all'utilizzo previsto.
Elenco di controllo per la progettazione
Inizia la tua strategia di progettazione basandoti sull'elenco di controllo per la revisione della progettazione per l'Efficienza delle Prestazioni. Definire una baseline basata sugli indicatori di prestazioni chiave per Frontdoor di Azure.
Pianificare la capacità analizzando i modelli di traffico previsti. Eseguire test approfonditi per comprendere le prestazioni dell'applicazione in carichi diversi. Prendere in considerazione fattori come transazioni simultanee, tassi di richiesta e trasferimento dei dati.
Scegliere gli SKU in base a tale pianificazione. Lo SKU Standard è più conveniente e adatto per scenari di traffico moderato. Se si prevede carichi più elevati, è consigliabile usare lo SKU Premium.
Analizzare i dati sulle prestazioni esaminando regolarmente le metriche delle prestazioni. report di Azure Front Door forniscono informazioni dettagliate su varie metriche che fungono da indicatori di prestazioni a livello tecnologico.
Usare i report di Frontdoor di Azure per impostare obiettivi di prestazioni realistici per il carico di lavoro. Prendere in considerazione fattori come tempi di risposta, velocità effettiva e percentuali di errore. Allineare le destinazioni ai requisiti aziendali e alle aspettative degli utenti.
Ottimizzare i trasferimenti di dati.
Usare la memorizzazione nella cache per ridurre la latenza nella gestione di contenuto statico, ad esempio immagini, fogli di stile e file JavaScript o contenuto che non cambia di frequente.
Ottimizzare l'applicazione per la memorizzazione nella cache. Usare le intestazioni di scadenza della cache nell'applicazione che controllano per quanto tempo il contenuto deve essere memorizzato nella cache dai client e dai proxy. La validità della cache più lunga indica richieste meno frequenti al server di origine, con un traffico ridotto e una latenza inferiore.
Ridurre le dimensioni dei file trasmessi in rete. I file più piccoli comportano tempi di caricamento più rapidi e un'esperienza utente migliorata.
Ridurre al minimo il numero di richieste back-end nell'applicazione.
Ad esempio, una pagina Web visualizza profili utente, ordini recenti, saldi e altre informazioni correlate. Anziché effettuare richieste separate per ogni set di informazioni, usare i modelli di progettazione per strutturare l'applicazione in modo che più richieste vengano aggregate in una singola richiesta.
Aggiornare i client per usare il protocollo HTTP/2 , che può combinare più richieste in una singola connessione TCP.
Usare WebSocket per supportare la comunicazione full-duplex in tempo reale, anziché effettuare richieste HTTP ripetute o eseguire il polling.
Aggregando le richieste, si inviano meno dati tra il front-end e il back-end e si stabiliscono meno connessioni tra il client e il back-end, riducendo così il sovraccarico. Inoltre, Frontdoor di Azure gestisce un minor numero di richieste, che impedisce l'overload.
Ottimizzare l'uso delle sonde di salute. Ottenere informazioni sulla salute dalle sonde di salute solo quando lo stato delle origini cambia. Bilanciare l'accuratezza del monitoraggio e ridurre al minimo il traffico non necessario.
Le sonde di integrità sono generalmente utilizzate per valutare l'integrità di più origini all'interno di un gruppo. Se nel gruppo di origine di Azure Front Door hai configurato solo un'origine, disabilita le sonde di integrità per ridurre il traffico non necessario sul tuo server di origine. Poiché è presente una sola istanza, lo stato della sondaggio di integrità non influirà sul routing.
Esaminare il metodo di routing di origine. Frontdoor di Azure offre diversi metodi di routing, tra cui il routing basato sulla latenza, basato su priorità, ponderato e basato sull'affinità di sessione, all'origine. Questi metodi influiscono significativamente sulle prestazioni dell'applicazione. Per maggiori informazioni sulla migliore opzione di instradamento del traffico per il tuo scenario, consultare i metodi di instradamento del traffico all'origine.
Esaminare la posizione dei server di origine. La posizione dei server di origine influisce sulla velocità di risposta dell'applicazione. I server di origine devono essere più vicini agli utenti. Frontdoor di Azure garantisce agli utenti da una posizione specifica di accedere al punto di ingresso di Frontdoor di Azure più vicino. I vantaggi delle prestazioni includono un'esperienza utente più rapida, un migliore uso del routing basato sulla latenza da Parte di Frontdoor di Azure e un tempo di trasferimento dei dati ridotto al minimo usando la memorizzazione nella cache, che archivia il contenuto più vicino agli utenti.
Per altre informazioni, vedere rapporto del traffico per posizione.
Consigli
Raccomandazione | Beneficio |
---|---|
Abilitare la memorizzazione nella cache. È possibile ottimizzare stringhe di query per la memorizzazione nella cache. Per il contenuto puramente statico, ignorare le stringhe di query per ottimizzare l'uso della cache. Se l'applicazione usa stringhe di query, prendere in considerazione la possibilità di includerle nella chiave della cache. L'inclusione delle stringhe di query nella chiave della cache consente a Frontdoor di Azure di gestire risposte memorizzate nella cache o altre risposte, in base alla configurazione. |
Frontdoor di Azure offre una soluzione di rete per la distribuzione di contenuti affidabile che memorizza nella cache il contenuto nella rete perimetrale. La memorizzazione nella cache riduce il carico sui server di origine e riduce lo spostamento dei dati attraverso la rete, il che aiuta a ottimizzare l'utilizzo della larghezza di banda. |
Usare la compressione dei file quando si accede al contenuto scaricabile. | La compressione in Frontdoor di Azure consente di distribuire contenuto nel formato ottimale, ha un payload più piccolo e distribuisce più velocemente il contenuto agli utenti. |
Quando si configurano i probe di integrità in Azure Front Door, è consigliabile usare richieste di HEAD anziché richieste di GET . Il sonda di diagnostica legge solo il codice di stato, non il contenuto. |
Le richieste HEAD consentono di esaminare una modifica dello stato senza recuperare l'intero contenuto. |
Valuta se è necessario abilitare affinità di sessione quando le richieste dello stesso utente devono essere indirizzate allo stesso server di origine. Dal punto di vista dell'affidabilità, questo approccio non è consigliato. Se si usa questa opzione, l'applicazione deve essere ripristinata normalmente senza interrompere le sessioni utente. Esiste anche un compromesso sul bilanciamento del carico perché limita la flessibilità della distribuzione uniforme del traffico tra più origini. |
Ottimizzare le prestazioni e mantenere la continuità per le sessioni utente, soprattutto quando le applicazioni si basano sulla gestione delle informazioni sullo stato in locale. |
Criteri di Azure
Azure offre un set completo di criteri predefiniti correlati a Frontdoor di Azure e alle relative dipendenze. È possibile controllare alcune delle raccomandazioni precedenti tramite Criteri di Azure. Ad esempio, è possibile verificare se:
- È necessario il livello Premium per supportare le regole WAF gestite e il collegamento privato nei profili frontdoor di Azure.
- È necessario usare la versione minima di TLS, ovvero la versione 1.2.
- È necessaria una connettività sicura e privata tra i servizi Frontdoor di Azure Premium e PaaS di Azure.
- È necessario abilitare i log delle risorse. L'ispezione del corpo della richiesta deve essere abilitata nel WAF.
- È necessario usare i criteri per applicare il set di regole WAF. Ad esempio, è necessario abilitare la protezione del bot e attivare regole di limitazione della frequenza.
Per una governance completa, vedere le definizioni predefinite di per la rete per la distribuzione di contenuti di Azure e altri criteri frontdoor di Azure elencati in definizioni di criteri predefiniti di Criteri di Azure.
Raccomandazioni di Azure Advisor
Azure Advisor è un consulente cloud personalizzato che consente di seguire le procedure consigliate per ottimizzare le distribuzioni di Azure. Le raccomandazioni di Advisor sono allineate ai pilastri di Well-Architected Framework.
Per altre informazioni, vedere le raccomandazioni in Azure Advisor.
Passaggi successivi
Considerare gli articoli seguenti come risorse che illustrano le raccomandazioni evidenziate in questo articolo.
- Usare le architetture di riferimento seguenti come esempi di come applicare le linee guida di questo articolo a un carico di lavoro:
- Creare competenze di implementazione usando la documentazione del prodotto seguente: