Microsoft AZ-204: Caching, CDN e Prestazioni di Azure — Guida allo studio

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Fa parte della Microsoft Azure Developer Associate AZ-204 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Azure Front Door: routing globale, integrità, sicurezza e affinità

Azure Front Door offre bilanciamento del carico globale di tipo anycast a livello 7, accelerazione dinamica dei siti e WAF integrato. Completa la CDN instradando e proteggendo il traffico dinamico, con la possibilità di memorizzare nella cache contenuti statici nelle versioni Standard/Premium.

Regole di routing:

• Abbinano i nomi host e i pattern di percorso in ingresso e li instradano a un gruppo di origini (pool di backend). Applicano riscrittura dei percorsi, trasformazione degli header, reindirizzamenti e impostazioni di protocollo per ogni regola.
• Configurano il caching a livello di rotta (Standard/Premium) per la memorizzazione nella cache perimetrale (edge caching) di asset statici o semi-statici quando si desidera un controllo più granulare sull’edge dell’applicazione.
• Utilizzano il failover basato sulla priorità e il bilanciamento del carico ponderato tra le origini, opzionalmente con geo-filtro per un routing specifico per regione.

Probe di integrità e stato dei backend:

• Definiscono il percorso del probe, il protocollo, l’intervallo e i codici di stato HTTP attesi. I probe vengono eseguiti da più posizioni edge per determinare lo stato di integrità dell’origine.
• Front Door utilizza lo stato di integrità per indirizzare il traffico verso le origini integre con bassa latenza. È necessario ottimizzare i timeout e la dimensione del campione per evitare il flapping; assicurarsi che l’endpoint del probe sia leggero e non memorizzato nella cache.

Integrazione WAF:

• Associano una policy WAF a Front Door per applicare set di regole gestite per le vulnerabilità web comuni e aggiungere regole personalizzate per restrizioni IP, geoblocking o limiti sulla dimensione delle richieste.
• Utilizzano la protezione dai bot e il rate limiting per assorbire il traffico abusivo sull’edge, preservando la capacità dell’origine.

Affinità di sessione:

• Abilitano l’affinità di sessione quando l’applicazione richiede che richieste consecutive raggiungano lo stesso backend (ad es. stato di sessione non distribuito). Front Door inserisce un cookie di affinità e instrada le richieste successive della stessa sessione al backend selezionato all’interno di una regola di routing.
• Preferire design stateless o uno stato di sessione basato su Redis per evitare l’affinità quando possibile; se utilizzata, definire attentamente l’ambito dell’affinità e impostare TTL appropriati per i cookie.

Interazione con la CDN:

• La CDN dovrebbe servire asset statici (immagini, script, media) con TTL lunghi; Front Door instrada le richieste dinamiche con WAF, terminazione TLS e routing basato sul percorso. Questa suddivisione massimizza i tassi di riscontro nella cache (cache hit rate) e minimizza la latenza dinamica.
• Per API o pagine che non possono essere memorizzate nella cache, mantenere un TTL basso o bypassare il caching; per l’HTML semi-statico, considerare TTL brevi con flussi di lavoro di eliminazione (purge) al momento della modifica.

Scenario pratico

Mozilla sta lanciando un microsito globale per la scoperta di add-on, con picchi di traffico elevati durante i rilasci. Hanno bisogno di una distribuzione rapida degli asset statici, API dinamiche resilienti e interazioni utente sicure e a bassa latenza in tutto il mondo.

1. Front Door per l’ingresso globale e la sicurezza

