Microsoft AZ-204: Azure 캐싱, CDN 및 성능 — 학습 가이드

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

다음의 일부입니다: Microsoft Azure Developer Associate AZ-204 — 학습 가이드. 검증된 답안으로 연습하기: Microsoft 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

개요

Azure에서 빠르고 안정적인 사용자 경험을 제공하려면 콘텐츠와 상태를 사용자와 가까운 곳에 배치하고, 원본 부하를 최소화하며, 장애를 정상적으로 처리해야 합니다. Azure Cache for Redis, Azure CDN, Azure Front Door는 함께 인메모리 가속, 에지 캐싱, 보안을 갖춘 글로벌 애니캐스트 라우팅을 제공합니다. Redis 데이터 구조와 연결 패턴, CDN 프로필과 캐싱 의미 체계, Front Door 라우팅 및 상태 프로브를 마스터하면 지연 시간이 짧고 복원력 있는 애플리케이션을 설계할 수 있습니다.

Azure Cache for Redis: 계층, 데이터 구조, 제거 정책 및 패턴

Azure Cache for Redis는 밀리초 미만의 데이터 액세스를 제공하는 관리형 Redis 서비스로, 일반적인 Redis 데이터 구조와 상위 계층의 고급 기능을 지원합니다.

계층:

Basic: SLA 및 데이터 복제가 없는 단일 노드 캐시입니다. 개발/테스트 및 중요하지 않은 워크로드에 적합합니다. 데이터 지속성, 클러스터링, VNet 통합을 지원하지 않습니다.
Standard: 자동 장애 조치 및 SLA를 갖춘 2노드 주/복제본 구성입니다. 프로덕션 환경에 적합합니다. 중단을 최소화하면서 스케일 업/다운을 지원하지만, 클러스터링이나 지속성은 지원하지 않습니다.
Premium: 더 높은 성능과 처리량, 더 큰 캐시 크기, Redis 지속성(RDB 및 AOF), 수평적 확장을 위한 클러스터링(샤딩), 가상 네트워크 통합, 영역 중복성(지원되는 지역), DR을 위한 지역 복제를 제공합니다. 또한 예약된 패치 기간과 고급 보안도 지원합니다.

데이터 구조 및 사용 시기:

Strings: 기본 키/값, 카운터, JSON blob; 속도 제한 및 카운터를 위한 원자적 INCR/DECR 연산에 사용합니다.
Hashes: 객체 필드(예: 사용자 프로필)를 필드-값 쌍을 가진 단일 키로 저장하여 부분 업데이트와 공간 효율성을 높입니다.
Lists: 삽입 순서대로 정렬되는 큐 또는 스택; 간단한 작업 큐를 위해 LPUSH/BRPOP와 함께 사용합니다.
Sets: 고유한 컬렉션; 태그, 멤버십 확인, 교집합 연산에 사용합니다.
Sorted Sets: 점수를 이용한 순위 지정; 순위표 및 시간 순서 이벤트에 이상적입니다.
Bitmaps/Bitfields: 위치에 따른 불리언 플래그 및 카운터를 간결하게 추적합니다.
HyperLogLog: 고정된 메모리로 카디널리티(고유 개수)를 근사적으로 계산합니다.
Geospatial: 위도/경도 좌표를 저장하고 쿼리하며, 반경 검색을 수행합니다.
Streams: 이벤트 수집 및 소비자 그룹을 위한 추가 전용 로그입니다.

제거 정책 (maxmemory에 도달했을 때 적용됨):

volatile-lru: 만료가 설정된 키 중에서 가장 최근에 사용되지 않은 키를 제거합니다 (Azure Cache for Redis의 기본값).
allkeys-lru: 만료 여부와 관계없이 가장 최근에 사용되지 않은 키를 제거합니다.
volatile-ttl: 만료 시간이 가장 가까운 키를 제거합니다.
volatile-random / allkeys-random: 만료가 설정된 키 또는 모든 키 중에서 임의의 키를 제거합니다.
noeviction: 제거하지 않음; 메모리를 추가하는 쓰기 명령은 오류와 함께 실패합니다.
volatile-lfu / allkeys-lfu: 가장 적게 사용된 키를 제거하는 변형입니다 (최신 Redis 버전용).

데이터 중요도와 액세스 패턴에 따라 제거 정책을 선택하세요. 캐시의 경우, allkeys-lru 또는 allkeys-lfu가 가장 좋은 적중률을 보입니다. 신중하게 만료를 설정한 혼합 저장소의 경우, volatile-ttl 또는 volatile-lru가 TTL을 존중할 수 있습니다.

