본문으로 건너뛰기

1.2 Branch와 인접 개념

DB 사본을 요청할 때는 원본의 어느 시점을 사용할지 먼저 정해야 합니다. 사본에 직접 쓸지, 이후 변경도 받아야 할지도 정해야 합니다. 같은 데이터를 읽는 두 환경이라도 하나는 시험 종료까지 상태를 유지해야 합니다. 다른 하나는 원본의 변경을 계속 받아야 할 수 있습니다. 요청서에 branch라는 이름만 적으면 이 차이를 표현하지 못합니다. 이 장은 snapshot, writable clone, branch, replica, backup을 동작과 수명으로 나눕니다. 제품별 예외를 확인하는 기준도 제시합니다.

기준 상태와 쓰기 가능한 사본​

Snapshot과 clone의 관계는 ZFS에서 구체적으로 확인됩니다. ZFS snapshot은 특정 시점의 파일시스템 또는 volume을 나타냅니다. 읽기 전용 사본이며, clone은 snapshot에서 만드는 writable dataset입니다. 생성한 dataset은 origin snapshot에 의존하며 기존 block을 공유합니다. 여기서 snapshot은 사본의 기준 상태를 식별합니다. clone은 그 상태에서 별도로 쓸 수 있는 대상을 제공합니다. 두 객체를 같은 이름으로 부르면 변경 대상과 보존 대상을 설명하기 어렵습니다. 이 구분의 근거는 OpenZFS의 snapshot과 clone 설명입니다. 모든 제품의 snapshot API가 같은 객체를 만든다는 뜻은 아닙니다.

데이터베이스를 실행하려면 저장소 사본 외에 DB가 요구하는 조건도 충족해야 합니다. 실행 중인 PostgreSQL의 파일시스템 snapshot에는 전체 cluster가 포함되어야 합니다. 필요한 WAL과 tablespace도 일관된 시점으로 포함되어야 합니다. PGDATA 디렉터리 하나를 복사한 것만으로 모든 배치에서 유효한 사본이 되지는 않습니다. 따라서 저장소의 snapshot 생성 성공과 검증용 PostgreSQL의 기동 조건을 구분해야 합니다. 파일시스템 객체와 SQL 접속 대상은 완료를 판단하는 단위가 서로 다릅니다.

Aurora clone은 별도 volume의 논리적 상태를 제공합니다. 변경되지 않은 page는 원본과 공유합니다. 이 설명에서 별도 상태와 물리 데이터 공유는 함께 성립합니다. 원본이나 clone에 쓰기가 발생하면 새 page 공간이 필요합니다. 따라서 공유 자체가 같은 내용을 계속 보여 준다는 뜻은 아닙니다. 또한 DB instance 준비는 저장소 공유와 별도 작업입니다. 저장 단위와 접속 준비를 구분하면 clone이 무엇을 완료했다는 뜻인지 더 정확히 이해할 수 있습니다.

구현 계층의 자세한 설명은 기존 Copy-on-Write와 Thin Clone 계보를 참고합니다. 여기서는 기존 데이터를 공유하고 변경 후 상태를 분리한다는 원리만 사용합니다. 해당 장의 제품 상태와 성능 수치는 이 총론의 기준일과 구분해서 읽어야 합니다. 이 장은 branch를 선택하기 전에 요구 동작을 정하는 데 필요한 차이를 중심으로 설명합니다.

Branch라는 이름의 제공 범위​

Branch가 뜻하는 객체의 수준은 공급사마다 다릅니다. DBLab 4.0은 snapshot을 가리키는 명명된 branch를 도입했습니다. 그 포인터와 접속 가능한 PostgreSQL clone은 구분해야 합니다. Neon의 데이터 포함 branch에는 database, role, extension, schema와 data가 포함됩니다. PlanetScale Postgres의 일반적인 새 branch는 빈 DB입니다. 부모 schema와 data가 없으며, backup에서 복원하는 생성 경로는 두 항목을 포함합니다. 같은 이름의 생성 버튼을 비교하더라도 시작 상태가 다릅니다.