• Creare un profilo Front Door Standard con dominio personalizzato e TLS gestito. Definire le regole di routing: /api/* verso il gruppo di origini dell’API App Service e /* verso il nome host dell’endpoint CDN.
• Perché: Il routing anycast porta gli utenti all’edge più vicino; il WAF su Front Door blocca i pattern malevoli prima che raggiungano le origini; il routing basato sul percorso separa nettamente il traffico dinamico da quello statico.

2. Policy WAF e rate limiting

• Associare una policy WAF con i set di regole gestite abilitati e una regola personalizzata per limitare (throttle) le richieste POST eccessive a /api/search.
• Perché: Protegge le API da attacchi di classe OWASP e da client abusivi, preservando la capacità dell’origine durante i picchi.

3. Probe di integrità e gruppi di origini

• Configurare un gruppo di origini API con due istanze di App Service in regioni diverse. Usare probe di integrità su /healthz con stato atteso 200 e un intervallo di 10 secondi. Impostare una regione con priorità 1 e l’altra con priorità 2, con failover.
• Perché: Assicura un failover regionale automatico se la regione primaria si degrada; i probe rilevano lo stato di integrità indipendentemente dalle risposte memorizzate nella cache.

4. Sessione basata su Redis e caching dell’output

• Distribuire Azure Cache for Redis Standard e integrare l’API con IDistributedCache per memorizzare uno stato di sessione minimo e frammenti di output di breve durata per risposte API comuni (ad es. elenchi di add-on popolari) con TTL di 60–300 secondi.
• Perché: Riduce la latenza delle API e il carico sul database mantenendo lo stato al di fuori del livello web; TTL brevi mantengono i dati aggiornati senza invalidazione manuale.

5. Strutture dati Redis per le classifiche (leaderboard)

• Usare un set ordinato (sorted set) di Redis per categoria (ad es. addons:top:{category}) per mantenere classifiche basate sui download. Aggiornare i punteggi in modo asincrono tramite un consumer di coda ed esporre API di lettura che leggono le prime N voci.
• Perché: I set ordinati offrono aggiornamenti in O(log n) e letture di intervalli (range read) veloci, perfetti per classifiche in tempo reale con alta concorrenza in lettura.

6. Resilienza della connessione con StackExchange.Redis

• Inizializzare un singleton ConnectionMultiplexer con ssl=True, abortConnect=False, connectRetry=5 e timeout ragionevoli. Gestire gli eventi ConnectionFailed/Restored per l’osservabilità e impostare SyncTimeout a un valore sufficientemente alto per i picchi, utilizzando al contempo le API asincrone.
• Perché: Assicura una gestione trasparente del failover ed evita interruzioni a livello di processo durante eventi di rete transitori o failover di Redis.

7. CDN per asset statici con caching aggressivo

• Creare un profilo e un endpoint Azure CDN ottimizzati per la “distribuzione web generica” (General web delivery) con il sito web statico dell’account di archiviazione come origine. Configurare le regole di caching per rispettare gli header di origine, ma sovrascriverli con un TTL di 7 giorni per /static/*, e abilitare la compressione. Impostare il caching delle stringhe di query su “Memorizza nella cache ogni URL univoco” (Cache every unique URL) e usare il fingerprinting per gli asset (app.css?v=hash).
• Perché: Il caching perimetrale (edge caching) distribuisce gli asset rapidamente in tutto il mondo; il fingerprinting consente TTL lunghi con aggiornamenti istantanei durante i deploy; la compressione riduce le dimensioni dei trasferimenti.

8. Processo di eliminazione (purge) nella CI/CD

• Aggiungere uno step di deployment che elimina (purge) i percorsi CDN per i manifest HTML e JSON al momento del rilascio (ad es. /index.html, /manifest/*.json) e precarica le pagine critiche per avere cache calde (warm cache) nei tier supportati.
• Perché: Assicura che gli utenti ricevano rapidamente l’HTML aggiornato mantenendo nella cache gli asset immutabili; il precaricamento riduce la latenza di avvio a freddo (cold-start) dopo il deploy.

9. Affinità di sessione di Front Door solo dove necessario

• Mantenere le API stateless e affidarsi a Redis per lo stato di sessione; disabilitare l’affinità di sessione di Front Door per le rotte /api/*. Per uno strumento di amministrazione legacy che richiede affinità, abilitarla su /admin/* con un TTL breve.
• Perché: Massimizza la distribuzione del carico e la “cacheability” per la maggior parte degli utenti, limitando l’affinità all’ambito minimo richiesto.

Questa architettura utilizza Front Door per un routing perimetrale (edge routing) sicuro e intelligente e per il WAF, Azure CDN per la distribuzione di contenuti statici con un alto tasso di riscontro nella cache (hit-rate) e un controllo preciso dell’aggiornamento, e Azure Cache for Redis per alleggerire il carico delle letture a caldo (hot read), mantenere dati di sessione e classifiche a bassa latenza e assorbire i picchi in modo controllato.

← Soluzioni Basate su Eventi e Messaggi di Azure · Tutti i domini · Monitoraggio →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Microsoft →