Microsoft AZ-204: Mise en cache, CDN et performances Azure — Guide d'étude

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

Fait partie du Microsoft Azure Developer Associate AZ-204 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Des expériences utilisateur rapides et fiables dans Azure dépendent du placement du contenu et de l’état au plus près des utilisateurs, de la minimisation de la charge sur l’origine et de la gestion élégante des défaillances. Azure Cache for Redis, Azure CDN et Azure Front Door fournissent ensemble l’accélération en mémoire, la mise en cache en périphérie (edge) et le routage anycast mondial avec sécurité. La maîtrise des structures de données et des modèles de connexion Redis, des profils CDN et de la sémantique de mise en cache, ainsi que du routage et des sondes d’intégrité de Front Door vous permet de concevoir des applications résilientes à faible latence.

Azure Cache for Redis : niveaux, structures de données, éviction et modèles

Azure Cache for Redis est un service Redis géré qui fournit un accès aux données en moins d’une milliseconde, prenant en charge les structures de données Redis courantes et des capacités avancées dans les niveaux supérieurs.

Niveaux :

Basic : Cache à nœud unique sans SLA et sans réplication de données. Idéal pour les charges de travail de dev/test et non critiques. Pas de persistance des données, pas de clustering, pas d’intégration VNet.
Standard : Nœud double primaire/réplica avec basculement automatique et un SLA. Adapté à la production. Prend en charge la montée/descente en charge avec une interruption minimale, mais pas de clustering ni de persistance.
Premium : Performances et débit plus élevés, tailles de cache plus importantes, persistance Redis (RDB et AOF), clustering (sharding) pour la mise à l’échelle horizontale, intégration de réseau virtuel, redondance de zone (dans les régions prises en charge) et géo-réplication pour la reprise d’activité (DR). Prend également en charge les fenêtres de mise à jour planifiées et la sécurité avancée.

Structures de données et quand les utiliser :

Strings : Clé/valeur de base, compteurs, blobs JSON ; INCR/DECR atomiques pour la limitation de débit et les compteurs.
Hashes : Stocker les champs d’un objet (ex: profil utilisateur) sous une clé unique avec des paires champ-valeur pour des mises à jour partielles et une meilleure efficacité spatiale.
Lists : Files d’attente ou piles, ordonnées par insertion ; utiliser avec LPUSH/BRPOP pour des files de travail simples.
Sets : Collections d’éléments uniques ; à utiliser pour les tags, les vérifications d’appartenance, les intersections.
Sorted Sets : Classement avec des scores ; idéal pour les classements (leaderboards) et les événements ordonnés par le temps.
Bitmaps/Bitfields : Suivi compact d’indicateurs booléens et de compteurs sur des positions.
HyperLogLog : Cardinalité approximative (comptage d’éléments uniques) avec une mémoire fixe.
Geospatial : Stocker et interroger des coordonnées lat/long, recherches par rayon.
Streams : Journal en ajout seul pour l’ingestion d’événements et les groupes de consommateurs.

Stratégies d’éviction (appliquées lorsque maxmemory est atteint) :

volatile-lru : Évincer les clés les moins récemment utilisées (LRU) ayant une expiration (par défaut sur Azure Cache for Redis).
allkeys-lru : Évincer les clés les moins récemment utilisées (LRU) sans tenir compte de l’expiration.
volatile-ttl : Évincer les clés ayant le temps d’expiration le plus proche.
volatile-random / allkeys-random : Évincer des clés aléatoires, limitées aux clés expirant ou à toutes les clés.
noeviction : Ne pas évincer ; les commandes d’écriture qui ajouteraient de la mémoire échouent avec une erreur.
volatile-lfu / allkeys-lfu : Variantes d’éviction des moins fréquemment utilisées (LFU) (pour les versions plus récentes de Redis).

Choisissez la stratégie d’éviction en fonction de la criticité des données et des modèles d’accès. Pour les caches, allkeys-lru ou allkeys-lfu donnent les meilleurs taux de réussite (hit rates). Pour les stockages mixtes avec des expirations définies avec soin, volatile-ttl ou volatile-lru peuvent respecter vos TTL.

