클라우드 데이터 웨어하우스 비용 예산 및 알림 설정하기

모든 분석 팀이 한 번쯤 겪어본 상황이 있습니다. 월말 청구서가 도착했는데, 단 하나의 SQL 웨어하우스가 예산을 초과해 버린 것입니다. 밤새 켜져 있었던 컴퓨팅 리소스 때문일 수도 있고, 분기 검토 중에 80명의 Tableau 사용자를 지원하기 위해 자동 확장된 임시(ad hoc) 웨어하우스 때문일 수도 있습니다. 비용도 문제지만, 더 큰 좌절감은 너무 늦을 때까지 아무도 몰랐다는 점입니다.

선제적 비용 관리(Proactive cost management)는 이러한 방식을 완전히 바꿉니다. 사후에 청구서를 분석하는 대신, 비용이 지출되기 전에 가드레일을 설정합니다. 예산은 웨어하우스, 팀 또는 BI 워크로드와 연계됩니다. 설정한 임계값에 도달하면 알림이 전송되고 대시보드를 통해 사용량 추세를 실시간으로 파악할 수 있으며, 이 모든 것이 Databricks Data & AI Platform에서 이루어집니다. 온프레미스 시스템이나 다른 클라우드 데이터 웨어하우스에서 마이그레이션하는 중이라면, 지금이 바로 이러한 거버넌스를 구축할 적기입니다.

사후 대응적 비용 관리가 실패하는 이유는 무엇일까요?

데이터 웨어하우징 워크로드는 고유한 비용 문제를 야기합니다. SQL 웨어하우스는 수요를 예측하기 어렵고 일시적으로 급증하는 대화형 및 사용자 주도형 워크로드(BI 대시보드, ad hoc 분석, 임베디드 분석)를 처리합니다. 임원 전체 회의 한 번으로 200개의 대시보드가 동시에 새로 고침되면 단 몇 분 만에 비용이 급증할 수 있습니다. 대부분의 조직은 동일한 방식으로 FinOps 여정을 시작합니다. 누군가 지난달 사용량 CSV 파일을 다운로드하고, 피벗 테이블을 열고, 질문을 던지기 시작하는 것이죠. 하지만 이러한 방식은 다음 네 가지 이유로 실패합니다.

• 누가 비용을 지출하고 있는지 파악할 수 없습니다. 사용량이 이를 유발한 팀이나 쿼리가 아닌 플랫폼 전체로 합산되므로, 특정 주체에게 책임을 묻기 어렵습니다.
• 예산 책임자가 없습니다. 웨어하우스나 팀에 연계된 지출 목표가 없으면, 2 TB 테이블에서 SELECT *를 실행하는 분석가는 비용을 전혀 체감하지 못합니다. 결국 플랫폼 팀이 묵묵히 비용을 감당하게 됩니다.
• 너무 늦게 알게 됩니다. 지난달 Excel 보고서에 초과 지출이 나타날 때쯤에는 이미 두 번의 청구 주기가 지난 후이며, 초과 지출을 유발한 결정이 무엇이었는지 파악하기 어렵습니다.
• 수동 검토는 확장성이 떨어집니다. 5개의 웨어하우스는 매월 피벗 테이블 검토를 통해 관리할 수 있을지 모릅니다. 하지만 수십 개로 확장되고 Tableau, Power BI, Looker를 사용하는 수백 명의 분석가를 지원해야 하는 상황이 되면 관리가 불가능해집니다.

선제적 비용 관리(속성 지정, 예산, 알림, 대시보드, 최적화)는 이 다섯 가지 문제를 모두 해결합니다.

서버리스(serverless)로 시작하기: 첫 번째 비용 결정

예산을 설정하기 전에 적절한 웨어하우스 유형을 선택하세요. SQL Serverless 웨어하우스는 대부분의 워크로드에 대해 Databricks가 권장하는 옵션입니다. 몇 초 만에 시작되고 쿼리가 완료되는 즉시 축소(scale down)되며, Intelligent Workload Management가 컴퓨팅 리소스를 자동으로 할당하므로 대기 상태가 아닌 실제 쿼리 실행에 대해서만 비용을 지불하면 됩니다.

기존의 레거시 클라우드 데이터 웨어하우스에서 마이그레이션하는 경우, 이는 큰 변화입니다. 대부분의 레거시 플랫폼은 항상 켜져 있는 컴퓨팅에 대해 비용을 청구하거나 수동으로 크기를 조정해야 합니다. 서버리스는 이러한 유형의 비용 실수를 완전히 방지합니다.

