Lakebase 백스테이지, 파트 3

이 시리즈의 첫 번째 파트에서는 Databricks Lakebase에서 Backstage를 실행하여 1초 만에 데이터베이스 브랜칭을 수행하는 방법을 살펴보았습니다. 한편 두 번째 파트에서는 Unity Catalog가 해당 운영 데이터베이스를 기업 거버넌스 영역으로 통합했습니다.

하지만 실제로 조직도를 바꿀 수 있는 진짜 이점은 바로 여기에 있습니다.

일반적인 스택에서 '클라우드 비용을 증가시키는 인프라의 소유자는 누구이며, 비용은 얼마나 들었는가?'라는 질문에 답하려면 두 가지 경계를 넘어야 합니다. 소유권 그래프는 Backstage(플랫폼 엔지니어링 팀 소유)에 있고, 비용 데이터는 데이터 웨어하우스(데이터 팀 관리)에 있기 때문입니다. 이 질문에 답하려면 ETL 파이프라인, Jira 티켓 또는 Slack 스레드가 필요합니다.

분리된 컴퓨팅으로 가능해진 공유

FinOps 분석가가 라이브 포털에 영향을 주지 않고 정확히 동일한 기본 스토리지에 대해 대규모 분석 쿼리를 실행할 수 있는 이유는 Lakebase가 워크로드별로 컴퓨팅을 격리하기 때문입니다.

Backstage는 격리된 자체 자동 확장(autoscaling) 컴퓨팅 엔벨로프를 갖게 됩니다. 일반적인 포털 사용 시 카탈로그 쿼리는 엔드투엔드로 55~65ms가 소요되었고, 검색은 2~4ms가 걸렸습니다. 웹 애플리케이션과 분석 워크로드가 동일한 컴퓨팅 클러스터를 두고 경쟁하지 않기 때문에, 마침내 동일한 데이터 기저(substrate)를 안전하게 공유할 수 있습니다.

해결 방법: Lakehouse 페더레이션 인증

라이브 Postgres 데이터를 분석용 청구 데이터와 조인하기 위해 Databricks Lakehouse Federation을 사용합니다. 하지만 현재 Lakehouse Federation의 Postgres 커넥터는 정적 사용자/비밀번호 자격 증명만 지원합니다. Lakebase는 OAuth JWT를 통해 앱 아이덴티티를 인증하므로, 페더레이션 엔진에는 병렬 인증 경로가 필요합니다.

이에 대한 해결책은 앱이 사용하는 OAuth 아이덴티티와는 별개로 페더레이션에 연결된 SCRAM-SHA-256 인증을 사용하는 네이티브 Postgres 역할을 생성하는 것입니다:

이제 동일한 데이터베이스에 대해 두 개의 인증 경로를 관리하게 됩니다.

FinOps 조인

외부 카탈로그가 활성화되면, FinOps 분석가는 운영 Postgres 테이블에서 Backstage 리소스 이름을 직접 가져와 system.billing.usage에 있는 Lakebase 자체 청구 행과 조인하는 단일 쿼리를 작성할 수 있습니다:

실제 결과:

해당 행의 왼쪽은 라이브 Backstage Postgres 카탈로그 내부에서 직접 가져온 것이고, 오른쪽은 Unity Catalog 시스템 청구 테이블에서 가져온 것입니다. 역사적으로 이 두 가지는 동일한 SQL 엔진에 존재한 적이 없었지만, 이제 데이터 이동 없이 조인됩니다.

그냥 ETL을 사용하면 되지 않나요?

회의적인 시각을 가진 사람들은 왜 1시간에 한 번씩 Python 스크립트를 사용하여 RDS 인스턴스를 Delta 테이블로 동기화하지 않는지 물을 수 있습니다.

답은 브랜칭에 있습니다. 개발자가 PR을 테스트하기 위해 1초 만에 임시 데이터베이스 복제본을 생성할 때, 해당 임시 테스트 환경에 대한 비용 가시성을 확보하기 위해서만 새로운 ETL 파이프라인을 동적으로 프로비저닝해야 합니다. 하지만 Lakebase를 사용하면 브랜치가 생성되는 즉시 청구 및 소유권 데이터를 즉시 쿼리할 수 있습니다. (이 POC에서는 삭제된 테스트 브랜치에 0.0107 DBU가 자동으로 독립적으로 할당되었습니다).

융합의 운영화

이 3부작 시리즈는 1초 만에 생성되는 데이터베이스 브랜치로 시작하여 통합 거버넌스를 거쳐, 파이프라인 없이 운영 소유권 데이터와 클라우드 청구 데이터를 조인하는 단일 SQL 쿼리라는 결과에 도달했습니다. 이것이 바로 기술적으로 융합이 작동한다는 증거입니다. 실무자들이 다음에 던질 질문은 '이를 운영화하려면 무엇이 필요한가?'입니다.

이 경로를 따르려는 팀을 위해 이번 POC에서 주목할 만한 두 가지 사항을 소개합니다.

페더레이션 인증 공백

앞서 설명한 Lakehouse Federation 해결 방법(앱이 사용하는 OAuth 아이덴티티와 별개로 연결된 정적 자격 증명을 가진 네이티브 Postgres 역할)은 현재로서는 올바른 접근 방식입니다. Lakebase 운영 데이터를 Unity Catalog의 분석 테이블과 조인하려는 모든 팀은 이 병렬 인증 경로를 설정해야 합니다. 어차피 페더레이션은 애플리케이션 사용자로 실행되어서는 안 되므로 이러한 분리는 보안상 이점이 있지만, 비밀번호 순환(rotation)은 직접 관리해야 합니다. 이 패턴을 도입하는 팀의 경우 안전한 비밀번호 생성, 읽기 전용 권한이 있는 역할 생성, 연결 구성, 외부 카탈로그 생성 등의 단계를 반복 가능한 스크립트로 패키징할 수 있습니다. 패턴만 파악하면 몇 분 만에 끝나는 일회성 설정입니다. Federation에서 OAuth JWT를 기본적으로 지원한다면 이러한 해결 방법이 전혀 필요하지 않을 것입니다.

개발 팀을 위한 브랜치 비용 가시성

FinOps 조인은 '이 인프라의 비용은 얼마이며 소유자는 누구인가?'라는 플랫폼 질문에 대한 답을 제공합니다. 하지만 동일한 청구 데이터는 엔지니어링 관리자에게 중요한 또 다른 이야기, 즉 '개발 프로세스 자체의 비용은 얼마인가?'에 대해서도 알려줍니다.

파트 1의 브랜칭 워크플로에서는 모든 풀 리퀘스트(PR)가 임시 CI 브랜치를 생성하고, 모든 개발자가 자신만의 기능(feature) 브랜치를 갖습니다. 이러한 브랜치들은 system.billing.usage에 branch_id 및 endpoint_id별로 세분화되어 독립적인 라인 항목으로 표시됩니다. 엔지니어링 관리자는 팀의 개발/테스트 브랜칭이 프로덕션 대비 스프린트에서 정확히 얼마나 많은 컴퓨팅을 소비했는지 확인하고, 브랜치 수명 주기 정책에 대해 정보에 입각한 결정을 내릴 수 있습니다.

핵심은 임시 브랜치가 청구 데이터에서도 임시로 취급되어야 한다는 점입니다. 짧은 TTL로 생성된 CI 브랜치는 main으로의 직접 푸시, 워크플로 오류, 누락된 이벤트 등 어떤 이유로든 정리가 실패하더라도 자동으로 만료됩니다. 수명 주기 제어가 없으면 분리된(orphaned) 브랜치가 조용히 누적될 수 있으며, 각 브랜치에는 프로젝트에 대해 청구되는 활성 컴퓨팅 엔드포인트가 연결되어 있습니다. 테스트 브랜치의 비용은 0.0107 DBU였습니다. 이는 미미한 수준입니다. 하지만 한 달 동안 실행되는 30개의 분리된 브랜치는 그렇지 않습니다.

요점은 브랜칭이 비용이 많이 든다는 것이 아니라, 비용 대비 생산성 향상을 고려해야 한다는 것입니다. 팀이 스프린트당 이틀의 환경 대기 시간을 없애고 코드베이스의 20~30%를 모의(mock) 객체로 유지 관리하는 일을 중단한다면, 브랜치당 0.0107 DBU는 관리해야 할 비용 항목이 아니라 팀이 지금까지 했던 투자 중 가장 저렴한 생산성 투자입니다. 그리고 대부분의 생산성 투자와 달리 이는 측정이 가능합니다. 인프라가 브랜치별, 개발자별, 스프린트별로 정확히 얼마의 비용이 들었는지 알려주기 때문입니다. 이는 대부분의 엔지니어링 팀이 데이터베이스와 나눌 수 없었던 대화입니다.

다음 단계

마무리하기 전에 FinOps 이야기에서 짚고 넘어가야 할 점이 하나 더 있습니다. Lakebase 엔드포인트는 0으로 확장(scale to zero)됩니다. 브랜치에 대한 쿼리가 실행되지 않으면 컴퓨팅이 일시 중단되고 청구가 중단됩니다. 0.0107 DBU라는 수치는 실행된 브랜치의 비용이지 존재하는 브랜치의 비용이 아닙니다. 테스트 실행 사이에 대기 중인 수많은 임시 브랜치는 비용을 발생시키지 않습니다.

이번 시리즈를 통해 실제 앱, 실제 벤치마크, 실제 거버넌스, 실제 비용 데이터를 활용하여 인프라가 제대로 작동한다는 것을 증명했습니다. 저희 측에서는 Databricks와 Thoughtworks가 협력하여 실제 개발 팀, 실제 스프린트, 실제 속도 측정을 통해 이를 POC에서 실제 실무로 전환하고 있습니다. 지난 30년 동안 운영 데이터와 분석 데이터를 서로 다른 영역에 분리해 두었던 제약이 이제 사라지고 있습니다.

이 시리즈의 모든 부분에는 월요일 아침에 바로 적용할 수 있는 실질적인 시사점이 있습니다. 실제 스키마에서 다음 마이그레이션을 분기(branch)해 보세요. 브랜치를 대상으로 모의 테스트가 많은 테스트 제품군 하나를 재작성해 보세요. 청구 데이터를 소유권 그래프에 결합해 보세요. 가장 먼저 움직이는 팀이 다음 단계를 정의하게 될 것입니다.

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