Postgres의 데이터베이스 브랜칭: Databricks Lakebase를 이용한 Git 스타일 워크플로우

데이터베이스는 개발 워크플로의 마지막 병목 현상입니다

데이터베이스 브랜칭은 최신 개발 워크플로에서 누락된 기본 요소입니다. 스택의 다른 모든 부분은 빠른 반복을 지원하도록 발전했습니다. 코드는 Git을 사용합니다. 인프라는 Terraform을 사용합니다. 배포는 몇 분 안에 실행되는 CI/CD 파이프라인을 사용합니다. 그러나 관계형 데이터베이스는 여전히 10년 전과 같은 방식으로 작동합니다.

대부분의 팀은 단일 스테이징 데이터베이스를 공유합니다. 설정 후 며칠 이내에 해당 데이터베이스는 프로덕션과 동기화되지 않습니다. 개발자가 다른 순서로 마이그레이션을 적용함에 따라 스키마가 달라집니다. 시퀀스 값이 더 이상 일치하지 않습니다. 테스트 데이터가 축적되어 결과를 오염시킵니다. 결국 누군가가 전체를 다시 시드하고 주기가 다시 시작됩니다.

새 환경을 설정하는 것은 더 나쁩니다. 표준 접근 방식은 프로덕션에 대해 pg_dump를 실행하고, 완료될 때까지 기다린 다음(데이터베이스 크기에 따라 몇 분에서 몇 시간), 새 인스턴스에 로드하고, 액세스를 구성하고, 결과가 실제로 프로덕션에서 실행 중인 것을 반영하기를 바라는 것입니다. 500GB 데이터베이스의 경우 이는 500GB 복사 작업과 이를 실행하는 데 필요한 컴퓨팅 및 스토리지가 추가됩니다.

결과는 예측 가능합니다. 팀은 너무 비싸고 너무 느리기 때문에 새 환경을 만드는 것을 피합니다. 개발자는 단일 가변 스테이징 데이터베이스를 공유합니다. 마이그레이션은 오래된 데이터에 대해 테스트되거나 전혀 테스트되지 않습니다. 미리 보기 배포는 현실적인 스키마 대신 빈 고정 데이터에 대해 실행됩니다. CI 테스트는 상태를 공유하고 불안정한 결과를 생성합니다.

데이터베이스는 개발자가 만지기를 두려워하는 스택의 부분이 됩니다.

Databricks Lakebase Postgres는 데이터베이스 브랜칭으로 이를 변경합니다.

데이터베이스 브랜칭이란 정확히 무엇인가

데이터베이스 브랜치는 데이터베이스 복사본이 아닙니다. 이 구별은 격리된 환경의 경제성을 완전히 변경하기 때문에 중요합니다.

데이터베이스를 복사할 때 모든 데이터와 스키마를 새롭고 독립적인 인스턴스로 복제합니다. 시간과 비용은 데이터베이스 크기에 따라 선형적으로 확장됩니다. 모든 복사본은 전체 클론이며, 모든 클론은 생성되는 순간부터 오래되기 시작합니다.

브랜치는 다르게 작동합니다. Lakebase에서 브랜치를 만들면 다음과 같은 새롭고 완전히 격리된 Postgres 환경을 얻게 됩니다.

• 특정 시점의 부모의 정확한 스키마와 데이터에서 시작합니다.
• 복제하는 대신 동일한 기본 스토리지를 공유합니다.
• 실제로 변경할 때만 새 데이터를 씁니다.

이를 쓰기 시 복사라고 합니다. 두 브랜치가 분기되지 않는 한 동일한 저장된 데이터를 참조합니다. 브랜치에서 마이그레이션을 실행하거나, 행을 삽입하거나, 테이블을 수정하면 해당 변경 사항만 별도로 기록됩니다. 다른 모든 것은 부모와 공유됩니다.

데이터베이스 복사 대 데이터베이스 브랜치

실질적으로 이는 다음을 의미합니다.