Cas d’utilisation courants :

Mise en cache de session : Stocker l’état de la session utilisateur via IDistributedCache ou un middleware de session. Gardez des clés de petite taille, utilisez un TTL aligné sur le timeout de la session, et activez l’affinité de session en périphérie si nécessaire.
Mise en cache de sortie : Mettre en cache des fragments de page rendus ou des réponses complètes, indexés par route et segment d’utilisateur. Invalider lors des changements de contenu en utilisant le versionnement de clé ou un DEL explicite.
Pub/Sub : Messagerie quasi temps réel pour les notifications ou la diffusion en rafale (fan-out) de l’invalidation de cache. Utiliser des canaux pour diffuser les changements à plusieurs abonnés.
Classements (Leaderboards) : Ensembles triés avec des scores pour le classement ; ZADD/ZREVRANGE pour mettre à jour et lire le top N ; utiliser des ensembles triés secondaires pour les classements sur des fenêtres temporelles.

Connexion à Azure Redis : chaînes de connexion, StackExchange.Redis et résilience

Les points de terminaison de connexion et les clés sont fournis dans le portail Azure sous Clés d’accès. La chaîne de connexion principale inclut l’hôte, le port, TLS et le mot de passe (par exemple, contoso.redis.cache.windows.net:6380,password=…;ssl=True;abortConnect=False). Utilisez toujours TLS sur le port 6380 en production.

Bonnes pratiques avec StackExchange.Redis :

Utilisez un unique ConnectionMultiplexer à longue durée de vie par processus. Il est thread-safe et multiplexe les requêtes efficacement. Créez-le une seule fois, stockez-le dans un conteneur statique ou d’injection de dépendances (DI), et réutilisez-le.
Options de configuration : définissez AbortOnConnectFail=false pour la tolérance au basculement dans le cloud ; définissez ConnectRetry et ConnectTimeout pour les problèmes transitoires ; SyncTimeout ajusté à la charge de travail ; KeepAlive pour maintenir les trous d’épingle NAT. Exemple d’options sous forme de texte : ssl=True, abortConnect=False, connectRetry=5, connectTimeout=5000.
Utilisez des méthodes asynchrones pour éviter l’épuisement du pool de threads sous charge. Les méthodes IDatabase (StringGetAsync, HashSetAsync, SortedSetAddAsync) sont non bloquantes.
Gérez les événements de résilience : abonnez-vous aux événements ConnectionFailed, ConnectionRestored et ConfigurationChanged pour journaliser et observer les changements de topologie et les basculements. StackExchange.Redis résout automatiquement le nouveau primaire lors d’un basculement.
Évitez les scripts Lua à longue exécution et les transactions lourdes ; préférez les commandes petites et atomiques. Le pipeline se fait naturellement via le multiplexeur ; ne regroupez pas trop de commandes au point de provoquer des timeouts.
Timeouts et nouvelles tentatives : ne réessayez pas aveuglément les commandes non idempotentes. Utilisez des modèles idempotents ou des files d’attente write-through pour les écritures critiques.
Sérialisation : stockez des charges utiles (payloads) compactes (ex: MessagePack) pour minimiser le trafic réseau et la mémoire. Évitez les valeurs géantes ; préférez les hashes avec un accès au niveau du champ.
Nommage des clés : préfixez par application/environnement (prod:session:{userId}) pour éviter les collisions et simplifier les opérations en masse et les purges.
Sécurité : effectuez une rotation des clés d’accès, restreignez via VNet (Premium) et envisagez Private Link pour un accès privé. Ne mettez pas « Autoriser l’accès uniquement via SSL » sur false en production.

Azure CDN : profils, points de terminaison, origines, optimisation et fraîcheur du contenu

Azure CDN met en cache le contenu statique dans des POPs (points de présence) en périphérie pour réduire la latence et la charge sur l’origine. Un profil CDN regroupe des points de terminaison et un niveau de tarification/fournisseur ; un point de terminaison définit le nom d’hôte de périphérie et se connecte à une ou plusieurs origines.

