엣지 컴퓨팅?

■ 엣지 컴퓨팅이란?

엣지는 브라우저도 아니고, 그냥 CDN도 아니다.
사용자와 서버 사이, 가장 가까운 CDN 서버 안에서 실행되는 초경량 서버다.

 

# 전통적인 웹 구조

사용자 → Origin 서버 → DB → Origin 서버 → 사용자

 

• 모든 요청이 무조건 서버까지 도달
• 로그인 실패, 봇, 캐시 가능한 요청도 전부 DB 접근

# Edge 기반 구조

사용자 → Edge 서버 → (필요할 때만) Origin 서버 → DB

Edge 서버는 아래와 같은 작업을 Origin에 묻지도 않고 혼자 처리한다.

• 로그인 토큰 검증
• 국가 판별
• 게시판 분기
• A/B 테스트
• 캐시 처리

엣지 서버와 엣지 컴퓨팅은 다르다

엣지 서버는 장소,
엣지 컴퓨팅은 그 장소에서 무엇을 하느냐다.

엣지 서버	엣지 컴퓨팅
전 세계 CDN에 배치된 물리적인 서버	그 서버에서 직접 코드를 실행하는 기술

 

 

■ 엣지 컴퓨팅에서 가장 중요한 개념: 캐시를 코드처럼 다룬다

엣지는 단순히 “파일 저장소”가 아니다.

• 요청을 직접 가로채고
• 캐시된 데이터를 먼저 내려주고
• 동시에 최신 데이터를 백그라운드에서 갱신한다.

이게 바로 stale-while-revalidate 전략이다.

■ 여기서 드는 의문

1. “캐시 데이터를 보여주는거면 실시간 아닌 거 아닌가?”

2. “어차피 DB는 Origin 서버에 있는데 CDN 서버에서 한 번 더 거쳐 가면 오히려 느려지는 거 아냐?”

 

1번에 대한 해답으로는

HTTP(RFC 5861), MDN Web, Cloud CDN등의 공식 문서를 확인하면 아래와 같이 공통으로 말한다.

stale 데이터를 먼저 사용자에게 전달하고
동시에 백그라운드에서 최신화를 진행해 지연을 사용자에게 숨긴다.

즉, 목표는 “DB 최신성”이 아니라 사용자를 기다리게 하지 않는 것 이다.

 

2번에 대한 해답과 1번에 대한 추가 설명은  TTL=3초 + stale-while-revalidate 기준으로 실제 Edge 동작 흐름 시뮬레이션을 보면 이해가 간다!

⏰ 00초 — A 유저 요청

Edge: 캐시 없음 → Origin 요청
DB: [1번글]
Edge 캐시 저장 (유효: 00~03초)
A에게 [1번글]

⏰ 01초 — 관리자 2번글 작성

캐시 영향 없음
Edge는 모름
DB만 변경됨

⏰ 02초 — B 유저 요청

Edge: 캐시 유효 (00~03초)
Origin 요청 안함
B에게 [1번글]

⏰ 05초 — C 유저 요청
TTL(3초) 초과 → stale 상태

Edge:
  - C에게 [1번글] 즉시 전달 (stale)
  - 동시에 Origin 백그라운드 호출
Origin: [1번글, 2번글]
Edge 캐시 갱신 (05~08초)

⏰ 06초 — A 새로고침

Edge: 캐시 유효
A에게 [1번글, 2번글]
Origin 요청 없음

⏰ 30초 — 관리자 3번글 작성

Edge 캐시는 08초에 만료됨
현재 캐시: 존재하지만 완전 stale

⏰ 45초 — G 사용자가 게시판 접속

Edge:
  - G에게 [1번글, 2번글] 즉시 응답
  - 동시에 Origin 요청
Origin: [1번글, 2번글, 3번글]
Edge 캐시 갱신 (45~48초)

 

Origin 호출 횟수 비교

요청 시점	Origin 호출 여부
00초 A	⭕
02초 B	❌
05초 C	⭕
06초 A	❌
45초 G	⭕

총 요청 5회 중 Origin 호출은 단 3회 나머지는 전부 Edge가 처리한다.

만약 모든 유저가 엣지컴퓨팅 없이 origin서버로 DB요청을 같은 시간에 동시에 한다면 DB CPU 100%를 넘어서 서버가 터지고 말 것이다...

■ 결론

Edge는 “느린 캐시”가 아니라 “사용자를 기다리게 하지 않는 캐시”를 제공함으로서 서버가 터지지 않게 하는 완충지대이다.