엣지 컴퓨팅의 역설 — 함수를 사용자보다 DB 근처에 배치해야 할 때

엣지 컴퓨팅의 전제는 '사용자 근처에서 실행하면 빠르다'이지만, DB 조회가 여러 번 포함된 함수에선 오히려 반대가 사실이다. DB가 있는 리전에 함수를 고정 배치하면 사용자까지 왕복은 1회 늘지만, DB 왕복 수천 km × 3회가 수 ms × 3회로 바뀐다.

핵심 포인트

상세 정리

전제 붕괴 조건: 단순 연산(헤더 조작, A/B 테스트 판정)은 엣지 근접 배포가 맞다. 하지만 DB를 3번 조회하는 함수는 함수 위치가 달라지면 총 지연 공식이 완전히 바뀐다.
구체 수치 예시: 호주 사용자 → 시드니 엣지(20ms) → 미국 동부 DB(~14,000km, 왕복 3회). 시드니 함수가 DB 3번 조회하면 14,000km × 2 × 3 = 1초 이상 추가 지연.
최적 배치: 미국 동부 리전 함수로 라우팅. 사용자→함수는 대양 횡단 1회(~150ms)이지만 DB 왕복 3번이 수 ms. 전체가 오히려 빠름.
패턴 결론: 실시간 DB 조회가 많은 함수 → DB와 동일 리전 고정 배포. 정적 콘텐츠 서빙/캐시 적중 시 → 글로벌 엣지 배포로 분산.
Edge Runtime 특성: JS/TS/Wasm 실행 가능한 경량 컨테이너. 일반 서버리스(Lambda 등)보다 MicroVM 오버헤드 없어 콜드 스타트 빠르고 비용 낮음. 대신 일부 Node.js API(fs 등) 미지원.

왜 읽나엣지 컴퓨팅 도입을 검토하거나 Vercel/Cloudflare Workers 함수 배치 전략을 최적화하려는 인프라/백엔드 엔지니어에게 지연 폭포 문제를 실제 수치로 설명하고 배치 결정 기준을 제시한다.

Vercel Blog 블로그

원문은 여기서 이어서 읽을 수 있어요

읽음 (0)

이 글과 비슷한