Lumen Technologies는 이를 직접 경험했습니다. 두 개의 핵심 통신 시스템을 온프레미스 데이터 웨어하우스에서 SQL Serverless로 마이그레이션하여 컴퓨팅 비용을 30~40% 절감하고 쿼리 속도를 90% 향상시켰습니다. 이제 시스템은 10분마다 약 7 GB를 처리할 수 있도록 자동으로 확장되며, Serverless 덕분에 일시적으로 급증하는 실시간 워크로드와 관련된 상시 가동 비용(always-on tax)이 제거되었습니다.

선제적 비용 관리의 5대 핵심 요소

이 프레임워크는 5가지 요소로 구성됩니다. 처음 4가지는 지출을 시각화하고, 마지막 5번째는 실제로 비용을 절감하는 역할을 합니다.

• 비용 속성 지정(Cost Attribution). 모든 항목에 태그를 지정하여 어떤 웨어하우스에서 누가 얼마를 썼는지 파악합니다.
• 예산(Budgets). 계정, 작업 공간(workspace) 또는 팀 수준에서 월별 지출 목표를 정의합니다.
• 알림(Alerts). 지출이 임계값에 도달하거나 초과하는 즉시 알림을 받습니다.
• 대시보드(Dashboards). 웨어하우스 추세를 시각화하고 비용을 핵심 운영 지표로 관리합니다.
• 최적화(Optimizations). 애초에 작업에 소요되는 비용 자체를 줄입니다.

핵심 요소 1: 두 가지 수준에서의 비용 속성 지정

속성을 지정할 수 없으면 관리할 수도 없습니다. 웨어하우스의 경우 이는 웨어하우스 자체와 개별 쿼리라는 두 가지 수준을 의미합니다. 하나는 어떤 웨어하우스가 비용을 지출했는지 알려주고, 다른 하나는 웨어하우스 내부의 누가 비용을 지출했는지 알려줍니다.

수준 1: 웨어하우스 태깅

SQL 웨어하우스는 system.billing.usage로 전파되는 key:value 쌍의 사용자 지정 태그를 지원하여, 소비된 모든 DBU를 팀, 프로젝트 또는 비용 센터에 연결합니다. 태깅은 모든 웨어하우스 유형에서 동일하게 작동합니다. Classic, Pro, Serverless 모두 웨어하우스 수준에서 태그가 지정되므로 한 가지 패턴만 익히면 어디에나 적용할 수 있습니다.

UI의 SQL Warehouses > [사용자 웨어하우스] > Edit > Tags에서 태그를 설정하거나, REST API를 통해 웨어하우스를 생성하세요.

REST API를 통한 태깅

최소 세 가지 차원(dimension)을 적용하세요: 팀(소유자), 비용 센터(지불자), 사용 사례(BI 서비스 제공, ad hoc, 예약된 새로 고침).

현재 웨어하우스 태그를 강제하는 기본 정책이 없기 때문에 누구나 태그가 없는 웨어하우스를 생성할 수 있습니다. 대신 프로비저닝 프로세스에 강제 적용 단계를 구축하세요. Terraform, Declarative Automation Bundles 또는 정의에 태그가 포함된 REST API를 사용하여 웨어하우스를 생성하고, UI 사용은 예외적인 경우로 취급하세요. 이 포스트의 뒷부분에 나오는 속성 누락(attribution-gap) 쿼리를 통해 누락된 항목을 찾아낼 수 있습니다.

수준 2: 쿼리 태깅

웨어하우스 태그는 지난달에 웨어하우스 비용으로 4,000달러가 발생했다는 사실은 알려주지만, 그 중 60%가 15분마다 새로 고침되는 단 하나의 Power BI 대시보드에서 발생했다는 사실은 알려주지 않습니다. 웨어하우스는 공유되는 리소스이기 때문에 이러한 공백을 메우는 것이 중요합니다. 하나의 BI 웨어하우스가 수십 개의 대시보드, 여러 dbt 모델, 그리고 지속적인 ad hoc 쿼리를 처리하기 때문입니다.

쿼리 태그(Query tags)(Public Preview)는 개별 SQL 문에 비즈니스 컨텍스트를 첨부하여 이 공백을 메워줍니다.

태그는 executed_by 및 statement_id와 함께 system.query.history(Public Preview)의 query_tags 열에 저장되므로, 웨어하우스별이 아닌 대시보드, 모델 또는 비용 센터별로 지출을 그룹화할 수 있습니다. 일부 도구는 이를 자동으로 설정해 줍니다. 예를 들어 dbt-databricks 1.11.0부터 모델 쿼리에는 dbt 모델 이름이 자동으로 태깅되며, Power BI는 ADBC 드라이버를 통해 작업 공간 및 데이터 세트 식별자를 전달합니다.

두 가지 주의할 점이 있습니다. 쿼리 태그는 SQL 웨어하우스 쿼리에만 적용되며, 청구 데이터가 아닌 쿼리 기록에 저장되므로 쿼리당 비용을 확인하려면 이 두 가지를 직접 조인해야 합니다.

SQL을 작성하기 전에 Governance Hub(베타)의 비용(Cost) 페이지를 확인해 보세요. 이곳은 지출, 비용 요인, 예산, 태깅 범위를 계정 수준에서 보여주며, 사용량 중 추적 가능한 부분이 얼마나 되는지 가장 빠르게 확인할 수 있는 방법입니다. 계정 관리자는 계정 콘솔의 Previews 페이지에서 이 기능을 활성화할 수 있습니다.

필라 2: 계정 콘솔에서 예산 설정하기

예산 생성하기

계정 콘솔에서 Usage > Budgets로 이동하여 Add budget을 클릭하고 다음을 구성합니다.

• 이름: 설명적인 이름(예: "Analytics SQL Warehouses, Monthly")
• 금액: USD 기준 월간 목표 금액
• 범위: 워크스페이스 및/또는 태그별 필터링(예: Team:Analytics)
• 이메일 알림: 지출이 예산 금액에 도달할 때 알림을 받을 수신자

예산 구성 예시

핵심 패턴은 계층형 예산입니다. 즉, 책임 소재를 명확히 하기 위한 팀 수준의 예산과 함께, 감시망을 벗어나는 모든 지출을 잡아내기 위한 안전망으로서 계정 전체 예산을 함께 구성하는 것입니다. 

예산은 모니터링 메커니즘일 뿐, 강제 제한선(hard cap)이 아니라는 점을 유념하세요. 예산이 초과된다고 해서 사용이 중단되거나 요금 청구가 방지되는 것은 아니므로 실제 청구 금액은 예산을 초과할 수 있습니다. 목표는 인지하고 신속하게 대응하는 것이지, 새로고침 도중에 프로덕션 대시보드를 중단시키는 것이 아닙니다.

GetYourGuide는 이를 직접 테스트했습니다. 모든 Looker 워크로드를 SQL 서버리스로 통합한 결과, 팀에서 클래식 클러스터가 더 저렴할 것이라고 예상했음에도 불구하고 BI 서빙 비용이 약 20% 절감되고 쿼리 속도가 35% 빨라졌습니다. 웨어하우스 유형 선택은 한 번 결정하고 끝내는 것이 아니라 지속적으로 재검증할 가치가 있는 예산 결정 사항입니다.

소진율 파악하기

아무 예산이나 클릭하면 현재 지출 대 목표, 남은 예산, 일별 소진율 시각화 차트를 볼 수 있습니다. 데이터 웨어하우징의 경우, 이 차트는 특히 많은 것을 보여줍니다.

• 선형적인 일별 소진은 안정적인 BI 서빙 비용을 의미합니다.
• 월요일/금요일에 급증하는 톱니형 패턴은 평일에 집중되는 애드혹 탐색 작업을 나타냅니다.
• 월 중순의 갑작스러운 급증은 비용 검토 없이 새로운 대시보드가 배포되었음을 의미합니다.
• 점진적인 상승 추세는 자연스러운 사용량 증가가 예상했던 예산 가정을 초과하고 있음을 의미합니다.

필라 3: 비용 거버넌스의 신경망, 알림

예산은 현재 상태를 알려주고, 알림은 조치를 취해야 할 때를 알려줍니다.

예산 이메일 알림

예산을 생성할 때 지출이 예산 금액을 초과하면 알림을 받을 이메일 수신자를 추가하세요. 코드는 전혀 필요하지 않습니다.

임계값 기준 알림의 경우, Databricks SQL 알림을 생성하여 `system.billing.usage`를 직접 쿼리하세요. 가장 중요한 패턴은 다음과 같습니다.

일별 SQL 웨어하우스 지출이 임계값을 초과할 때 알림

지출 속도 알림: 예상 월말 지출이 예산을 초과할 때

이것은 팀들이 가장 유용하게 활용하는 패턴입니다. 예산이 초과된 후에 알림을 보내는 대신, 월말 지출을 예측하여 예측치가 예산을 넘어서기 전에 조치를 취할 수 있는 시간적 여유를 두고 알림을 보냅니다.

이 작업을 4시간마다 실행하도록 예약하고 Slack 또는 이메일로 전송되도록 설정하세요. 이를 통해 팀은 예산이 초과되기 전에 대응할 수 있는 며칠간의 시간(웨어하우스 크기 적정화, 비용이 많이 드는 쿼리 최적화, 배치 작업 연기 등)을 확보할 수 있습니다.

구체화된 뷰 새로고침으로 인한 숨겨진 비용 감지

구체화된 뷰 새로고침 비용은 팀에서 가장 자주 놓치는 부분 중 하나입니다. 웨어하우스 사용량이 아닌 서버리스 파이프라인 사용량으로 청구되기 때문입니다. 하루에 두 번만 업데이트되는 소스에 대해 15분마다 새로고침하도록 설정된 뷰는 아무런 이득 없이 비용만 낭비하게 됩니다. 새로고침 일정을 기본 데이터가 실제로 변경되는 빈도에 맞추고 파이프라인 지출을 직접 모니터링하세요.

필라 4: 대시보드 및 지속적인 모니터링

알림은 특정 시점의 트리거입니다. 대시보드는 지속적인 컨텍스트를 제공합니다. Databricks는 계정 관리자가 Unity Catalog가 활성화된 모든 워크스페이스로 가져올 수 있는 사전 구축된 사용량 대시보드를 제공합니다. 여기에는 지출 트렌드, top-N 분석, 태그 필터링, 웨어하우스별 드릴다운이 포함됩니다. 맞춤형 모니터링을 위해 다음 두 가지 쿼리가 특히 유용합니다:

팀별 SQL 웨어하우스 비용

귀속되지 않은 SQL 사용량(귀속 격차)

태그가 지정되지 않은 SQL 사용량은 귀속 격차, 즉 어떤 팀으로도 추적할 수 없는 웨어하우스 지출을 의미합니다. 이를 0으로 줄이세요.

Raiffeisen Bank International은 Databricks 시스템 테이블을 기반으로 웨어하우스별, 사용자별, 워크로드별 가시성을 제공하는 자체 비용 모니터링 및 예측 플랫폼을 직접 구축했습니다. 그 결실은 기술적인 면만큼이나 문화적인 면에서도 나타났습니다. 워크로드가 3~4배 빨라졌고, 더 중요한 것은 팀이 스스로의 지출을 확인하고 이를 설명해야 할 때 강제적인 지시 없이도 행동이 변화한다는 점이었습니다.

필러 5: 최적화, 실제로 청구 비용을 변화시키는 핵심 요소

처음 네 가지 필러가 지출을 시각화하는 것에 관한 것이라면, 이번 필러는 지출을 줄이는 것에 관한 것이며 대부분의 팀이 놓치는 부분이기도 합니다. 비용과 성능을 동시에 개선하는 두 가지 변화부터 시작해 보세요.

Unity Catalog 관리형 테이블에 대한 예측 최적화를 켜세요. Databricks는 각 테이블이 실제로 쿼리되는 방식에 따라 사용자를 대신해 OPTIMIZE, VACUUM, ANALYZE를 실행하며, CLUSTER BY AUTO를 통해 쿼리 패턴이 변경됨에 따라 클러스터링 키를 조정합니다. 스캔되는 데이터가 적을수록 쿼리 속도가 빨라지고 DBU 사용량이 줄어들며, 유지 관리 일정을 따로 관리할 필요가 없습니다. 이 기능은 2024년 11월 11일 이후에 생성된 계정에는 기본적으로 활성화되어 있으며, 이전 계정에는 2026년까지 순차적으로 적용될 예정입니다.

앞서 설명한 시작 및 유휴 상태의 경제적 이점을 누리려면 기본적으로 서버리스 웨어하우스를 사용하세요. 대부분의 팀에게 이것이 지속적인 노력 없이도 가장 큰 비용 절감 효과를 볼 수 있는 방법입니다.

여기에서 몇 가지 설정을 세부 조정하는 것이 좋습니다:

• 자동 중지 시간을 단축하세요. Pro 및 Classic은 중지 전 유휴 시간이 기본 45분으로 설정되어 있으며, 서버리스는 기본 10분으로 설정되어 있습니다. UI에서는 이를 5분으로, API를 통해서는 1분으로 낮출 수 있습니다. 마지막 대시보드가 닫힌 후 BI 웨어하우스가 유휴 상태로 유지되는 매 순간은 낭비입니다.
• 문 제한 시간(statement timeout)을 설정하세요(Beta — 프리뷰를 활성화한 다음 API를 통해 웨어하우스별로 설정). 통제 불능 상태의 쿼리 하나 때문에 주말 내내 컴퓨팅 자원이 낭비되어서는 안 됩니다. BI 웨어하우스에서는 짧게 설정하고, ETL에서는 더 길게 유지하세요.
• 기본 웨어하우스를 지정하여(관리자 설정 > 컴퓨팅) 단 10개의 행을 빠르게 확인하기 위해 ETL 규모의 클러스터가 활성화되는 것을 방지하고, 과도한 프로비저닝 대신 Small 또는 Medium 크기로 시작하세요.
• 목적에 맞게 스케일 업 또는 스케일 아웃을 수행하세요. 스케일 업(더 큰 크기, 현재 5X-Large까지 지원(Public Preview))은 단일 대용량 쿼리를 더 빠르게 처리하고, 스케일 아웃(최대 클러스터 수 증가)은 더 많은 동시 사용자를 지원합니다. 잘못된 방식을 선택하는 것은 흔히 발생하는 값비싼 실수입니다.

데이터 레이어도 중요합니다. OPTIMIZE, VACUUM, 및 리퀴드 클러스터링(liquid clustering)은 각각 쿼리에 필요한 컴퓨팅 자원을 줄여주며, 이는 하루에 수천 개의 BI 쿼리에 걸쳐 누적 효과를 냅니다.

근본적으로 대부분의 비용 문제는 쿼리 문제입니다. 조인 키 누락이나 넓은 테이블에 대한 SELECT * 실행은 웨어하우스가 어떻게 튜닝되어 있든 동일한 비용이 발생합니다. 그리고 필러 1의 귀속 분석을 통해 어떤 쿼리와 대시보드를 수정해야 하는지 파악할 수 있습니다.

핵심 요약

1. 첫날부터 서버리스와 귀속 분석을 플랫폼에 내장하세요. 즉각적인 시작, 자동 확장(autoscaling), 유휴 시간 비용 제로의 혜택을 누리려면 기본적으로 SQL Serverless 웨어하우스를 사용하고, 처음부터 맞춤형 태그를 강제 적용하세요. 귀속되지 않은 사용량은 보이지 않으며, 보이지 않는 사용량은 항상 늘어나기 마련입니다.

2. 여러 수준에서 선제적으로 예산을 설정하고 알림을 구성하세요. 책임 부여를 위한 팀별 예산과 이상 징후 감지를 위한 계정 전반의 예산을 함께 구성하세요. 또한 단순한 임계값뿐만 아니라 소비 속도에 대해서도 알림을 설정하여, 한도가 초과된 후가 아니라 조치를 취할 수 있는 시간적 여유가 있을 때 초과 소식을 받아볼 수 있도록 하세요.

3. 지출을 시각화하고 이를 문화로 정착시키세요.  가장 지속 가능한 절감 효과는 통제가 아닌 투명성에서 비롯되므로, 팀이 일하는 공간에 비용 대시보드를 배치하세요. RBI가 확인했듯이, 팀이 스스로의 지출을 직접 볼 수 있을 때 강제적인 지시 없이도 행동이 변화합니다.

시작하기

비용이 걷잡을 수 없이 늘어나기 전에 제어할 수 있는 가장 빠른 시작 방법은 다음과 같습니다:

• 첫 번째 예산 생성(계정 콘솔) 
• SQL 웨어하우스 및 쿼리에 태그를 지정하여 사용량 귀속 분석하기
• 시스템 테이블로 비용 모니터링, 웨어하우스별 인사이트를 위해 system.billing.usage 쿼리하기
• SQL 웨어하우스 크기 조정 및 확장 동작, IWM 및 서버리스 경제성 이해하기
• 비용 최적화 모범 사례, 웨어하우스 크기 조정, Photon 및 Delta Lake 최적화
• 혼돈에서 통제까지: Databricks를 통한 비용 성숙도 여정, FinOps 성숙도를 위한 crawl-walk-run 프레임워크

클라우드 데이터 웨어하우스 비용을 제어할 준비가 되셨나요? Databricks 무료 체험 계정을 설정하고, 첫 번째 SQL Serverless 웨어하우스를 생성한 다음, 계정 콘솔에서 이메일 알림이 포함된 예산을 구성해 보세요. 5분밖에 걸리지 않으며 비용도 들지 않습니다.

비용 가시성에 대해 자세히 알아보려면 청구 시스템 테이블 설명서를 살펴보고, 사전 구축된 사용량 대시보드를 가져와 첫날부터 지출 모니터링을 시작해 보세요.

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