일반적인 사용 사례:

세션 캐싱: IDistributedCache 또는 세션 미들웨어를 통해 사용자 세션 상태를 저장합니다. 키를 작게 유지하고, 세션 타임아웃에 맞춰 TTL을 사용하며, 필요한 경우 에지에서 세션 선호도를 활성화합니다.
출력 캐싱: 렌더링된 페이지 조각이나 전체 응답을 경로 및 사용자 세그먼트를 키로 하여 캐시합니다. 콘텐츠 변경 시 키 버전 관리 또는 명시적 DEL을 사용하여 무효화합니다.
Pub/Sub: 알림 또는 캐시 무효화 팬아웃을 위한 거의 실시간 메시징입니다. 채널을 사용하여 여러 구독자에게 변경 사항을 브로드캐스트합니다.
순위표: 순위 지정을 위해 점수가 있는 정렬된 집합을 사용합니다. ZADD/ZREVRANGE로 상위 N개를 업데이트하고 읽으며, 시간대별 순위를 위해 보조 정렬된 집합을 사용합니다.

Azure Redis 연결: 연결 문자열, StackExchange.Redis 및 복원력

연결 엔드포인트와 키는 Azure 포털의 ‘액세스 키’ 아래에 제공됩니다. 기본 연결 문자열에는 호스트, 포트, TLS 및 암호가 포함됩니다(예: contoso.redis.cache.windows.net:6380,password=…;ssl=True;abortConnect=False). 프로덕션 환경에서는 항상 6380 포트에서 TLS를 사용해야 합니다.

StackExchange.Redis 모범 사례:

프로세스당 단일하고 오래 지속되는 ConnectionMultiplexer를 사용하세요. 이는 스레드로부터 안전하며 요청을 효율적으로 다중화합니다. 한 번 생성하여 정적 변수나 DI 컨테이너에 저장하고 재사용하세요.
구성 옵션: 클라우드 장애 조치 허용을 위해 AbortOnConnectFail=false로 설정하고, 일시적인 문제에 대비해 ConnectRetry 및 ConnectTimeout을 설정하며, 워크로드에 맞게 SyncTimeout을 조정하고, NAT 핀홀을 유지하기 위해 KeepAlive를 설정합니다. 텍스트 형식의 옵션 예: ssl=True, abortConnect=False, connectRetry=5, connectTimeout=5000.
부하 시 스레드 풀 고갈을 피하기 위해 비동기 메서드를 사용하세요. IDatabase 메서드(StringGetAsync, HashSetAsync, SortedSetAddAsync)는 논블로킹 방식입니다.
복원력 이벤트 처리: ConnectionFailed, ConnectionRestored, ConfigurationChanged 이벤트를 구독하여 토폴로지 변경 및 장애 조치를 로깅하고 관찰합니다. StackExchange.Redis는 장애 조치 시 자동으로 주 노드를 다시 확인합니다.
오래 실행되는 Lua 스크립트와 무거운 트랜잭션을 피하고, 작고 원자적인 명령을 선호하세요. 멀티플렉서를 통해 자연스럽게 파이프라이닝되며, 타임아웃이 발생할 정도로 과도하게 배치하지 마세요.
타임아웃 및 재시도: 멱등성이 없는 명령을 무조건 재시도하지 마세요. 중요한 쓰기 작업에는 멱등성 패턴이나 write-through 큐를 사용하세요.
직렬화: 네트워크 트래픽과 메모리를 최소화하기 위해 압축된 페이로드(예: MessagePack)를 저장하세요. 거대한 값을 피하고, 필드 수준 액세스가 가능한 해시를 선호하세요.
키 명명: 충돌을 피하고 대량 작업 및 제거를 단순화하기 위해 앱/환경별로 접두사를 붙이세요(예: prod:session:{userId}).
보안: 액세스 키를 순환하고, VNet(Premium)을 통해 제한하며, 프라이빗 액세스를 위해 Private Link를 고려하세요. 프로덕션 환경에서 “SSL을 통해서만 액세스 허용"을 false로 설정하지 마세요.

Azure CDN: 프로필, 엔드포인트, 원본, 최적화 및 콘텐츠 최신성

Azure CDN은 에지 POP에 정적 콘텐츠를 캐시하여 지연 시간을 줄이고 원본 부하를 감소시킵니다. CDN 프로필은 엔드포인트와 가격 책정 계층/공급자를 그룹화합니다. 엔드포인트는 에지 호스트 이름을 정의하고 하나 이상의 원본에 연결됩니다.

프로필 및 엔드포인트:

