Vercel 요청의 여정: Edge 네트워크 탐색

Vercel Edge Network가 요청을 처리하는 전 과정을 두 가지 핵심 지표, Edge Requests와 Fast Data Transfer(FDT)를 중심으로 설명한다. 전 세계 18개 Edge 리전에 Anycast 라우팅을 적용해 사용자와 가장 가까운 PoP로 트래픽을 유도하고, x-vercel-id 헤더로 요청 경로를 추적할 수 있다.

핵심 포인트

Anycast 라우팅: 헬스/속도/근접성을 동시에 고려해 최적 PoP(Point of Presence)로 트래픽을 전달한다
Edge Request는 플랫폼 방화벽과 WAF 영구 액션을 통과한 요청만 집계, 차단된 요청은 카운트에서 제외된다
FDT(Fast Data Transfer)는 인바운드(사용자→Vercel)와 아웃바운드(Vercel→사용자) 데이터 이동을 모두 측정한다
x-vercel-id 응답 헤더로 어느 Edge 리전이 요청을 처리했는지, 어느 리전에서 함수가 실행됐는지 확인할 수 있다
TTFB, LCP 개선을 위해 코드 스플리팅, 이미지 최적화, 자동 압축(JS/CSS/이미지)을 활용한다

상세 정리

PoP 배치: 전 세계 18개 Edge 리전에 PoP를 두고, 헬스 메트릭/속도/사용자 근접성을 종합해 최적 PoP를 동적으로 선택한다
Anycast 라우팅: 동일 IP 주소를 여러 PoP에서 광고해 BGP가 자동으로 가장 가까운 경로를 선택하게 한다
동적 재라우팅: 장애 발생 시 자동으로 리던던트 시스템으로 트래픽을 우회해 서비스 연속성을 유지한다
Edge Request 정의: 방화벽 규칙과 WAF 검사를 통과한 요청. 콘텐츠 타입에 무관하게 실시간 처리된다
요청 포함 데이터: 지리적 위치, 환경 변수, 배포 세부 정보가 Edge Request에 포함돼 함수에서 활용 가능하다
FDT 측정 범위: 요청 단계(사용자→Vercel)와 응답 단계(Vercel→사용자) 양방향 데이터 이동을 모두 합산한다
FDT 최적화 방법: 코드 스플리팅/트리 쉐이킹, Vercel Image Optimization 서비스, API 페이로드 최소화, 자동 압축(이미지/JS/CSS)으로 데이터 전송량을 줄인다
x-vercel-id 활용: 예를 들어 뉴욕 요청이 iad1(워싱턴 DC)에서 처리되고 sfo1(샌프란시스코)에서 함수를 실행한 경우 헤더에 두 리전이 모두 표시된다
주의: x-vercel-id 헤더에는 PoP 정보는 포함되지 않고 Edge 리전 정보만 포함된다
비용 관계: 요청 빈도와 데이터 볼륨이 직접적으로 청구 비용에 영향을 미치므로 두 지표 모두 모니터링이 필요하다