작성자: 벤자민 느오켈레메, 피라스 파라 , Jen Darrouzet
Lakebase는 현대적인 애플리케이션 개발의 운영 현실에 맞게 구축된 완전 관리형 Postgres 데이터베이스입니다. Postgres 엔진을 제공하는 시장의 다른 데이터베이스 공급업체와 Lakebase를 차별화하는 점은 서버리스 컴퓨팅 레이어를 통해 스토리지와 컴퓨팅을 분리한 기본 아키텍처와 Lakehouse 및 데이터 인텔리전스 플랫폼과의 긴밀한 통합입니다. 이 아키텍처와 몇 가지 이점에 대한 자세한 내용은 여기에서 읽어보실 수 있습니다. 하지만 종종 간과되기 쉬운 이점은 이 아키텍처 덕분에 Lakebase의 비용 효율성도 매우 높다는 것입니다. 이 블로그에서는 이러한 비용 효율성이 어디에서 비롯되는지 분석하고, 이를 최대한 활용하기 위한 실용적인 팁을 공유합니다.
데이터베이스 브랜치를 사용하면 개발자가 개발, 테스트 또는 실험 목적으로 프로덕션 데이터를 사용하여 격리된 환경을 만들 수 있습니다. 각 환경마다 데이터베이스의 별도 물리적 복사본을 만들어야 하는 방식과 달리, Lakebase 브랜치는 동일한 기본 스토리지를 공유하고 브랜치가 상위 브랜치에서 갈라질 때 변경 사항을 추적합니다. 이 덕분에 브랜칭은 수명이 짧은 개발 및 테스트 환경에서 특히 비용 효율적입니다. 팀은 데이터베이스의 완전히 별개인 복사본을 프로비저닝하고 유지 관리할 필요 없이 프로덕션과 유사한 데이터로 작업할 수 있습니다.
오토스케일링(Autoscaling)은 다양한 활동 수준에 따라 Lakebase 인스턴스의 컴퓨팅 리소스를 동적으로 변경합니다. 인스턴스가 확장 및 축소될 수 있는 최소 및 최대 범위를 제어할 수 있습니다. 이 기능의 비용 이점은 분명합니다. 컴퓨팅 용량을 피크 시간대 사용량에 맞춰 정적으로 프로비저닝하는 대신 워크로드 수요에 따라 확장할 수 있습니다.
최대 컴퓨팅 크기를 설정하면 컴퓨팅 비용의 상한선을 제한하여 예상치 못한 지출을 방지하므로 비용을 예측 가능하게 만드는 데 도움이 됩니다. 사용량이 적은 기간에는 컴퓨팅이 축소되어 비용이 절감됩니다. '0으로 축소(scale to zero)' 기능과 결합하면 일정 기간 활동이 없을 때 컴퓨팅이 완전히 일시 중단되어 컴퓨팅 비용이 0으로 줄어듭니다. 0으로 축소된 상태에서 컴퓨팅이 재개되는 데는 수백 밀리초밖에 걸리지 않습니다. 따라서 개발 워크플로, 비프로덕션 앱 변형, 두 자릿수 밀리초 대기 시간이 필요하지 않은 프로덕션 앱과 같이 대기 시간에 극도로 민감하지 않은 시나리오에 특히 매력적입니다.
0으로 축소 기능이 꺼져 있는 경우, Lakebase는 기본 용량에 대해 25% 할인을 제공하는 상시 가동 요금제(always on pricing)를 적용합니다. 이러한 비용 절감은 HA 구성과 같이 0으로 축소할 수 없는 모든 컴퓨팅에도 적용됩니다.
Lakebase의 스토리지 및 컴퓨팅 분리는 읽기 복제본과 고가용성(high availability)의 비용 효율성도 높여줍니다. 읽기 복제본은 기본(primary)과 동일한 기본 스토리지 레이어에서 읽는 독립적인 컴퓨팅 인스턴스이므로, 읽기 용량을 확장하기 위해 데이터베이스의 다른 복사본을 생성하고 비용을 지불할 필요가 없습니다. 마찬가지로, 고가용성은 기존의 고가용성 스토리지 레이어를 계속 사용하면서 가용 영역 전체에 중복 컴퓨팅을 추가합니다. 즉, 스토리지 사용량을 늘리지 않고도 읽기 스케일과 컴퓨팅 중복성을 추가할 수 있습니다.
Lakebase와 더 넓은 Databricks Intelligence Platform의 긴밀한 통합을 통해 두 환경 간의 관리형 동기화가 가능합니다. 동기화된 테이블(Synced tables)은 Lakebase 데이터베이스에 Unity Catalog 데이터를 노출하여 애플리케이션 또는 피처 서빙(feature-serving) 사용 사례에 대한 저대기시간 트랜잭션 읽기를 지원합니다.
고객들이 흔히 하는 실수는 애플리케이션이 훨씬 더 작은 활성 하위 집합만 쿼리하는데도 대규모 Delta 테이블을 Lakebase로 푸시하는 것입니다. 이로 인해 Lakebase 스토리지가 부풀려지고 동기화 비용이 증가하며, 일부 시나리오에서는 성능 문제가 발생할 수도 있습니다. 해결 방법은 간단합니다. 애플리케이션에 필요한 작업 세트만 동기화하는 것입니다. 구체화된 뷰(Materialized View)를 사용하여 앱에 필요한 데이터를 정확히 정의하고(예: 롤링 60일 창), 해당 데이터만 동기화하세요. Lakebase 동기화 파이프라인은 MV의 자동 변경 데이터 피드(automatic change data feed)를 사용하여 읽기 시점에 행 수준의 변경 사항을 계산할 수 있습니다. 즉, 롤링 창에서 행이 오래되어 삭제되는 것을 포함하여 MV에 대한 변경 사항이 Lakebase에 점진적으로 전파될 수 있습니다. 그 결과 전체 기록은 Delta에 유지되면서 Lakebase에는 최신의 저대기시간 활성 하위 집합이 유지됩니다. 이를 아래에서 설명하는 요구 사항에 맞는 가장 효율적인 동기화 모드와 결합하면 훨씬 더 비용 효율적인 역방향 ETL 패턴을 구축할 수 있습니다.
Synced Tables는 내부적으로 관리형 Serverless Spark Declarative Pipelines(SDP)이며 동기화가 진행되는 동안 실행됩니다. 따라서 동기화 비용은 이동하는 데이터의 양, Lakebase 인스턴스 크기/용량 단위(CUs) 등의 요인 에 의해 결정됩니다.
Lakehouse에서 Lakebase로 데이터를 이동하기 위한 세 가지 동기화 모드가 있으며, 데이터가 실제로 얼마나 최신 상태여야 하는지에 따라 모드를 맞추는 것이 중요합니다. 올바른 모드를 선택하면 비용을 제어하면서 대기 시간 요구 사항을 충족할 수 있습니다.
| 모드 | 설명 | 가장 적합한 사용 시기 |
|---|---|---|
| Snapshot | 모든 데이터의 복사본 | 주기당 소스 행의 10% 이상이 변경되는 경우. 이러한 시나리오에서는 Triggered 모드보다 훨씬 더 비용 효율적입니다. |
| Triggered | 요청 시 또는 특정 간격으로 실행되는 증분 업데이트 | 소스 행이 알려진 주기에 따라 변경되는 경우. 새로 고칠 때마다 삽입, 업데이트 및 삭제가 전파됩니다. |
| Continuous | 초 단위 대기 시간의 실시간 스트리밍 | 변경 사항이 거의 실시간으로 Lakebase에 반영되어야 하는 경우. 가장 높은 비용으로 가장 낮은 지연 시간을 제공합니다. |
Snapshot은 업데이트 빈도가 낮거나 변동성이 큰 테이블에 가장 비용 효율적인 옵션인 반면, Continuous는 파이프라인이 지속적으로 실행되어 처리할 변경 사항이 없는 경우에도 컴퓨팅을 소비하므로 가장 비용이 많이 들 수 있습니다. 동기화 사이에 소스 데이터의 10% 이상이 변경되는 경우 Snapshot 모드가 최대 10배 더 효율적일 수 있으므로 권장됩니다. 증분 워크로드의 경우 Triggered 모드가 비용과 대기 시간의 이 상적인 균형을 제공합니다. Triggered 모드를 테이블 업데이트 트리거(table-update trigger)와 결합하여 소스 데이터가 변경될 때만 실행되도록 함으로써 예산 범위 내에서 거의 지속적인 최신 상태를 유지할 수 있습니다. 일반적으로 실행 간격을 길게 두지 마세요. 대량의 변경 사항이 밀리면 후속 동기화가 느려지고 비용이 많이 들 수 있습니다.
또 다른 유용한 비용 최적화 방법은 여러 테이블을 단일 동기화 파이프라인으로 빈패킹(binpack)하거나 그룹화하는 기능입니다. 사용 사례에서 허용하는 경우, 동일한 파이프라인이 여러 Delta 테이블의 변경 사항을 Lakebase로 동기화하여 해당 테이블들이 동일한 기본 컴퓨팅을 공유하도록 할 수 있습니다. 이는 파이프라인이 항상 실행되는 Continuous 동기화에 특히 유용합니다. 각 테이블에 대해 개별적으로 지속 실행되는 파이프라인 비용을 지불하지 않아도 되기 때문입니다.
Lakebase 프로젝트가 생성되면 자동으로 프로덕션 브랜치와 기본 읽기-쓰기 컴퓨팅이 함께 제공됩니다. 기본적으로 해당 컴퓨팅은 8~16 CU 사이에서 오토스케일링되도록 구성되며, 24시간 동안 활동이 없으면 0으로 축소되도록 설정되어 있습니다. 이러한 기본값은 워크로드에 완전히 적합할 수 있지만, 애플리케이션에 더 적은 컴퓨팅이 필요한 경우 이를 그대로 두면 필요한 것보다 더 많은 용량에 대해 비용을 지불하게 될 수 있습니다.
프로젝트를 생성한 후 나중에 크기를 조정하는 것을 기억하는 대신, 프로그래밍 방식으로 프로젝트를 프로비저닝할 때 초기 컴퓨팅 범위를 설정할 수 있습니다. 예를 들어, Databricks SDK를 사용하는 경우 다음과 같습니다.
Declarative Automation Bundles(DABs)를 사용하여 선언적으로 Lakebase를 관리하는 경우, 프로비저닝하는 엔드포인트의 컴퓨팅 범위를 유사하게 정의할 수 있습니다.
사이즈 산정에서 가장 중요한 입력값은 워킹 세트(working set)입니다. 이는 디스크에 있는 데이터베이스의 전체 크기와 달리, 애플리케이션이 자주 액세스하는 데이터와 인덱스를 의미합니다. 20 GB의 핫 워킹 세트가 있는 2500 GB 데이터베이스에 2500 GB의 RAM이 필요하지는 않습니다. 해당 20 GB에 약간의 여유 공간(headroom)을 더한 만큼만 캐싱하여 유지할 수 있는 메모리만 있으면 됩니다. 이는 컴퓨트가 메모리를 사용하는 방식 때문에 중요합니다. RAM은 컴퓨트 크기에 따라 선형적으로 확장되며, 컴퓨트 RAM의 최대 75%를 컴퓨트 캐시로 사용할 수 있습니다. 워킹 세트가 이 캐시에 들어맞으면 대부분의 읽기 작업이 메모리에서 처리되므로 속도가 빠르게 유지되고 대기 시간(latency)이 일정하게 유지됩니다. 캐시에 들어맞지 않으면 Postgres는 캐시 미스가 발생한 페이지를 스토리지에서 가져와야 합니다. 이는 메모리 히트보다 훨씬 느리며, 애플리케이션이 체감할 수 있는 대기 시간 변동성을 초래합니다. 따라서 크기 산정은 주로 다른 작업을 위한 여유 공간을 남겨두면서 캐시가 워킹 세트를 초과하는 컴퓨트를 선택하는 작업입니다. 하지만 컴퓨트 크기에 따라 확장되는 것이 메모리만은 아닙니다. 쿼리 복잡성, 동시성, 대기 시간 목표도 함께 고려해야 합니다. 동시성이 높거나 대기 시간에 민감한 워크로드는 동일한 데이터 크기에서 가볍게 사용하는 내부 도구보다 더 많은 여유 공간이 필요하기 때문입니다.
데이터베이스 연결도 특별히 주의를 기울여야 합니다. max_connections, 즉 동시 Postgres 연결의 하드 한도도 컴퓨트 크기에 의해 결정되며, 자동 확장(autoscaling) 컴퓨트의 경우 특정 규칙을 따릅니다. 즉, 한도는 최대 CU와 최소 CU의 8배 중 더 작은 값으로 설정됩니다. 따라서 최대값을 높이더라도 연결은 최소값의 최대 8배까지만 추가되며, 그 시점을 지나면 최소값이 작을 경우 더 큰 최대값이 제공할 수 있는 효과가 제한됩니다. 많은 수의 연결을 여는 애플리케이션은 이 한도에 도달하여 오류와 함께 새로운 연결을 거부하기 시작할 수 있습니다. 연결 볼륨이 실제 제약 조건인 경우 이를 최소 CU에 반영하고 Lakebase 앞에 연결 풀러(connection pooler)를 배치하세요. 풀러를 사용하면 많은 클라이언트 연결이 Postgres 연결 풀을 공유할 수 있으며 최대 10,000개의 동시 클라이언트 연결을 지원합니다. 풀링은 많은 연결을 여는 앱에 일반적으로 적합한 해결책이며, 단순히 연결 한도를 높이기 위해 컴퓨트 크기를 키우는 것보다 비용이 저렴합니다.
이러한 사항을 추측할 필요는 없습니다. Lakebase 메트릭 대시보드는 5분, 15분, 1시간 구간의 워킹 세트 크기를 보고하고 사용 가능한 컴퓨트 캐시와 함께 직접 보여주므로 핫 데이터가 적합한지 한눈에 확인할 수 있습니다. 캐시 히트율, CPU, RAM, 연결 사용률과 함께 이를 확인하여 초기 크기 산정을 검증하고 늘리거나 줄이세요. 액세스 패턴이 안정적인 워크로드의 경우, 1시간 워킹 세트를 사용 가능한 컴퓨트 캐시와 비교하는 것이 특히 유용한 신호입니다. 자동 확장은 워 킹 세트가 최소 CU에서 이미 메모리에 들어맞을 때 가장 큰 이점을 제공합니다. 그렇지 않으면 컴퓨트가 확장될 때마다 콜드 캐시 페널티를 지불해야 하기 때문입니다. 이러한 메트릭을 사용하여 워킹 세트를 수용하는 최소값과 피크 부하를 흡수하는 최대값을 설정하세요.
크기 부족(언더사이징)은 완전히 실패한 형태로 나타나는 경우가 드뭅니다. 그보다는 오진하기 쉬운 다음과 같은 증상으로 나타나는 경우가 많습니다.
특정 시점 복구(PITR)는 구성 가능한 2~30일의 복구 기간 내의 어느 순간으로든 데이터베이스를 복구하는 데 필요한 기록을 지속적으로 유지합니다. 반면 스냅샷은 수동으로 생성하거나 일별, 주별 또는 월별 자동 일정에 따라 생성할 수 있는 루트 브랜치의 특정 시점 캡처입니다.
Lakebase는 해당 기간 동안의 변경 기록을 유지해야 하므로 PITR 스토리지는 쓰기 작업과 복구 기간의 길이에 따라 모두 증가합니다. 쓰기 작업이 많은 애플리케이션의 경우 PITR 기간이 길어지면 상당한 스토리지 소비가 발생할 수 있습니다. 비용을 고려한 접근 방식은 장애 복구 요구사항을 충족하는 PITR 기간을 선택하고, 더 장기적인 복구 지점이 필요한 경우 예약된 스냅샷으로 이를 보완하는 것입니다.
다행히 두 가지 모두 일반 Lakebase 브랜치 스토리지보다 저렴한 요금으로 책정됩니다. 스냅샷 스토리지($0.090/GB-월)는 일반 브랜치 스토리지보다 약 74% 저렴하며, PITR 스토리지($0.200/GB-월)는 약 42% 저렴합니다. 예약된 스냅샷은 특히 스토리지 효율성이 높을 수 있습니다. 일정의 첫 번째 스냅샷은 전체 스냅샷으로 저장되는 반면, 이후 스냅샷은 증분 변경 사항에 대해서만 요금이 부과됩니다.
복구 기간 내에 언제든지 발생할 수 있는 실수로 인한 삭제나 잘못된 쓰기와 같은 예기치 않은 장애로부터 복구하려면 PITR을 사용하세요. 계획된 복구 지점에는 스냅샷을 사용하세요. 예를 들어, 위험성이 있는 마이그레이션이나 대량 업데이트를 수행하기 전에 수동 스냅샷을 찍고, 정기적이고 장기적인 보호를 위해 예약된 스냅샷을 사용하세요.
궁극적으로 복구 구성을 실제 복구 요구사항에 맞추세요. 필요한 것보다 더 많은 기록이나 복구 지점을 유지하면 의미 있는 추가 가치를 제공하지 못하면서 스토리지 비용만 증가할 수 있습니다.
위에서 설명한 것처럼 Lakebase 비용은 데이터베이스 컴퓨트, 데이터베이스 스토리지, 그리고 Synced Tables를 사용할 때 레이크하우스(Lakehouse)에서 Lakebase로 데이터를 동기화하는 데 사용되는 서버리스 파이프라인 컴퓨트의 세 가지 영역으로 나뉩니다.
컴퓨트는 시간 경과에 따른 CU 사용량을 기준으로 측정됩니다. 자동 확장(Autoscaling)을 사용하면 데이터베이스가 구성된 범위 내에서 확장됨에 따라 소비되는 컴퓨트 용량을 따릅니다.
스토리지에는 데이터베이스 브랜치 스토리지, 특정 시점 복구(PITR) 기록 및 스냅샷 스토리지가 포함됩니다. 이들은 기본 스토리지 사용량을 기준으로 별도로 측정됩니다.
Synced Tables는 관리형 파이프라인을 사용하여 Unity Catalog에서 Lakebase로 데이터를 이동합니다. 동기화에 사용되는 파이프라인 컴퓨트는 Lakebase 데이터베이스 컴퓨트와 별도로 청구됩니다.
Lakebase 컴퓨트 및 스토리지 사용량은 system.billing.usage에서 확인할 수 있 습니다. 스토리지 사용량은 product_features.lakebase.storage_type을 사용하여 더 세분화할 수 있습니다.
BRANCH_DATA_STORAGE: 만료되지 않는 데이터베이스 브랜치용 스토리지BRANCH_CHANGE_STORAGE: 만료되는 브랜치에 대해 저장된 변경 데이터BRANCH_HISTORY_STORAGE: PITR을 위해 유지되는 기록아래 쿼리는 usage와 system.billing.list_prices를 조인하여 유효 정가 기준의 일일 비용을 추정합니다.
Lakebase는 청구 시스템 테이블에서 별도의 컴퓨팅 및 스토리지 SKU를 제공하며, 스토리지 유형 필드에서 위에 표시된 추가 세부 정보를 제공합니다.
프로젝트 UID는 Lakebase UI의 Project > Settings > UID에서 찾을 수 있습니다. 프로그래밍 방식으로는 프로젝트 이름을 알고 있는 경우, 프로젝트 목록을 조회하고 status.display_name에 일치시켜 UID를 가져올 수 있습니다.
Synced Table 파이프라인 사용량은 system.billing.usage에서도 쿼리할 수 있습니다. 기본 파이프라인 ID를 필터링하고 system.billing.list_prices에 조인하여 파이프라인의 일일 비용을 추정할 수 있습니다.
이 쿼리는 사용 기간 동안의 유효 정가를 사용하여 비용을 추정합니다. 고객별 계약 할인은 반영되지 않습니다.
파이프라인 ID는 UI에서 Synced Table을 열고 Pipeline ID를 복사하여 찾을 수 있습니다. 프로그래밍 방식으로는 Synced Table을 가져와 status.pipeline_id을 읽으면 됩니다.
Lakebase는 공유 스토리지 및 브랜칭부터 오토스케일링 및 서버리스 컴퓨팅에 이르기까지 아키텍처 설계 단계부터 비용 효율적으로 설계되었습니다. 이러한 내장된 효율성을 사이징, 동기화 전략 및 복구에 대한 신중한 구성과 결합하면 애플리케이션에 필요한 성능, 가용성 및 개발자 경험을 확보하는 동시에 비용을 예측 가능한 수준으로 유지할 수 있습니다.
(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)
블로그를 구독하고 최신 게시물을 이메일로 받아보세요.