Prospettiva di Azure Well-Architected Framework in Frontdoor di Azure

  • Articolo

Frontdoor di Azure è un servizio di bilanciamento del carico globale e una rete per la distribuzione di contenuti che instrada il traffico HTTP e HTTPS. Frontdoor di Azure distribuisce e distribuisce il traffico più vicino agli utenti dell'applicazione.

Questo articolo presuppone che in qualità di architetto siano state esaminate le opzioni di bilanciamento del carico e sia stato scelto Frontdoor di Azure come servizio di bilanciamento del carico per il carico di lavoro. Presuppone inoltre 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 per la progettazione che presenta aree architetturali di interesse e strategie di progettazione 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. Elencano invece le raccomandazioni principali mappate alle prospettive di progettazione. Usare i consigli per creare un modello di verifica o ottimizzare gli ambienti esistenti.

Architettura di base che illustra le raccomandazioni chiave: architettura di base cruciale 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 creando una resilienza sufficiente e la possibilità di recuperare rapidamente gli 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 pertinenza per i requisiti aziendali tenendo presente i livelli e le funzionalità della rete per la distribuzione di contenuti di Azure. Estendere la strategia in modo da includere più approcci in base alle esigenze.

  • Stimare il modello di traffico e il volume. Il numero di richieste dal client al perimetro frontdoor di Azure può influire sulla scelta del livello. Se è necessario supportare un volume elevato di richieste, prendere in considerazione il livello Azure Frontdoor Premium perché le prestazioni influisce infine sulla disponibilità. Tuttavia, c'è un compromesso dei costi. Questi livelli sono descritti in Efficienza delle prestazioni.

  • Scegliere la strategia di distribuzione. Gli approcci fondamentali alla distribuzione sono attivi-attivi e attivi-passivi. La distribuzione attiva-attiva indica che più ambienti o timbri che eseguono il carico di lavoro gestiscono 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 multiregione, i francobolli vengono eseguiti in aree diverse per una maggiore disponibilità con un servizio di bilanciamento del carico globale, ad esempio Frontdoor di Azure, che distribuisce il traffico. È quindi importante configurare il servizio di bilanciamento del carico per l'approccio di distribuzione appropriato.

    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 il minimo possibile ridimensionamento e ridimensionamento dei dati e viene eseguito senza carico. In caso di failover, le risorse di calcolo e dati sono ridimensionate per gestire il carico dall'area primaria. Per altre informazioni, vedere Strategie di progettazione chiave per la progettazione di più aree.

    Alcune applicazioni richiedono che le connessioni utente rimangano 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 Frontdoor di Azure e nei server di origine. Per garantire che i cookie o gli URL di reindirizzamento funzionino correttamente, mantenere il nome host HTTP originale quando si usa un proxy inverso, ad esempio un servizio di bilanciamento del carico, davanti a un'applicazione Web.

  • Implementare il modello di monitoraggio degli endpoint di integrità. L'applicazione deve esporre gli endpoint di integrità, che aggregano lo stato dei servizi critici e delle dipendenze che l'applicazione deve gestire le richieste. I probe di integrità di Frontdoor di Azure usano l'endpoint per rilevare l'integrità dei server di origine. Per altre informazioni, vedere Modello di monitoraggio degli endpoint di integrità.

  • Sfruttare le funzionalità di rete per la distribuzione di contenuti predefinite in Frontdoor di Azure. La funzionalità di rete per la distribuzione di contenuti di Frontdoor di Azure ha centinaia di posizioni perimetrali e può aiutare a resistere agli attacchi DDoS (Distributed Denial of Service). Queste funzionalità consentono di migliorare l'affidabilità.

  • Si consideri un'opzione di gestione del traffico ridondante. Frontdoor di Azure è un servizio distribuito a livello globale che viene eseguito come singleton in un ambiente. Frontdoor di Azure è un singolo punto di errore potenziale 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. Si considerino solo per carichi di lavoro cruciali con una tolleranza molto bassa all'interruzione del servizio. Considerare attentamente i compromessi.

Consigli

Recommendation Vantaggi
Scegliere un metodo di routing che supporti 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 i modelli attivi-passivi.

Combinare i metodi precedenti con 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 peso specificato.
Supportare la ridondanza avendo più origini in uno o più pool back-end.

Avere sempre istanze ridondanti dell'applicazione e assicurarsi che ogni istanza esponga un endpoint o un'origine. È possibile inserire tali origini in uno o più pool back-end.		 Più origini supportano la ridondanza distribuendo il traffico tra più istanze dell'applicazione. Se un'istanza non è disponibile, altre origini back-end possono comunque ricevere traffico.
Configurare i probe di integrità nell'origine.

