Microsoft AZ-204: Cache, CDN e Desempenho do Azure — Guia de estudos

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

Faz parte do Microsoft Azure Developer Associate AZ-204 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

Experiências de usuário rápidas e confiáveis no Azure dependem de posicionar conteúdo e estado perto dos usuários, minimizando a carga na origem e lidando com falhas de forma elegante. O Azure Cache for Redis, a Azure CDN e o Azure Front Door, juntos, fornecem aceleração em memória, cache de borda e roteamento anycast global com segurança. Dominar as estruturas de dados do Redis e os padrões de conexão, os perfis da CDN e a semântica de cache, e o roteamento e as investigações de integridade (health probes) do Front Door permite que você projete aplicações resilientes e de baixa latência.

Azure Cache for Redis: camadas, estruturas de dados, remoção e padrões

O Azure Cache for Redis é um serviço Redis gerenciado que fornece acesso a dados em submilisegundos, suportando estruturas de dados comuns do Redis e capacidades avançadas nas camadas (tiers) superiores.

Camadas (Tiers):

Básico: Cache de nó único sem SLA e sem replicação de dados. Bom para desenvolvimento/teste e cargas de trabalho não críticas. Sem persistência de dados, sem clustering, sem integração com VNet.
Standard: Primário/réplica de dois nós com failover automático e um SLA. Adequado para produção. Suporta escalonamento vertical (up/down) com interrupção mínima, mas sem clustering ou persistência.
Premium: Desempenho e throughput mais altos, tamanhos de cache maiores, persistência do Redis (RDB e AOF), clustering (sharding) para escala horizontal, integração com rede virtual (virtual network), redundância de zona (em regiões suportadas) e georreplicação para DR. Também suporta janelas de patch agendadas e segurança avançada.

Estruturas de dados e quando usá-las:

Strings: Chave/valor básico, contadores, blobs JSON; INCR/DECR atômicos para limitação de taxa (rate limiting) e contadores.
Hashes: Armazena campos de objetos (ex: perfil de usuário) como uma única chave com pares de campo-valor para atualizações parciais e eficiência de espaço.
Lists: Filas ou pilhas, ordenadas por inserção; use com LPUSH/BRPOP para filas de trabalho simples.
Sets: Coleções de itens únicos; use para tags, verificações de associação (membership), interseções.
Sorted Sets: Ranking com pontuações (scores); ideal para placares de líderes (leaderboards) e eventos ordenados por tempo.
Bitmaps/Bitfields: Rastreamento compacto de flags booleanos e contadores sobre posições.
HyperLogLog: Cardinalidade aproximada (contagens de itens únicos) com memória fixa.
Geospatial: Armazena e consulta coordenadas de latitude/longitude, buscas por raio.
Streams: Log somente de acréscimo (append-only) para ingestão de eventos e grupos de consumidores.

Políticas de remoção (aplicadas quando o maxmemory é atingido):

volatile-lru: Remove as chaves menos recentemente usadas com um tempo de expiração (padrão no Azure Cache for Redis).
allkeys-lru: Remove as chaves menos recentemente usadas, independentemente do tempo de expiração.
volatile-ttl: Remove as chaves com o tempo de expiração mais próximo.
volatile-random / allkeys-random: Remove chaves aleatórias, limitado a chaves que expiram ou a todas as chaves.
noeviction: Não remove; comandos de escrita que adicionariam memória falham com um erro.
volatile-lfu / allkeys-lfu: Variantes de remoção das menos frequentemente usadas (para versões mais recentes do Redis).

Escolha a política de remoção com base na criticidade dos dados e nos padrões de acesso. Para caches, allkeys-lru ou allkeys-lfu oferecem as melhores taxas de acerto (hit rates). Para armazenamentos mistos com expirações cuidadosamente definidas, volatile-ttl ou volatile-lru podem respeitar seus TTLs.

Casos de uso comuns:

Cache de sessão: Armazene o estado da sessão do usuário via IDistributedCache ou middleware de sessão. Mantenha as chaves pequenas, use um TTL alinhado com o timeout da sessão e habilite a afinidade de sessão na borda, se necessário.
Cache de saída: Armazene em cache fragmentos de página renderizados ou respostas completas, usando como chave a rota e o segmento de usuário. Invalide em caso de alterações de conteúdo usando versionamento de chave ou um DEL explícito.
Pub/Sub: Mensageria quase em tempo real para notificações ou distribuição (fan-out) de invalidação de cache. Use canais para transmitir alterações para múltiplos assinantes (subscribers).
Placares de líderes (Leaderboards): Sorted sets com pontuações (scores) para ranking; ZADD/ZREVRANGE para atualizar e ler o top-N; use sorted sets secundários para rankings com janela de tempo.

Conectando-se ao Azure Redis: strings de conexão, StackExchange.Redis e resiliência

Os endpoints de conexão e as chaves são fornecidos no portal do Azure em Access keys. A string de conexão primária inclui host, porta, TLS e senha (por exemplo, contoso.redis.cache.windows.net:6380,password=…;ssl=True;abortConnect=False). Sempre use TLS na porta 6380 em produção.

Melhores práticas do StackExchange.Redis:

Use um único ConnectionMultiplexer de longa duração por processo. Ele é thread-safe e multiplexa requisições eficientemente. Crie-o uma vez, armazene-o em um contêiner estático ou de DI (Injeção de Dependência) e reutilize-o.
Opções de configuração: defina AbortOnConnectFail=false para tolerância a failover na nuvem; defina ConnectRetry e ConnectTimeout para problemas transitórios; SyncTimeout ajustado para a carga de trabalho; KeepAlive para manter os pinholes de NAT. Exemplo de opções em formato de texto: ssl=True, abortConnect=False, connectRetry=5, connectTimeout=5000.
Use métodos assíncronos para evitar o esgotamento do pool de threads (thread pool starvation) sob carga. Os métodos da IDatabase (StringGetAsync, HashSetAsync, SortedSetAddAsync) não são bloqueantes.
Lide com eventos de resiliência: inscreva-se (subscribe) nos eventos ConnectionFailed, ConnectionRestored e ConfigurationChanged para registrar e observar mudanças de topologia e failovers. O StackExchange.Redis resolve novamente o primário automaticamente em caso de failover.
Evite scripts Lua de longa execução e transações pesadas; prefira comandos pequenos e atômicos. O pipeline ocorre naturalmente através do multiplexer; não agrupe comandos em lote (batch) a ponto de causar timeouts.
Timeouts e novas tentativas (retries): não tente novamente de forma cega comandos que não são idempotentes. Use padrões idempotentes ou filas write-through para escritas críticas.
Serialização: armazene payloads compactos (ex: MessagePack) para minimizar o tráfego de rede e a memória. Evite valores gigantes; prefira hashes com acesso no nível do campo.
Nomenclatura de chaves: use prefixos por aplicação/ambiente (prod:session:{userId}) para evitar colisões e simplificar operações em massa e limpezas.
Segurança: rotacione as chaves de acesso, restrinja via VNet (Premium) e considere o Private Link para acesso privado. Não defina “Allow access only via SSL” como falso em produção.

Azure CDN: perfis, endpoints, origens, otimização e atualização de conteúdo

A Azure CDN armazena conteúdo estático em cache em POPs de borda para reduzir a latência e a carga na origem. Um perfil de CDN agrupa endpoints e o nível de preço/provedor; um endpoint define o hostname de borda e se conecta a uma ou mais origens.

Perfis e endpoints:

Crie um ou mais endpoints por aplicação ou ambiente sob um perfil. Cada endpoint tem seu próprio hostname de borda (ex: app.azureedge.net) que você mapeia para domínios personalizados com TLS.
Use perfis separados para isolar o faturamento ou aplicar diferentes provedores/recursos, se necessário.

Tipos de origem:

Azure Blob Storage: Ideal para sites estáticos e mídias grandes. Habilite a opção Static website ou mapeie para um contêiner; garanta os tipos MIME e os cabeçalhos de cache adequados.
App Service: Use para conteúdo dinâmico ou APIs REST onde respostas selecionadas podem ser cacheadas. Configure o cabeçalho de host de origem (origin host header) para o hostname da sua aplicação e garanta o uso de HTTPS.
Origem personalizada (Custom origin): Qualquer endpoint HTTP(S) publicamente acessível, incluindo on-premises por meio de um IP público ou proxy reverso.

Tipos de otimização (aplicados na criação do endpoint):

Entrega geral da web (General web delivery): Balanceado para muitos ativos de pequeno/médio porte (HTML, CSS, JS, imagens) com cobertura ampla de POPs.
Download de arquivos grandes (Large file download): Otimizado para arquivos grandes com ajuste de solicitações de intervalo (range requests), gerenciamento de conexão e configurações orientadas à vazão (throughput).
Streaming de vídeo (Video streaming): Otimizado para download progressivo ou entrega de segmentos HLS/DASH, mantendo o cache de segmentos eficiente e respeitando solicitações de intervalo de bytes (byte-range requests).

Regras de cache e purga:

Regras de cache globais e personalizadas permitem que você controle os TTLs com base no caminho, extensão do arquivo, método da solicitação e comportamento da query string. Nos níveis Standard, configure as regras nas configurações de cache do endpoint; o nível Premium adiciona mecanismos de regras avançados.
Faça a purga (purge) de conteúdo inválido por caminho com curingas (ex: /images/*) através do portal, CLI ou API REST. As purgas se propagam por todos os POPs; use purgas direcionadas para minimizar o raio de impacto (blast radius). Os níveis Premium suportam o pré-carregamento (preload) para aquecer os caches.

Controles de atualização do conteúdo:

TTL: A CDN respeita os cabeçalhos Cache-Control e Expires da origem por padrão. Você pode sobrescrever ou definir TTLs mínimos/máximos com regras. Para ativos imutáveis, sirva

undefined

para maximizar as taxas de acerto (hit rates).

Diretivas Cache-Control: no-store e private não são cacheados pela CDN; must-revalidate e s-maxage permitem um controle refinado do cache compartilhado. Prefira s-maxage para TTLs específicos da CDN, mantendo o max-age conservador para os navegadores.
Comportamento de cache de query string: escolha entre ignorar query strings (um único objeto cacheado por caminho), cachear cada URL única (cada combinação de query string é cacheada separadamente) ou ignorar o cache na presença de query string. Para ativos versionados (ex: app.css?v=hash), cacheie cada URL única. Para parâmetros de analytics (utm_), ignore as query strings para melhorar as taxas de acerto.
Vary e compressão: Garanta que Vary: Accept-Encoding esteja definido ao usar compressão; a CDN cacheará variantes separadas por chave do Vary. Habilite a compressão da CDN para ativos de texto para reduzir a largura de banda.

Azure Front Door: roteamento global, saúde, segurança e afinidade

O Azure Front Door oferece balanceamento de carga global de Camada 7 baseado em anycast, aceleração dinâmica de sites e WAF integrado. Ele complementa a CDN ao rotear e proteger o tráfego dinâmico, enquanto opcionalmente armazena em cache o conteúdo estático nas camadas Standard/Premium.

Regras de roteamento:

Correspondem a hostnames e padrões de caminho de entrada e roteiam para um grupo de origem (pool de back-end). Aplique reescritas de caminho, transformações de cabeçalho, redirecionamentos e configurações de protocolo por regra.
Configure o cache na rota (Standard/Premium) para o armazenamento em cache de borda de ativos estáticos ou semi-estáticos quando desejar um controle mais rígido na borda da aplicação.
Use failover baseado em prioridade e balanceamento de carga ponderado entre as origens, opcionalmente com filtragem geográfica para roteamento específico da região.

Sondas de saúde e saúde do back-end:

Defina o caminho da sonda, protocolo, intervalo e códigos de status HTTP esperados. As sondas são executadas de vários locais de borda para determinar a saúde da origem.
O Front Door usa o status de saúde para direcionar o tráfego para origens saudáveis com baixa latência. Ajuste os timeouts e o tamanho da amostra para evitar oscilações (flapping); garanta que o endpoint da sonda seja leve e não armazenado em cache.

Integração com WAF:

Anexe uma política de WAF ao seu Front Door para aplicar conjuntos de regras gerenciadas para vulnerabilidades web comuns e adicione regras personalizadas para restrições de IP, bloqueio geográfico ou limites de tamanho de solicitação.
Use proteção contra bots e limitação de taxa (rate limiting) para absorver o tráfego abusivo na borda, preservando a capacidade da origem.

Afinidade de sessão:

Habilite a afinidade de sessão quando sua aplicação exigir que solicitações consecutivas atinjam o mesmo back-end (por exemplo, estado de sessão não distribuído). O Front Door injeta um cookie de afinidade e roteia as solicitações subsequentes na mesma sessão para o back-end selecionado dentro de uma regra de roteamento.
Prefira designs stateless (sem estado) ou estado de sessão baseado em Redis para evitar a afinidade sempre que possível; se usada, defina o escopo da afinidade com cuidado e configure TTLs de cookie apropriados.

Interação com a CDN:

A CDN deve servir ativos estáticos (imagens, scripts, mídia) com TTLs longos; o Front Door roteia solicitações dinâmicas com WAF, terminação TLS e roteamento baseado em caminho. Essa divisão maximiza as taxas de acerto de cache (cache hit rates) e minimiza a latência dinâmica.
Para APIs ou páginas que não podem ser armazenadas em cache, mantenha o TTL baixo ou ignore o cache; para HTML semi-estático, considere TTLs curtos com fluxos de trabalho de purga na alteração (purge-on-change).

Cenário de Problema Prático

A Mozilla está lançando um microssite global para descoberta de add-ons com altos picos de tráfego durante os lançamentos. Eles precisam de entrega rápida de ativos estáticos, APIs dinâmicas resilientes e interações de usuário seguras e de baixa latência em todo o mundo.

Front Door para entrada global e segurança

Crie um perfil Front Door Standard com um domínio personalizado e TLS gerenciado. Defina regras de roteamento: /api/* para o grupo de origem da API do App Service e /* para o hostname do endpoint da CDN.
Por quê: O roteamento anycast leva os usuários à borda mais próxima; o WAF no Front Door bloqueia padrões maliciosos antes que cheguem às origens; o roteamento baseado em caminho separa claramente o tráfego dinâmico e estático.

Política de WAF e limitação de taxa (rate limiting)

Anexe uma política de WAF com conjuntos de regras gerenciadas habilitados e uma regra personalizada para limitar solicitações POST excessivas para /api/search.
Por quê: Protege as APIs contra ataques da classe OWASP e clientes abusivos, preservando a capacidade da origem durante os picos.

Sondas de saúde e grupos de origem

Configure o grupo de origem da API com duas instâncias do App Service em regiões diferentes. Use sondas de saúde em /healthz com status 200 esperado e um intervalo de 10 segundos. Defina uma região como prioridade 1 e a outra como prioridade 2, com failover.
Por quê: Garante o failover regional automático se uma região primária se degradar; as sondas detectam a saúde independentemente das respostas em cache.

Sessão baseada em Redis e cache de saída

Implante o Azure Cache for Redis Standard e integre a API com IDistributedCache para armazenar um estado de sessão mínimo e fragmentos de saída de curta duração para respostas comuns da API (por exemplo, listas de add-ons populares) com TTLs de 60 a 300 segundos.
Por quê: Reduz a latência da API e a carga no banco de dados, mantendo o estado fora da camada web; TTLs curtos mantêm os dados atualizados sem invalidação manual.

Estruturas de dados do Redis para placares de líderes (leaderboards)

Use um sorted set do Redis por categoria (por exemplo, addons:top:{category}) para manter classificações baseadas em downloads. Atualize as pontuações de forma assíncrona por meio de um consumidor de fila e exponha APIs de leitura que leem as N principais entradas.
Por quê: Os sorted sets fornecem atualizações em O(log n) e leituras de intervalo rápidas, perfeitos para classificações em tempo real com alta concorrência de leitura.

Resiliência de conexão com StackExchange.Redis

Inicialize um singleton ConnectionMultiplexer com ssl=True, abortConnect=False, connectRetry=5 e timeouts sensatos. Manipule os eventos ConnectionFailed/Restored para observabilidade e defina o SyncTimeout alto o suficiente para picos, enquanto usa APIs assíncronas.
Por quê: Garante o tratamento de failover transparente e evita interrupções em todo o processo durante eventos de rede transitórios ou failovers do Redis.

CDN para ativos estáticos com cache agressivo

Crie um perfil e um endpoint da Azure CDN otimizados para entrega web geral com o site estático da conta de armazenamento como origem. Configure regras de cache para honrar os cabeçalhos de origem, mas substitua para um TTL de 7 dias para /static/*, e habilite a compressão. Defina o cache de query string como “Cache every unique URL” e use fingerprinting nos ativos (app.css?v=hash).
Por quê: O cache de borda entrega ativos rapidamente em todo o mundo; o fingerprinting permite TTLs longos com atualizações instantâneas em deploys; a compressão reduz os tamanhos de transferência.

Processo de purga no CI/CD

Adicione uma etapa de implantação que purga os caminhos da CDN para manifestos HTML e JSON no lançamento (por exemplo, /index.html, /manifest/*.json) e pré-carrega páginas críticas para aquecer os caches nas camadas suportadas.
Por quê: Garante que os usuários recebam o HTML novo rapidamente, mantendo os ativos imutáveis em cache; o pré-carregamento (preloading) reduz a latência de partida a frio (cold-start) pós-deploy.

Afinidade de sessão do Front Door apenas onde necessário

Mantenha as APIs stateless e dependa do Redis para o estado da sessão; desabilite a afinidade de sessão do Front Door para as rotas /api/. Para uma ferramenta de administração legada que requer afinidade, habilite-a em /admin/ com um TTL curto.
Por quê: Maximiza a distribuição de carga e a capacidade de cache para a maioria dos usuários, limitando a afinidade ao escopo mínimo necessário.

Essa arquitetura usa o Front Door para roteamento de borda seguro e inteligente e WAF, a Azure CDN para entrega de conteúdo estático com alta taxa de acertos de cache (high-hit-rate) e controle preciso de atualização, e o Azure Cache for Redis para descarregar leituras frequentes (hot reads), manter dados de sessão e placares de líderes de baixa latência e absorver picos de forma suave.

← Soluções do Azure Baseadas em Eventos e Mensagens · Todos os domínios · Monitoramento →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →