다음을 통해 공유

비용 최적화 모범 사례

  • 아티클

이 문서에서는 원칙별로 구성된 비용 최적화 원칙을 지원하는 모범 사례를 설명합니다.

1. 최적의 리소스 선택

성능 최적화 데이터 형식 사용

Databricks Data Intelligence 플랫폼을 최대한 활용하려면 Delta Lake를 스토리지 프레임워크로 사용해야 합니다. 보다 간단하고 신뢰할 수 있는 ETL 파이프라인을 빌드하는 데 도움이 되며 Parquet, ORC 및 JSON 사용에 비해 워크로드 속도를 크게 높일 수 있는 많은 성능 향상 기능이 제공됩니다. Azure Databricks에 대한 최적화 권장 사항을 참조하세요. 워크로드가 작업 컴퓨팅에서도 실행 중인 경우 이는 컴퓨팅 리소스의 가동 시간이 짧아지면 비용이 절감됩니다.

작업 컴퓨팅 사용

작업은 데이터브릭스 컴퓨팅 인스턴스에서 비대화형 코드를 실행하는 방법입니다. 예를 들어 ETL(추출, 변환 및 로드) 워크로드를 대화형으로 또는 일정에 따라 실행할 수 있습니다. 물론 Notebook UI에서 대화형으로 작업을 실행할 수도 있습니다. 그러나 작업 컴퓨팅에서 비대화형 워크로드는 다목적 컴퓨팅보다 훨씬 적은 비용이 듭니다. 작업 컴퓨팅 및 다목적 컴퓨팅을 비교하려면 가격 책정 개요를 참조하세요.

일부 작업의 추가 이점은 각 작업 또는 워크플로가 새 컴퓨팅 인스턴스에서 실행되어 워크로드를 서로 격리할 수 있다는 것입니다. 그러나 멀티태스크 워크플로는 모든 작업에 컴퓨팅 리소스를 다시 사용할 수 있으므로 컴퓨팅 시작 시간은 워크플로당 한 번만 발생합니다. 작업용 컴퓨팅 구성을 참조하세요.

SQL 워크로드에 SQL Warehouse 사용

대화형 SQL 워크로드의 경우 Databricks SQL Warehouse 는 가장 비용 효율적인 엔진입니다. 가격 책정 개요를 참조하세요. 모든 SQL Warehouse는 기본적으로 Photon과 함께 제공되며, 이는 기존 SQL 및 DataFrame API 호출을 가속화하고 워크로드당 전체 비용을 줄입니다.

또한 서버리스 SQL Warehouse는 많은 수의 쿼리를 빠르고 비용 효율적으로 처리하는 Databricks SQL 서버리스 기능을 향상시키는 기능 집합인 IWM(지능형 워크로드 관리)을 지원합니다.

워크로드에 최신 런타임 사용

Azure Databricks 플랫폼은 데이터 엔지니어링 작업(Databricks 런타임) 또는 기계 학습 작업(Machine Learning용 Databricks 런타임)에 최적화된 다양한 런타임을 제공합니다. 런타임은 작업에 가장 적합한 라이브러리를 제공하고 제공된 모든 라이브러리가 최신 상태이고 최적으로 함께 작동하도록 하기 위해 빌드됩니다. Databricks 런타임은 정기적인 주기로 릴리스되어 주요 릴리스 간에 성능이 향상됩니다. 이러한 성능 향상은 컴퓨팅 리소스의 보다 효율적인 사용으로 인해 비용을 절감하는 경우가 많습니다.

올바른 워크로드에만 GPU 사용

GPU가 있는 가상 머신은 딥 러닝을 위해 계산 속도를 크게 높일 수 있지만 CPU 전용 컴퓨터보다 훨씬 더 비쌉니다. GPU 가속 라이브러리가 있는 워크로드에 대해서만 GPU 인스턴스를 사용합니다.

대부분의 워크로드는 GPU 가속 라이브러리를 사용하지 않으므로 GPU 사용 인스턴스의 이점을 활용하지 않습니다. 작업 영역 관리자는 불필요한 사용을 방지하기 위해 GPU 머신 및 컴퓨팅 리소스를 제한할 수 있습니다. 블로그 포스트 “GPU는 정말 비쌀까요? Databricks 클러스터에서 추론을 위한 GPU 벤치마킹"을 참조하세요.

워크로드에 서버리스 서비스 사용

BI 사용 사례

BI 워크로드는 일반적으로 버스트에서 데이터를 사용하고 여러 동시 쿼리를 생성합니다. 예를 들어 BI 도구를 사용하는 사용자는 대시보드를 업데이트하거나 쿼리를 작성한 다음 플랫폼과의 추가 상호 작용 없이 결과를 분석할 수 있습니다. 이 시나리오에서 데이터 플랫폼은 다음과 같습니다.

  • 유휴 컴퓨팅 리소스를 종료하여 비용을 절감합니다.
  • 사용자가 BI 도구를 사용하여 새 데이터 또는 업데이트된 데이터를 요청할 때 컴퓨팅 리소스를 신속하게 제공합니다.

서버리스가 아닌 Azure Databricks SQL Warehosue의 시작 시간은 몇 분이므로 많은 사용자가 더 높은 비용을 수락하고 유휴 기간 동안 종료하지 않는 경향이 있습니다. 반면에 서버리스 SQL Warehouse는 몇 초 안에 시작 및 확장되므로 즉시 가용성과 유휴 종료를 모두 달성할 수 있습니다. 이렇게 하면 뛰어난 사용자 환경과 전반적인 비용 절감이 가능합니다.

또한 서버리스 SQL Warehouse는 서버리스가 아닌 Warehouse보다 더 일찍 축소되어 비용이 절감됩니다.

ML 및 AI 모델 서비스

대부분의 모델은 웹 또는 클라이언트 애플리케이션에 통합하기 위한 REST API로 제공됩니다. 서비스를 제공하는 모델은 시간이 지남에 따라 다양한 요청을 수신하며, 플랫폼을 제공하는 모델은 항상 충분한 리소스를 제공해야 하지만 실제로 필요한 만큼만 제공해야 합니다(업 스케일링 및 다운스컬링).

Mosaic AI Model Service 는 서버리스 컴퓨팅을 사용하며 모델을 배포하기 위한 고가용성 및 짧은 대기 시간 서비스를 제공합니다. 서비스는 수요 변화에 맞게 자동으로 확장 또는 축소되어 대기 시간 성능을 최적화하면서 인프라 비용을 절감합니다.

올바른 인스턴스 유형 사용

최신 세대의 클라우드 인스턴스 유형을 사용하면 최상의 성능과 최신 기능을 제공하므로 거의 항상 성능 이점이 제공됩니다.

워크로드에 따라 최상의 성능/가격 비율을 얻기 위해 올바른 인스턴스 패밀리를 선택하는 것도 중요합니다. 엄지 손가락의 몇 가지 간단한 규칙은 다음과 같습니다.

  • ML, 무거운 순서 섞기 및 분산 워크로드에 최적화된 메모리
  • 구조적 스트리밍 워크로드 및 유지 관리 작업에 최적화된 컴퓨팅(예: 최적화 및 진공)
  • 임시 및 대화형 데이터 분석과 같은 캐싱의 이점을 활용하는 워크로드에 최적화된 스토리지
  • 특정 ML 및 DL 워크로드에 최적화된 GPU
  • 특정 요구 사항이 없는 경우 범용

가장 효율적인 컴퓨팅 크기 선택

Azure Databricks는 작업자 노드당 하나의 실행기를 실행합니다. 따라서 실행기와 작업자라는 용어는 Azure Databricks 아키텍처의 컨텍스트에서 서로 교환적으로 사용됩니다. 사람들은 종종 작업자 수 측면에서 클러스터 크기를 고려하지만 고려해야 할 다른 중요한 요소가 있습니다.

  • 총 실행기 코어(컴퓨팅): 모든 실행기의 총 코어 수입니다. 이는 컴퓨팅 인스턴스의 최대 병렬 처리를 결정합니다.
  • 총 실행기 메모리: 모든 실행기의 총 RAM 양입니다. 이는 데이터를 디스크로 넘기기 전에 메모리에 저장할 수 있는 데이터의 양을 결정합니다.
  • 실행기 로컬 스토리지: 로컬 디스크 스토리지의 유형 및 양입니다. 로컬 디스크는 무작위 재생 및 캐싱 중 유출의 경우에 주로 사용됩니다.

추가 고려 사항에는 작업자 인스턴스 유형 및 규모도 포함되며, 이는 앞의 요소에 영향을 미칩니다. 컴퓨팅 크기를 조정하는 경우 다음을 고려합니다.

  • 워크로드는 얼마나 많은 데이터를 소비하나요?
  • 워크로드의 컴퓨팅 복잡성은 어느 정도인가요?
  • 어디에서 데이터를 읽고 있나요?
  • 데이터는 외부 스토리지에서 어떻게 분할되나요?
  • 얼마나 많은 병렬 처리가 필요하나요?

세부 정보 및 예제는 컴퓨팅 크기 조정 고려 사항에서 찾을 수 있습니다.

성능 최적화 쿼리 엔진 평가

Photon 은 SQL 워크로드 및 DataFrame API 호출(데이터 수집, ETL, 스트리밍, 데이터 과학 및 대화형 쿼리의 경우)을 가속화하는 고성능 Databricks 네이티브 벡터화된 쿼리 엔진입니다. Photon은 Apache Spark API와 호환되므로 시작하는 것은 코드 변경 및 잠금 없이 켜는 것만큼 쉽습니다.

관찰된 속도 향상은 상당한 비용 절감으로 이어질 수 있으며, 정기적으로 실행되는 작업은 Photon을 사용하여 더 빠르고 저렴할지 여부를 평가해야 합니다.

2. 동적으로 리소스 할당

자동 크기 조정 컴퓨팅 사용

자동 크기 조정을 사용하면 Databricks에서 작업 특성을 고려하여 작업자를 동적으로 다시 할당합니다. 파이프라인의 특정 부분은 다른 부분보다 계산 집약적일 수 있으며, Databricks는 이러한 작업 단계에서 자동으로 추가 작업자를 추가하고 더 이상 필요하지 않은 경우 제거합니다. 자동 스케일링은 정적 크기의 컴퓨팅 인스턴스에 비해 전체 비용을 절감할 수 있습니다.

컴퓨팅 자동 확장은 구조화된 스트리밍 워크로드에 대해 클러스터 크기를 축소할 때 제한이 있습니다. Databricks는 스트리밍 워크로드에 대해 향상된 자동 크기 조정과 함께 Delta Live Tables를 사용하는 것이 좋습니다.

자동 종료 사용

Azure Databricks는 유휴 리소스를 줄이고 컴퓨팅 리소스를 배포할 수 있는 시기를 제어하여 비용을 제어하는 데 도움이 되는 몇 가지 기능을 제공합니다.

  • 모든 대화형 컴퓨팅 리소스에 대한 자동 종료를 구성합니다. 지정된 유휴 시간이 지나면 컴퓨팅 리소스가 종료됩니다. 자동 해지를 참조하세요.
  • 업무 시간 중에만 컴퓨팅이 필요한 사용 사례의 경우 컴퓨팅 리소스를 자동 종료로 구성할 수 있으며, 예약된 프로세스는 사용자가 데스크톱으로 돌아오기 전에 아침에 컴퓨팅을 다시 시작할 수 있습니다(필요한 경우 전전 데이터일 수 있음). CACHE SELECT를 참조하세요.
  • 컴퓨팅 시작 시간이 너무 길면 클러스터 풀을 사용하는 것이 좋습니다. 풀 모범 사례를 참조하세요. Azure Databricks 풀은 유휴 상태의 즉시 사용할 수 있는 인스턴스 집합입니다. 유휴 인스턴스를 사용하여 클러스터 노드를 만들면 클러스터 시작 및 자동 크기 조정 시간이 줄어듭니다. 풀에 유휴 인스턴스가 없는 경우, 풀은 클러스터의 요청을 수용하기 위해 인스턴스 공급자로부터 새 인스턴스를 할당하여 확장합니다.

Azure Databricks은 인스턴스가 풀에서 유휴 상태인 동안 DBU(Databricks 단위)를 청구하지 않으므로 비용을 절감할 수 있습니다. 인스턴스 공급자 요금이 적용됩니다.

컴퓨팅 정책을 사용하여 비용 제어

컴퓨팅 정책은 컴퓨팅 리소스에 대한 많은 비용별 제한을 적용할 수 있습니다. 운영 우수성 - 컴퓨팅 정책 사용을 참조하세요. 예시:

3. 비용 모니터링 및 제어

비용 모니터링

Azure Cost Manager를 사용하여 Azure Databricks 비용을 분석합니다. 컴퓨팅 및 작업 영역 태그도 Azure Cost Manager에 전달됩니다. 비용 특성은 태그 클러스터를 참조하세요.

비용 특성에 대한 태그 클러스터

일반적으로 비용을 모니터링하고 지불 거절을 위해 조직의 비즈니스 단위 및 팀에 Azure Databricks 사용량을 정확하게 할당하기 위해 클러스터, SQL Warehouse 및 풀에 태그를 지정할 수 있습니다. 이러한 태그는 비용 분석을 위해 자세한 DBU(Databricks Units ) 및 클라우드 공급자 VM 및 Blob Storage 사용량으로 전파됩니다.

팀 및 사용 사례에 대한 작업 영역 및 클러스터를 설정할 때 비용 제어 및 특성이 고려되는지 확인합니다. 이렇게 하면 태그 지정이 간소화되고 비용 특성의 정확도가 향상됩니다.

총 비용에는 DBU 가상 머신, 디스크 및 관련 네트워크 비용이 포함됩니다. 서버리스 SQL Warehouse의 경우 DBU 비용에는 이미 가상 머신 및 디스크 비용이 포함됩니다.

Azure Databricks 리소스의 태그는 Azure Portal의 비용 분석 도구에서 사용할 수 있습니다.

추적 및 차지백 비용에 대한 가시성 구현

복잡한 기술 에코시스템을 사용할 때는 미지의 기능을 사전에 이해하는 것이 플랫폼 안정성을 유지하고 비용을 제어하는 데 핵심적인 요소입니다. 관찰성은 생성하는 데이터를 기반으로 시스템을 분석하고 최적화하는 방법을 제공합니다. 이는 알려진 문제를 추적하는 대신 새 패턴을 식별하는 데 중점을 둔 모니터링과 다릅니다.

Databricks는 시스템 카탈로그에 있는 고객 계정 운영 데이터의 Databricks 호스팅 분석 저장소인 시스템 테이블을 사용하여 뛰어난 관찰 기능을 제공합니다. 계정 전체에서 기록 관찰 가능성을 제공하고 플랫폼 원격 분석에 대한 사용자 친화적인 테이블 형식 정보를 포함합니다.

블로그: Databricks에서 비용 최적화 및 안정성 지능적으로 균형 조정을 참조하세요

정기적으로 비용 보고서 공유

월별 비용 보고서를 생성하여 소비 증가 및 변칙을 추적합니다. 클러스터 태그 지정을 사용하여 워크로드를 소유한 팀과 사용 사례 또는 팀을 통해 이러한 보고서를 공유합니다. 이렇게 하면 놀라움을 없애고 비용이 너무 높아질 경우 팀이 워크로드를 사전에 조정할 수 있습니다.

Delta Sharing 송시 비용 모니터링 및 관리

다른 데이터 공유 플랫폼과 달리 Delta Sharing에는 데이터 복제가 필요하지 않습니다. 이 모델에는 많은 장점이 있지만 이는 클라우드 또는 지역에서 데이터를 공유할 때 클라우드 공급업체가 데이터 송신 요금을 부과할 수도 있음을 의미합니다. Delta Sharing 송신 비용 모니터링 및 관리(공급자용)를 참조하여 송신 요금을 모니터링하고 관리하세요.

4. 비용 효율적 워크로드 디자인

Always-On 및 트리거된 스트리밍 균형 조정

일반적으로 스트리밍에 대해 생각할 때 "실시간", "24/7" 또는 "always on"과 같은 용어가 떠오릅니다. 데이터 수집이 실시간으로 발생하는 경우 기본 컴퓨팅 리소스는 24/7을 실행하여 하루 중 1시간마다 비용이 발생해야 합니다.

그러나 연속 이벤트 스트림을 사용하는 모든 사용 사례에서 해당 이벤트를 분석 데이터 집합에 즉시 추가해야 하는 것은 아닙니다. 사용 사례에 대한 비즈니스 요구 사항에 몇 시간 또는 매일 새 데이터만 필요한 경우 해당 요구 사항은 하루에 몇 번만 실행하여 워크로드 비용을 크게 절감할 수 있습니다. Databricks는 짧은 대기 시간 요구 사항이 없는 증분 워크로드에 대해 AvailableNow 트리거와 함께 구조적 스트리밍을 사용하는 것이 좋습니다. 증분 일괄 처리 구성하기를 참조하세요.

주문형 인스턴스와 용량 초과 인스턴스 간의 균형

스폿 인스턴스는 더 낮은 가격으로 사용할 수 있는 클라우드의 과도한 가상 머신 리소스를 활용합니다. 비용을 절감하기 위해 Azure Databricks은 스팟 인스턴스를 사용하여 클러스터를 만들 수 있도록 지원합니다. Databricks는 첫 번째 인스턴스(Spark 드라이버)가 항상 주문형 가상 머신이어야 한다고 권장합니다. 스폿 인스턴스는 클라우드 공급자가 하나 이상의 스폿 인스턴스를 제거했으므로 더 오래 걸릴 수 있는 워크로드에 적합합니다.