Configurare Frontdoor di Azure per eseguire controlli di integrità per determinare se l'istanza back-end è disponibile e pronta per continuare a ricevere le richieste.		 I probe di integrità abilitati fanno parte dell'implementazione del modello di monitoraggio dell'integrità. I probe di integrità assicurano che Frontdoor di Azure instrada solo il traffico alle istanze sufficientemente integre per gestire le richieste.
Per altre informazioni, vedere Procedure consigliate per i probe di integrità.
Impostare un timeout sull'inoltro delle richieste al back-end.

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.		 I timeout consentono di evitare problemi di prestazioni e problemi di disponibilità terminando le richieste che richiedono più tempo del previsto.
Usare lo stesso nome host in Frontdoor di Azure e l'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 della richiesta e il reindirizzamento URL.		 Impostare lo stesso nome host per evitare malfunzionamenti con affinità di sessione, autenticazione e autorizzazione. Per altre informazioni, vedere Mantenere il nome host HTTP originale tra un proxy inverso e l'applicazione Web back-end.
Decidere se l'applicazione richiede l'affinità di sessione. Se si hanno requisiti di affidabilità elevati, è consigliabile disabilitare l'affinità di sessione. Con l'affinità di sessione, le connessioni utente rimangono nella stessa origine durante la sessione utente. Se l'origine diventa non 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 frequenza può aiutare a evitare problemi come una tempesta di tentativi.

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 per limitare il traffico proveniente da Frontdoor di Azure.

Elenco di controllo della progettazione

Avviare la strategia di progettazione in base all'elenco di controllo della revisione della progettazione per la sicurezza. Identificare le vulnerabilità e i controlli per migliorare il comportamento di sicurezza. Estendere la strategia per includere più approcci in base alle esigenze.

  • Esaminare la baseline di sicurezza per Frontdoor di Azure.

  • Proteggere i server back-end. Il front-end funge da singolo punto di ingresso all'applicazione.

    Frontdoor di Azure usa collegamento privato di Azure per accedere all'origine di un'applicazione. collegamento privato crea segmentazione in modo che i back-end non debbano esporre indirizzi IP pubblici e endpoint. Per altre informazioni, vedere Proteggere l'origine con collegamento privato in Frontdoor Premium di Azure.

    Configurare i servizi back-end per accettare solo le richieste con lo stesso nome host usato esternamente da Frontdoor di Azure.

  • Consenti solo l'accesso autorizzato al piano di controllo. Usare il controllo degli accessi in base al ruolo di Azure Frontdoor per limitare l'accesso solo alle identità necessarie.

  • Bloccare le minacce comuni al bordo. 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ù vicino all'origine di attacco. Considerare il filtro geografico per limitare l'accesso all'applicazione Web in base a paesi o aree geografiche.

    Per altre informazioni, vedere Azure Web application firewall in Frontdoor di Azure.

  • Proteggere Frontdoor di Azure dal traffico imprevisto. Frontdoor di Azure usa il piano di base della protezione DDoS di Azure 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 per tali indirizzi per le funzionalità avanzate di protezione e rilevamento.

    Esistono anche set di regole WAF che rilevano il traffico del bot o volumi imprevisti di traffico che potrebbero essere potenzialmente dannosi.

  • Proteggere i dati in transito. Abilitare i certificati TLS (Transport Layer Security) end-to-end, HTTP to HTTPS reindirizzamento e certificati TLS gestiti quando applicabile. Per altre informazioni, vedere Procedure consigliate TLS per Frontdoor di Azure.

  • Monitorare l'attività anomale. Esaminare regolarmente i log per verificare gli attacchi e i falsi positivi. Inviare log WAF da Frontdoor di Azure alle informazioni di sicurezza centralizzate dell'organizzazione e alla gestione degli eventi (SIEM), ad esempio Microsoft Sentinel, per rilevare i modelli di minaccia e incorporare misure preventive nella progettazione del carico di lavoro.

Consigli

Recommendation Vantaggi
Abilitare i set di regole WAF che rilevano e bloccano il traffico potenzialmente dannoso. Questa funzionalità è disponibile nel livello Premium. È consigliabile impostare questi set di regole:
- Predefinito
- Protezione bot
- Restrizione IP
- Filtro geografico
- Limitazione della velocità		 I set di regole predefiniti vengono aggiornati spesso in base ai tipi di attacco OWASP top-10 e alle informazioni di Microsoft Threat Intelligence.
I set di regole specializzate rilevano determinati casi d'uso. Ad esempio, le regole del bot classificano i bot come buoni, 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 al back-end. I servizi back-end devono essere consapevoli del nome host in modo che possano creare regole per accettare il traffico solo da tale host.
Abilitare TLS end-to-end, HTTP to HTTPS reindirizzamento e certificati TLS gestiti quando applicabile.

Esaminare le procedure consigliate TLS per Frontdoor di Azure.

