Vercel의 모든 빌드 뒤 데이터베이스를 마이그레이션한 방법

Vercel의 모든 빌드는 대기 컨테이너로 구성된 build warm pool에서 시작된다. 이 풀은 컨테이너의 준비 상태, 인증 토큰, 실행 중인 빌드와 과금 대상 deployment를 연결하는 매핑을 관리한다.

초기에는 빠르고 접근이 쉬운 Redis에 상태를 저장했지만, 시간이 지나며 문제가 커졌다. 토큰과 컨테이너 상태는 손실돼도 재생성할 수 있지만, billing mapping이 사라지면 어떤 deployment에 빌드 비용을 청구해야 하는지 복구할 수 없기 때문이다.

Vercel은 bursty한 배포 트래픽에 맞는 온디맨드 확장, 기본 제공 TTL, 고동시성 환경에서 connection 관리가 필요 없다는 점을 고려해 DynamoDB를 새 저장소로 선택했다. 다만 Redis 수준의 latency를 그대로 보장하지는 않았기 때문에, 기존 접근 패턴에 맞춘 스키마 설계가 필요했다.

기존 Redis 구조에서는 다음과 같은 작업이 저렴하게 처리됐다.

• 토큰을 set과 sorted set에 저장하고 만료 처리
• pending, polling, building 상태별 sorted set 관리
• 컨테이너와 deployment 연결
• 웜 풀 보충 과정에서 컨테이너 수를 수백 번 조회

새 스키마는 데이터베이스가 아니라 실제 접근 패턴을 중심으로 설계됐다. 대부분의 작업이 특정 컨테이너를 알고 시작하고 polling만 토큰에서 출발한다는 점에 따라 container ID를 sort key로 삼고, 토큰은 사용 가능한 인증 정보가 테이블 조회 결과에 노출되지 않도록 hash 형태의 필드로 저장했다.

풀은 중단되지 않고 컨테이너 생성, polling, 작업 할당, 만료가 계속 진행되므로 데이터를 한 번에 복사할 수 없었다. 이에 따라 마이그레이션은 production traffic을 유지한 채 여러 단계로 진행했으며, 각 단계는 feature flag 뒤에 배치하고 필요할 경우 즉시 rollback할 수 있도록 구성했다.