Edge Computing & CDNs

1. Overview

엣지 컴퓨팅과 CDN(Edge Computing & CDNs)은 뉴욕에 있는 오리진(Origin) 서버 하나로 전 세계 유저를 커버하려다 터지는 글로벌 트래픽의 재앙을 막고, 유저의 스마트폰과 가장 가까운 기지국(Edge)까지 서버를 전진 배치하여 빛의 속도(Latency) 한계를 극복하는 극강의 글로벌 인프라 통제술을 해부합니다.

학습자는 단순히 정적 이미지(JPG)를 캐싱하던 전통적인 **CDN(Content Delivery Network)**의 캐시 적중률(Cache Hit Ratio)과 무효화(Invalidation)의 물리학을 뜯어봅니다. 나아가 정적 파일을 넘어, 사용자와 가장 가까운 엣지 서버(Cloudflare Workers, AWS Lambda@Edge)에서 직접 동적 코드(JS)를 실행하여 오리진 서버의 부하를 0으로 만들어버리는 **엣지 컴퓨팅(Edge Computing)**의 마법을 장악합니다. 마지막으로, 전 세계 어디서 접속하든 밀리초 단위로 데이터를 동기화하는 엣지 데이터베이스(Edge KV)와, 비디오 스트리밍을 끊김 없이 쏘아대는 실시간 글로벌 분산 아키텍처 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• CDN (Content Delivery Network): Point of Presence (PoP), Cache Hit/Miss, Time to Live (TTL), Invalidation(무효화).
• Edge Computing: Cloudflare Workers, Lambda@Edge, Edge Functions (V8 Isolate).
• Edge Data: Edge KV (Key-Value 스토어), CRDT 기반 글로벌 데이터 동기화.
• Latency Optimization: BGP Anycast, TLS Termination at Edge, TCP Connection Reuse.

Out-of-Scope

• 웹팩(Webpack) 프론트엔드 최적화: 브라우저 레벨의 JS 번들링 크기 축소 $\rightarrow$ 프론트엔드 최적화 영역.
• 비디오 코덱 인코딩 (H.264/AV1): 미디어 파일 압축 기술 $\rightarrow$ 미디어 프로세싱 영역으로 위임.

Boundaries

• Cloud vs Edge: 클라우드는 중앙 집중식 데이터센터(AWS 버지니아 리전)에 거대한 컴퓨팅 파워를 몰아넣고 연산하는 구조입니다. 반면 엣지는 연산 능력을 쪼개서 통신사 기지국이나 로컬 캐시 서버(PoP) 등 전 세계 수백 곳에 흩뿌리는 구조입니다. "모든 것을 중앙(Origin)에서 연산한다"는 클라우드의 사고방식을 버리고, "보안 검증(JWT)이나 리다이렉트는 무조건 엣지에서 끝내고 중앙으로 트래픽을 보내지 않는다(Offloading)"는 엣지 오프로딩의 차이를 명확히 경계 짓습니다.

3. Counterexample

• 캐시 무효화(Invalidation)의 악몽: 쇼핑몰 서버에 "블랙프라이데이 $90\%$ 세일" 메인 배너를 올렸습니다. CDN 캐시 TTL을 1주일로 길게 잡아놨습니다. 1시간 뒤 세일이 취소되어 오리진 서버의 배너를 지웠지만, 전 세계 100개의 CDN 엣지에는 여전히 $90\%$ 세일 배너가 캐싱되어 유저들에게 뿌려집니다. 놀란 개발자가 수동으로 캐시 퍼지(Purge/Invalidate)를 날리지만 전파되는 데 5분이 걸려 수억 원의 매출 손실이 발생합니다. "캐시 무효화는 컴퓨터 과학에서 가장 어려운 두 가지 중 하나"라는 명언을 무시하고, Event-driven 캐시 무효화 파이프라인을 구축하지 않은 끔찍한 캐싱 참사입니다.
• 비효율적인 오리진 핑퐁 (Global Latency): 한국 유저가 도쿄 리전의 API를 찌릅니다. 그런데 도쿄 API가 "이 유저가 로그인했는지" 검증(JWT)하기 위해 미국의 인증 서버로 통신을 다녀옵니다. 한국 $\rightarrow$ 도쿄 $\rightarrow$ 미국 $\rightarrow$ 도쿄 $\rightarrow$ 한국으로 데이터가 지구 한 바퀴를 돌면서 API 응답에 2초가 걸립니다. JWT 검증 코드를 AWS Lambda@Edge(서울 엣지)에 배포했다면, 한국에서 10ms 만에 인증을 끝내고 바로 도쿄 API를 찌를 수 있는 엣지 컴퓨팅의 잠재력을 버린 네트워킹 부채입니다.

4. Prerequisites

• 네트워크 레이턴시 (Basic): RTT(Round Trip Time)와 대역폭. (03-02 Networking Basics)
• API 게이트웨이 오프로딩 (Basic): 중앙 집중형 트래픽 통제. (07-06-05 API Gateways)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 빛의 속도와 배달의 민족, CDN (CDN & The Speed of Light)

• Why to Learn: 글로벌 유저를 대상으로 서비스할 때, 오리진(Origin) 서버 하나만으로 버티려다 RTT(Round Trip Time) 지연으로 인해 서비스가 버벅대는 물리적 한계를 인프라로 박살 내기 위함입니다.
• What to Learn:
  • Concepts: CDN (Content Delivery Network), Origin Server, PoP (Point of Presence - 엣지 노드), Cache Hit/Miss, Static Assets (정적 파일).
  • Skills: Cloudfront/Cloudflare를 이용한 정적 리소스(이미지, JS, CSS) 캐싱 아키텍처 설계.
• How to Learn:
  • 1단계: 빛의 한계 (RTT): 서울에서 뉴욕 서버로 패킷을 쏘면 빛의 속도로 편도 100ms, 왕복(RTT) 200ms가 걸립니다. TCP Handshake(3-way)와 TLS 협상까지 더하면 이미지 하나 받아오는 데 1초가 넘게 걸리는 물리적 한계를 해부합니다.
  • 2단계: 동네 슈퍼마켓 (CDN PoP): 뉴욕 서버(Origin)의 정적 이미지를 서울, 도쿄, 파리의 CDN 서버(PoP)에 복사해 둡니다. 서울 유저가 접속하면 가장 가까운 서울 PoP에서 10ms 만에 이미지를 던져줍니다(Cache Hit). 만약 서울 PoP에 이미지가 없으면(Cache Miss), 1번만 뉴욕 서버에 다녀와서 캐싱해 두는 글로벌 물류망을 뜯어봅니다.
• Implement: Cache Hit/Miss 시뮬레이터 로직 (CLI). PoP_Cache = {}. 뉴욕 오리진 지연은 200ms, 서울 PoP 지연은 10ms. 서울 유저가 image.jpg 요청. 1회차: Cache Miss $\rightarrow$ 뉴욕 다녀옴(210ms) $\rightarrow$ PoP_Cache 저장. 2회차: Cache Hit $\rightarrow$ 서울 PoP에서 바로 반환(10ms). 압도적인 성능 차이 콘솔 렌더링.

Recommended

Core Topic 02: 캐시 무효화 지옥 (Cache Invalidation Hell)

• Why to Learn: "컴퓨터 과학의 가장 큰 난제는 캐시 무효화와 변수 네이밍이다"라는 격언처럼, 낡은 캐시 데이터가 유저에게 뿌려져 비즈니스가 망가지는 것을 막기 위함입니다.
• What to Learn:
  • Concepts: TTL (Time To Live), Cache Invalidation (무효화), Cache Purge, Cache Busting (버전 핑거프린팅).
  • Skills: 정적 파일 배포 시 파일명 해시(Hash) 변경을 통한 영구 캐싱(Cache Busting)과, API 응답에 대한 Event-driven 퍼지(Purge) 설계.
• How to Learn:
  • 1단계: 무효화의 고통 (TTL vs Purge): 캐시 수명(TTL)을 1시간으로 주면 1시간 동안 업데이트가 반영 안 됩니다. 1분으로 주면 오리진 서버가 폭발합니다. 수동으로 'Purge(삭제)' API를 쏴도 100개 엣지에 전파되는 데 시간이 걸리는 딜레마를 해부합니다.
  • 2단계: 캐시 버스팅 (Cache Busting): app.js 대신 빌드할 때마다 app_v1.js, app_v2.js처럼 해시값을 붙입니다. 그리고 CDN에는 TTL=100년(영구 캐시)을 때려버립니다. 새 버전을 배포하면 HTML 파일 내의 링크가 v2로 바뀌어 유저 브라우저와 CDN이 완전히 새로운 파일로 인식하게 만드는, 무효화(Invalidate)를 굳이 할 필요가 없는 궁극의 캐시 회피 기법을 뜯어봅니다.
• Implement: 빌드 해시 기반 Cache Busting 스크립트. 파이썬으로 가상 빌드 툴 구현. 소스 코드(src/)의 텍스트가 변경될 때마다 MD5 해시값을 계산하여 빌드 폴더에 style.[hash].css로 파일을 생성. index.html이 항상 최신 해시값을 링크하도록 sed 대체(Replace)를 자동 수행하는 파이프라인 렌더링.

Practical

Core Topic 03: 코드를 밀어내라, 엣지 컴퓨팅 (Edge Computing & Workers)

• Why to Learn: 중앙 서버(Origin)로 트래픽이 오기 전에, 유저와 가장 가까운 엣지(Edge) 노드에서 보안 검사나 리다이렉트를 처리해 오리진 서버의 부하를 0으로(Offloading) 만들기 위함입니다.
• What to Learn:
  • Concepts: Edge Computing, Cloudflare Workers, Lambda@Edge, V8 Isolate (경량 컨테이너 대안), A/B Testing at Edge.
  • Skills: 오리진 서버에 도달하기 전 엣지에서 JWT 인증, IP 차단, 모바일/PC 분기 라우팅(A/B 테스트)을 가로채는 Edge Function 작성.
• How to Learn:
  • 1단계: 무거운 중앙 서버: 유저가 쿠폰을 발급받으려 합니다. 10만 명이 동시에 클릭합니다. 중앙 API 서버는 "이 유저가 로그인했나(JWT)?", "블랙리스트 IP인가?"를 검사하다가 정작 쿠폰 발급 비즈니스 로직을 돌리기도 전에 죽어버립니다.
  • 2단계: 엣지 오프로딩(Edge Offloading): Cloudflare Worker(엣지 노드)에 JS 코드 10줄을 배포합니다. 10만 명의 트래픽이 중앙으로 오기 전에, 전 세계 100개 엣지 노드에서 JS 코드가 먼저 실행되어 가짜 JWT와 블랙리스트 IP를 0.01초 만에 차단(401)해버립니다. 중앙 서버에는 뚫고 들어온 '진짜 유효한 요청' 1만 개만 도착하는 압도적인 방어막을 뜯어봅니다.
• Implement: 엣지 미들웨어(V8 Isolate 모사) 라우팅 봇. Edge_Worker 함수가 Request를 가로챔. User-Agent를 파싱하여 모바일이면 오리진의 Mobile_Origin, PC면 PC_Origin으로 백그라운드 라우팅을 바꿔치기(Rewrite). 클라이언트 측에서는 URL 변경 없이 0.1초 만에 맞춤형 UI 서버로 접속되는 엣지 라우팅 데모.

Advanced

Core Topic 04: 상태를 가진 엣지, 글로벌 데이터 동기화 (Edge Data & Stateful Edge)

• Why to Learn: 엣지 노드에서 코드만 실행하는 것(Stateless)을 넘어, 엣지 노드에 데이터베이스(KV)를 올려두어 글로벌 읽기 속도를 1ms로 끌어올리면서도 충돌을 막아내기 위함입니다.
• What to Learn:
  • Concepts: Edge KV (Key-Value), Global Data Synchronization, CRDT (Conflict-free Replicated Data Type), Strong vs Eventual Consistency at Edge.
  • Skills: Cloudflare KV나 DynamoDB Global Tables를 활용하여, 전 세계 엣지에 읽기 캐시를 뿌리고 비동기로 쓰기를 동기화하는 상태 기반(Stateful) 엣지 아키텍처.
• How to Learn:
  • 1단계: 글로벌 DB의 한계: 한국 엣지에서 Worker가 돌지만, DB가 미국(us-east-1)에 있으면 결국 DB 쿼리 하느라 200ms를 기다려야 합니다. 엣지 컴퓨팅의 이점이 완전히 증발하는 끔찍한 병목입니다.
  • 2단계: Edge KV와 CRDT: 전 세계 엣지 노드 안에 초고속 메모리 DB(Edge KV)를 심습니다. 한국 유저가 엣지에 쓰기(Write)를 하고, 미국 유저가 동시에 같은 키에 쓰기(Write)를 합니다. 이 충돌을 해결하기 위해, 락(Lock)을 걸지 않고도 나중에 머지(Merge)될 때 수학적으로 일관성이 보장되는 CRDT 알고리즘으로 동기화하는 궁극의 글로벌 데이터 구조를 해부합니다.
• Implement: CRDT (Grow-only Counter) 충돌 병합 시뮬레이터. 한국 엣지(KR_Node)와 미국 엣지(US_Node)가 오프라인 상태에서 각각 유저 '좋아요' 카운트를 증가시킴 (KR: +3, US: +5). 네트워크가 복구되어 서로 데이터를 교환할 때, 단순히 덮어쓰지 않고 merge(A, B) = max(A.count, B.count) 혹은 A.increments + B.increments 로직을 통해 최종 데이터 정합성을 달성하는 콘솔 데모.

7. Terminology

8. References

Primary

• [P1] CS2023 - Networking and Communication (NC) - Content Delivery Networks
• [P5] SFIA - Enterprise IT Architecture (ARCH) - Edge Computing Strategies

Secondary

• [Designing Data-Intensive Applications] Martin Kleppmann - Replication and Conflict Resolution (CRDTs)
• [Web Scalability for Startup Engineers] Artur Ejsmont - Caching and CDNs

Industry

• [Cloudflare Learning Center] - What is edge computing?
• [AWS CloudFront Documentation] - Customizing at the edge with Lambda@Edge

9. Final Checklist

Primary

• 글로벌 서비스 오픈 시 유저가 서울에서 미국 오리진(Origin) 서버를 직접 찌를 때 발생하는 빛의 속도 한계(네트워크 RTT 지연)를, CDN PoP(엣지 노드)가 어떻게 10ms 단위로 단축시키는지 물리적으로 설명할 수 있는가?
• CDN 캐싱 전략에서 Cache Hit Ratio(캐시 적중률)를 높이려다 유저에게 낡은 데이터를 보여주게 되는 딜레마를, TTL(수명) 튜닝과 이벤트 기반 무효화(Invalidation) 파이프라인으로 어떻게 밸런싱할지 증명할 수 있는가?

Secondary

• 정적 파일(HTML/CSS) 배포 시 캐시 삭제(Purge) API를 날리는 수동적 짓을 멈추고, 빌드마다 파일명에 MD5 해시를 박아넣는 Cache Busting 패턴을 통해 영구 캐시(TTL=Max)를 걸어버리는 프론트엔드 최적화 기법을 해부할 수 있는가?
• 모든 트래픽이 오리진 서버에 도달하기 전에, Cloudflare Workers나 Lambda@Edge 같은 엣지 컴퓨팅(Edge Computing) 노드에서 불량 IP를 차단하고 JWT 토큰을 검증하여 백엔드를 100% 보호(Offloading)하는 아키텍처를 설계할 수 있는가?

Industry

• 모바일 앱과 데스크톱 브라우저가 접속할 때 오리진 서버에서 코드로 분기 처리하는 대신, 엣지(Edge) 단에서 User-Agent HTTP 헤더를 파싱하여 모바일 전용 서버로 트래픽을 즉각 우회시키는(Rewrite) 라우팅 엣지 펑션을 짤 수 있는가?
• 글로벌 전역의 엣지 서버에서 동적 데이터(Edge KV)를 동시에 쓰기(Write) 할 때 발생하는 지리적 충돌(Geo-conflict)을, 중앙 DB의 글로벌 락(Lock) 없이 CRDT(충돌 없는 복제 데이터 타입)로 수학적으로 병합(Merge)하는 분산 정합성 원리를 논증할 수 있는가?