Databricks Lakebase를 활용한 데이터베이스 브랜칭 및 개발 워크플로 혁신

섹션별 상세

운영 및 분석 데이터베이스의 통합은 아키텍처적 선택이 아닌 물리적 제약의 해소로 가능해졌다. 기존에는 OLTP와 OLAP의 저장 구조와 컴퓨팅 프로필이 달라 별도의 플랫폼으로 운영되었으나, Lakebase는 이를 단일 토대 위에서 액세스 패턴의 차이로 전환한다.

Lakebase는 Neon 아키텍처를 기반으로 서버리스 Postgres 인터페이스를 제공하여 기존 애플리케이션과의 호환성을 유지한다. 실제 테스트에서 Spotify의 Backstage 포털을 RDS 대신 Lakebase에 연결했을 때, 별도의 코드 수정 없이 인증 방식 조정만으로 정상 작동함을 확인했다.

Copy-on-Write 아키텍처를 통해 데이터 복사 없는 즉각적인 데이터베이스 브랜칭이 가능하다. 브랜칭은 실제 데이터를 복제하는 대신 동일한 하위 페이지를 가리키는 포인터를 생성하며, 쓰기 작업이 발생할 때만 데이터가 분기되어 1초 내외의 빠른 속도를 보장한다.

전통적인 RDS 방식과 Lakebase의 Copy-on-Write 아키텍처를 비교한 다이어그램 — Diagram기존 RDS는 스냅샷 복원 시 데이터 복제로 인해 수 분에서 수 시간이 소요되지만, Lakebase는 공유 스토리지 계층을 사용하여 데이터 복사 없이 1~4초 내에 브랜칭과 복구가 가능함을 시각적으로 보여준다. 이는 컴퓨팅과 스토리지가 분리된 현대적 데이터 아키텍처의 이점을 명확히 설명한다.

근거

63MB 규모의 Backstage 카탈로그 데이터 평면 클론 생성에 1.09초가 소요됐다. — Branching Changes the Database Development Cycle 섹션 마지막 문단

포인트 인 타임 복구(PITR) 기능을 통해 데이터 삭제 사고 발생 시 수 초 내에 이전 상태로 복구할 수 있다. 실험 결과 테이블의 모든 데이터를 삭제한 후 특정 시점으로 복구 브랜치를 생성하는 데 3.78초가 소요되었으며, 이는 장애 대응 시간을 획기적으로 단축시킨다.

근거

데이터 삭제 후 특정 시점으로의 복구(PITR)를 완료하는 데 총 3.78초가 걸렸다. — Point-in-Time Recovery: The Undo Button 섹션

데이터베이스 브랜칭의 대중화는 개발자의 워크플로에서 목(Mock) 객체와 인메모리 DB 사용 필요성을 제거한다. 개발자는 기능 개발 시작 단계부터 실제 데이터가 포함된 독립적인 DB 브랜치에서 작업하며, 이는 전체 테스트 코드의 20-30%를 차지하던 테스트 인프라 비용을 절감시킨다.

근거

개발 팀의 테스트 코드 중 약 20-30%가 목(Mock) 객체 생성 등 테스트 인프라 구축에 소모된다. — What Branching Enables 섹션 하단

기술

Databricks Lakebase
Neon
Postgres
Backstage
Unity Catalog

활용 사례

위험한 DB 스키마 마이그레이션 사전 테스트
실제 데이터를 활용한 격리된 개발 및 QA 환경 구축
데이터 사고 발생 시 즉각적인 시점 복구(PITR)

언급된 리소스

문서Neon Architecture

문서Backstage by Spotify