프로필 아래에 애플리케이션 또는 환경별로 하나 이상의 엔드포인트를 생성합니다. 각 엔드포인트는 고유한 에지 호스트 이름(예: app.azureedge.net)을 가지며, 이를 TLS를 사용하여 사용자 지정 도메인에 매핑합니다.
필요한 경우 청구를 분리하거나 다른 공급자/기능을 적용하려면 별도의 프로필을 사용하세요.

원본 유형:

Azure Blob Storage: 정적 웹 사이트 및 대용량 미디어에 이상적입니다. 정적 웹 사이트 기능을 활성화하거나 컨테이너에 매핑하고, 올바른 MIME 유형과 캐시 헤더를 설정해야 합니다.
App Service: 선택된 응답을 캐시할 수 있는 동적 콘텐츠 또는 REST API에 사용합니다. 원본 호스트 헤더를 앱의 호스트 이름으로 구성하고 HTTPS를 사용하도록 하세요.
사용자 지정 원본: 공용 IP 또는 리버스 프록시를 통해 온프레미스를 포함하여 공개적으로 연결 가능한 모든 HTTP(S) 엔드포인트입니다.

최적화 유형(엔드포인트 생성 시 적용):

일반 웹 전송: 광범위한 POP 커버리지를 통해 다수의 중소 규모 자산(HTML, CSS, JS, 이미지)에 대해 균형을 맞춥니다.
대용량 파일 다운로드: 범위 요청 튜닝, 연결 관리 및 처리량 중심 설정을 통해 대용량 파일에 최적화되어 있습니다.
비디오 스트리밍: 점진적 다운로드 또는 HLS/DASH 세그먼트 전송에 최적화되어 있으며, 세그먼트 캐싱을 효율적으로 유지하고 바이트 범위 요청을 존중합니다.

캐싱 규칙 및 제거(Purging):

전역 및 사용자 지정 캐싱 규칙을 사용하면 경로, 파일 확장자, 요청 메서드 및 쿼리 문자열 동작을 기반으로 TTL을 제어할 수 있습니다. Standard 계층에서는 엔드포인트의 캐싱 설정에서 규칙을 구성하고, Premium 계층에는 고급 규칙 엔진이 추가됩니다.
포털, CLI 또는 REST API를 통해 와일드카드(예: /images/*)를 사용하여 경로별로 유효하지 않은 콘텐츠를 제거(purge)합니다. 제거 작업은 모든 POP로 전파됩니다. 영향 범위를 최소화하려면 대상 지정 제거를 사용하세요. Premium 계층은 캐시를 준비(warming)하기 위한 사전 로드(preload)를 지원합니다.

콘텐츠 최신성 제어:

TTL: CDN은 기본적으로 원본의 Cache-Control 및 Expires 헤더를 따릅니다. 규칙을 사용하여 최소/최대 TTL을 재정의하거나 설정할 수 있습니다. 불변(immutable) 자산의 경우,

undefined

을 제공하여 적중률을 극대화하세요.

Cache-Control 지시문: no-store와 private은 CDN에 의해 캐시되지 않습니다. must-revalidate와 s-maxage는 세분화된 공유 캐시 제어를 허용합니다. CDN 관련 TTL에는 s-maxage를 선호하고, 브라우저용으로는 max-age를 보수적으로 유지하는 것이 좋습니다.
쿼리 문자열 캐싱 동작: 쿼리 문자열 무시(경로당 단일 캐시 객체), 모든 고유 URL 캐시(각 쿼리 문자열 조합을 별도로 캐시), 또는 쿼리 문자열이 있을 때 캐시 우회 중에서 선택합니다. 버전이 지정된 자산(예: app.css?v=hash)의 경우 ‘모든 고유 URL 캐시’를 사용하세요. 분석 매개변수(utm_)의 경우 ‘쿼리 문자열 무시’를 사용하여 적중률을 높이세요.
Vary 및 압축: 압축 시 Vary: Accept-Encoding이 설정되었는지 확인하세요. CDN은 Vary 키별로 별도의 변형을 캐시합니다. 텍스트 자산에 대해 CDN 압축을 활성화하여 대역폭을 줄이세요.

Azure Front Door: 글로벌 라우팅, 상태, 보안 및 세션 선호도

Azure Front Door는 애니캐스트 기반의 Layer 7 글로벌 부하 분산, 동적 사이트 가속, 통합 WAF를 제공합니다. 동적 트래픽을 라우팅하고 보호하면서 Standard/Premium 등급에서는 정적 콘텐츠를 선택적으로 캐싱하여 CDN을 보완합니다.

라우팅 규칙:

들어오는 호스트 이름과 경로 패턴을 매칭하여 원본 그룹(백엔드 풀)으로 라우팅합니다. 규칙별로 경로 재작성, 헤더 변환, 리디렉션, 프로토콜 설정을 적용합니다.
애플리케이션 엣지에서 더 세밀한 제어가 필요할 때, 정적 또는 반정적 자산의 엣지 캐싱을 위해 경로(Standard/Premium) 수준에서 캐싱을 구성합니다.
원본 간에 우선순위 기반 장애 조치 및 가중치 기반 부하 분산을 사용하며, 선택적으로 지역별 라우팅을 위해 지역 필터링(geo-filtering)을 사용할 수 있습니다.

상태 프로브 및 백엔드 상태:

프로브 경로, 프로토콜, 간격, 예상 HTTP 상태 코드를 정의합니다. 프로브는 여러 엣지 로케이션에서 실행되어 원본 상태를 확인합니다.
Front Door는 상태 정보를 사용하여 트래픽을 대기 시간이 짧은 정상 원본으로 보냅니다. 플래핑(flapping)을 방지하기 위해 타임아웃과 샘플 크기를 조정하고, 프로브 엔드포인트가 가볍고 캐시되지 않도록 해야 합니다.

WAF 통합:

Front Door에 WAF 정책을 연결하여 일반적인 웹 취약점에 대한 관리형 규칙 집합을 적용하고, IP 제한, 지역 차단(geoblocking) 또는 요청 크기 제한을 위한 사용자 지정 규칙을 추가합니다.
봇 보호 및 속도 제한(rate limiting)을 사용하여 엣지에서 악의적인 트래픽을 흡수하고 원본 용량을 보존합니다.

세션 선호도:

애플리케이션이 연속적인 요청을 동일한 백엔드로 보내야 할 때(예: 분산되지 않은 세션 상태) 세션 선호도를 활성화합니다. Front Door는 선호도 쿠키를 주입하고, 동일한 세션의 후속 요청을 라우팅 규칙 내에서 선택된 백엔드로 라우팅합니다.
가능하면 선호도를 피하기 위해 상태 비저장(stateless) 설계나 Redis 기반 세션 상태를 선호합니다. 만약 사용한다면, 선호도 범위를 신중하게 설정하고 적절한 쿠키 TTL을 지정해야 합니다.

CDN과의 상호 작용:

CDN은 긴 TTL로 정적 자산(이미지, 스크립트, 미디어)을 제공해야 합니다. Front Door는 WAF, TLS 종료, 경로 기반 라우팅을 통해 동적 요청을 라우팅합니다. 이러한 분리는 캐시 적중률을 극대화하고 동적 지연 시간을 최소화합니다.
캐시할 수 없는 API나 페이지의 경우 TTL을 낮게 유지하거나 캐싱을 우회합니다. 반정적 HTML의 경우, 변경 시 제거(purge-on-change) 워크플로와 함께 짧은 TTL을 고려합니다.

실용적인 문제 시나리오

Mozilla가 출시 기간 동안 트래픽 급증이 예상되는 애드온 검색을 위한 글로벌 마이크로사이트를 론칭합니다. 이들은 전 세계적으로 빠른 정적 자산 제공, 복원력 있는 동적 API, 안전하고 지연 시간이 짧은 사용자 상호작용이 필요합니다.

글로벌 진입점 및 보안을 위한 Front Door

사용자 지정 도메인과 관리형 TLS를 사용하여 Front Door Standard 프로필을 생성합니다. 라우팅 규칙을 정의합니다: /api/*는 App Service API 원본 그룹으로, /*는 CDN 엔드포인트 호스트 이름으로 라우팅합니다.
이유: 애니캐스트 라우팅은 사용자를 가장 가까운 엣지로 연결합니다. Front Door의 WAF는 악성 패턴이 원본에 도달하기 전에 차단합니다. 경로 기반 라우팅은 동적 트래픽과 정적 트래픽을 깔끔하게 분리합니다.

WAF 정책 및 속도 제한

관리형 규칙 집합이 활성화된 WAF 정책을 연결하고, /api/search로 들어오는 과도한 POST 요청을 조절(throttle)하는 사용자 지정 규칙을 추가합니다.
이유: OWASP급 공격과 악의적인 클라이언트로부터 API를 보호하여 트래픽 급증 시 원본 용량을 보존합니다.

상태 프로브 및 원본 그룹

서로 다른 지역에 있는 두 개의 App Service 인스턴스로 API 원본 그룹을 구성합니다. /healthz 경로에 대해 예상 상태 코드 200과 10초 간격으로 상태 프로브를 사용합니다. 한 지역은 우선순위 1로, 다른 지역은 우선순위 2로 설정하여 장애 조치를 구성합니다.
이유: 주 지역의 성능이 저하될 경우 자동 지역 장애 조치를 보장합니다. 프로브는 캐시된 응답과 독립적으로 상태를 감지합니다.

Redis 기반 세션 및 출력 캐싱

Azure Cache for Redis Standard를 배포하고 API를 IDistributedCache와 통합하여 최소한의 세션 상태와 일반적인 API 응답(예: 인기 애드온 목록)에 대한 단기 출력 조각을 60~300초의 TTL로 저장합니다.
이유: 웹 계층에서 상태를 분리하면서 API 지연 시간과 데이터베이스 부하를 줄입니다. 짧은 TTL은 수동 무효화 없이 데이터의 최신성을 유지합니다.

리더보드를 위한 Redis 데이터 구조

카테고리별로 Redis 정렬 집합(sorted set, 예: addons:top:{category})을 사용하여 다운로드 기반 순위를 유지합니다. 큐 컨슈머를 통해 비동기적으로 점수를 업데이트하고, 상위 N개 항목을 읽는 읽기 API를 노출합니다.
이유: 정렬 집합은 O(log n) 시간 복잡도의 업데이트와 빠른 범위 읽기를 제공하여, 읽기 동시성이 높은 실시간 순위에 완벽합니다.

StackExchange.Redis를 사용한 연결 복원력

싱글톤 ConnectionMultiplexer를 ssl=True, abortConnect=False, connectRetry=5 및 합리적인 타임아웃으로 초기화합니다. 관찰 가능성을 위해 ConnectionFailed/Restored 이벤트를 처리하고, 비동기 API를 사용하면서 버스트(bursts)에 대비해 SyncTimeout을 충분히 높게 설정합니다.
이유: 일시적인 네트워크 이벤트나 Redis 장애 조치 중에도 원활한 장애 조치 처리를 보장하고 프로세스 전체의 중단을 방지합니다.

적극적인 캐싱을 사용하는 정적 자산용 CDN

스토리지 계정 정적 웹사이트를 원본으로 하여 ‘일반 웹 배달’에 최적화된 Azure CDN 프로필과 엔드포인트를 생성합니다. 캐싱 규칙을 구성하여 원본 헤더를 따르도록 하되, /static/* 경로에 대해서는 7일 TTL로 재정의하고 압축을 활성화합니다. 쿼리 문자열 캐싱을 ‘고유한 URL마다 캐시’로 설정하고 자산을 핑거프린팅합니다(app.css?v=hash).
이유: 엣지 캐싱은 전 세계적으로 자산을 빠르게 전달합니다. 핑거프린팅은 배포 시 즉각적인 업데이트를 가능하게 하면서 긴 TTL을 허용합니다. 압축은 전송 크기를 줄입니다.

CI/CD의 퍼지(Purge) 프로세스

릴리스 시 HTML 및 JSON 매니페스트의 CDN 경로(예: /index.html, /manifest/*.json)를 퍼지(purge)하고, 지원되는 등급에서 웜 캐시(warm cache)를 위해 중요한 페이지를 미리 로드하는 배포 단계를 추가합니다.
이유: 불변 자산을 캐시된 상태로 유지하면서 사용자가 최신 HTML을 빠르게 받도록 보장합니다. 미리 로드하면 배포 후 콜드 스타트 지연 시간이 줄어듭니다.

필요한 경우에만 Front Door 세션 선호도 사용

API를 상태 비저장(stateless)으로 유지하고 세션 상태는 Redis에 의존합니다. /api/* 경로에 대한 Front Door 세션 선호도를 비활성화합니다. 선호도가 필요한 레거시 관리 도구의 경우, /admin/* 경로에 짧은 TTL로 활성화합니다.
이유: 대부분의 사용자에 대해 부하 분산 및 캐시 가능성을 극대화하면서, 선호도는 필요한 최소한의 범위로 제한합니다.

이 아키텍처는 안전하고 지능적인 엣지 라우팅 및 WAF를 위해 Front Door를, 정밀한 최신성 제어와 함께 높은 적중률의 정적 콘텐츠 전송을 위해 Azure CDN을, 그리고 핫 리드(hot read) 오프로드, 짧은 지연 시간의 세션 및 리더보드 데이터 유지, 트래픽 급증을 원활하게 흡수하기 위해 Azure Cache for Redis를 사용합니다.

← Azure 이벤트 기반 및 메시지 솔루션 · 모든 도메인 · Azure 모니터링 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →