Microsoft AZ-204: Azure Caching, CDN en Prestaties — Studiegids

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

Onderdeel van de Microsoft Azure Developer Associate AZ-204 — Studiegids. Oefen met geverifieerde antwoorden in het Microsoft-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Snelle, betrouwbare gebruikerservaringen in Azure zijn afhankelijk van het plaatsen van content en state dicht bij gebruikers, het minimaliseren van de belasting op de origin en het correct afhandelen van storingen. Azure Cache for Redis, Azure CDN en Azure Front Door bieden samen in-memory versnelling, edge caching en wereldwijde anycast-routing met beveiliging. Door Redis-datastructuren en verbindingspatronen, CDN-profielen en caching-semantiek, en Front Door-routing en health probes te beheersen, kunt u applicaties met lage latentie en hoge veerkracht ontwerpen.

Azure Cache for Redis: tiers, datastructuren, eviction en patronen

Azure Cache for Redis is een beheerde Redis-service die datatoegang biedt met een latentie van minder dan een milliseconde, en ondersteunt gangbare Redis-datastructuren en geavanceerde mogelijkheden in de hogere tiers.

Tiers:

Basic: Single-node cache zonder SLA en zonder datareplicatie. Goed voor dev/test en niet-kritieke workloads. Geen datapersistentie, geen clustering, geen VNet-integratie.
Standard: Twee-node primary/replica met automatische failover en een SLA. Geschikt voor productie. Ondersteunt op- en afschalen met minimale onderbreking, maar geen clustering of persistentie.
Premium: Hogere prestaties en doorvoersnelheid, grotere cache-omvang, Redis-persistentie (RDB en AOF), clustering (sharding) voor horizontale schaalbaarheid, integratie met virtuele netwerken, zoneredundantie (in ondersteunde regio’s) en geo-replicatie voor DR. Ondersteunt ook geplande patch-vensters en geavanceerde beveiliging.

Datastructuren en wanneer ze te gebruiken:

Strings: Basis key/value, tellers, JSON-blobs; atomische INCR/DECR voor rate limiting en tellers.
Hashes: Sla objectvelden (bijv. gebruikersprofiel) op als een enkele sleutel met veld-waardeparen voor gedeeltelijke updates en efficiënt ruimtegebruik.
Lists: Wachtrijen of stacks, geordend op invoeging; gebruik met LPUSH/BRPOP voor eenvoudige work queues.
Sets: Unieke verzamelingen; gebruik voor tags, lidmaatschapscontroles, doorsnedes.
Sorted Sets: Ranglijsten met scores; ideaal voor leaderboards en op tijd geordende gebeurtenissen.
Bitmaps/Bitfields: Compact bijhouden van booleaanse vlaggen en tellers over posities.
HyperLogLog: Geschatte cardinaliteit (unieke tellingen) met vast geheugengebruik.
Geospatial: Opslaan en bevragen van lat/long-coördinaten, zoekopdrachten binnen een straal.
Streams: Append-only log voor event-ingestie en consumer groups.

Eviction-beleid (toegepast wanneer maxmemory is bereikt):

volatile-lru: Verwijder de minst recent gebruikte sleutels met een vervaltijd (standaard op Azure Cache for Redis).
allkeys-lru: Verwijder de minst recent gebruikte sleutels, ongeacht de vervaltijd.
volatile-ttl: Verwijder sleutels met de dichtstbijzijnde vervaltijd.
volatile-random / allkeys-random: Verwijder willekeurige sleutels, beperkt tot sleutels die vervallen of alle sleutels.
noeviction: Niet verwijderen; schrijfopdrachten die geheugen zouden toevoegen, mislukken met een foutmelding.
volatile-lfu / allkeys-lfu: Varianten voor het verwijderen van de minst frequent gebruikte sleutels (voor nieuwere Redis-versies).

Kies het eviction-beleid op basis van de kriticiteit van de data en de toegangspatronen. Voor caches geven allkeys-lru of allkeys-lfu de beste hit rates. Voor gemengde opslag met zorgvuldig ingestelde vervaltijden kunnen volatile-ttl of volatile-lru uw TTL’s respecteren.

Veelvoorkomende use cases:

Sessie-caching: Sla de status van gebruikerssessies op via IDistributedCache of sessie-middleware. Houd sleutels klein, gebruik een TTL die is afgestemd op de sessie-timeout en schakel indien nodig sessie-affiniteit in op de edge.
Output-caching: Cache gerenderde paginafragmenten of volledige responsen, gesleuteld op route en gebruikerssegment. Invalideer bij inhoudswijzigingen met behulp van key-versioning of een expliciete DEL.
Pub/Sub: Bijna real-time messaging voor notificaties of fan-out voor cache-invalidatie. Gebruik channels om wijzigingen naar meerdere subscribers te broadcasten.
Leaderboards: Sorted sets met scores voor ranglijsten; ZADD/ZREVRANGE om top-N bij te werken en te lezen; gebruik secundaire sorted sets voor ranglijsten binnen een tijdvenster.

Verbinding maken met Azure Redis: connection strings, StackExchange.Redis en veerkracht

Verbindings-endpoints en sleutels vindt u in de Azure-portal onder Access keys. De primaire connection string bevat host, poort, TLS en wachtwoord (bijvoorbeeld contoso.redis.cache.windows.net:6380,password=…;ssl=True;abortConnect=False). Gebruik in productie altijd TLS op poort 6380.

StackExchange.Redis best practices:

Gebruik één enkele, langdurige ConnectionMultiplexer per proces. Deze is thread-safe en multiplext verzoeken efficiënt. Maak hem één keer aan, sla hem op in een static- of DI-container en hergebruik hem.
Configuratie-opties: stel AbortOnConnectFail=false in voor tolerantie voor cloud-failover; stel ConnectRetry en ConnectTimeout in voor tijdelijke problemen; SyncTimeout afgestemd op de workload; KeepAlive om NAT-pinholes open te houden. Voorbeeldopties in tekstvorm: ssl=True, abortConnect=False, connectRetry=5, connectTimeout=5000.
Gebruik async-methoden om uitputting van de thread pool onder belasting te voorkomen. IDatabase-methoden (StringGetAsync, HashSetAsync, SortedSetAddAsync) zijn niet-blokkerend.
Behandel veerkracht-events: abonneer u op ConnectionFailed-, ConnectionRestored- en ConfigurationChanged-events om topologiewijzigingen en failovers te loggen en te observeren. StackExchange.Redis lost automatisch de primaire node opnieuw op bij een failover.
Vermijd langlopende Lua-scripts en zware transacties; geef de voorkeur aan kleine, atomische commando’s. Pipelining gebeurt natuurlijk via de multiplexer; batch niet te veel tot het punt van timeouts.
Timeouts en retries: probeer niet-idempotente commando’s niet blindelings opnieuw uit te voeren. Gebruik idempotente patronen of write-through wachtrijen voor kritieke schrijfacties.
Serialisatie: sla compacte payloads op (bijv. MessagePack) om netwerkverkeer en geheugengebruik te minimaliseren. Vermijd gigantische waarden; geef de voorkeur aan hashes met toegang op veldniveau.
Naamgeving van sleutels: gebruik een prefix per app/omgeving (prod:session:{userId}) om botsingen te vermijden en bulkoperaties en opschoning te vereenvoudigen.
Beveiliging: roteer toegangssleutels, beperk toegang via VNet (Premium) en overweeg Private Link voor private toegang. Zet ‘Allow access only via SSL’ in productie niet op ‘false’.

Azure CDN: profielen, eindpunten, origins, optimalisatie en versheid van content

Azure CDN slaat statische content op in edge POP’s om de latentie te verminderen en de belasting op de origin te verlagen. Een CDN-profiel groepeert eindpunten en een prijscategorie/provider; een eindpunt definieert de edge-hostnaam en maakt verbinding met een of meer origins.

Profielen en eindpunten:

Maak een of meer eindpunten per applicatie of omgeving aan onder een profiel. Elk eindpunt heeft zijn eigen edge-hostnaam (bijv. app.azureedge.net) die u koppelt aan aangepaste domeinen met TLS.
Gebruik afzonderlijke profielen om de facturering te isoleren of om, indien nodig, verschillende providers/functies toe te passen.

Origin-types:

Azure Blob Storage: Ideaal voor statische websites en grote mediabestanden. Schakel ‘Static website’ in of koppel aan een container; zorg voor de juiste MIME-types en cache-headers.
App Service: Gebruik voor dynamische content of REST API’s waarbij geselecteerde responses in de cache kunnen worden opgeslagen. Configureer de origin-hostheader naar de hostnaam van uw app en zorg voor HTTPS.
Custom origin: Elk publiek bereikbaar HTTP(S)-eindpunt, inclusief on-premises via een openbaar IP-adres of reverse proxy.

Optimalisatietypes (toegepast bij het aanmaken van een eindpunt):

General web delivery: Gebalanceerd voor veel kleine/middelgrote assets (HTML, CSS, JS, afbeeldingen) met een brede dekking van POP’s.
Large file download: Geoptimaliseerd voor grote bestanden met afstemming van ‘range requests’, verbindingsbeheer en instellingen gericht op doorvoersnelheid.
Video streaming: Geoptimaliseerd voor ‘progressive download’ of de levering van HLS/DASH-segmenten, waarbij de caching van segmenten efficiënt blijft en ‘byte-range requests’ worden gerespecteerd.

Cachingregels en purgen:

Globale en aangepaste cachingregels stellen u in staat om TTL’s te beheren op basis van pad, bestandsextensie, request-methode en het gedrag van queryreeksen. Op Standard-niveaus configureert u regels in de caching-instellingen van het eindpunt; Premium voegt geavanceerde ‘rules engines’ toe.
Purge ongeldige content per pad met wildcards (bijv. /images/*) via de portal, CLI of REST API. Purges worden doorgevoerd naar alle POP’s; gebruik gerichte purges om de ‘blast radius’ te minimaliseren. Premium-niveaus ondersteunen ‘preload’ om caches op te warmen.

Beheer van de versheid van content:

TTL: De CDN respecteert standaard de Cache-Control- en Expires-headers van de origin. U kunt met regels de TTL’s overschrijven of minimale/maximale TTL’s instellen. Voor onveranderlijke (‘immutable’) assets, serveer Cache-Control: public,max-age=31536000,immutable om de hit-rates te maximaliseren.
Cache-Control-richtlijnen: no-store en private worden niet door de CDN gecachet; must-revalidate en s-maxage maken fijnmazig beheer van gedeelde caches mogelijk. Geef de voorkeur aan s-maxage voor CDN-specifieke TTL’s, terwijl u max-age conservatief houdt voor browsers.
Gedrag voor caching van queryreeksen: kies om queryreeksen te negeren (één gecachet object per pad), elke unieke URL te cachen (elke combinatie van queryreeksen wordt afzonderlijk gecachet), of de cache te omzeilen bij een queryreeks. Voor geversioneerde assets (bijv. app.css?v=hash), cache elke unieke URL. Voor analyseparameters (utm_), negeer queryreeksen om de hit-rates te verbeteren.
Vary en compressie: Zorg ervoor dat Vary: Accept-Encoding is ingesteld bij het comprimeren; de CDN zal afzonderlijke varianten per Vary-sleutel cachen. Schakel CDN-compressie in voor tekst-assets om bandbreedte te besparen.

Azure Front Door: globale routing, status, beveiliging en affiniteit

Azure Front Door biedt op anycast gebaseerde, Layer 7 globale load balancing, dynamische site-acceleratie en een geïntegreerde WAF. Het vult CDN aan door dynamisch verkeer te routeren en te beveiligen, terwijl het optioneel statische content kan cachen in Standard/Premium.

Routeringsregels:

Koppel inkomende hostnamen en padpatronen en routeer naar een origin-groep (backend-pool). Pas per regel pad-herschrijvingen, header-transformaties, redirects en protocolinstellingen toe.
Configureer caching op de route (Standard/Premium) voor edge-caching van statische of semi-statische assets wanneer je meer controle aan de rand van de applicatie wilt.
Gebruik op prioriteit gebaseerde failover en gewogen load balancing over origins, optioneel met geo-filtering voor regiospecifieke routing.

Health probes en backend-status:

Definieer het probe-pad, protocol, interval en de verwachte HTTP-statuscodes. Probes worden uitgevoerd vanaf meerdere edge-locaties om de status van de origin te bepalen.
Front Door gebruikt de status om verkeer naar gezonde origins met lage latentie te sturen. Pas time-outs en de steekproefgrootte aan om ‘flapping’ te voorkomen; zorg ervoor dat het probe-eindpunt lichtgewicht en niet-gecached is.

WAF-integratie:

Koppel een WAF-beleid aan je Front Door om beheerde regelsets voor veelvoorkomende webkwetsbaarheden af te dwingen en voeg aangepaste regels toe voor IP-restricties, geoblocking of limieten voor aanvraaggrootte.
Gebruik bot-bescherming en rate limiting om misbruikverkeer aan de edge op te vangen, waardoor de origin-capaciteit behouden blijft.

Sessie-affiniteit:

Schakel sessie-affiniteit in wanneer je applicatie vereist dat opeenvolgende aanvragen naar dezelfde backend gaan (bijv. een niet-gedistribueerde sessiestatus). Front Door injecteert een affiniteitscookie en routeert volgende aanvragen in dezelfde sessie naar de geselecteerde backend binnen een routeringsregel.
Geef de voorkeur aan stateless ontwerpen of een door Redis ondersteunde sessiestatus om affiniteit waar mogelijk te vermijden; indien gebruikt, beperk de scope van de affiniteit zorgvuldig en stel de juiste cookie-TTL’s in.

Samenspel met CDN:

CDN moet statische assets (afbeeldingen, scripts, media) met lange TTL’s serveren; Front Door routeert dynamische aanvragen met WAF, TLS-beëindiging en op pad gebaseerde routing. Deze scheiding maximaliseert de cache-hitrates en minimaliseert de dynamische latentie.
Houd voor API’s of pagina’s die niet kunnen worden gecached de TTL laag of omzeil caching; overweeg voor semi-statische HTML korte TTL’s met purge-on-change workflows.

Praktisch Probleemscenario

Mozilla lanceert een wereldwijde microsite voor de ontdekking van add-ons, met hoge verkeerspieken tijdens releases. Ze hebben snelle levering van statische assets, veerkrachtige dynamische API’s en veilige gebruikersinteracties met lage latentie wereldwijd nodig.

Front Door voor globale toegang en beveiliging

Maak een Front Door Standard-profiel aan met een aangepast domein en beheerde TLS. Definieer routeringsregels: /api/* naar de App Service API origin-groep en /* naar de hostnaam van het CDN-eindpunt.
Waarom: Anycast-routing brengt gebruikers naar de dichtstbijzijnde edge; WAF bij Front Door blokkeert kwaadaardige patronen voordat ze de origins bereiken; op pad gebaseerde routing scheidt dynamisch en statisch verkeer netjes.

WAF-beleid en rate limiting

Koppel een WAF-beleid met ingeschakelde beheerde regelsets en een aangepaste regel om buitensporige POST-verzoeken naar /api/search te beperken.
Waarom: Beschermt API’s tegen aanvallen van de OWASP-klasse en misbruikende clients, waardoor de origin-capaciteit tijdens pieken behouden blijft.

Health probes en origin-groepen

Configureer een API origin-groep met twee App Service-instanties in verschillende regio’s. Gebruik health probes op /healthz met een verwachte status 200 en een interval van 10 seconden. Stel één regio in op prioriteit 1, de andere op prioriteit 2, met failover.
Waarom: Zorgt voor automatische regionale failover als een primaire regio degradeert; probes detecteren de status onafhankelijk van gecachte antwoorden.

Door Redis ondersteunde sessie- en output-caching

Implementeer Azure Cache for Redis Standard en integreer de API met IDistributedCache om minimale sessiestatus en kortstondige output-fragmenten voor veelvoorkomende API-antwoorden (bijv. lijsten met populaire add-ons) op te slaan met TTL’s van 60-300 seconden.
Waarom: Vermindert API-latentie en databasebelasting terwijl de status buiten de web-tier wordt gehouden; korte TTL’s zorgen voor actualiteit zonder handmatige invalidatie.

Redis-datastructuren voor leaderboards

Gebruik een Redis sorted set per categorie (bijv. addons:top:{category}) om op downloads gebaseerde ranglijsten bij te houden. Werk scores asynchroon bij via een queue-consumer en stel lees-API’s beschikbaar die de top-N-items lezen.
Waarom: Sorted sets bieden O(log n) updates en snelle bereik-leesacties, perfect voor real-time ranglijsten met hoge gelijktijdige leesbewerkingen.

Verbindingsresilience met StackExchange.Redis

Initialiseer een singleton ConnectionMultiplexer met ssl=True, abortConnect=False, connectRetry=5 en verstandige time-outs. Behandel ConnectionFailed/Restored-events voor observeerbaarheid en stel SyncTimeout hoog genoeg in voor bursts bij het gebruik van async API’s.
Waarom: Zorgt voor een naadloze afhandeling van failover en voorkomt procesbrede storingen tijdens tijdelijke netwerkgebeurtenissen of Redis-failovers.

CDN voor statische assets met agressieve caching

Maak een Azure CDN-profiel en -eindpunt aan, geoptimaliseerd voor Algemene weblevering, met de statische website van het opslagaccount als origin. Configureer cachingregels om origin-headers te respecteren, maar overschrijf dit naar een TTL van 7 dagen voor /static/*, en schakel compressie in. Stel caching van queryreeksen in op ‘Cache every unique URL’ en fingerprint assets (app.css?v=hash).
Waarom: Edge-caching levert assets wereldwijd snel af; fingerprinting maakt lange TTL’s mogelijk met onmiddellijke updates bij implementaties; compressie vermindert de overdrachtsgroottes.

Purge-proces in CI/CD

Voeg een deployment-stap toe die bij een release CDN-paden voor HTML- en JSON-manifesten purget (bijv. /index.html, /manifest/*.json) en kritieke pagina’s vooraf laadt voor warme caches in ondersteunde tiers.
Waarom: Zorgt ervoor dat gebruikers snel verse HTML krijgen terwijl onveranderlijke assets gecached blijven; vooraf laden vermindert de koude-startlatentie na de implementatie.

Sessie-affiniteit van Front Door alleen waar vereist

Houd API’s stateless en vertrouw op Redis voor de sessiestatus; schakel de sessie-affiniteit van Front Door uit voor /api/-routes. Schakel het voor een legacy admin-tool die affiniteit vereist in op /admin/ met een korte TTL.
Waarom: Maximaliseert de lastenverdeling en cachebaarheid voor de meeste gebruikers, terwijl affiniteit wordt beperkt tot de minimaal vereiste scope.

Deze architectuur gebruikt Front Door voor veilige, intelligente edge-routing en WAF, Azure CDN voor de levering van statische content met een hoge hitrate en precieze controle over de actualiteit, en Azure Cache for Redis om ‘hot reads’ te ontlasten, sessie- en leaderboard-data met lage latentie te onderhouden en pieken soepel op te vangen.

← Azure Event-gebaseerde en Berichtenoplossingen · Alle domeinen · Azure Monitoring →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →