서울 사용자는 빠른데 미국·유럽 사용자는 페이지가 3초씩 걸린다고 합니다. 이미지가 전부 서울 원본 서버에서 지구를 돌아가는 탓입니다. 게다가 어느 날 새벽, HTTPS 인증서가 만료돼 전 사용자가 '안전하지 않음' 경고를 봤습니다. 빠르게, 그리고 안전하게 전 세계로 보내는 일은 DNS·CDN·인증서가 함께 풉니다.
- 1관리형 DNS가 단순 주소 변환을 넘어 트래픽을 제어하는 방법을 안다
- 2CDN이 엣지 캐싱으로 지연·부하를 줄이는 원리를 설명할 수 있다
- 3캐시 TTL·캐시 키·무효화가 왜 중요한지 이해한다
- 4TLS 인증서를 관리형으로 자동 갱신하는 이점을 안다
- 5DNS→CDN→LB→원본으로 이어지는 요청 경로를 그릴 수 있다
이름으로 안내하고, 가까운 곳에서 답한다
관리형 DNS — 주소록을 넘어선 트래픽 제어
DNS는 기본적으로 example.com → IP를 알려줍니다. 관리형 DNS(Route 53 등)는 여기에 트래픽 제어를 더합니다.
- failover: 헬스체크로 주(primary)가 죽으면 예비(secondary)로 자동 전환
- 지연/지리 기반: 사용자와 가까운 리전·엣지로 보냄
- 가중치: 10%만 새 버전으로 보내는 점진 배포([[release-strategy]])
같은 도메인이라도 누가·어디서 묻느냐에 따라 다른 답을 줄 수 있습니다.
CDN — 콘텐츠를 사용자 옆으로 옮긴다
CDN은 이미지·JS·CSS·동영상 같은 정적 콘텐츠를 전 세계 엣지 로케이션에 캐싱합니다. 사용자는 먼 원본(origin) 대신 가까운 엣지에서 받아 지연이 줄고, 원본 서버는 같은 파일을 매번 안 보내도 되니 부하·전송비가 줍니다.
핵심 개념 두 가지: TTL(엣지가 콘텐츠를 보관하는 시간)과 캐시 키(무엇을 기준으로 같은 콘텐츠로 볼지). 이 둘을 모르면 캐시가 너무 오래 남거나(옛 버전 노출) 너무 안 먹습니다(원본 부하 그대로).
TLS 인증서 — 관리형으로 자동 갱신
HTTPS를 위한 TLS 인증서를 수동 관리하면 '갱신을 잊어 만료→전체 다운' 사고가 납니다. 관리형 인증서 서비스(예: ACM)는 무료 발급·자동 갱신되며, 로드밸런서나 CDN에 붙여 HTTPS를 종단합니다. 운영에서 인증서는 "한 번 붙이고 자동으로 갱신되게" 하는 것이 정답입니다.
어떤 레코드가 어디를 가리키는지, 라우팅 정책이 걸렸는지 확인합니다.
aws route53 list-resource-record-sets --hosted-zone-id "$ZONE_ID" \
--query "ResourceRecordSets[?Type=='A'].{Name:Name,Alias:AliasTarget.DNSName,Policy:Failover}" --output table
+------------------+-----------------------------+----------+
| app.example.com | d111.cloudfront.net | - |
| api.example.com | alb-123.elb.amazonaws.com | PRIMARY |
+------------------+-----------------------------+----------+
aws route53 list-resource-record-sets응답 헤더로 CDN 캐시 적중 여부를 봅니다(X-Cache: Hit from cloudfront 등). HTTPS·캐시 동작을 한 번에 점검합니다.
curl -sI https://app.example.com/static/main.abc123.js | grep -iE "x-cache|cache-control|server"
server: CloudFront
x-cache: Hit from cloudfront
cache-control: public, max-age=31536000, immutable
curl -I- x-cache가 'Miss'만 반복되면 — 캐시 키 설정 과다(쿼리·쿠키별 분리)나 짧은 TTL로 캐시가 안 먹는 것. 원본 부하·비용 그대로
- Cache-Control max-age 값 — 정적 자산인데 너무 짧으면 효과↓, 자주 바뀌는데 너무 길면 옛 버전 노출
- 파일명에 해시가 없는 정적 자산 + 긴 TTL — 배포해도 사용자에게 안 바뀜. 해시 파일명 또는 무효화 필요
- 인증서 만료일(NotAfter) — 자동 갱신 대상인지, 임박했는지. 수동 인증서면 만료 모니터링 필수
상황: 새 버전을 배포해도 CDN/브라우저가 옛 정적 파일을 계속 제공.
원인: 정적 파일 이름이 그대로(main.js)인데 긴 TTL로 엣지·브라우저에 캐시돼 있음. TTL이 끝나기 전엔 새 파일을 안 받아옴.
진단: curl -I로 x-cache와 cache-control max-age 확인 → 파일명이 빌드마다 바뀌는지 확인.
해결: 정적 자산은 내용 기반 해시 파일명(main.abc123.js)을 쓰면, 내용이 바뀔 때 파일명이 바뀌어 캐시가 자연히 갱신됩니다(HTML은 짧은 TTL). 급하면 CDN 무효화(invalidation) 를 호출. 무효화 남발은 비용·지연이 있으니 해시 파일명이 근본 해법입니다.
"전 세계 사용자인데 특정 지역만 느려요"의 단골 해법이 CDN 도입과 지연 기반 라우팅입니다. 반대로 "CDN을 붙였는데 원본 부하가 안 줄어요"는 거의 항상 캐시 키·TTL 설정 문제 — 캐시 히트율(x-cache Hit 비율)을 지표로 보고 튜닝합니다.
인증서 만료로 인한 전사 장애는 의외로 흔합니다. 관리형 인증서 자동 갱신 + 만료 임박 알림([[cloud-observability-governance]])을 기본으로 둡니다. DNS는 변경이 전 세계에 퍼지는 데 시간(TTL)이 걸리므로, 마이그레이션 전 TTL을 미리 줄여두는 것도 실무 팁입니다.
다음 모듈에서는 컴퓨트·네트워크를 떠나 데이터가 사는 곳 — 오브젝트·블록·파일 스토리지의 종류와 선택 기준으로 들어갑니다.