• 데이터베이스 크기에 관계없이 브랜치 생성은 몇 초가 걸립니다. 10GB 데이터베이스와 2TB 데이터베이스 브랜치는 동일한 시간 안에 생성됩니다.
• 스토리지 비용은 총 데이터 크기가 아닌 변경 사항에 비례합니다. 500GB 데이터베이스에서 50MB의 데이터를 수정하는 브랜치는 약 50MB의 추가 스토리지를 사용합니다.
• 각 브랜치는 자체 Postgres 연결 문자열과 컴퓨팅 엔드포인트를 갖습니다. 브랜치는 서로 그리고 부모로부터 완전히 격리됩니다.
• 유휴 브랜치는 자동으로 컴퓨팅을 0으로 축소합니다. 브랜치가 실제로 사용될 때만 활성 컴퓨팅에 대해 비용을 지불합니다.

브랜치는 자유롭게 생성, 사용 및 폐기하도록 설계되었습니다. 개발자, CI 파이프라인, AI 에이전트, 자동화에 의해. 유지 관리해야 하는 귀중한 환경이 아닙니다. Git 브랜치처럼 일회용입니다.

데이터베이스 브랜칭을 가능하게 하는 아키텍처

기존 관리형 Postgres(RDS, Azure Database for PostgreSQL)는 컴퓨팅과 스토리지를 함께 묶습니다. 데이터베이스 프로세스와 해당 데이터는 동일한 인스턴스에 있으며 데이터는 단일 가변 파일 시스템으로 저장됩니다. 그렇기 때문에 두 번째 환경을 만들기 위한 유일한 옵션은 복사입니다. 파일 시스템을 복제해야 합니다.

하지만 lakebase는 다르게 구축됩니다. 컴퓨팅과 스토리지를 완전히 분리합니다. 모든 데이터는 변경 사항을 덮어쓰는 대신 새 버전으로 기록하는 분산 버전 관리 스토리지 엔진에 기록됩니다. 이 로그 구조 아키텍처는 데이터베이스 브랜칭을 기본 기능으로 가능하게 하는 것입니다.

스토리지에 버전이 있기 때문에 여러 브랜치가 충돌 위험 없이 동일한 기본 데이터를 참조할 수 있습니다. 컴퓨팅이 독립적이기 때문에 각 브랜치는 자체 Postgres 프로세스를 실행하고 자체적으로 확장됩니다. 유휴 상태인 비프로덕션 브랜치는 자동으로 0으로 축소되고 연결이 들어오면 밀리초 내에 다시 시작됩니다.

모든 데이터베이스 브랜칭 구현이 동일한 것은 아닙니다. 일부 플랫폼은 전체 인스턴스 복사본을 만들어 브랜치라고 부릅니다. 다른 플랫폼은 데이터 없이 스키마만 브랜치합니다. Lakebase 브랜치는 스키마와 데이터를 모두 포함하고, 스토리지 계층에서 쓰기 시 복사를 사용하여 복제를 피하고, 브랜치당 독립적이고 자동 확장되는 컴퓨팅을 제공합니다. 이것이 추가 인프라를 프로비저닝하지 않고도 자유롭고 대규모로 브랜치를 생성하는 것을 실용적으로 만드는 것입니다.

이 아키텍처는 시간 여행도 가능하게 합니다. 구성 가능한 복원 창 내에서 모든 데이터 버전이 유지되므로 현재 상태뿐만 아니라 과거의 모든 시점에서 브랜치를 만들 수 있습니다. 이것이 즉각적인 시점 복구를 지원하는 것입니다. WAL 로그를 다시 재생하거나 백업을 복원하는 대신 필요한 타임스탬프에서 브랜치를 만들고 직접 읽습니다.

데이터베이스 브랜칭이 팀에 제공하는 이점

데이터베이스 브랜칭이 비싼 복사 작업이 아닌 빠르고 저렴한 기본 기능이 되면 새로운 워크플로가 실용적으로 됩니다. 다음은 가장 일반적인 패턴의 요약입니다. (다음 게시물에서 각 패턴을 자세히 다룹니다.)

개발자당 하나의 브랜치. 모든 엔지니어는 프로덕션과 유사한 데이터가 포함된 자체 격리된 환경을 얻습니다. 더 이상 공유 개발 데이터베이스에서 서로의 변경 사항을 덮어쓰지 않습니다. 브랜치가 프로덕션에서 너무 많이 벗어나면 명령 하나로 재설정하여 최신 스키마와 데이터를 가져옵니다. 브랜치는 유휴 상태일 때 0으로 축소되므로 이 패턴은 대규모 팀에서도 저렴하게 유지됩니다.

풀 리퀘스트당 하나의 브랜치. PR이 열리면 브랜치를 자동으로 생성하고 병합되거나 닫힐 때 삭제합니다. Vercel 또는 Netlify의 미리 보기 배포는 자체 데이터베이스 브랜치를 가지므로 프런트엔드 미리 보기는 현실적이고 격리된 데이터로 지원됩니다. 마이그레이션은 빈 테스트 고정 데이터가 아닌 실제 데이터 모양 및 제약 조건에 대해 실행됩니다. 이것은 팀이 가장 먼저 채택하는 워크플로이며, 전반적으로 데이터베이스 브랜칭을 채택하도록 설득하는 워크플로입니다.

테스트 실행당 하나의 브랜치. CI 파이프라인은 각 실행에 대해 새롭고 격리된 데이터베이스를 얻습니다. 이전 테스트의 잔여 상태가 없습니다. 빈 컨테이너 이미지가 시작되고 가짜 데이터로 채워질 때까지 기다릴 필요가 없습니다. 공유 데이터 또는 테스트 순서 종속성으로 인한 불안정한 결과가 없습니다. 각 실행은 동일한 기준선에서 시작합니다. 결정론적 데이터가 필요한 테스트의 경우 고정 시점 또는 특정 로그 시퀀스 번호(LSN)에서 브랜치를 만들 수 있습니다.

즉각적인 복구. 복구 창 내에서 원하는 시점으로 분기를 생성하세요. 프로덕션 환경을 건드리지 않고도 삭제된 테이블을 검사하거나, 실패한 마이그레이션을 디버깅하거나, 기록 데이터를 감사할 수 있습니다. 스키마 차이를 사용하여 변경 전후의 상태를 비교하세요. 복구 분기에서 필요한 것을 내보낸 다음 삭제하세요. 이 전체 프로세스는 기존 PITR이 요구하는 몇 시간 또는 며칠이 아닌 몇 초가 걸립니다.

AI 에이전트를 위한 임시 환경. AI 에이전트는 Lakebase API를 통해 프로그래밍 방식으로 데이터베이스를 프로비저닝하고, 작업 기간 동안 사용한 다음, 완료되면 종료할 수 있습니다. 플랫폼은 스냅샷 위에 버전 관리를 구축할 수 있습니다. 모든 에이전트 작업은 체크포인트를 생성하며, 사용자는 버전을 즉시 전환할 수 있습니다. 에이전트가 잘못된 마이그레이션을 실행하거나 데이터를 손상시키는 경우, 롤백은 단일 API 호출로 가능합니다.

시작하기

Databricks Lakebase의 데이터베이스 분기는 Postgres 데이터베이스를 개발 워크플로에서 가장 느린 부분에서 가장 빠른 부분으로 바꿔줍니다.

콘솔, CLI 또는 API를 사용하여 1분 안에 첫 번째 분기를 생성할 수 있습니다. CLI에서 보는 모습은 다음과 같습니다.

이것으로 완료되었습니다. 이제 프로덕션의 전체 스키마와 데이터가 포함된 격리된 Postgres 환경이 준비되었습니다.

Postgres를 기반으로 구축하고 데이터베이스 환경 관리에 따르는 오버헤드에 지쳤다면, 단일 개발 분기로 시작하세요. 그런 다음 PR당 하나씩 사용해 보세요. 단일 데이터베이스 분기 워크플로로 시작한 대부분의 팀은 빠르게 나머지 워크플로도 채택합니다.

Databricks Lakebase는 에이전트와 앱을 위해 구축된 서버리스 Postgres입니다. 자세한 내용은 databricks.com/product/lakebase에서 확인하세요.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)