Microsoft AZ-204: Almacenamiento en caché, CDN y rendimiento de Azure — Guía de estudio

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

Forma parte de la Microsoft Azure Developer Associate AZ-204 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Información general

Para lograr experiencias de usuario rápidas y fiables en Azure, es fundamental ubicar el contenido y el estado cerca de los usuarios, minimizar la carga en el origen y gestionar los fallos con elegancia. Azure Cache for Redis, Azure CDN y Azure Front Door proporcionan conjuntamente aceleración en memoria, almacenamiento en caché perimetral y enrutamiento anycast global con seguridad. Dominar las estructuras de datos y los patrones de conexión de Redis, los perfiles y la semántica de almacenamiento en caché de CDN, y el enrutamiento y los sondeos de estado de Front Door le permite diseñar aplicaciones resilientes y de baja latencia.

Azure Cache for Redis: niveles, estructuras de datos, expulsión y patrones

Azure Cache for Redis es un servicio de Redis gestionado que proporciona acceso a datos en menos de un milisegundo, admitiendo las estructuras de datos comunes de Redis y capacidades avanzadas en los niveles superiores.

Niveles:

Básico: Caché de nodo único sin SLA y sin replicación de datos. Adecuado para desarrollo/pruebas y cargas de trabajo no críticas. Sin persistencia de datos, sin clústeres, sin integración con VNet.
Estándar: Configuración de dos nodos (principal/réplica) con conmutación por error automática y un SLA. Adecuado para producción. Admite el escalado vertical (hacia arriba/abajo) con una interrupción mínima, pero sin clústeres ni persistencia.
Premium: Mayor rendimiento y capacidad de proceso, tamaños de caché más grandes, persistencia de Redis (RDB y AOF), clústeres (sharding) para escalado horizontal, integración con redes virtuales, redundancia de zona (en regiones compatibles) y georreplicación para DR (recuperación ante desastres). También admite ventanas de aplicación de revisiones programadas y seguridad avanzada.

Estructuras de datos y cuándo usarlas:

Cadenas (Strings): Par clave/valor básico, contadores, blobs JSON; INCR/DECR atómico para limitación de velocidad y contadores.
Hashes: Almacena campos de objetos (p. ej., perfil de usuario) como una única clave con pares campo-valor para actualizaciones parciales y eficiencia de espacio.
Listas: Colas o pilas, ordenadas por inserción; usar con LPUSH/BRPOP para colas de trabajo sencillas.
Conjuntos (Sets): Colecciones de elementos únicos; usar para etiquetas, comprobaciones de pertenencia, intersecciones.
Conjuntos ordenados (Sorted Sets): Clasificación con puntuaciones; ideal para tablas de clasificación y eventos ordenados por tiempo.
Mapas de bits/Campos de bits (Bitmaps/Bitfields): Seguimiento compacto de indicadores booleanos y contadores sobre posiciones.
HyperLogLog: Cardinalidad aproximada (recuentos únicos) con memoria fija.
Geoespacial: Almacena y consulta coordenadas de latitud/longitud, búsquedas por radio.
Streams: Registro de solo anexo para la ingesta de eventos y grupos de consumidores.

Políticas de expulsión (se aplican cuando se alcanza maxmemory):

volatile-lru: Expulsar las claves menos usadas recientemente que tengan una caducidad (predeterminado en Azure Cache for Redis).
allkeys-lru: Expulsar las claves menos usadas recientemente, independientemente de su caducidad.
volatile-ttl: Expulsar las claves con el tiempo de caducidad más próximo.
volatile-random / allkeys-random: Expulsar claves aleatorias, limitado a claves que caducan o a todas las claves.
noeviction: No expulsar; los comandos de escritura que añadirían memoria fallan con un error.
volatile-lfu / allkeys-lfu: Variantes de expulsión de las menos usadas frecuentemente (para versiones más nuevas de Redis).

Elija la política de expulsión según la criticidad de los datos y los patrones de acceso. Para cachés, allkeys-lru o allkeys-lfu ofrecen las mejores tasas de acierto. Para almacenes mixtos con caducidades cuidadosamente establecidas, volatile-ttl o volatile-lru pueden respetar sus TTL.

Casos de uso comunes:

Almacenamiento en caché de sesiones: Almacene el estado de la sesión del usuario a través de IDistributedCache o middleware de sesión. Mantenga las claves pequeñas, use un TTL alineado con el tiempo de espera de la sesión y habilite la afinidad de sesión en el perímetro si es necesario.
Almacenamiento en caché de salida: Almacene en caché fragmentos de página renderizados o respuestas completas, usando como clave la ruta y el segmento de usuario. Invalide los cambios de contenido mediante el versionado de claves o un DEL explícito.
Pub/Sub: Mensajería casi en tiempo real para notificaciones o distribución masiva (fan-out) de invalidación de caché. Use canales para difundir cambios a múltiples suscriptores.
Tablas de clasificación: Conjuntos ordenados con puntuaciones para la clasificación; ZADD/ZREVRANGE para actualizar y leer los N primeros; use conjuntos ordenados secundarios para clasificaciones por ventana de tiempo.

Conexión a Azure Redis: cadenas de conexión, StackExchange.Redis y resiliencia

Los puntos de conexión y las claves de conexión se proporcionan en el portal de Azure, en “Claves de acceso”. La cadena de conexión principal incluye el host, el puerto, TLS y la contraseña (por ejemplo, contoso.redis.cache.windows.net:6380,password=…;ssl=True;abortConnect=False). Use siempre TLS en el puerto 6380 en producción.

Mejores prácticas para StackExchange.Redis:

Use un único ConnectionMultiplexer de larga duración por proceso. Es seguro para subprocesos (thread-safe) y multiplexa las solicitudes de forma eficiente. Créelo una vez, guárdelo en un contenedor estático o de inyección de dependencias (DI) y reutilícelo.
Opciones de configuración: establezca AbortOnConnectFail=false para la tolerancia a la conmutación por error en la nube; establezca ConnectRetry y ConnectTimeout para problemas transitorios; SyncTimeout ajustado para la carga de trabajo; KeepAlive para mantener los pinholes de NAT. Ejemplo de opciones en formato de texto: ssl=True, abortConnect=False, connectRetry=5, connectTimeout=5000.
Use métodos asíncronos para evitar el agotamiento del grupo de subprocesos bajo carga. Los métodos de IDatabase (StringGetAsync, HashSetAsync, SortedSetAddAsync) no son bloqueantes.
Gestione los eventos de resiliencia: suscríbase a los eventos ConnectionFailed, ConnectionRestored y ConfigurationChanged para registrar y observar los cambios de topología y las conmutaciones por error. StackExchange.Redis resuelve automáticamente de nuevo el nodo principal en una conmutación por error.
Evite los scripts de Lua de larga duración y las transacciones pesadas; prefiera comandos pequeños y atómicos. La canalización (pipeline) se realiza de forma natural a través del multiplexor; no agrupe en lotes excesivos hasta el punto de provocar tiempos de espera.
Tiempos de espera y reintentos: no reintente a ciegas los comandos no idempotentes. Use patrones idempotentes o colas de escritura directa (write-through) para escrituras críticas.
Serialización: almacene cargas útiles compactas (p. ej., MessagePack) para minimizar el tráfico de red y la memoria. Evite valores gigantes; prefiera hashes con acceso a nivel de campo.
Nomenclatura de claves: use prefijos por aplicación/entorno (prod:session:{userId}) para evitar colisiones y simplificar las operaciones masivas y las purgas.
Seguridad: rote las claves de acceso, restrinja mediante VNet (nivel Premium) y considere Private Link para el acceso privado. No establezca la opción “Permitir acceso solo a través de SSL” en false en producción.

Azure CDN: perfiles, puntos de conexión, orígenes, optimización y actualización del contenido

Azure CDN almacena en caché contenido estático en los POP de borde para reducir la latencia y la carga en el origen. Un perfil de CDN agrupa puntos de conexión y un plan de precios/proveedor; un punto de conexión define el nombre de host de borde y se conecta a uno o más orígenes.

Perfiles y puntos de conexión:

Crea uno o más puntos de conexión por aplicación o entorno bajo un perfil. Cada punto de conexión tiene su propio nombre de host de borde (p. ej., app.azureedge.net) que asignas a dominios personalizados con TLS.
Usa perfiles separados para aislar la facturación o aplicar diferentes proveedores/características si es necesario.

Tipos de origen:

Azure Blob Storage: Ideal para sitios web estáticos y archivos multimedia grandes. Habilita la opción de sitio web estático o asígnalo a un contenedor; asegúrate de que los tipos MIME y las cabeceras de caché sean los correctos.
App Service: Úsalo para contenido dinámico o API REST donde se puedan almacenar en caché respuestas seleccionadas. Configura la cabecera del host de origen con el nombre de host de tu aplicación y asegura el uso de HTTPS.
Origen personalizado: Cualquier punto de conexión HTTP(S) accesible públicamente, incluyendo entornos locales (on-premises) a través de una IP pública o un proxy inverso.

Tipos de optimización (aplicados en la creación del punto de conexión):

Entrega web general: Equilibrado para una gran cantidad de activos pequeños/medianos (HTML, CSS, JS, imágenes) con una amplia cobertura de POP.
Descarga de archivos grandes: Optimizado para archivos de gran tamaño con ajuste de solicitudes de rango, gestión de conexiones y configuraciones orientadas al rendimiento (throughput).
Streaming de video: Optimizado para descarga progresiva o entrega de segmentos HLS/DASH, manteniendo eficiente el almacenamiento en caché de segmentos y respetando las solicitudes de rango de bytes.

Reglas de caché y purga:

