[네트워크]CloudFront(CDN)에 대해서

OSI 7계층을 공부하며 실습을 위해 터미널을 열었습니다. 당연히 dig를 치면 바로 IP 주소가 나오고, 와이어샤크에 그 IP를 넣으면 패킷이 잡힐 줄 알았습니다. 하지만 현실은 달랐습니다. aws.amazon.com/ko/는 조회가 안 되고, 겨우 찾아낸 주소는 IP가 아닌 또 다른 도메인 이름이었습니다. 이러한 과정 속에서 발견한 CloudFront의 메커니즘과 계층별 통신의 디테일을 공유하고자 이 글을 작성하게 되었습니다.

CloudFront 

1. 별칭(CNAME)의 정체

aws.amazon.com을 조회했을 때 나타난 복잡한 도메인 주소들이 나옵니다. 그것이 바로 CloudFront가 동작하고 있다는 가장 확실한 증거입니다. AWS는 직접 IP를 알려주는 대신, CloudFront라는 '중간 전달자'를 거치게 설계되어 있습니다.

---

2. CloudFront(CDN)란 무엇인가?

CDN은 Content Delivery Network의 약자로, 콘텐츠를 사용자에게 더 빨리 전달하기 위해 전 세계에 거점을 둔 캐시 서버 망입니다.

• 핵심 원리 (Caching): 원본 서버(Origin)에 있는 데이터를 전 세계 곳곳의 엣지 로케이션(Edge Location)에 복사해 둡니다.
• 비유: 한국에 있는 맛집(원본 서버) 음식을 먹으려고 매번 한국에 오는 대신, 우리 집 앞 편의점(엣지 서버)에 입점된 밀키트를 사 먹는 것과 같습니다.

---

3. 왜 CloudFront를 써야 할까? (인프라적 이점)

1. 지연 시간(Latency) 최소화: 물리적 거리가 가까운 엣지 서버에서 데이터를 가져오므로 웹사이트 로딩 속도가 비약적으로 향상됩니다.
2. 보안 강화 (Shield & WAF): 실제 서버의 IP를 숨길 수 있고, DDoS 공격 같은 대규모 트래픽을 엣지 단계에서 먼저 흡수하여 방어합니다.
3. 트래픽 분산: 모든 부하가 메인 서버로 몰리는 것을 방지해 서버 비용을 절감하고 가용성을 높입니다.

---

4. 실습과의 연결: OSI 계층으로 보는 CloudFront

단계	동작 원리	관련 계층
DNS 조회	사용자와 가장 가까운 엣지 서버 IP를 할당 (CNAME 체인 확인)	L3 (Network)
연결 수립	사용자 <-> 엣지 서버 간의 빠른 TCP 연결	L4 (Transport)
데이터 전송	캐싱된 콘텐츠 전송 및 HTTPS 암호화 처리	L7 (Application)

---

5. 엣지 로케이션보다 실제 서버가 더 가까운 경우

한가지 의문점이 드는 부분은 “CDN(CloudFront)을 사용하면 무조건 속도가 빨라질까?”였다. “실제 서버(Origin)가 바로 옆에 있다면 어떻게 될까?”에 대한 궁금증을 인프라 관점에서 풀어보고자 합니다.

---

5.1) 물리적 거리보다 중요한 '경로의 원칙'

결론부터 말하면, 실제 서버가 아무리 가까워도 클라이언트는 항상 엣지 로케이션(Edge Location)과 통신합니다.

• 이유: DNS 조회 결과가 이미 엣지 로케이션의 IP를 가리키고 있기 때문입니다. 클라이언트는 실제 서버의 존재를 모른 채 엣지 서버를 '최종 목적지'로 알고 데이터를 요청합니다.
• 이점: 실제 서버의 IP를 숨겨 보안을 강화(보안 계층 유지)하고, 모든 트래픽을 CDN의 최적화된 네트워크 경로 안에서 통제할 수 있습니다.

---

5.2) 캐시 히트(HIT) vs 캐시 미스(MISS)

성능의 핵심은 엣지 서버에 데이터가 '있느냐 없느냐'에 달려 있습니다.

• Cache HIT: 엣지 서버에 이미 데이터가 있는 상태입니다. 실제 서버가 멀든 가깝든 엣지 서버가 즉시 응답하므로 가장 빠릅니다.
• Cache MISS: 엣지 서버에 데이터가 없는 상태입니다. 엣지 서버가 실제 서버(Origin)에 데이터를 가지러 갔다 와야 하므로, 이때는 실제 서버가 가까울수록 유리하지만, CDN을 거치지 않는 것보다 단계가 하나 더 추가되어 속도가 약간 떨어질 수 있습니다.

---

5.3) 캐시 미스는 언제 발생할까?

홈페이지 정보는 항상 캐시에 머물 것 같지만, 다음과 같은 상황에서 '미스'가 발생합니다.

1. 최초 접속: 해당 지역 엣지 서버에 아무도 접속한 적이 없어 데이터가 아직 복사되지 않았을 때.
2. TTL(Time To Live) 만료: 캐시에는 유효 기간이 있습니다. 이 시간이 지나면 엣지 서버는 데이터를 지우고 다시 오리진 서버에 최신 정보를 요청합니다.
3. 데이터 업데이트: 서버의 파일이 바뀌었더라도 CDN은 자동으로 알지 못합니다. 이때 TTL이 만료될 때까지 기다리거나, '캐시 무효화(Invalidation)'를 실행해야 합니다.

---

5.4) 캐시 무효화(Invalidation)

새로운 코드를 배포했는데 사용자들에게 예전 화면이 보인다면?

• 문제: 전 세계 엣지 서버의 캐시가 아직 살아있기 때문입니다.
• 해결: CloudFront Invalidation(무효화)을 실행합니다. 이는 전 세계 엣지 서버에 "지금 들고 있는 캐시 다 버리고, 오리진 서버에서 새로 가져와!"라고 명령을 내리는 과정입니다.

---

6. 마무리

CloudFront의 메커니즘은 단순히 속도를 높이는 기술을 넘어, 보안과 효율이라는 두 마리 토끼를 잡기 위한 인프라 엔지니어들의 정교한 설계가 녹아있음을 보여줍니다. OSI 7계층을 검증하기 위해 와이어샤크를 사용했고, ip 주소를 확인하던 과정에서 생긴 의문 하나를 통해  해결해 나아간 이번 과정이 좋은 기초체력이 되기를 바랍니다.