Supabase도 기본 branch와 데이터 포함 옵션을 나누어야 합니다. 기본 경로는 운영 데이터를 제외하고 schema, Edge Functions와 설정을 준비합니다. Dashboard의 Include data는 PITR add-on을 요구합니다. 데이터가 포함된다는 사실만으로 내부 저장 방식까지 CoW라고 판정할 근거는 없습니다. 기본값, 추가 조건과 구현 방식은 각각 확인해야 할 항목입니다. 다음 표는 이 차이를 실제 생성 결과와 대조할 수 있도록 정리한 것입니다.

제품과 모드기준으로 준비하는 상태데이터 범위
DBLab 4.0 named branchSnapshot을 가리키는 이름해당 snapshot의 상태
Neon 데이터 포함 branch부모에서 분기한 상태Database, role, extension, schema, data
PlanetScale Postgres 기본 생성빈 DB부모 schema와 data 미포함
PlanetScale Postgres backup 복원선택한 backupSchema와 data 포함
Supabase 기본 branchSchema, Functions, 설정운영 데이터와 Storage object 미포함
Supabase Include dataPITR add-on을 사용하는 선택 경로데이터 포함, 세부 객체 범위는 별도 확인

표에 없는 객체는 자동 상속 여부를 별도로 확인해야 합니다. 예를 들어 외부 secret, scheduled job, replication 설정은 제품별로 확인 범위가 다릅니다. Neon backend의 현재 Auth와 object storage 분기 기능은 확인된 범위에 한정해 해석합니다. 외부 인증 서비스나 외부 S3 bucket까지 적용된다고 보지는 않습니다. Supabase의 데이터 포함 옵션도 Auth와 Storage의 일부 세부 동작은 미확인 상태입니다. 미확인은 미지원과 다르며, 지원 여부가 불분명한 객체는 도입 검증 항목으로 남깁니다.

Branch에서 변경한 결과를 운영에 반영하는 방법도 이름만으로 결정되지 않습니다. Dolt는 cell 단위 변경을 고려하는 데이터 3-way 머지를 제공합니다. 같은 행의 서로 다른 컬럼 수정이 자동으로 합쳐지는 경우와 같은 cell의 충돌을 구분합니다. PlanetScale Vitess의 deploy request는 schema 변경 배포 절차입니다. 이 기능이 PlanetScale Postgres에도 적용되는지는 별도로 확인해야 합니다. 데이터 머지와 schema 배포, SQL MERGE도 각각 구분해야 합니다.

고정 시점과 원본 추종​

분기 뒤 최신 변경이 필요한지는 별도 요구입니다. PlanetScale Postgres branch는 자체 스토리지를 가지며 부모와 지속 복제되지 않습니다. Turso의 기존 libSQL Cloud 발표도 새 DB를 만드는 기능을 설명합니다. 기존 DB나 지정 timestamp를 기준으로 생성하는 기능입니다. 생성 후 지속 동기화나 데이터 머지 여부는 이 사실과 별도로 확인해야 합니다. 이 사례들은 branch 생성의 성공과 원본 변경 추종을 따로 확인해야 하는 이유를 보여 줍니다.

지속 추종의 예로 PostgreSQL의 warm standby를 비교합니다. 공식 문서는 동일한 base backup을 적재한 다른 서버에 WAL을 계속 전달하는 구성을 설명합니다. 이 동작은 고정한 기준점에서 사본을 준비하는 요청과 구분됩니다. 여기서는 넓은 의미의 replica 중 이 PostgreSQL 구성을 대표 예로 사용합니다. 지속 추종 사실만으로 변경 지연이 없다고 가정하지 않습니다. PostgreSQL의 지속 아카이빙 설명이 근거입니다.

그림의 화살표는 데이터의 관계와 준비 경로를 나타냅니다. 자원 격리나 장애 격리를 보장하지 않습니다. 별도 쓰기 대상이 있어도 스토리지, compute, 인증과 네트워크의 독립성은 따로 확인해야 합니다. 사실 대장은 branch 격리가 성능과 보안 격리를 보장한다는 주장을 거짓으로 분류합니다. 운영 설계에서는 데이터 변경의 격리, 공유 자원의 경합, 접근 권한을 나누어 검증합니다. 검증 결과도 기록합니다.

예를 들어 같은 기준 상태로 두 변경을 비교하는 작업을 생각해 봅니다. 이때는 시험 도중 원본의 새 변경을 받을 필요가 있는지 먼저 결정하도록 권합니다. 반대로 계속 갱신되는 데이터를 요구하는 작업도 있습니다. 이 경우 고정 시점 사본만으로는 요구를 충족했다고 판단하기 어렵습니다. 이 예시는 제품 기능을 추가로 주장하는 것이 아닌 선택 기준입니다. 요청서에는 기준 시점을 고정할 기간과 변경 추종 여부를 함께 적습니다. 결과를 읽는 사람에게도 데이터의 시점을 표시합니다.

보존 목적과 수명 의존성​

Backup은 복구할 데이터를 어떤 조건으로 보존할지 검토하는 범위에서 다룹니다. PostgreSQL PITR는 base backup과 WAL 재생을 사용하는 복구 경로입니다. 모든 제품의 PITR를 과거 branch 생성 하나로 설명하지 않습니다. 보존 기간도 장애 시 허용할 데이터 손실의 시간 목표인 RPO와 구분합니다. 이력에서 어느 과거 시점을 선택할지와 장애 때 어떤 데이터까지 남아야 할지는 서로 다른 질문입니다.

Clone이 존재한다는 사실만으로 독립적인 backup을 확보했다고 판정해서는 안 됩니다. ZFS clone에는 origin snapshot 의존성이 있습니다. Delta Lake의 shallow clone은 원본 data file을 참조합니다. 원본 VACUUM으로 필요한 파일이 삭제되면 읽기가 실패할 위험이 있습니다. Databricks Unity Catalog의 shallow clone은 참조 추적으로 파일을 보호합니다. 다만 원본 managed table 삭제 후 purge는 별도 위험입니다. 해당 기능의 preview 상태, Runtime 조건과 테이블 유형을 함께 확인해야 합니다.

이 차이는 삭제 정책에서도 드러납니다. 운영 설계에서는 사본의 사용 종료와 원본 참조 해제를 별도 관리 항목으로 둡니다. 실제 공간 회수 확인도 따로 관리합니다. 원본 삭제 뒤 clone의 안전성을 판단하려면 어떤 의존성이 해제되어야 삭제되는지 확인해야 합니다. 계정과 리전의 장애 범위 역시 별도 검증 대상입니다. 쓰기 가능한 조사 환경을 제공하는 목적과 장애 때 복구 자료를 남기는 목적은 다릅니다. 각 목적에 맞는 합격 조건을 적용해야 합니다.

접근 통제도 수명과 연결해서 검토합니다. 마스킹 UPDATE는 과거 tuple, snapshot과 backup의 원본 정보 제거를 보장하지 않습니다. 현재 조회 결과를 바꾼 상태와 과거 정보까지 제거한 상태는 구분해야 합니다. 시험 종료 뒤의 삭제 요구가 접근 차단인지, 재사용 금지인지, 보존 자료 정리인지 구체적으로 적습니다. 그래야 검증 범위 설정이 가능합니다. 제품별 미확인 객체와 보존 경로는 후속 운영 검증에 남깁니다.

요청서에는 시작할 데이터, 기준 시점, 허용할 쓰기, 원본 추종 여부를 산문으로 명시하도록 권합니다. 결과 반영 방법과 종료 후 보존 조건도 함께 적습니다. 그 뒤 제품의 branch와 clone 기능을 대응시키면 실제 요구를 기준으로 비교가 가능합니다. 다음 데이터 분기의 연대기는 이런 동작의 공개 과정을 살펴봅니다. 서로 다른 시기와 제품에서 어떤 단계로 공개되었는지 확인합니다.

참고​