Profils et points de terminaison :

Créez un ou plusieurs points de terminaison par application ou environnement sous un même profil. Chaque point de terminaison possède son propre nom d’hôte de périphérie (par ex., app.azureedge.net) que vous mappez à des domaines personnalisés avec TLS.
Utilisez des profils distincts pour isoler la facturation ou appliquer différents fournisseurs/fonctionnalités si nécessaire.

Types d’origine :

Azure Blob Storage : Idéal pour les sites web statiques et les médias volumineux. Activez la fonctionnalité Site web statique ou mappez vers un conteneur ; assurez-vous que les types MIME et les en-têtes de cache sont corrects.
App Service : À utiliser pour le contenu dynamique ou les API REST dont certaines réponses peuvent être mises en cache. Configurez l’en-tête d’hôte d’origine sur le nom d’hôte de votre application et assurez-vous d’utiliser HTTPS.
Origine personnalisée : Tout point de terminaison HTTP(S) publiquement accessible, y compris en local (on-premises) via une IP publique ou un proxy inverse.

Types d’optimisation (appliqués à la création du point de terminaison) :

Distribution web générale : Équilibré pour de nombreux actifs de petite/moyenne taille (HTML, CSS, JS, images) avec une large couverture de POPs.
Téléchargement de fichiers volumineux : Optimisé pour les gros fichiers avec un réglage des requêtes de plage (range request), une gestion des connexions et des paramètres axés sur le débit.
Streaming vidéo : Optimisé pour le téléchargement progressif ou la livraison de segments HLS/DASH, en maintenant une mise en cache efficace des segments et en respectant les requêtes de plage d’octets (byte-range requests).

Règles de mise en cache et purge :