Usare TLS versione 1.2 come versione minima consentita con crittografia 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 in Endpoint di dominio personalizzati di Frontdoor di Azure e archiviarli in Key Vault.		 TLS garantisce che gli scambi di dati tra il browser, Frontdoor di Azure e le origini back-end vengano crittografati per evitare manomissione.

Key Vault offre supporto certificato gestito e rinnovo e rotazione dei certificati semplici.

Ottimizzazione dei costi

L'ottimizzazione dei costi è incentrata sul rilevamento di modelli di spesa, sulla priorità degli investimenti in aree critiche e sull'ottimizzazione in altri utenti per soddisfare i requisiti aziendali dell'organizzazione.

I principi di progettazione dell'ottimizzazione dei costi forniscono una strategia di progettazione di alto livello per raggiungere tali obiettivi e rendere i compromessi in base alle esigenze nella progettazione tecnica correlata ad Azure Frontdoor e al relativo ambiente.

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. 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 piani e i prezzi di Frontdoor di Azure. Usare il calcolatore dei prezzi per stimare i costi realistici per ogni piano. 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 frequenza di unità superiore, ma si ottiene l'accesso ai vantaggi di sicurezza e alle funzionalità avanzate, ad esempio regole gestite in WAF e collegamento privato. Prendere in considerazione i compromessi sull'affidabilità e sulla sicurezza in base ai requisiti aziendali.

  • Prendere in considerazione i costi di larghezza di banda. I costi di larghezza di banda di Azure Frontdoor dipendono dal livello scelto e dal tipo di trasferimento dei dati. Frontdoor di Azure offre report predefiniti per le metriche fatturabili. Per valutare i costi correlati alla larghezza di banda e dove è possibile concentrarsi sugli sforzi 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 usando modelli di progettazione come Back-end per front-end e aggregazione gateway. 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 evitare 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 l'ottimizzazione delle risorse. A meno che il carico di lavoro non sia estremamente sensibile alla latenza, distribuire il traffico uniformemente in tutti gli ambienti per usare in modo efficace le risorse distribuite.

    Gli endpoint frontdoor di Azure possono servire 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 servito da una cache, è possibile risparmiare sui costi di larghezza di banda sostenuti quando la richiesta viene inoltrata ai back-end.

  • È consigliabile usare un'istanza condivisa fornita dall'organizzazione. I costi sostenuti dai servizi centralizzati vengono condivisi tra i carichi di lavoro. Si consideri tuttavia 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 relativi sia alla larghezza di banda che all'archiviazione possono accumularsi se alcune richieste non sono necessarie o se i dati di registrazione vengono conservati per un lungo periodo di tempo.

Consigli

Recommendation Vantaggi
Usare la memorizzazione nella cache 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 deve essere abilitata.		 La compressione riduce il consumo della larghezza di banda e migliora le prestazioni.
Disabilitare i controlli di integrità in pool back-end singoli.
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 che non sono necessarie per prendere decisioni di routing.

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 tali obiettivi per 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 la definizione dei processi di osservabilità, test e distribuzione correlati a Frontdoor di Azure.

  • Usare le tecnologie IaC (Infrastructure as Code). Usare tecnologie IaC come Bicep e i modelli di Azure Resource Manager per effettuare il provisioning dell'istanza di Frontdoor di Azure. 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 le funzionalità di reindirizzamento, quindi è possibile usare il reindirizzamento basato sul percorso per indirizzare singoli servizi. Un altro caso d'uso è la configurazione dei domini con caratteri jolly.

  • Gestire l'esposizione progressiva usando i metodi di routing di Frontdoor di Azure. Per un approccio ponderato al bilanciamento del carico , è possibile usare una distribuzione canary per inviare una percentuale specifica di traffico a un back-end. Questo approccio consente di testare nuove funzionalità e versioni in un ambiente controllato prima di implementarle.

  • Raccogliere e analizzare i dati operativi di Frontdoor di Azure come parte del monitoraggio del carico di lavoro. Acquisire i log e le metriche di Frontdoor di Azure pertinenti con i log di Monitoraggio di Azure. Questi dati consentono di risolvere i problemi, comprendere i comportamenti degli utenti e ottimizzare le operazioni.

  • Offload della gestione dei certificati in Azure. Ridurre il carico operativo associato alla rotazione e ai rinnovi della certificazione.

Consigli

Recommendation Vantaggi
Usare il reindirizzamento DA HTTP a HTTPS per supportare la compatibilità con l'inoltro. Quando il reindirizzamento è abilitato, Frontdoor di Azure reindirizza automaticamente i client che usano il protocollo meno recente per usare HTTPS per un'esperienza sicura.
Acquisire log e metriche.

Includere i log attività delle risorse, i log di accesso, i log dei probe 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 disponibili, è possibile ricevere notifiche istantanee di eventuali problemi operativi critici.
Esaminare i report di analisi predefiniti. Una visualizzazione olistica del profilo frontdoor di Azure consente di migliorare i miglioramenti in base al traffico e ai report di sicurezza tramite le metriche WAF.
Usare i 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 un'interruzione a causa di un certificato TLS non valido o scaduto.
Usare certificati TLS con caratteri jolly. Non è necessario modificare la configurazione per aggiungere o specificare ogni sottodominio separatamente.

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 di potenziali colli di bottiglia e l'ottimizzazione per le prestazioni di picco.

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 di revisione della progettazione per l'efficienza delle prestazioni. Definire una linea di base basata su 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, tariffe delle richieste e trasferimento dei dati.

    Basare le scelte dello SKU sulla pianificazione. Lo SKU Standard è più conveniente e adatto per scenari di traffico moderato. Se si prevedono carichi più elevati, è consigliabile usare lo SKU Premium.

  • Analizzare i dati sulle prestazioni esaminando regolarmente i report di Frontdoor di Azure. Questi report forniscono informazioni dettagliate su varie metriche che fungono da indicatori di prestazioni a livello di tecnologia.

    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 gli obiettivi 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 contenuti che non cambiano 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, il che comporta una riduzione del traffico 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 modelli di progettazione per strutturare l'applicazione in modo che più richieste vengano aggregate in una singola richiesta.

      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. Frontdoor di Azure gestisce anche un minor numero di richieste, che impedisce l'overload.

  • Ottimizzare l'uso dei probe di integrità. Ottenere informazioni sull'integrità dai probe di integrità solo quando lo stato delle origini cambia. Bilanciare l'accuratezza del monitoraggio e ridurre al minimo il traffico non necessario.

    I probe di integrità vengono in genere usati per valutare l'integrità di più origini all'interno di un gruppo. Se nel gruppo di origine di Frontdoor di Azure è stata configurata una sola origine, disabilitare i probe di integrità per ridurre il traffico non necessario nel server di origine. Poiché è presente una sola istanza, lo stato del probe 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 su latenza, basato su priorità, ponderato e basato sull'affinità di sessione, all'origine. Questi metodi influiscono in modo significativo sulle prestazioni dell'applicazione. Per altre informazioni sull'opzione di routing del traffico migliore per lo scenario, vedere Metodi di routing 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 che gli utenti di una posizione specifica accesino al punto di ingresso 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 tramite la memorizzazione nella cache, che archivia il contenuto più vicino agli utenti.

    Per altre informazioni, vedere Report Traffico per posizione.

Consigli

Recommendation Vantaggi
Abilitare la memorizzazione nella cache.

È possibile ottimizzare le 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, è consigliabile 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 il contenuto nella cache nella rete perimetrale della rete. La memorizzazione nella cache riduce il carico sui server back-end e riduce lo spostamento dei dati attraverso la rete, che consente di eseguire l'offload dell'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 il contenuto agli utenti più velocemente.
Quando si configurano i probe di GET integrità in Frontdoor di Azure, è consigliabile usare HEAD le richieste anziché le richieste.
Il probe di integrità legge solo il codice di stato, non il contenuto.		 HEAD le richieste consentono di eseguire query su una modifica dello stato senza recuperare l'intero contenuto.
Valutare se è necessario abilitare l'affinità di sessione quando le richieste dello stesso utente devono essere indirizzate allo stesso server back-end.

Dal punto di vista dell'affidabilità, questo approccio non è consigliato. Se si usa questa opzione, l'applicazione dovrebbe essere ripristinata normalmente senza interrompere le sessioni utente.

Esiste anche un compromesso sul bilanciamento del carico perché limita la flessibilità di distribuzione del traffico tra più back-end in modo uniforme.		 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 ampio set di criteri predefiniti correlati a Frontdoor di Azure e alle relative dipendenze. Alcune delle raccomandazioni precedenti possono essere controllate tramite Criteri di Azure. Ad esempio, è possibile verificare se:

  • È necessario il livello Premium per supportare le regole WAF gestite e 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. WAF deve avere l'ispezione del corpo della richiesta abilitata.
  • È necessario usare i criteri per applicare il set di regole WAF. Ad esempio, è necessario abilitare la protezione dei bot e attivare le regole di limitazione della frequenza.

Per una governance completa, vedere le definizioni predefinite per la rete per la distribuzione di contenuti di Azure e altri criteri frontdoor di Azure elencati in Criteri di Azure definizioni di criteri predefinite.

Raccomandazioni 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 di Frontdoor di Azure.

Passaggi successivi

Si considerino gli articoli seguenti come risorse che illustrano le raccomandazioni evidenziate in questo articolo.