Las reglas de caché globales y personalizadas te permiten controlar los TTL basándose en la ruta, la extensión del archivo, el método de solicitud y el comportamiento de la cadena de consulta. En los planes Estándar, configura las reglas en los ajustes de caché del punto de conexión; el plan Premium añade motores de reglas avanzados.
Purga el contenido no válido por ruta con comodines (p. ej., /images/*) a través del portal, la CLI o la API REST. Las purgas se propagan a través de los POP; utiliza purgas dirigidas para minimizar el radio de impacto. Los planes Premium admiten la precarga (preload) para calentar las cachés.

Controles de actualización del contenido:

TTL: La CDN respeta por defecto las cabeceras Cache-Control y Expires del origen. Puedes anular o establecer TTL mínimos/máximos con reglas. Para activos inmutables, sirve la cabecera

undefined

para maximizar las tasas de acierto (hit rates).

Directivas de Cache-Control: no-store y private no son almacenados en caché por la CDN; must-revalidate y s-maxage permiten un control detallado de la caché compartida. Prefiere s-maxage para los TTL específicos de la CDN mientras mantienes un max-age conservador para los navegadores.
Comportamiento de caché de la cadena de consulta: elige ignorar las cadenas de consulta (un único objeto en caché por ruta), almacenar en caché cada URL única (cada combinación de cadena de consulta se almacena por separado) o eludir la caché si hay una cadena de consulta. Para activos versionados (p. ej., app.css?v=hash), almacena en caché cada URL única. Para parámetros de análisis (utm_), ignora las cadenas de consulta para mejorar las tasas de acierto.
Vary y compresión: Asegúrate de que se establezca Vary: Accept-Encoding al comprimir; la CDN almacenará en caché variantes separadas por cada clave de Vary. Habilita la compresión de la CDN para los activos de texto para reducir el ancho de banda.

Azure Front Door: enrutamiento global, estado, seguridad y afinidad

Azure Front Door proporciona balanceo de carga global de capa 7 basado en anycast, aceleración dinámica de sitios y un WAF integrado. Complementa la CDN al enrutar y proteger el tráfico dinámico, mientras opcionalmente almacena en caché contenido estático en los niveles Standard/Premium.

Reglas de enrutamiento:

Hacen coincidir los nombres de host y patrones de ruta entrantes y los enrutan a un grupo de origen (backend pool). Aplica reescrituras de ruta, transformaciones de encabezado, redirecciones y configuraciones de protocolo por regla.
Configura el almacenamiento en caché en la ruta (Standard/Premium) para el almacenamiento en caché en el borde de activos estáticos o semiestáticos cuando desees un control más estricto en el borde de la aplicación.
Utiliza la conmutación por error (failover) basada en prioridad y el balanceo de carga ponderado entre los orígenes, opcionalmente con filtrado geográfico para un enrutamiento específico de la región.

Sondeos de estado y estado del backend:

Define la ruta del sondeo, el protocolo, el intervalo y los códigos de estado HTTP esperados. Los sondeos se ejecutan desde múltiples ubicaciones de borde para determinar el estado del origen.
Front Door utiliza el estado de salud para dirigir el tráfico a los orígenes saludables con baja latencia. Ajusta los tiempos de espera y el tamaño de la muestra para evitar el “flapping” (cambios de estado rápidos); asegúrate de que el endpoint del sondeo sea ligero y no se almacene en caché.

Integración con WAF:

Asocia una política de WAF a tu Front Door para aplicar conjuntos de reglas administradas para vulnerabilidades web comunes y agregar reglas personalizadas para restricciones de IP, geobloqueo o límites de tamaño de solicitud.
Usa la protección contra bots y la limitación de velocidad para absorber el tráfico abusivo en el borde, preservando la capacidad del origen.

Afinidad de sesión:

Habilita la afinidad de sesión cuando tu aplicación requiere que las solicitudes consecutivas lleguen al mismo backend (p. ej., estado de sesión no distribuido). Front Door inyecta una cookie de afinidad y enruta las solicitudes posteriores en la misma sesión al backend seleccionado dentro de una regla de enrutamiento.
Prefiere diseños sin estado (stateless) o un estado de sesión respaldado por Redis para evitar la afinidad cuando sea posible; si se usa, limita el alcance de la afinidad con cuidado y establece TTL de cookie apropiados.

Interacción con la CDN:

La CDN debe servir activos estáticos (imágenes, scripts, medios) con TTL largos; Front Door enruta las solicitudes dinámicas con WAF, terminación TLS y enrutamiento basado en rutas. Esta división maximiza las tasas de acierto de caché y minimiza la latencia dinámica.
Para API o páginas que no se pueden almacenar en caché, mantén un TTL bajo o evita el almacenamiento en caché; para HTML semiestático, considera TTL cortos con flujos de trabajo de purga al cambiar.

Escenario de Problema Práctico

Mozilla está lanzando un micrositio global para el descubrimiento de complementos (add-ons) con altos picos de tráfico durante los lanzamientos. Necesitan una entrega rápida de activos estáticos, API dinámicas resilientes e interacciones de usuario seguras y de baja latencia en todo el mundo.

Front Door para entrada global y seguridad

Crea un perfil de Front Door Standard con un dominio personalizado y TLS administrado. Define reglas de enrutamiento: /api/* al grupo de origen de la API de App Service y /* al nombre de host del endpoint de la CDN.
Por qué: El enrutamiento anycast lleva a los usuarios al borde más cercano; el WAF en Front Door bloquea patrones maliciosos antes de que lleguen a los orígenes; el enrutamiento basado en rutas separa limpiamente el tráfico dinámico y estático.

Política de WAF y limitación de velocidad

Asocia una política de WAF con los conjuntos de reglas administradas habilitados y una regla personalizada para limitar las solicitudes POST excesivas a /api/search.
Por qué: Protege las API de ataques de clase OWASP y de clientes abusivos, preservando la capacidad del origen durante los picos.

Sondeos de estado y grupos de origen

Configura el grupo de origen de la API con dos instancias de App Service en diferentes regiones. Usa sondeos de estado en /healthz con un estado esperado de 200 y un intervalo de 10 segundos. Establece una región con prioridad 1 y la otra con prioridad 2, con conmutación por error (failover).
Por qué: Asegura la conmutación por error regional automática si una región primaria se degrada; los sondeos detectan el estado independientemente de las respuestas almacenadas en caché.

Sesión respaldada por Redis y caché de salida

Despliega Azure Cache for Redis Standard e integra la API con IDistributedCache para almacenar un estado de sesión mínimo y fragmentos de salida de corta duración para respuestas de API comunes (p. ej., listas de complementos populares) con TTL de 60 a 300 segundos.
Por qué: Reduce la latencia de la API y la carga de la base de datos mientras mantiene el estado fuera de la capa web; los TTL cortos mantienen la frescura sin invalidación manual.

Estructuras de datos de Redis para tablas de clasificación (leaderboards)

Usa un conjunto ordenado (sorted set) de Redis por categoría (p. ej., addons:top:{category}) para mantener clasificaciones basadas en descargas. Actualiza las puntuaciones de forma asíncrona a través de un consumidor de cola y expón API de lectura que lean las N entradas principales.
Por qué: Los conjuntos ordenados proporcionan actualizaciones O(log n) y lecturas de rango rápidas, perfectas para clasificaciones en tiempo real con alta concurrencia de lectura.

Resiliencia de la conexión con StackExchange.Redis

Inicializa un ConnectionMultiplexer singleton con ssl=True, abortConnect=False, connectRetry=5 y tiempos de espera razonables. Maneja los eventos ConnectionFailed/Restored para la observabilidad y establece un SyncTimeout lo suficientemente alto para ráfagas mientras usas API asíncronas.
Por qué: Asegura un manejo de conmutación por error (failover) sin interrupciones y evita caídas en todo el proceso durante eventos de red transitorios o failovers de Redis.

CDN para activos estáticos con almacenamiento en caché agresivo

Crea un perfil y un endpoint de Azure CDN optimizados para la entrega web general con el sitio web estático de la cuenta de almacenamiento como origen. Configura reglas de almacenamiento en caché para respetar los encabezados de origen, pero anúlalos con un TTL de 7 días para /static/*, y habilita la compresión. Establece el almacenamiento en caché de la cadena de consulta en ‘Cache every unique URL’ y aplica ‘fingerprinting’ a los activos (app.css?v=hash).
Por qué: El almacenamiento en caché en el borde entrega los activos rápidamente en todo el mundo; el ‘fingerprinting’ permite TTL largos con actualizaciones instantáneas en los despliegues; la compresión reduce los tamaños de transferencia.

Proceso de purga en CI/CD

Añade un paso de despliegue que purgue las rutas de la CDN para los manifiestos HTML y JSON en cada lanzamiento (p. ej., /index.html, /manifest/*.json) y precarga las páginas críticas para calentar las cachés en los niveles compatibles.
Por qué: Asegura que los usuarios obtengan HTML actualizado rápidamente mientras se mantienen cacheados los activos inmutables; la precarga reduce la latencia de arranque en frío después del despliegue.

Afinidad de sesión de Front Door solo donde sea necesario

Mantén las API sin estado (stateless) y confía en Redis para el estado de la sesión; deshabilita la afinidad de sesión de Front Door para las rutas /api/. Para una herramienta de administración heredada que requiera afinidad, habilítala en /admin/ con un TTL corto.
Por qué: Maximiza la distribución de carga y la capacidad de almacenamiento en caché para la mayoría de los usuarios, al tiempo que limita la afinidad al ámbito mínimo requerido.

Esta arquitectura utiliza Front Door para un enrutamiento de borde inteligente y seguro y WAF, Azure CDN para la entrega de contenido estático con alta tasa de aciertos y control preciso de la frescura, y Azure Cache for Redis para descargar lecturas intensivas, mantener datos de sesión y tablas de clasificación de baja latencia, y absorber picos de tráfico con elegancia.

← Soluciones de mensajería y basadas en eventos de Azure · Todos los dominios · Supervisión →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →