IL-0357 Vercel · 2025-10-20awsnetworking
Vercel CDN 의 전역 캐시 일부를 잃어 정적 파일 요청이 최대 약 22% 실패했다
2025-10-20 Vercel 이 iad1 이라 부르는 AWS us-east-1 리전에 예상치 못한 장애가 나면서 Vercel 쪽에서 서로 독립된 사고 두 건이 났다. 이 사례는 us-east-1 데이터센터를 잃은 데서 시작해 고객 프로덕션 트래픽 제공을 흔든 첫 번째 사고를 다룬다. Vercel 은 19개 AWS 리전에서 Compute, CDN, Firewall 서비스를 운영한다. 프로덕션 트래픽을 처리하는 스택은 그중 어느 리전 하나를 잃어도 버티도록 설계돼 있었다.
06:55 UTC 에 첫 알림이 울렸고 처음에는 트래픽이 조금 흔들리는 정도였다. 07:07 에 당직 엔지니어들은 AWS 관리형 서비스에 큰 문제가 있을 가능성이 높다고 보고 가장 경험 많은 대응자들을 불렀다. 트래픽을 제공하는 스택에서 실패가 나자 07:15 에 iad1 의 트래픽을 이웃 데이터센터로 옮기기로 했고, 07:20 에 시작해 07:44 에 마쳤다. 이로써 그 리전에 직접 접속하던 최종 사용자의 서비스가 돌아왔다. 07:25 에는 백업 리전이나 보조 리전을 설정한 고객의 함수 호출을 다른 리전으로 돌려 그 고객들의 서비스를 모두 되살렸다.
07:45 에 연쇄 장애로 전역 캐시 인프라 일부를 잃었다. 각 CDN 리전의 Regional Cache 는 정적 자산과 캐시할 수 있는 동적 요청을 캐시하는 구성 요소다. 라우팅 메타데이터의 원본은 us-east-1 S3 였고, 시스템은 처음 쓸 때 데이터를 전역에 저장하도록 설계돼 있었다. 메타데이터가 모든 리전으로 퍼지고 있었는데도 Regional Cache 서비스가 연쇄적으로 무너졌고, 정적 파일 제공 실패가 최대 트래픽의 약 22% 에 이르렀다. 08:18 에 서비스가 복구됐고, Vercel 은 이 연쇄 장애의 근본 원인을 이미 완화했다고 밝혔다. us-east-1 을 유일한 리전으로 쓰던 고객의 함수 호출은 09:21 에 돌아왔다.
- 심각도
- –
- 영향 범위
- Static file serving from Vercel's CDN failed for up to about 22% of traffic; function invocations had elevated errors, and requests reaching iad1 directly were disrupted until re-routed
- 영향 사용자
- –
- 지역
- global, with us-east-1 (iad1) as the failed region
- 감지까지
- –
- 복구까지
- 33m
증상
2025-10-20 07:45 UTC 부터 Vercel CDN 의 정적 파일 제공이 실패하기 시작했고, 실패는 최대 트래픽의 약 22% 에 이르렀다. 이 시간대가 그날 사고 전체에서 피해가 가장 컸다.
그보다 앞선 06:55 UTC 에 Vercel 서비스 전반의 오류로 첫 자동 알림이 울렸고, 사고가 자동으로 만들어져 당직 엔지니어가 호출됐다. 처음에는 트래픽이 조금 흔들리는 정도였다. Vercel 이 iad1 이라 부르는 AWS us-east-1 리전에 직접 접속한 최종 사용자가 피해를 봤다.
당직 엔지니어는 알림이 계속 쌓이자 다른 당직자를 불러 사고 통화를 열었다. 07:07 에 당직 엔지니어들은 AWS 관리형 서비스에 큰 문제가 있을 가능성이 높다고 판단했고, Vercel 에서 가장 경험 많은 대응자들을 모두 호출하는 “Panic Rotation” 으로 에스컬레이션했다.
정적 파일 실패는 각 CDN 리전의 Regional Cache 서비스에서 났다. 메타데이터는 모든 리전으로 퍼지고 있었지만 Regional Cache 서비스가 연쇄적으로 무너져 피해 범위가 넓어졌다. 장애 시간 동안 함수 호출에서도 오류가 늘었다.
엣지에 아직 캐시되지 않은 ISR 콘텐츠 가운데 us-east-1 이 원본인 것은 잠시 제공되지 않았다. 반면 DNS 조회, Anycast IP 로의 라우팅, L3~L5 보호, TLS 핸드셰이크, L7 방화벽, Response Cache 는 예상대로 동작했다.
증상 오류율 상승
원인
원인 클라우드 제공자 장애
- 촉발
- Vercel 이 iad1 이라 부르는 AWS us-east-1 리전에 예상치 못한 장애가 났다. 이 리전을 잃은 뒤 07:45 UTC 에 연쇄 장애가 일어나 Vercel 의 전역 캐시 인프라 일부가 사라졌다.
감지
06:55 UTC 에 Vercel 서비스 전반의 오류로 첫 자동 알림이 울렸고, 사고가 자동으로 만들어져 당직 엔지니어가 호출됐다. 이 알림은 us-east-1 장애가 시작될 때 울린 것으로, 캐시 장애가 시작되기 50분 전이었다.
조치
- 07:15 UTC 에 iad1 의 트래픽을 이웃 데이터센터로 옮기기로 했고, 07:20 에 단계적으로 옮기기 시작해 07:44 에 마쳤다.
- 07:25 UTC 부터 백업 리전이나 보조 리전을 설정한 고객의 함수 호출을 다른 리전으로 돌려 그 고객들의 서비스를 모두 되살렸다.
- 08:18 UTC 에 서비스를 복구했고, 이 연쇄 장애의 근본 원인을 완화했다.
후속 조치
- 이번 장애로 드러난 장애 모드를 체계적으로 막을 수 있도록 아주 자세한 기술 포스트모템을 쓴다.
- 큰 리전 장애를 미리 연습하는 훈련을 이어 가고 더 강화한다.
교훈
–
출처
관련 사례
같은 원인 · 공통 CDN 과 엣지 네트워크
IL-0368AWS us-east-1 장애 동안 PlanetScale 컨트롤 플레인이 멈추고, 이어 일부 데이터베이스 브랜치가 네트워크 분할로 쿼리에 실패했다PlanetScale · 2025같은 원인 · 공통 오브젝트 스토리지
같은 원인 · 공통 CDN 과 엣지 네트워크
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0357
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0357/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.