혼돈에서 제어로: Databricks와 함께하는 비용 성숙도 여정

서론: 데이터와 AI 환경에서 FinOps의 중요성 

모든 산업의 기업들은 최적화와 더 적은 것으로 더 많은 것을 이루는 가치를 계속해서 중요시하고 있습니다. 이는 특히 오늘날의 데이터 환경에서 디지털 기반 회사에게 매우 해당되며, 이로 인해 AI와 데이터 집약적인 작업에 대한 수요가 점점 더 높아지고 있습니다. 이러한 조직들은 다양한 클라우드와 플랫폼 환경에서 수천 개의 리소스를 관리합니다. 빠르게 혁신하고 반복하기 위해, 이러한 리소스들은 팀이나 사업 부서 간에 민주화되어 있지만, 데이터 전문가들의 높은 속도는 신중한 비용 관리와 균형을 이루지 않으면 혼돈을 초래할 수 있습니다.

디지털 네이티브 조직들은 종종 중앙 플랫폼, DevOps, 또는 FinOps 팀을 이용하여 클라우드 및 플랫폼 리소스에 대한 비용과 통제를 감독합니다. 비용 통제와 감독의 공식적인 실천, The FinOps Foundation™에 의해 널리 알려져 있으며, 태깅, 예산, 컴퓨트 정책 등의 기능을 통해 Databricks에서도 지원됩니다. 그러나, 비용 관리를 우선시하고 구조화된 소유권을 설정하는 결정이 비용 성숙도를 하루아침에 만들어내지는 않습니다. 이 블로그에서 다루는 방법론과 기능들은 팀이 데이터 인텔리전스 플랫폼 내에서 비용 관리를 점진적으로 성숙시키는 데 도움이 됩니다.

다룰 내용:

• 비용 속성화: 태깅 및 예산 정책을 사용하여 비용을 할당하는 주요 고려 사항 검토.
• 비용 보고: Databricks AI/BI 대시보드를 이용한 비용 모니터링.
• 비용 제어: Terraform, Compute 정책, 그리고 Databricks Asset Bundles를 이용한 자동 비용 제어.
• 비용 최적화: 일반적인 Databricks 최적화 체크리스트 항목들.

당신이 엔지니어, 아키텍트, 또는 FinOps 전문가라면, 이 블로그는 Databricks 환경을 고성능이면서도 비용 효율적으로 유지하는 데 도움이 될 것입니다.

기술 솔루션 분석

이제 Databricks 플랫폼에서 성숙한 비용 관리 방법을 점진적으로 구현해 보겠습니다. 이것을 혼돈에서 통제로 가는 "기어가기, 걷기, 달리기" 여정으로 생각해보세요. 이 과정을 단계별로 어떻게 구현하는지 설명하겠습니다.

단계 1: 비용 할당 

첫 번째 단계는 비용을 올바른 팀, 프로젝트, 또는 작업 부하에 정확하게 할당하는 것입니다. 이것은 모든 리소스(서버리스 컴퓨팅 포함)를 효율적으로 태깅하여 비용이 발생하는 위치를 명확하게 파악하는 것을 포함합니다. 적절한 속성 부여는 팀 간의 정확한 예산 설정과 책임을 가능하게 합니다.

비용 속성화는 클래식 또는 서버리스 컴퓨팅 모델에 관계없이 모든 컴퓨팅 SKU에 대해 태깅 전략을 사용하여 수행할 수 있습니다. 클래식 컴퓨팅(워크플로우, 선언적 파이프라인, SQL 웨어하우스 등)은 클러스터 정의에서 태그를 상속받고, 서버리스는 서버리스 예산 정책을 준수합니다(AWS | Azure | GCP).

일반적으로 두 가지 종류의 리소스에 태그를 추가할 수 있습니다:

1. 계산 리소스: SQL 웨어하우스, 작업, 인스턴스 풀 등이 포함됩니다.
2. Unity 카탈로그 보안 가능 항목: 카탈로그, 스키마, 테이블, 뷰 등이 포함됩니다.

두 종류의 리소스에 대한 태깅은 효과적인 거버넌스와 관리에 기여할 것입니다:

1. 컴퓨팅 리소스에 태그를 붙이는 것은 비용 관리에 직접적인 영향을 미칩니다.
2. Unity 카탈로그 보안 가능 항목에 태그를 붙이면 그 객체들을 정리하고 검색하는 데 도움이 되지만, 이는 이 블로그의 범위를 벗어납니다. 

다른 컴퓨트 리소스에 태그를 붙이는 방법에 대한 자세한 내용은 이 글을 참조하십시오. (AWS | AZURE | GCP) 그리고 Unity Catalog securables에 태그를 붙이는 방법에 대한 자세한 내용은 이 글을 참조하십시오. (AWS | Azure | GCP)

클래식 컴퓨트 태깅

클래식 컴퓨팅의 경우, 컴퓨팅을 생성할 때 설정에서 태그를 지정할 수 있습니다. 아래는 UI와 Databricks SDK를 사용하여 각각에 대해 태그를 정의하는 방법을 보여주는 다양한 유형의 컴퓨팅 예시입니다.

SQL 웨어하우스 컴퓨트:

고급 옵션 섹션에서 SQL 웨어하우스의 태그를 설정할 수 있습니다.

Databricks SDK를 이용하여:

All-Purpose Compute

Databricks SDK를 이용하여:

작업 계산:

Databricks SDK를 이용하여:

선언적 파이프라인: 

무서버 컴퓨팅 태깅

서버리스 컴퓨팅의 경우, 예산 정책에 태그를 할당해야 합니다. 정책을 생성하면 정책 이름과 문자열 키 및 값의 태그를 지정할 수 있습니다. 

이것은 3단계 과정입니다:

• 단계 1: 예산 정책 만들기 (워크스페이스 관리자는 하나를 만들 수 있고, 관리 권한이 있는 사용자는 그것들을 관리할 수 있습니다)
• 단계 2: 예산 정책을 사용자, 그룹, 서비스 주체에 할당합니다
• 단계 3: 정책이 할당되면, 사용자는 서버리스 컴퓨트를 사용할 때 정책을 선택해야 합니다. 사용자에게 하나의 정책만 할당된 경우, 그 정책이 자동으로 선택됩니다. 사용자에게 여러 정책이 할당된 경우, 그들은 그 중 하나를 선택할 옵션이 있습니다.

서버리스 예산 정책(BP)에 대한 자세한 내용은 이러한 기사(AWS/AZURE/GCP)를 참조하실 수 있습니다.

예산 정책에 대해 기억해야 할 몇 가지 측면:

• 예산 정책은 예산과 매우 다르다 (AWS | Azure | GCP). 우리는 2단계: 비용 보고서에서 예산에 대해 다룰 것입니다.
• 예산 정책은 계정 수준에서 존재하지만, 워크스페이스에서 생성하고 관리할 수 있습니다. 관리자는 특정 워크스페이스에 정책을 바인딩하여 정책이 적용되는 워크스페이스를 제한할 수 있습니다. 
• 예산 정책은 서버리스 워크로드에만 적용됩니다. 현재, 이 블로그를 작성하는 시점에는 노트북, 작업, 파이프라인, 서빙 엔드포인트, 앱, 벡터 검색 엔드포인트에 적용됩니다. 
• 몇 가지 작업을 가진 작업의 예를 들어 보겠습니다. 각 작업은 자체 컴퓨트를 가질 수 있으며, BP 태그는 작업 수준에서(작업 수준이 아닌) 할당됩니다. 따라서 한 작업은 서버리스에서 실행되고 다른 작업은 일반적인 비서버리스 컴퓨트에서 실행될 가능성이 있습니다. 다음 시나리오에서 예산 정책 태그가 어떻게 작동하는지 살펴보겠습니다:
  •  사례 1: 두 작업 모두 서버리스에서 실행
    • 이 경우, BP 태그는 시스템 테이블로 전파될 것입니다.
  • 사례 2: 서버리스에서 하나의 작업만 실행됩니다
    • 이 경우에는, BP 태그도 서버리스 컴퓨팅 사용에 대한 시스템 테이블로 전파되며, 클래식 컴퓨팅 청구 기록은 클러스터 정의에서 태그를 상속합니다.
  • 사례 3: 두 작업 모두 서버리스 컴퓨팅에서 실행되지 않음
    • 이 경우에는 BP 태그가 시스템 테이블로 전파되지 않습니다.

Terraform을 사용하여:

태그 관련 모범 사례:

• 모든 사람이 일반 키를 적용하는 것이 좋으며, 더 세밀한 통찰력을 원하는 조직은 그들의 조직에 맞는 고특이성 키를 적용해야 합니다. 
• 조직 전체에서 적용하고자 하는 고정 키와 값에 대한 비즈니스 정책을 개발하고 모든 사용자와 공유해야 합니다. 4단계에서는 컴퓨트 정책이 어떻게 체계적으로 허용된 값 의 태그와 올바른 위치에 필요한 태그를 제어하는지 살펴볼 것입니다. 
• 태그는 대소문자를 구분합니다. 타이틀 케이스, 파스칼 케이스, 케밥 케이스와 같은 일관되고 읽기 쉬운 대소문자 스타일을 사용하세요.
• 초기 태깅 준수를 위해, 태그를 쿼리하고 조직의 정책과의 불일치를 보고하는 예약된 작업을 구축하는 것을 고려해 보세요.
• 모든 사용자가 적어도 하나의 예산 정책에 대한 권한을 가지는 것이 권장됩니다. 이렇게 하면 사용자가 서버리스 컴퓨팅을 사용하여 노트북/작업/파이프라인 등을 생성할 때마다 할당된 BP가 자동으로 적용됩니다.

샘플 태그 -  키: 값 쌍

단계 2: 비용 보고

시스템 테이블

다음은 비용 보고, 또는 단계 1에서 제공된 컨텍스트를 통해 비용을 모니터링하는 능력입니다. Databricks는 내장된 시스템 테이블, like system.billing.usage, 이것이 비용 보고의 기초입니다. 시스템 테이블은 고객이 보고 솔루션을 커스터마이징하고자 할 때도 유용합니다.

예를 들어, 다음에 보게 될 계정 사용량 대시보드는 Databricks AI/BI 대시보드이므로 모든 쿼리를 보고 대시보드를 매우 쉽게 사용자의 요구에 맞게 커스터마이징할 수 있습니다. Databricks 사용량에 대해 매우 특정적인 필터를 사용하여 ad hoc 쿼리를 작성해야 하는 경우, 이를 사용할 수 있습니다.

계정 사용량 대시보드

리소스에 태그를 붙이기 시작하고 비용을 비용 센터, 팀, 프로젝트, 또는 환경에 할당하면, 비용이 가장 높은 영역을 발견하기 시작할 수 있습니다. Databricks는 사용량 대시보드 를 제공하며, 이를 단순히 AI/BI 대시보드로 자신의 작업 공간에 가져와서 즉시 사용할 수 있는 비용 보고를 제공합니다.

이 대시보드의 새로운 버전 버전 2.0 이 아래에 표시된 여러 개선 사항과 함께 미리보기를 위해 사용 가능합니다. 이전에 계정 사용 대시보드를 가져온 적이 있다면, 오늘 GitHub 에서 새 버전을 가져와 주세요!

이 대시보드는 다음과 같은 데이터를 포함한 많은 유용한 정보와 시각화를 제공합니다:

• 사용량 개요, 시간에 따른 총 사용량 추세 및 SKU와 작업 공간과 같은 그룹에 의한 강조.
• 선택한 청구 가능한 객체(예: job_id, warehouse_id, cluster_id, endpoint_id 등)에 따른 상위 N 사용량을 순위별로 나열합니다.
• 태그를 기반으로 한 사용 분석(단계 1에서 태그를 많이 붙일수록 이 기능이 더 유용합니다).
• 앞으로 몇 주간과 몇 달간 지출이 어떻게 될지를 나타내는 AI 예측.

대시보드를 통해 날짜 범위, 작업 공간, 제품, 심지어 개인 요금에 대한 사용자 정의 할인까지 필터링할 수 있습니다. 이 대시보드에는 많은 정보가 포함되어 있어 대부분의 비용 보고 요구사항에 대한 주요 원스톱 쇼핑처럼 작동합니다.

작업 모니터링 대시보드

Lakeflow 작업의 경우, 리소스 기반 비용 및 최적화 기회를 빠르게 확인할 수 있는 작업 시스템 테이블 AI/BI 대시보드 를 추천합니다, 예를 들면:

• 월별 잠재적 절약액 상위 25개 작업
• 평균 CPU 사용률이 가장 낮은 상위 10개 작업
• 평균 메모리 사용량이 가장 높은 상위 10개 작업
• 고정 작업자 수를 가진 작업들 최근 30일
• 지난 30일 동안 구식 DBR 버전에서 실행 중인 작업

DBSQL 모니터링

Databricks SQL의 향상된 모니터링을 위해, 우리의 SQL SME 블로그 여기를 참조하십시오. 이 가이드에서, 우리의 SQL 전문가들이 사용자, 출처, 심지어 쿼리 수준 비용까지 볼 수 있는 세분화된 비용 모니터링 대시보드를 오늘 설정하는 방법을 안내해 드릴 것입니다.

모델 제공

마찬가지로, 모델 서빙에 대한 비용을 모니터링하기 위한 전문 대시보드가 있습니다! 이는 배치 추론, 토큰 당 지불 사용, 프로비저닝된 처리량 엔드포인트 등에 대한 더 세밀한 보고에 도움이 됩니다. 자세한 정보는 이 관련 블로그를 참조하세요.

예산 알림

이전에 서버리스 예산 정책에 대해 언급했었는데, 이는 서버리스 컴퓨팅 사용량을 속성 또는 태그로 지정하는 방법입니다. 그러나 Databricks에는 별도의 예산 기능(AWS | Azure | GCP)도 있습니다. 예산은 계정 전체의 지출을 추적하거나, 특정 팀, 프로젝트, 작업 공간의 지출을 추적하기 위해 필터를 적용하는 데 사용할 수 있습니다.

예산을 설정할 때, 예산이 일치해야 하는 작업 공간과/또는 태그를 지정한 다음 금액(USD로)을 설정하고, 예산이 초과되면 수신자 목록에 이메일을 보낼 수 있습니다. 이것은 사용자의 지출이 주어진 금액을 초과했을 때 사용자에게 적극적으로 알림을 주는데 유용할 수 있습니다. 예산이 SKU의 목록 가격을 사용한다는 점을 유의하십시오.

단계 3: 비용 제어

다음으로, 팀은 데이터 팀이 동시에 자립적이고 비용을 의식하는 경계를 설정할 수 있어야 합니다. Databricks는 관리자와 실무자 모두를 위해 이를 단순화합니다. 컴퓨트 정책 (AWS | Azure | GCP)을 참조하세요.

여러 속성들이 컴퓨트 정책으로 제어될 수 있으며, 이에는 모든 클러스터 속성뿐만 아니라 dbu_per_user와 같은 중요한 가상 속성들도 포함됩니다. 비용 제어를 위해 특히 관리해야 할 주요 속성 몇 가지를 살펴보겠습니다:

사용자 당 DBU 제한 및 사용자 당 최대 클러스터 수 제한

종종, 팀을 위해 자체 서비스 클러스터 생성을 가능하게 하는 컴퓨팅 정책을 만들 때, 우리는 그 사용자들의 최대 지출을 제어하려고 합니다. 이것이 비용 제어에 가장 중요한 정책 속성이 적용되는 곳입니다: dbus_per_hour.

dbus_per_hour 는 range 정책 유형과 함께 사용하여 사용자가 생성할 수 있는 클러스터의 DBU 비용에 하한과 상한을 설정할 수 있습니다. 그러나 이것은 정책을 사용하는 클러스터 당 최대 DBU만 강제하므로, 이 정책에 대한 권한이 있는 단일 사용자는 여전히 많은 클러스터를 생성할 수 있고, 각 클러스터는 지정된 DBU 한도에서 제한됩니다.

이를 더 발전시켜, 각 사용자가 무제한의 클러스터를 생성하는 것을 방지하기 위해, 우리는 max_clusters_by_user라는 다른 설정을 사용할 수 있습니다. 이는 실제로 정책 정의에서 찾을 수 있는 속성이 아니라 최상위 컴퓨팅 정책에 대한 설정입니다.

All-Purpose vs. Job 클러스터 제어

정책은 어떤 클러스터 유형에 대해 사용될 수 있는지를 cluster_type 가상 속성을 사용하여 강제해야 합니다. 이는 “all-purpose”, “job”, “dlt” 중 하나가 될 수 있습니다. 정책을 작성할 때 정확히 정책이 설계된 클러스터 유형을 강제하기 위해 fixed 유형을 사용하는 것을 추천합니다:

일반적인 패턴은 작업과 파이프라인에 대한 별도의 정책을 생성하고, 모든 목적의 클러스터에 대해 max_clusters_by_user 를 1로 설정하는 것입니다(예: Databricks의 기본 개인 컴퓨팅 정책이 정의된 방식) 그리고 사용자당 더 많은 클러스터를 허용합니다.

인스턴스 유형 강제

VM 인스턴스 유형은 allowlist 또는 regex 유형으로 편리하게 제어할 수 있습니다. 이를 통해 사용자들은 너무 비싸거나 예산을 초과하는 크기를 선택하지 않으면서 인스턴스 유형에 다소 유연성을 가지고 클러스터를 생성할 수 있습니다.

최신 Databricks 런타임 강제 적용

최신 Databricks 런타임(DBR)을 계속 업데이트하고, 장기 지원(LTS) 릴리스를 고려하는 것이 중요합니다. 컴퓨팅 정책은 spark_version 속성에서 이를 쉽게 강제하기 위한 몇 가지 특별한 값 을 가지고 있으며, 이 중 몇 가지를 알아두는 것이 좋습니다:

• auto:latest-lts: 는 최신 장기 지원(LTS) Databricks 런타임 버전에 매핑됩니다.
• auto:latest-lts-ml: 는 최신 LTS Databricks Runtime ML 버전에 매핑됩니다.
• 또는 auto:latest 와 auto:latest-ml 은 최신 일반적으로 사용 가능한(GA) Databricks 런타임 버전(또는 ML)에 대한 것이며, 이는 LTS가 아닐 수 있습니다.
  • 참고: 이 옵션들은 LTS에 도달하기 전에 최신 기능에 액세스해야 하는 경우 유용할 수 있습니다.

우리는 정책에서 spark_version 을 allowlist 유형을 사용하여 제어하는 것을 권장합니다:

스폿 인스턴스

정책에서는 클라우드 속성도 제어할 수 있으며, 예를 들어 스팟 인스턴스의 인스턴스 가용성을 강제하고 필요에 따라 온디맨드로 전환할 수 있습니다. 스팟 인스턴스를 사용할 때는 항상 "first_on_demand"을 최소 1로 설정하여 클러스터의 드라이버 노드가 항상 온디맨드 상태가 되도록 해야 합니다.

AWS에서:

Azure에서:

GCP에서 (참고: GCP는 현재 first_on_demand 속성을 지원할 수 없습니다):

태깅 강제

앞서 보았듯이, 태깅 은 조직이 비용을 할당하고 세분화된 수준에서 보고하는 능력에 있어 중요합니다. Databricks에서 일관된 태그를 강제하는 데 고려해야 할 두 가지 사항이 있습니다:

1. custom_tags. 를 제어하는 컴퓨트 정책. 속성.
2. 서버리스의 경우, 1단계에서 논의한 대로 Serverless 예산 정책 을 사용하세요.

컴퓨팅 정책에서는 태그 이름을 접미사로 붙여 여러 개의 사용자 정의 태그를 제어할 수 있습니다. 사용자의 수동 입력을 줄이기 위해 가능한 한 많은 고정 태그를 사용하는 것이 권장되지만, 허용 목록은 여러 선택 사항을 허용하면서도 값의 일관성을 유지하는 데 탁월합니다.

웨어하우스에 대한 쿼리 타임아웃

장기 실행 SQL 쿼리는 매우 비용이 많이 들고, 너무 많은 쿼리가 대기열에 들어가면 다른 쿼리를 방해할 수 있습니다. 장기 실행 SQL 쿼리는 대체로 최적화되지 않은 쿼리(불량 필터 또는 필터 없음) 또는 최적화되지 않은 테이블 때문입니다.

관리자는 워크스페이스 수준에서 Statement Timeout 을 설정하여 이를 제어할 수 있습니다. 워크스페이스 수준의 타임아웃을 설정하려면, 워크스페이스 관리 설정으로 이동하여 Compute를 클릭한 다음 SQL 웨어하우스 옆에 있는 Manage를 클릭하세요. SQL 구성 매개변수 설정에서, 시간 초과 값이 초 단위인 구성 매개변수를 추가합니다.

모델 속도 제한

ML 모델과 LLM들도 너무 많은 요청으로 인해 남용될 수 있으며, 예상치 못한 비용이 발생할 수 있습니다. Databricks는 모델 서빙 엔드포인트에서 사용 추적 및 속도 제한을 쉽게 사용할 수 있는 AI Gateway 를 제공합니다.

엔드포인트 전체 또는 사용자별로 비율 제한을 설정할 수 있습니다. 이는 Databricks UI, SDK, API, 또는 Terraform을 사용하여 구성할 수 있습니다; 예를 들어, 우리는 Terraform을 사용하여 비율 제한이 있는 Foundation Model 엔드포인트를 배포할 수 있습니다:

실용적인 컴퓨트 정책 예시

실제 컴퓨트 정책의 예를 더 보려면, 여기에서 우리의 솔루션 가속기를 참조하세요: https://github.com/databricks-industry-solutions/cluster-policy  

단계 4: 비용 최적화

마지막으로, 워크스페이스, 클러스터, 스토리지 계층에서 확인할 수 있는 최적화 방법들을 살펴보겠습니다. 이들 대부분은 자동으로 확인하거나 구현할 수 있으며, 이에 대해 살펴보겠습니다. 여러 최적화는 컴퓨트 수준에서 이루어집니다. 이에는 VM 인스턴스 유형의 적절한 크기 조정, Photon 사용 여부 결정, 적절한 컴퓨트 유형 선택 등의 작업이 포함됩니다.

최적의 리소스 선택

• 모든 목적 대신 작업 컴퓨트를 사용하십시오(다음에 이에 대해 더 깊게 다룰 것입니다).
• 최고의 비용 효율을 위해 SQL 웨어하우스를 SQL 전용 작업에 사용하세요.
• 최신 패치와 성능 향상을 받기 위해 최신 런타임 을 사용하세요. 예를 들어, DBR 17.0은 Spark 4.0(블로그)으로 업그레이드하며, 이는 많은 성능 최적화를 포함합니다.
• 더 빠른 시작, 종료, 그리고 더 나은 총 소유 비용(TCO)을 위해 서버리스를 사용하세요.
• 지속적인 스트리밍이나 AvailableNow 트리거를 사용하지 않는 경우, 자동 스케일링 워커를 사용하세요.
  • 그러나 Lakeflow 선언적 파이프라인의 발전으로 인해 Enhanced Autoscaling이라는 기능 덕분에 스트리밍 워크로드에 대한 자동 스케일링이 잘 작동합니다 (AWS | Azure | GCP).
• 올바른 VM 인스턴스 유형을 선택하세요:
  • 새로운 세대의 인스턴스 유형과 현대 프로세서 아키텍처는 일반적으로 성능이 더 좋고 종종 비용이 더 저렴합니다. 예를 들어, AWS에서는 Databricks가 Graviton이 활성화된 VM들을 선호합니다 (예: c7g.xlarge 대신 c7i.xlarge); 이들은 최대 3배 더 나은 가격 대 성능을 제공할 수 있습니다 (블로그). 
  • 대부분의 ML 작업에 최적화된 메모리. 예를 들어, r7g.2xlarge
  • 스트리밍 작업 부하에 최적화된 컴퓨팅. 예를 들어, c6i.4xlarge
  • 디스크 캐싱에서 이점을 얻는 워크로드(임시 및 대화형 데이터 분석)에 최적화된 스토리지. 예를 들어, i4g.xlarge와 c7gd.2xlarge.
  • GPU 가속 라이브러리를 사용하는 워크로드에만 GPU 인스턴스를 사용하세요. 또한, 분산 훈련을 수행하지 않는 한, 클러스터는 단일 노드여야 합니다.
  • 그 외의 경우는 일반적인 목적으로 사용합니다. 예를 들어, m7g.xlarge.
  • Dev와 Stage와 같은 하위 환경에서 Spot 또는 Spot Fleet 인스턴스를 사용하세요.

모든 목적의 컴퓨팅에서 작업을 실행하는 것을 피하십시오

비용 제어에서 언급했듯이, 클러스터 비용은 작업 계산을 사용하여 자동화된 작업을 실행함으로써 최적화할 수 있습니다. 모든 목적의 계산이 아닙니다. 정확한 가격 은 프로모션과 활성 할인에 따라 달라질 수 있지만, Job Compute는 일반적으로 All-Purpose보다 2-3배 저렴합니다 .

Job Compute는 또한 각각의 작업에 대해 새로운 컴퓨트 인스턴스를 제공하며, 워크로드를 서로 격리시키면서도, 필요한 경우 모든 작업에 대해 컴퓨트 리소스를 재사용할 수 있습니다. 작업용 컴퓨트를 어떻게 구성하는지 보세요 (AWS | Azure | GCP).

Databricks 시스템 테이블을 사용하면, 다음 쿼리를 사용하여 대화형 All-Purpose 클러스터에서 실행 중인 작업을 찾을 수 있습니다. 이는 Jobs System Tables AI/BI Dashboard 의 일부로서, 워크스페이스에 쉽게 가져올 수 있습니다!

모든 목적 클러스터와 연속 작업에 대한 Photon 모니터링

Photon 은 Databricks 데이터 인텔리전스 플랫폼에서 Spark를 위한 최적화된 벡터화 엔진으로, 매우 빠른 쿼리 성능을 제공합니다. Photon은 작업 클러스터의 경우 DBU의 양을 2.9배, 모든 목적의 클러스터의 경우 약 2배 증가시킵니다. DBU 배수에도 불구하고, Photon은 런타임 기간을 줄임으로써 작업에 대한 전체 TCO를 낮출 수 있습니다.

반면에, 대화형 클러스터는 사용자가 명령을 실행하지 않을 때 상당한 양의 유휴 시간이 있을 수 있으므로, 모든 용도의 클러스터가 이 유휴 컴퓨트 비용을 최소화하기 위해 자동 종료 설정을 적용하도록 확인해 주세요. 항상 그런 것은 아니지만, 이로 인해 Photon에서 비용이 더 높아질 수 있습니다. 이는 또한 서버리스 노트북이 매우 적합하게 만들어주며, 이들은 유휴 비용을 최소화하고, 최상의 성능을 위해 Photon으로 실행되며, 몇 초 만에 세션을 시작할 수 있습니다.

마찬가지로, Photon은 24/7 작동하는 연속 스트리밍 작업에 항상 유익하지는 않습니다. Photon을 사용할 때 필요한 작업 노드 수를 줄일 수 있는지 모니터링하세요. 이렇게 하면 TCO가 감소하며, 그렇지 않으면 Photon은 연속 작업에 적합하지 않을 수 있습니다.

참고: 다음 쿼리를 사용하여 Photon으로 설정된 대화형 클러스터를 찾을 수 있습니다:

데이터 저장 및 파이프라인 최적화

여기에서 다룰 수 있는 데이터, 저장, Spark 최적화 전략이 너무 많습니다. 다행히도, Databricks는 이를 Databricks, Spark 및 Delta Lake 작업 최적화를 위한 종합 가이드에 모아 놓았습니다. 이 가이드에는 데이터 레이아웃과 왜곡부터 델타 병합 최적화까지 모든 것이 포함되어 있습니다. 또한 Databricks는 성능 최적화를 위한 팁이 더 많이 담긴 데이터 엔지니어링 대서 를 제공합니다.

실제 세계 응용 프로그램

조직의 모범 사례

조직 구조와 소유권의 모범 사례는 우리가 다음으로 다룰 기술 솔루션만큼 중요합니다.

Databricks 플랫폼을 포함한 고도로 효과적인 FinOps 실천을 운영하는 디지털 네이티브들은 일반적으로 조직 내에서 다음을 우선 순위로 두고 있습니다:

• 플랫폼 관리 및 모니터링에 대한 명확한 소유권을 유지하세요.
• 프로젝트 전, 중, 후의 솔루션 비용 고려.
• 지속적인 개선 문화–항상 최적화 중.

이들은 FinOps에 가장 성공적인 조직 구조 중 일부입니다:

• 중앙집중식 (예: 우수성 센터, 허브 앤 스포크)
  • 이는 FinOps와 정책, 제어, 도구를 다른 팀에 배포하는 중앙 플랫폼 또는 데이터 팀의 형태를 취할 수 있습니다.
• 하이브리드 / 분산 예산 센터
  • 중앙 집중형 모델을 다른 도메인 특정 팀으로 분산시킵니다. 그 도메인/팀에 대해 위임된 하나 이상의 관리자가 있을 수 있으며, 이는 대규모 플랫폼 및 FinOps 실천과 지역화된 프로세스 및 우선 순위를 조정합니다.

우수성 센터 예시

우수성 센터는 핵심 플랫폼 관리를 중앙화하고, 정책 및 번들 템플릿과 같은 안전하고 재사용 가능한 자산으로 사업 부문을 강화하는 등 많은 이점이 있습니다.

우수성 센터는 종종 데이터 플랫폼, 플랫폼 엔지니어, 또는 데이터 운영 팀과 같은 팀을 중심, 또는 "허브"로 두는 허브-스포크 모델을 사용합니다. 이 팀은 사용 대시보드를 사용하여 비용을 할당하고 보고하는 책임이 있습니다. 팀에게 최적화되고 비용을 고려한 자체 서비스 환경을 제공하기 위해, 플랫폼 팀은 사용 사례와/또는 사업 부문("스포크")에 맞게 컴퓨트 정책과 예산 정책을 만들어야 합니다. 필수는 아니지만, 강력한 일관성, 버전 관리, 그리고 모듈화 기능을 위해 이러한 아티팩트를 Terraform과 VCS로 관리하는 것을 권장합니다.

주요 학습 내용

이것은 Databricks와 함께 비용을 통제하는 데 도움이 될 수 있는 상당히 철저한 가이드였으므로, 우리는 그 과정에서 여러 가지를 다루었습니다. 요약하면, 크롤-워크-런 여정은 다음과 같습니다: 

1. 비용 속성
2. 비용 보고서
3. 비용 제어
4. 비용 최적화

마지막으로, 가장 중요한 핵심 내용을 몇 가지 요약하면 다음과 같습니다:

• 탄탄한 태깅은 모든 좋은 비용 할당 및 보고의 기초입니다. 고품질 태그를 강제하기 위해 컴퓨트 정책 을 사용하십시오.
• Databricks 지출을 보고하고 예측하는 주요 정거장인 사용 대시보드 를 가져옵니다.
• 비용 절약 기회를 찾고 모니터링하기 위해 작업 시스템 테이블 AI/BI 대시보드 를 가져옵니다.
• 클러스터 생성에 대한 비용 제어와 자원 제한을 강제하기 위해 컴퓨팅 정책 을 사용하세요.

다음 단계

오늘 시작하고 첫 번째 컴퓨팅 정책을 만들거나, 우리의 정책 예제 중 하나를 사용하세요. 그런 다음, 사용량 대시보드 를 주요 보고 및 예측 Databricks 지출로 가져옵니다. 이전에 공유한 단계 3에서 클러스터, 작업 공간, 데이터에 대한 최적화를 체크하십시오. 이전에 공유한 단계 3에서 클러스터, 작업 공간, 데이터에 대한 최적화를 체크하십시오.

Databricks Delivery Solutions Architects (DSAs) 는 조직 전반의 데이터 및 AI 이니셔티브를 가속화합니다. 그들은 아키텍처 리더십을 제공하고, 플랫폼의 비용과 성능을 최적화하며, 개발자 경험을 향상시키고, 성공적인 프로젝트 실행을 주도합니다. DSAs는 초기 배포와 생산 수준의 솔루션 사이의 간극을 메우며, 데이터 엔지니어링, 기술 리드, 임원, 그리고 다른 이해관계자를 포함한 다양한 팀과 긴밀하게 협력하여 맞춤형 솔루션과 더 빠른 가치 창출을 보장합니다. DSA로부터 맞춤형 실행 계획, 전략적 지도, 그리고 데이터 및 AI 여정 동안의 지원을 받기 위해, Databricks 계정 팀에게 연락해 주세요.

 

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