pile·
인프라 / DevOps·vercel-blogVercel Blog·

캐시 stampede 방지: Vercel CDN의 요청 collapsing 아키텍처

ISR 캐시 만료 시 다수 요청이 동시에 함수를 호출해 원점을 과부하시키는 cache stampede 문제를 Vercel CDN이 리전당 단일 함수 호출로 해결하는 내부 아키텍처를 공개했다. 노드 레벨 + 리전 레벨 2계층 분산 락과 이중 확인 locking 패턴으로 동시성을 제어하며, 현재 하루 300만 건 이상의 요청을 자동으로 collapse 하고 있다.

핵심 포인트
  • 리전당 단일 함수 호출: 만료된 ISR 경로에 동시 요청이 들어오면 하나만 함수를 호출하고 나머지는 캐시 결과를 기다려 받는다.
  • 2계층 분산 락: 노드 레벨 인메모리 락으로 요청을 먼저 로컬 그룹화한 뒤, 리전 레벨 락으로 단일 함수 호출을 보장한다.
  • 이중 확인 locking: 락 획득 후 캐시를 한 번 더 확인해 대기 중 다른 요청이 이미 재생성했으면 함수 호출을 생략한다.
  • 타임아웃 hedging: 락 획득이 지정 시간(3초) 내 안 되면 대기를 포기하고 직접 함수를 호출해 cascading failure를 방지한다.
  • 현재 하루 300만 건 이상의 요청을 자동으로 collapse. 수동 설정 불필요.
상세 정리
  • 문제 — cache stampede: ISR 캐시 만료 후 동시 요청이 각각 독립적으로 함수를 호출해 원점 서버 과부하와 중복 연산이 발생한다.
  • 해결 원칙: 리전당 단일 함수 호출 — 첫 번째 요청만 함수를 호출하고, 나머지는 캐시된 결과를 기다린다.
  • 노드 레벨 락: 동일 CDN 노드에 동시 요청이 들어오면 인메모리 락으로 첫 번째 외에는 로컬에서 대기한다. 이를 통해 리전 락 경합을 수백 건이 아닌 노드 수에 비례하게 줄인다.
  • 리전 레벨 락: 노드 그룹화 이후 리전 전체에서 단일 락을 획득해 함수 호출을 하나로 보장한다. 노드별 선행 그룹화가 없으면 수백 건이 리전 락에 동시 경합하는 병목이 생긴다.
  • 이중 확인 locking 4단계: 1) 요청 도착 시 캐시 확인 → 2) 노드+리전 락 순차 획득 → 3) 락 획득 후 캐시 재확인(대기 중 다른 요청이 재생성했을 수 있음) → 4) 캐시가 여전히 비어있을 때만 함수 호출.
  • 실패 처리: 함수 오류 시 결과를 캐시하지 않아 캐시 오염을 방지. 다음 락 획득 요청이 재시도한다.
  • 타임아웃 hedging: 락 획득이 예: 3초 내 이뤄지지 않으면 대기를 포기하고 직접 함수를 호출한다. 느린 재생성으로 인한 cascading failure를 방지하는 안전망이다.
  • 자동 프레임워크 통합: Vercel이 라우트를 분석해 ISR·정적 생성·동적 렌더링 여부 메타데이터를 모든 리전에 배포, 수동 설정 없이 캐시 가능 여부를 CDN이 자동 판단한다.
  • 운영 규모: 하루 300만 건 이상의 요청을 collapse. 모든 ISR 사용 프로젝트에 자동 활성화.
왜 읽나ISR 기반 Next.js 앱에서 캐시 만료 시 thundering herd 문제가 CDN 레벨에서 어떻게 해결되는지, 분산 시스템의 이중 확인 locking 패턴과 2계층 락 아키텍처를 실제 운영 사례로 이해하고 싶은 인프라·백엔드 엔지니어에게 적합.
vercel-blog
Vercel Blog 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. 인프라 / DevOps·vercel-blogVercel Blog·

    Vercel CLI 드라이런 배포로 실제 배포 전 구성 미리 확인하기

    Vercel CLI v54.17.2부터 vercel deploy --dry 명령으로 실제 파일 업로드 없이 배포 구성을 미리 검사할 수 있다. 프레임워크 감지 결과, 포함/제외 파일 목록, 디렉터리 크기 분포, 콘텐츠 해시까지 사전에 확인하고 나서 배포를 결정할 수 있어 의도치 않은 배포 실패를 예방한다.

    #deployment#ci-cd#vercel-cli+1