Vercel이 핵심 메타데이터 데이터베이스(Azure Cosmos DB)의 프로덕션 장애복구를 처음 실행한 과정을 다룬다. 57회의 스테이징 테스트로 준비를 마친 후 Azure West US → East US 2로 쓰기 트래픽을 전환했으며, 14분 만에 페일오버를 완료하고 고객 트래픽에 영향 없이 성공했다.
핵심 포인트- 프로덕션 첫 시도 전 스테이징에서 57회 장애복구를 반복해 모든 코드 경로·SDK를 사전 검증했다.
- Azure West US → East US 2 페일오버: 14:09 UTC 시작, 14:23 완료(14분), 1시간 안정 확인 후 원복.
- Cosmos DB 클라이언트가 페일오버를 자동 감지하지 못하는 문제 발견 → 런타임 메타데이터 기반 쓰기 대상 동적 갱신으로 해결.
- 재시도 대기 시간을 5분에서 5밀리초로 단축해 업스트림 SDK에도 반영했다.
- 약 500개 빌드가 중단됐으나 고객 프로덕션 트래픽 영향 제로, CDN은 별도 DynamoDB 아키텍처로 완전 격리.
상세 정리- 배경: Vercel 제어 평면(API 요청·배포·백그라운드 작업)은 19개 지역에 분산된 Cosmos DB 메타데이터 저장소 의존. 실제 쓰기 페일오버 테스트는 이번이 처음이었다.
- 준비: 스테이징에서 57회 장애복구 반복 후 Notion 기반 플레이북 작성 완료. 모든 SDK와 코드 경로를 검증한 뒤 프로덕션 진입.
- 실행: 14:09 UTC 페일오버 시작, 14:23 Azure East US 2로 전환 완료. 1시간 동안 안정성 확인 후 West US로 원복.
- 문제 1 — Cosmos DB 클라이언트 페일오버 미인식: 클라이언트가 자체적으로 쓰기 대상을 전환하지 못했다. 런타임 메타데이터를 읽어 쓰기 엔드포인트를 동적으로 업데이트하는 방식으로 해결.
- 문제 2 — 5분 재시도 지연: 클라이언트가 연결 전 5분을 대기하는 지연 발견. 5밀리초로 단축 후 업스트림 SDK에 반영.
- 문제 3 — 대형 파티션 쓰기 지연: 특정 파티션에서 쓰기 지연 발생. 프로토콜 최적화로 완화.
- 트래픽 이상: 약 2% 쓰기 트래픽이 새 지역으로 완전히 전환되지 않는 현상 발견, 사후 분석 및 보완 조치.
- 감시: 24/7 온콜 팀 배치, 예상된 경보만 발동(거짓양성 없음), 다층 추적 신호 체계 운영.
- 빌드 영향: 주로 자사 서비스 포함 약 500개 빌드가 중단됐으나 재시작 후 정상 완료.
- CDN 격리: CDN 트래픽은 별도 DynamoDB 아키텍처로 운영돼 데이터베이스 페일오버 영향 없이 정상 동작.
왜 읽나분산 클라우드 데이터베이스의 실제 프로덕션 장애복구 테스트에서 SDK 클라이언트 페일오버 미인식, 재시도 지연, 대형 파티션 이슈 같은 예상치 못한 함정이 어떻게 드러나는지 알고 싶은 SRE·인프라 엔지니어에게 유용하다.