모든 Vercel 빌드를 지탱하는 데이터베이스 마이그레이션 이야기

Vercel이 빌드 웜 풀(warm pool) 상태 데이터를 Redis에서 DynamoDB로 마이그레이션한 과정을 다룬다. 빌드 풀의 청구 매핑 데이터가 Redis 장애 시 복구 불가능하다는 구조적 위험이 이주를 결정한 핵심 이유였고, 24/7 프로덕션 트래픽 속에서 다운타임 없이 5단계 점진적 전환을 완료했다.

핵심 포인트

Redis에 청구 매핑 데이터를 두면 Redis 장애 시 복구 불가능 — 내구성 저장소인 DynamoDB로 전환이 필수였다.
5단계 페이즈(Redis 전용 → 이중 쓰기 → 섀도우 읽기 → DynamoDB 우선 → DynamoDB 전용)로 각 단계마다 롤백 가능하게 점진적으로 전환했다.
DynamoDB 스키마는 컨테이너 중심 모델로 재설계 — TTL 인덱스로 만료 컨테이너를 자동 필터링하고, 청구 데이터는 별도 테이블로 분리해 일관성을 보장했다.
DynamoDB 전환 후 쿼리 지연이 1.29ms → 5.13ms로 증가하면서 기존에 숨겨져 있던 N+1 쿼리 문제가 드러났다.
공급 루프(provisioning loop)를 병렬 실행으로 전환해 성능 문제를 해결 — 웜 풀별 직렬 대기를 제거하고 동시 실행을 채택했다.

상세 정리

배경: Redis는 빌드 웜 풀 상태(컨테이너 상태, 인증 토큰, 청구 매핑)를 저장하는 임시 캐시였으나, 청구 데이터 손실 시 복구 불가능한 구조적 위험이 있었다.
Redis 스키마 문제: 토큰을 집합과 정렬된 집합에 중복 보관하고, 상태 변경마다 제거/추가를 반복. 상태 카운트는 O(n) 복잡도로 빌드 루프에서 수백 번 호출됐다.
DynamoDB 재설계: warmPoolId(PK) + containerId(SK)를 기본 키로, token은 해시로 저장, expiresAt으로 만료 자동 관리. 청구 데이터는 별도 테이블로 독립 보관해 일관성 보장.
롤아웃 전략: 각 단계마다 일치율·쓰기 오류·쿼리 지연·만료 수를 모니터링하며 모든 불일치 원인을 규명 후 다음 단계로 이동했다.
3월 첫 장애: 섀도우 읽기 단계에서 상태 카운트의 O(n) 쿼리가 한 리전의 빌드를 중단시켰다. 상태 카운트 인덱스를 추가해 해결했다.
3월 두 번째 장애: Redis 인프라 자체가 장애를 일으켰는데, 이미 DynamoDB로 전환된 컴포넌트는 영향을 받지 않아 마이그레이션의 가치를 입증했다.
성능 차이 발견: DynamoDB 전환 후 공급 루프가 1분 이상 정체하기 시작. 원인은 수백 개 웜 풀 각각에 대해 DynamoDB 읽기를 순차 실행하는 N+1 패턴이었다.
해결책 선택: 배치 처리는 하드코딩된 지연에 의존해 불채택. 대신 각 웜 풀 공급 호출을 동시 실행으로 변경 — 낮은 확률의 중복 컨테이너 생성은 수용 가능한 트레이드오프로 판단했다.
부수 발견: 이 최적화로 Redis 시절에도 간헐적으로 루프가 1분 이상 정체했음이 드러났다. 빌드 요청 경로 밖에 있어 그동안 조사 동기가 없었던 숨겨진 문제였다.
결과: 2026년 4월 마이그레이션 완료. 청구 데이터 내구성 확보 + 공급 루프 성능 최적화를 동시에 달성했다.

왜 읽나Redis 같은 인메모리 저장소를 DynamoDB 같은 내구성 저장소로 무중단 마이그레이션하는 실전 사례를 찾는 백엔드·인프라 엔지니어에게, 5단계 롤아웃 전략과 지연 증가로 드러난 N+1 문제 해결 과정을 구체적으로 참고할 수 있다.

Vercel Blog 블로그

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

원문 읽기

읽음 (0)

·takedown 요청

모든 Vercel 빌드를 지탱하는 데이터베이스 마이그레이션 이야기

이 글과 비슷한

분석가가 직접 만든 마케팅 자동화 시스템 — 오디언스 빌더 제작기

DynamoDB 핫 파티션을 해결하는 3가지 방법 (3): 조회를 인덱스 테이블로 옮기기

Amazon Aurora 및 Amazon RDS의 PostgreSQL 18: 보안, 모니터링 및 개발자 기능 향상