Les règles de mise en cache globales et personnalisées vous permettent de contrôler les TTL en fonction du chemin, de l’extension de fichier, de la méthode de requête et du comportement des chaînes de requête. Sur les niveaux Standard, configurez les règles dans les paramètres de mise en cache du point de terminaison ; le niveau Premium ajoute des moteurs de règles avancés.
Purgez le contenu invalide par chemin avec des caractères génériques (par ex., /images/*) via le portail, la CLI ou l’API REST. Les purges se propagent à travers les POPs ; utilisez des purges ciblées pour minimiser le rayon d’impact. Les niveaux Premium prennent en charge le préchargement (preload) pour préchauffer les caches.

Contrôles de la fraîcheur du contenu :

TTL : Par défaut, le CDN respecte les en-têtes Cache-Control et Expires de l’origine. Vous pouvez outrepasser ou définir des TTL minimum/maximum avec des règles. Pour les actifs immuables, servez

undefined

pour maximiser les taux de réussite de cache.

Directives Cache-Control : no-store et private ne sont pas mis en cache par le CDN ; must-revalidate et s-maxage permettent un contrôle fin du cache partagé. Préférez s-maxage pour les TTL spécifiques au CDN tout en gardant max-age conservateur pour les navigateurs.
Comportement de mise en cache des chaînes de requête : choisissez d’ignorer les chaînes de requête (un seul objet en cache par chemin), de mettre en cache chaque URL unique (chaque combinaison de chaîne de requête est mise en cache séparément), ou de contourner le cache en présence d’une chaîne de requête. Pour les actifs versionnés (par ex., app.css?v=hash), mettez en cache chaque URL unique. Pour les paramètres d’analyse (utm_), ignorez les chaînes de requête pour améliorer les taux de réussite de cache.
Vary et compression : Assurez-vous que Vary: Accept-Encoding est défini lors de la compression ; le CDN mettra en cache des variantes distinctes pour chaque clé Vary. Activez la compression CDN pour les actifs textuels afin de réduire la bande passante.

Azure Front Door : routage global, intégrité, sécurité et affinité

Azure Front Door fournit un équilibrage de charge global de couche 7 basé sur anycast, une accélération de site dynamique et un WAF intégré. Il complète le CDN en routant et en protégeant le trafic dynamique tout en mettant éventuellement en cache le contenu statique dans les niveaux Standard/Premium.

Règles de routage :

Correspondent aux noms d’hôte et aux modèles de chemin entrants et acheminent vers un groupe d’origines (pool de backends). Appliquez des réécritures de chemin, des transformations d’en-têtes, des redirections et des paramètres de protocole par règle.
Configurez la mise en cache au niveau de la route (Standard/Premium) pour la mise en cache en périphérie des ressources statiques ou semi-statiques lorsque vous souhaitez un contrôle plus fin à la périphérie de l’application.
Utilisez le basculement basé sur la priorité et l’équilibrage de charge pondéré entre les origines, avec en option un filtrage géographique pour un routage spécifique à une région.

Sondes d’intégrité et intégrité du backend :

Définissez le chemin de la sonde, le protocole, l’intervalle et les codes d’état HTTP attendus. Les sondes s’exécutent depuis plusieurs emplacements de périphérie pour déterminer l’intégrité de l’origine.
Front Door utilise l’état d’intégrité pour diriger le trafic vers des origines saines avec une faible latence. Ajustez les délais d’attente et la taille de l’échantillon pour éviter l’instabilité (« flapping ») ; assurez-vous que le point de terminaison de la sonde est léger et non mis en cache.

Intégration WAF :

Attachez une politique WAF à votre Front Door pour appliquer des ensembles de règles gérés pour les vulnérabilités web courantes et ajoutez des règles personnalisées pour les restrictions d’IP, le géoblocage ou les limites de taille de requête.
Utilisez la protection contre les bots et la limitation de débit pour absorber le trafic abusif en périphérie, préservant ainsi la capacité de l’origine.

Affinité de session :

Activez l’affinité de session lorsque votre application nécessite que les requêtes consécutives atteignent le même backend (par exemple, un état de session non distribué). Front Door injecte un cookie d’affinité et achemine les requêtes ultérieures de la même session vers le backend sélectionné au sein d’une règle de routage.
Préférez les conceptions sans état (stateless) ou un état de session basé sur Redis pour éviter l’affinité lorsque c’est possible ; si elle est utilisée, délimitez soigneusement la portée de l’affinité et définissez des TTL de cookie appropriés.

Interaction avec le CDN :

Le CDN doit servir les ressources statiques (images, scripts, médias) avec des TTL longs ; Front Door achemine les requêtes dynamiques avec le WAF, la terminaison TLS et le routage basé sur le chemin. Cette répartition maximise les taux de succès du cache et minimise la latence dynamique.
Pour les API ou les pages qui ne peuvent pas être mises en cache, maintenez un TTL bas ou contournez la mise en cache ; pour le HTML semi-statique, envisagez des TTL courts avec des workflows de purge lors des modifications.

Scénario de problème pratique

Mozilla lance un microsite mondial pour la découverte d’add-ons, avec des pics de trafic élevés lors des lancements. Ils ont besoin d’une livraison rapide des ressources statiques, d’API dynamiques résilientes et d’interactions utilisateur sécurisées à faible latence dans le monde entier.

Front Door pour le point d’entrée global et la sécurité

Créez un profil Front Door Standard avec un domaine personnalisé et un TLS géré. Définissez des règles de routage : /api/* vers le groupe d’origines de l’API App Service et /* vers le nom d’hôte du point de terminaison CDN.
Pourquoi : Le routage anycast amène les utilisateurs vers le point de présence (edge) le plus proche ; le WAF au niveau de Front Door bloque les modèles malveillants avant qu’ils n’atteignent les origines ; le routage basé sur le chemin sépare nettement le trafic dynamique et statique.

Politique WAF et limitation de débit

Attachez une politique WAF avec des ensembles de règles gérés activés et une règle personnalisée pour limiter les requêtes POST excessives vers /api/search.
Pourquoi : Protège les API contre les attaques de type OWASP et les clients abusifs, préservant la capacité de l’origine pendant les pics.

Sondes d’intégrité et groupes d’origines

Configurez le groupe d’origines de l’API avec deux instances App Service dans différentes régions. Utilisez des sondes d’intégrité sur /healthz avec un statut attendu de 200 et un intervalle de 10 secondes. Définissez une région avec la priorité 1, l’autre avec la priorité 2, avec basculement.
Pourquoi : Assure un basculement régional automatique si une région primaire se dégrade ; les sondes détectent l’état d’intégrité indépendamment des réponses mises en cache.

Session et cache de sortie basés sur Redis

Déployez Azure Cache for Redis Standard et intégrez l’API avec IDistributedCache pour stocker un état de session minimal et des fragments de sortie à courte durée de vie pour les réponses API courantes (par exemple, les listes d’add-ons populaires) avec des TTL de 60 à 300 secondes.
Pourquoi : Réduit la latence de l’API et la charge de la base de données tout en gardant l’état hors du niveau web ; les TTL courts maintiennent la fraîcheur sans invalidation manuelle.

Structures de données Redis pour les classements

Utilisez un ensemble trié (sorted set) Redis par catégorie (par exemple, addons:top:{category}) pour maintenir les classements basés sur les téléchargements. Mettez à jour les scores de manière asynchrone via un consommateur de file d’attente et exposez des API de lecture qui lisent les N premières entrées.
Pourquoi : Les ensembles triés fournissent des mises à jour en O(log n) et des lectures de plages rapides, parfait pour les classements en temps réel avec une forte concurrence en lecture.

Résilience de la connexion avec StackExchange.Redis

Initialisez un singleton ConnectionMultiplexer avec ssl=True, abortConnect=False, connectRetry=5, et des délais d’attente raisonnables. Gérez les événements ConnectionFailed/Restored pour l’observabilité et définissez SyncTimeout suffisamment haut pour les rafales tout en utilisant des API asynchrones.
Pourquoi : Assure une gestion transparente du basculement et évite les pannes à l’échelle du processus lors d’événements réseau transitoires ou de basculements Redis.

CDN pour les ressources statiques avec une mise en cache agressive

Créez un profil et un point de terminaison Azure CDN optimisés pour la livraison web générale avec le site web statique du compte de stockage comme origine. Configurez des règles de mise en cache pour respecter les en-têtes d’origine, mais les remplacer par un TTL de 7 jours pour /static/*, et activez la compression. Réglez la mise en cache des chaînes de requête sur « Mettre en cache chaque URL unique » et utilisez une empreinte (fingerprint) pour les ressources (app.css?v=hash).
Pourquoi : La mise en cache en périphérie (edge) livre les ressources rapidement dans le monde entier ; l’utilisation d’empreintes permet des TTL longs avec des mises à jour instantanées lors des déploiements ; la compression réduit la taille des transferts.

Processus de purge dans la CI/CD

Ajoutez une étape de déploiement qui purge les chemins CDN pour les manifestes HTML et JSON lors d’une nouvelle version (par exemple, /index.html, /manifest/*.json) et précharge les pages critiques pour avoir des caches « chauds » dans les niveaux pris en charge.
Pourquoi : Assure que les utilisateurs obtiennent rapidement le HTML à jour tout en gardant les ressources immuables en cache ; le préchargement réduit la latence de démarrage à froid après le déploiement.

Affinité de session Front Door uniquement là où c’est nécessaire

Gardez les API sans état (stateless) et comptez sur Redis pour l’état de session ; désactivez l’affinité de session Front Door pour les routes /api/. Pour un outil d’administration hérité qui nécessite l’affinité, activez-la sur /admin/ avec un TTL court.
Pourquoi : Maximise la répartition de la charge et la capacité de mise en cache pour la plupart des utilisateurs tout en limitant l’affinité à la portée minimale requise.

Cette architecture utilise Front Door pour le routage de périphérie intelligent et sécurisé et le WAF, Azure CDN pour la livraison de contenu statique avec un taux de succès élevé et un contrôle précis de la fraîcheur, et Azure Cache for Redis pour décharger les lectures intensives, maintenir des données de session et de classement à faible latence, et absorber les pics en douceur.

← Solutions basées sur les événements et la messagerie Azure · Tous les domaines · Supervision →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →