Cloudflare D1, 제어 평면 분리로 550만 데이터베이스 돌파

Cloudflare의 서버리스 관리형 데이터베이스 D1이 2026년 10월 8일 기준 총 550만 개 데이터베이스를 돌파했다. AI 개발과 바이브 코딩 플랫폼에서 요구되는 수백만 개의 소규모 데이터베이스를 지원하기 위해, Cloudflare은 쿼리 성능 저하 없이 확장성을 확보하고자 제어 평면(control plane)을 핵심 쿼리 경로에서 분리하는 아키텍처를 도입했다.

아키텍처 및 확장 원리

핵심은 데이터 평면(쿼리 실행)과 제어 평면(데이터베이스 관리)의 분리다. 쿼리는 **Durable Objects(DO)**를 통해 에지에서 처리되며, 제어 평면 작업은 연결 풀링과 캐싱을 위해 Hyperdrive를 경유하는 중앙 Postgres 클러스터에 의존한다. 중요한 라우팅 메타데이터는 전역 분산 키-값 저장소인 Workers KV에 저장되어, 캐시 미스가 발생하지 않는 한 쿼리 요청이 중앙 데이터베이스에 접근하지 않도록 한다.

주요 설계 원칙은 다음과 같다:

• 멱등성 및 자가 교정: 모든 프로세스는 장애를 처리하고 안전하게 재시도하도록 설계된다. Durable Objects는 주기적인 하트비트를 제어 평면으로 전송해 상태를 동기화하고 고아 리소스를 정리한다.
• 최종 일관성: 강한 일관성이 필요 없는 구성 요소는 큐잉과 최종 일관성을 활용해 신뢰성과 가용성을 높인다.
• 사전 계산된 집계: 사용자 요청 처리 시 주기적으로 집계를 사전 계산해 스캔 쿼리를 피한다.

데이터베이스 생성 흐름

데이터베이스 생성은 속도와 신뢰성을 위해 최적화되었으며, 최근 예시에서 약 1.6초가 소요됐다. 과정은 다음과 같다:

1. Hyperdrive를 통해 Postgres 읽기 복제본에서 계정 한도를 확인한다.
2. 고유한 데이터베이스 UUID와 Durable Object ID를 생성한다.
3. Durable Object를 초기화하고 메타데이터를 중앙 Postgres 주 복제본에 영속화한다.
4. 빠른 에지 조회를 위해 데이터베이스와 DO의 매핑 정보를 Workers KV에 기록한다.

초기 Postgres 쓰기 실패 시 시스템은 새 ID로 재시도한다. Postgres 쓰기는 '생성 체크포인트'로 작용하며, 이후 확인 단계가 실패하더라도 데이터베이스는 생성된 것으로 간주된다. 하트비트는 실패한 시도에서 발생한 고아 Durable Objects가 결국 삭제 표시되도록 보장한다.

쿼리 실행 및 제한 적용

쿼리 실행은 중앙 구성 요소를 완전히 우회한다. Edge API Worker가 요청을 검증하고 Workers KV에서 라우팅 메타데이터를 가져온다. 캐시 미스 발생 시 Hyperdrive를 통해 Postgres 읽기 복제본에 쿼리한다. 이후 요청은 D1 Eyeball Worker로 전달되어 백업 Durable Object로 쿼리를 프록시한다.

저장소 및 사용량 제한은 중앙 데이터베이스의 부하 급증을 방지하기 위해 비동기적으로 적용된다:

• 저장소 제한: Durable Objects는 사용량 업데이트를 큐에 게시하며, 이는 집계되어 Postgres에 기록된다. 고비용 합계 쿼리를 피하기 위해 증분 뷰 유지 관리 패턴을 사용한다.
• 행 사용량 제한: 무료 티어 사용자의 일일 실행 제한은 ClickHouse에서 추적된다. 중앙 리미터가 누적 사용량을 확인하고 제한 초과 시 전역 KV 저장소인 Quicksilver에 플래그를 설정하면, Durable Objects는 하트비트 시 이를 확인해 추가 쿼리를 거부한다.

이 아키텍처를 통해 D1은 효율적인 제어 평면 작업으로 수백만 개의 데이터베이스를 관리하면서 높은 처리량의 쿼리 실행을 지원한다.