Databricks에서 비용 관리 모범 사례
이 블로그는 Databricks 환경을 관리하고 유지 관리하는 데 중요한 주제에 초점을 맞출 관리자 필수 시리즈의 일부입니다. 추가 주제에 대한 추가 블로그를 계속 지켜봐 주시고, 작업 공간 및 관리자 모범 사례에 대한 이전 블로그를 참조하세요!
클라우드 플랫폼을 사용하는 주요 이점 중 하나는 유연성입니다. Databricks Lakehouse Platform은 사용자에게 거의 즉각적이고 수평적으로 확장 가능한 컴퓨팅에 쉽게 액세스할 수 있도록 제공합니다. 그러나 이러한 컴퓨팅 리소스 생성의 용이성으로 인해 관리되지 않고 안전 장치가 없으면 클라우드 비용이 급증할 위험이 있습니다. 관리자로서 우리는 과도한 인프라 비용을 피하는 것과 동시에 사용자가 불필요한 마찰 없이 작업할 수 있도록 하는 것 사이의 완벽한 균형을 맞추려고 노력합니다. 이 블로그에서는 사용자 생산성을 저해하지 않고 비용을 제어하면서 이 균형을 찾기 위한 Databricks 관리자 도구에 대해 논의합니다.
DBU란 무엇인가요?
Databricks 플랫폼에서 사용 가능한 비용 제어에 대해 자세히 알아보기 전에 워크로드를 실행하는 비용의 기본을 이해하는 것이 중요합니다. DBU(Databricks Unit)는 플랫폼 내에서 소비의 기본 단위입니다. SQL Warehouse를 제외하고 DBU 소비량은 해당 클러스터의 일부인 노드 수와 기본 VM 인스턴스 유형의 컴퓨팅 성능을 기반으로 합니다(SQL 웨어하우스는 본질적으로 클러스터 그룹이므로 DBU 속도는 엔드포인트를 구성하는 클러스터의 DBU 속도 합계입니다). 가장 높은 수준에서 각 클라우드는 유사한 클러스터에 대해 약간 다른 DBU 속도를 갖지만(노드 유형이 클라우드마다 다르므로), Databricks 웹사이트에는 지원되는 각 클라우드 공급자(AWS | Azure | GCP)에 대한 DBU 계산기가 있습니다.
DBU 사용량을 달러 금액으로 변환하려면 클러스터의 DBU 속도와 해당 DBU를 생성한 워크로드 유형(예: 자동화된 작업, 범용 컴퓨팅, Delta Live Tables, SQL 컴퓨팅, 서버리스 컴퓨팅) 및 구독 요금제 등급(Azure 및 GCP의 표준 및 프리미엄, AWS의 표준, 프리미엄 및 엔터프라이즈)이 필요합니다. 예를 들어, 엔터프라이즈 Databricks 작업 공간은 AWS에서 작업 DBU 목록 속도가 20센트/DBU입니다. 3 DBU/시간으로 실행되는 인스턴스 유형을 사용하면 4개 노드 작업 클러스터는 1시간 동안 2.40달러(0.2달러 * 3 * 4)가 청구됩니다. DBU 계산기를 사용하여 총 요금을 계산할 수 있으며 목록 가격은 SKU 및 등급을 포함한 클라우드별 매트릭스에 요약되어 있습니다(AWS | Azure | GCP).
비용은 컴퓨팅 리소스, 특히 클러스터 사용량을 통해 계산되므로 클러스터 정책을 통해 Databricks 작업 공간을 관리하는 것이 매우 중요합니다. 다음 섹션에서는 클러스터 정책의 다양한 속성이 DBU 소비를 제한하고 플랫폼 비용을 효과적으로 관리하는 방법을 논의합니다. 이어지는 섹션에서는 고려해야 할 기본 클라우드 비용과 Databricks 사용량 및 청구 방법을 모니터링하는 방법을 검토합니다.
클러스터 정책을 통한 비용 관리
클러스터 정책이란 무엇인가요?
클러스터 정책을 통해 관리자는 새 클러스터를 만들 때 사용 가 능한 구성 집합을 제어할 수 있으며, 이러한 정책은 개별 사용자 또는 사용자 그룹에 할당할 수 있습니다. 기본적으로 모든 사용자는 작업 공간 내에서 "무제한 클러스터 생성 허용" 권한을 갖습니다. 이 권한은 할당된 정책 외부에서 사용자가 제약 없이 클러스터를 생성할 수 있도록 하여 관리되지 않고 통제 불능 상태의 비용으로 이어질 수 있으므로 거의 사용되지 않아야 합니다.
정책 내에서 관리자는 변경할 수 없는 고정 값, 더 허용적인 값 범위 및 정규식 또는 완전히 열린 기본값을 통해 각 구성 설정을 제한할 수 있습니다. 정책은 VM 인스턴스 유형과 같은 더 세분화된 설정부터 시간당 최대 DBU 또는 클러스터 워크로드 유형과 같은 더 높은 수준의 "합성" 속성에 이르기까지 모든 것에 대한 제한을 통해 단일 클러스터에서 소비할 수 있는 DBU 양을 효과적으로 제한합니다.
처음에는 더 제한적인 클러스터가 비용을 절감한다고 생각할 수 있지만 항상 그런 것은 아닙니다. 매우 제한적인 정책은 클러스터가 제 시간에 작업을 완료하지 못하게 하여 장기 실행 작업으로 인한 비용이 더 많이 발생합니다. 따라서 클러스터 정책을 공식화할 때 사용 사례 기반 접근 방식을 취하여 팀에 워크로드에 적합한 컴퓨팅 성능을 제공하는 것이 필수적입니다. 이를 돕기 위해 Databricks는 최적화된 Apache Spark(™) 런타임 및 특히 Photon 엔진과 같은 성능 기능을 제공하여 처리 시간 단축을 통한 비용 절감을 주도합니다. 런타임 정책은 나중에 섹션에서 논의하겠지만 먼저 수평 확장을 관리하는 정책부터 시작하겠습니다.
노드 수 제한, 자동 확장 및 자동 종료
컴퓨팅 비용과 관련하여 흔히 발생하는 문제는 활용도 가 낮거나 유휴 상태인 클러스터입니다. Databricks는 직접적인 사용자 개입 없이 이러한 문제를 동적으로 완화하기 위해 자동 확장 및 자동 종료 기능을 제공합니다. 이러한 기능은 사용자에게 제공되는 컴퓨팅 리소스에 지장을 주지 않고 정책을 통해 시행할 수 있습니다.
노드 수 제한 및 자동 확장
정책은 클러스터 자동 확장 기능이 설정된 최소 작업자 노드 수로 활성화되도록 강제할 수 있습니다. 예를 들어, 아래와 같은 정책은 자동 확장이 사용되도록 하고 사용자가 최대 10개의 작업자 노드를 가진 클러스터를 가질 수 있도록 허용하지만 필요할 때만 가능합니다.
최대 작업자 수에 대한 시행 유형이 "범위"이므로 생성 중에 10보다 작은 값으로 변경할 수 있습니다. 그러나 최소 작업자 수는 "고정"으로 하나로 설정되므로 클러스터가 활용도가 낮을 때 항상 하나의 작업자로 축소되어 컴퓨팅 비용을 절감할 수 있습니다. 여기에 표시된 추가 필드는 "기본값"으로, 이름에서 알 수 있듯이 클러스터 구성 페이지에서 최대 작업자 수의 기본값을 설정합니다. 이는 기본적으로 클러스터의 최대 작업자 수를 줄이는 데 도움이 되므로 생성자가 10개 노드로 확장하도록 의도적으로 허용해야 합니다.
정책을 만들고 할당할 때 사용 사례를 이해하는 것은 노드 수 제한 및 자동 확장을 시행해야 하는지 여부에 매우 중요합니다. 예를 들어, 자동 확장을 시행하는 것은 다음과 같은 경우에 잘 작동합니다.
- 공유 범용 컴퓨팅 클러스터: 팀은 애드혹 분석 및 실험 작업 또는 머신 러닝 워크로드를 위해 하나의 클러스터를 공유할 수 있습니다.
- 다양한 복잡성을 가진 장기 실행 배치 작업: 작업은 필요한 리소스 정도에 따라 클러스터를 확장하기 위해 자동 확장을 활용할 수 있습니다.
자동 확장을 사용하는 작업은 클러스터 확장으로 인해 노드 시작 시간으로 인해 완료가 지연될 수 있으므로 시간 민감하지 않아야 합니다. 이를 완화하려면 가능한 경우 인스턴스 풀을 사용하세요.
표준 스트리밍 워크로드는 과거에는 자동 크기 조정의 이점을 누리지 못했습니다. 작업이 진행되는 동안 노드 수가 최대치로 늘어난 후 그대로 유지되었기 때문입니다. 이러한 유형의 워크로드를 다루는 팀에게 더 프로덕션 수준에 적합한 옵션은 Delta Live Tables와 향상된 자동 크기 조정(DLT 워크로드는 이 블로그의 뒷부분에서 설명할 "cluster_type" 정책으로 강제 적용 가능)을 활용하는 것입니다. DLT는 스트리밍 워크로드를 염두에 두고 개발되었지만, 대상 테이블의 증분 업데이트를 허용하는 Trigger.AvailableNow 옵션을 활용하면 배치 파이프라인에도 동일하게 적용할 수 있습니다.
클러스터 크기 조정 정책의 또 다른 일반적인 구성은 단일 노드 정책입니다. 단일 노드 클러스터는 플랫폼을 탐색하려는 신규 사용자, 분산되지 않은 ML 라이브러리를 활용하는 데이터 과학 팀, 그리고 간단한 탐색적 데이터 분석이 필요한 사용자에게 유용할 수 있습니다. 단일 노드 클러스터 정책 예시에 나와 있듯이, 정책은 특정 인스턴스 풀을 활용하도록 제한할 수 있습니다. 따라서 이 정책이 할당된 팀은 풀의 최대 용량 설정에 따라 생성할 수 있는 단일 노드 클러스터 수에 제한이 있습니다.
자동 종료
Databricks 플랫폼 내에서 클러스터를 생성할 때 설정할 수 있는 또 다른 속성은 자동 종료 시간으로, 설정된 유휴 시간 후에 클러스터를 종료합니다. 유휴 시간은 Spark 작업, Structured Streaming 또는 JDBC 호출과 같은 클러스터 활동이 없는 상태로 정의됩니다. 클러스터 활동으로 간주되지 않는 활동은 클러스터에 SSH 연결을 생성하고 bash 명령을 실행하는 것입니다.
가장 일반적인 자동 종료 시간은 1시간입니다. 예를 들어, 고정된 1시간 창으로 설정된 정책은 다음과 같습니다.
이 예시에서는 "hidden" 속성이 이 컨트롤에 추가되어 사용자의 클러스터 구성 페이지에서 위젯을 숨깁니다. 이 속성은 모든 목적 클러스터에만 적용되며, 작업 및 DLT 클러스터는 할당된 모든 작업이 완료되면 자동으로 종료됩니다.
클러스터 런타임 및 Photon
Databricks 런타임은 Databricks에서 성능 최적화의 중요한 부분입니다. 고객은 구성을 크게 변경하지 않고도 최신 런타임에서 실행되는 클러스터로 전환하여 자동 이점을 얻는 경우가 많습니다. 클러스터 정책을 만드는 관리자는 최신 런타임을 실행하는 효과에 대해 클러스터 생성자에게 교육하는 것이 비용 절감에 중요합니다. 사용자가 최신 런타임으로 이동함에 따라 이전 런타임은 단계적으로 폐지되고 정책을 통해 제한될 수 있습니다. 빠른 예시로, 사용자를 11.0 또는 11.1 버전의 DB 런타임으로만 제한하는 "spark_version" 속성은 다음과 같습니다.
하지만 이 정책은 허용 목록을 확장하거나 정규식을 사용하여 다른 버전, ML 런타임, Photon 런타임 또는 GPU 런타임을 허용함으로써 더 유연하게 만들 수 있습니다.
비용 절감을 위해 성능을 최적화할 때 고려해야 할 또 다른 런타임 기능은 벡터화된 Photon 엔진 사용입니다. Photon은 벡터화된 Spark 엔진을 통해 워크로드의 일부를 지능적으로 가속화하며, 이를 통해 고객은 성능이 3배에서 8배까지 향상되는 것을 볼 수 있습니다. 성능의 이러한 대폭적인 향상은 작업 완료 시간을 단축하고 결과적으로 총 비용을 절감합니다.
클라우드 인스턴스 유형 및 스팟 인스턴스
클러스터 생성 중 드라이버 노드와 워커 노드 모두에 대해 VM 인스턴스 유형을 별도로 선택할 수 있습니다. 사용 가능한 각 인스턴스 유형은 서로 다른 DBU 요율을 가지며, 각 클라우드( AWS, Azure, GCP)의 Databricks 가격 책정 추정 페이지에서 확인할 수 있습니다. 예를 들어, AWS에서는 2개의 코어와 8GB 메모리를 가진 m4.large 인스턴스 유형이 시간당 0.4 DBU를 소비하는 반면, 64개의 코어와 256GB 메모리를 가진 m4.16xlarge 인스턴스 유형은 모든 목적 컴퓨팅 모드에서 시간당 12 DBU를 소비합니다. 컴퓨팅 리소스 간 DBU 사용량의 범위가 매우 넓기 때문에 정책을 통해 이 속성을 제한하는 것이 중요합니다.
클라우드 인스턴스 유형은 "allowlist" 유형 또는 "fixed" 유형을 사용하여 가장 편리하게 제어할 수 있으며, 후자는 단일 유형의 인스턴스만 사용하도록 허용합니다. 아래 예시는 사용자에게 사용 가능한 워커 노드 유형에 대한 정책을 설정하는 "node_type_id" 속성과 드라이버 노드 유형에 대한 정책을 설정하는 "driver_node_type_id" 속성을 보여줍니다.
관리자로서 이러한 정책을 만들 때 각 팀이 실행하는 워크로드 유형을 파악하고 적절한 정책을 할당하는 것이 중요합니다. 적은 양의 데이터를 처리하는 워크로드는 낮은 메모리 인스턴스 유형만 필요로 하는 반면, 딥러닝 모델을 훈련하는 것은 일반적으로 더 많은 DBU를 소비하는 GPU 클러스터에서 가장 큰 이점을 얻을 것입니다. 궁극적으로 인스턴스 유형을 제한하는 것은 균형 잡힌 접근 방식이 필요합니다. 팀이 정책 제한으로 인해 사용 가능한 리소스보다 더 많은 리소스가 필요한 워크로드를 실행해야 하는 경우, 작업 완료 시간이 길어져 비용이 증가할 수 있습니다. 정의된 워크로드를 위해 클러스터를 구성할 때 따라야 할 모범 사례가 있습니다. 예를 들어, 많은 와이드 변환과 데이터 셔플링이 필요한 복잡한 워크로드의 경우 수평 확장(노드 추가)보다 수직 확장(더 강력한 인스턴스 유형 사용)이 권장됩니다. 그렇긴 하지만, 경험이 적은 팀에게는 불필요하게 강력한 VM이 일반적인 복잡하지 않은 워크로드에 큰 이점을 제공하지 않으므로 더 작은 인스턴스 유형으로 제한된 정책을 할당해야 합니다.
Databricks 플랫폼의 비교적 새로운 비용 절감 기능 중 하나는 Arm64 명령어 세트 아키텍처를 기반으로 구축된 AWS Graviton 지원 VM을 사용할 수 있다는 것입니다. AWS에서 제공한 연구와 Photon을 사용하여 Databricks에서 실행한 벤치마크에 따르면, 이러한 Graviton 지원 인스턴스는 AWS EC2 인스턴스 유형 세트에서 최고의 가격 대비 성능 비율을 제공합니다.
스팟 인스턴스
Databricks는 스팟 인스턴스(GCP의 Databricks에서 사용 가능한 옵션은 스팟 인스턴스와 유사한 선점형 인스턴스를 사용)를 통해 기본 VM 컴퓨팅 비용을 절감할 수 있는 또 다른 구성을 제공합니다. 스팟 인스턴스는 기본 클라우드 제공업체가 제공하는 예비 VM으로, 실시간 마켓플레이스에서 입찰됩니다. 이러한 인스턴스는 최대 90%까지 인스턴스 컴퓨팅 비용을 절감할 수 있는 가파른 할인을 가능하게 합니다. 스팟 인스턴스의 단점은 짧은 통지 기간(AWS의 경우 2분, Azure 및 GCP의 경우 30초)으로 기본 클라우드 제공업체에 의해 언제든지 회수될 수 있다는 것입니다.
AWS를 사용하는 경우, 스팟 인스턴스 사용을 포함하는 클러스터 정책을 다음과 같이 정의할 수 있습니다.
Azure의 경우:
이 예시들에서는 클러스터 생성 초기에 노드 하나(특히 드라이버 노드)만 온디맨드 인스턴스가 될 수 있으며, 클러스터 내의 다른 모든 노드는 스팟 인스턴스가 됩니다. 여기서는 대체 옵션이 활성화되어 있으므로, 클라우드 제공업체에 반환된 스팟 인스턴스를 대체하기 위해 온디맨드 인스턴스가 요청됩니다. GCP의 정책은 현재 "first_on_demand" 속성을 강제할 수 없지만, 선점형 노드는 다음과 같이 여전히 강제할 수 있습니다.
기본적으로 선점형 인스턴스가 활성화된 경우 클러스터 시작 시 드라이버 노드만 온디맨드 인스턴스를 사용합니다.
실험 워크로드 또는 임시 쿼리와 같이 안정성과 워크로드 지속 시간이 우선순위가 아닌 내결함성 프로세스를 실행할 때 스팟 인스턴스를 사용하면 인스턴스 비용을 쉽게 절감할 수 있습니다. 따라서 스팟 인스턴스는 개발 및 스테이징 환경에 가장 적합합니다.
스팟 인스턴스 중단율과 가격은 티셔츠 사이즈 및 클라우드 리전에 따라 다를 수 있습니다. 따라서 최적의 클러스터 구성을 계획하는 데는 AWS Spot Instance Advisor, Azure 계정 포털의 Azure Spot Pricing and History 또는 Google Cloud Pricing Calculator와 같은 각 클라우드 제공업체의 도구를 활용할 수 있습니다.
Azure에는 비용 제어에 대한 추가적인 방법이 있다는 점에 유의하세요. Databricks는 예약 인스턴스를 사용하여 추가적인 (잠재적으로 상당한) 할인을 제공하면서도 불안정성을 추가하지 않을 수 있습니다.
클러스터 태깅
팀에서 활용하는 리소스를 관찰하는 기능은 클러스터 태깅을 통해 가능합니다. 이러한 태그는 클라우드 제공업체 수준까지 전파되어 Databricks 플랫폼과 기본 클라우드 비용 모두에서 사용량 및 비용을 추적할 수 있습니다. 그러나 클러스터 정책이 없으면 클러스터를 생성하는 사용자는 태그를 할당할 필요가 없습니다. 따라서 관리자가 Databricks 플랫폼에 대한 액세스를 요청하는 팀을 위해 정책을 만들 때, 정책이 할당될 팀에 특정한 클러스터 태그 적용을 포함하는 것이 중요합니다.
다음은 사용자 지정 비용 센터 태그를 적용하는 정책을 만드는 한 가지 예입니다.
클러스터를 사용하는 팀을 식별하는 태그가 할당되면 관리자는 사용량 로그를 분석하여 생성된 DBU 및 비용을 클러스터를 활용하는 팀에 연결할 수 있습니다. 이러한 태그는 VM 사용량 수준까지 전파되어 클라우드 제공업체 인스턴스 비용도 팀 또는 비용 센터에 연결될 수 있습니다. 사용량 로그 모니터링에 대한 일반적인 옵션은 아래 섹션에서 논의됩니다.
클러스터 풀을 사용할 때 클러스터 태그에 대한 중요한 차이점은 클러스터 풀 태그 (클러스터 태그가 아님)만 기본 VM 인스턴스로 전파된다는 것입니다. 클러스터 풀 생성은 클러스터 정책에 의해 제한되지 않으므로 관리자는 팀에 사용 권한을 할당하기 전에 적절한 태그로 클러스터 풀을 만들어야 합니다. 그러면 팀은 클러스터를 만들 때 해당 풀에 연결할 수 있는 정책을 통해 액세스할 수 있습니다. 이렇게 하면 풀을 사용하는 팀과 관련된 태그가 청구를 위해 VM 인스턴스 수준까지 전파되도록 보장합니다.
정책 가상 속성
클러스터 구성 페이지에 표시되는 설정 외에도 정책으로 제한할 수 있는 "가상" 속성도 있습니다. 이 범주에서 사용할 수 있는 두 가지 속성은 "dbus_per_hour" 및 "cluster_type"입니다.
"dbus_per_hour" 속성을 사용하면 클러스터 생성자는 DBU 사용량이 정책에 설정된 제한보다 낮게 유지되는 한 구성에 대한 유연성을 가질 수 있습니다. 이 속성 자체는 이전에 논의된 속성처럼 기본 VM 인스턴스에 대한 비용을 직접 제한하지는 않습니다 (DBU 요금이 VM 인스턴스 요금과 상관관계가 있는 경우가 많음). 다음은 사용자가 시간당 10 DBU 미만을 사용하는 클러스터를 생성하도록 제한하는 정책 예시입니다.
사용 가능한 다른 가상 속성은 "cluster_type"으로, 사용자가 다양한 유형의 클러스터에서 제한하도록 활용할 수 있습니다. 이 속성을 통해 허용되는 유형은 "all-purpose", "job" 및 "dlt"이며, 마지막은 Delta Live Tables를 참조합니다. 다음은 이 정책을 사용하는 예시입니다.
클러스터 유형 제한은 개발 및 배포 수명주기 전반에 걸쳐 참여하는 서로 다른 팀과 작업할 때 특히 유용합니다. 새로운 ETL 또는 머신러닝 파이프라인 개발에 참여하는 팀은 일반적으로 모든 용도 클러스터에만 액세스해야 하는 반면, 배포 엔지니어링 팀은 작업 클러스터 또는 Delta Live Tables(DLT)를 사용합니다. 이러한 정책은 개발 및 배포 수명주기의 각 특정 단계에 대해 올바른 클러스터 유형을 사용하도록 보장하여 모범 사례를 시행할 수 있습니다.
일반적인 잘못된 관행은 모든 용도 클러스터를 공유하는 자동화된 워크로드를 배포하는 것입니다. 처음에는 단일 클러스터로 사용량을 추적할 수 있으므로 더 저렴한 옵션처럼 보일 수 있습니다. 그러나 이러한 유형의 구성은 클러스터가 실행되어야 하는 시간을 연장하여 컴퓨팅 비용을 증가시키는 리소스 경합을 유발합니다. 대신, 한 번에 하나의 작업을 실행하도록 격리된 작업 클러스터를 사용하면 일련의 작업을 완료하는 데 필요한 컴퓨팅 시간이 단축됩니다. 이렇게 하면 Databricks DBU 사용량과 기본 클라우드 인스턴스 비용이 모두 절감됩니다. 더 나은 성능과 작업 클러스터가 제공하는 DBU당 더 낮은 비용 비율은 상당한 비용 절감으로 이어집니다. 저희는 고객들이 워크로드의 10%만 모든 용도 클러스터에서 작업 클러스터로 이동하는 것만으로도 수만 달러를 절약하는 것을 보았습니다. 작업 클러스터 재사용은 각 작업 간 의 클러스터 시작 시간을 제거하여 일련의 작업의 적시 완료를 보장하는 데 활용될 수 있습니다.
팀이 올바른 워크로드를 위해 클러스터를 생성할 수 있도록 정책을 공식화하기 위해 따라야 할 모범 사례가 있습니다. 일반적인 제한 정책 패턴으로는 단일 노드 클러스터, 작업 전용 클러스터 또는 팀이 공유할 수 있는 자동 확장 모든 용도 클러스터가 있습니다. 전체 정책 예시는 여기에서 찾을 수 있습니다.
클라우드 제공업체 비용
Databricks 사용량 관점(DBU)에서 모든 비용은 활용된 컴퓨팅 리소스에 연결될 수 있습니다. 그러나 기본 클라우드의 네트워크 및 스토리지에 대한 비용도 고려해야 합니다.
스토리지
Databricks와 같은 플랫폼을 사용하는 이점은 Azure의 ADLS Gen2, AWS의 S3 또는 GCP의 GCS와 같이 상대적으로 저렴한 클라우드 스토리지와 원활하게 작동한다는 것입니다. 이는 특히 Delta Lake 형식을 사용할 때 유리한데, 관리하기 어려운 스토리지 계층에 대한 데이터 거버넌스를 제공하고 Databricks와 함께 사용할 때 성능 최적화를 제공하기 때문입니다.
스토리지와 관련하여 흔히 발생하는 잘못된 최적화는 가능한 경우 수명 주기 관리를 무시하는 것입니다. 최근 사례에서 우리는 고객 S3 버킷이 약 2.5PB였으며, 그 중 약 800TB만이 실제 데이터였 습니다. 나머지 1.7PB는 가치가 없는 버전 관리된 데이터였습니다. 오래된 객체를 클라우드 스토리지에서 제거하는 것은 일반적인 모범 사례이지만, Delta Vacuum 주기와 일치시키는 것이 중요합니다. 스토리지 수명 주기가 Delta에서 진공 처리되기 전에 객체를 제거하면 테이블이 손상될 수 있습니다. 더 광범위하게 구현하기 전에 프로덕션이 아닌 데이터에 수명 주기 정책을 테스트해야 합니다. 예시 정책은 다음과 같을 수 있습니다.
S3의 Glacier 또는 ADLS의 Archive와 같은 비표준 스토리지 계층은 Databricks에서 지원되지 않으므로 해당 계층이 사용되기 전에 Vacuum을 실행해야 합니다.
네트워킹
Databricks 플랫폼 내에서 사용되는 데이터는 데이터 웨어하우스부터 Kafka와 같은 스트리밍 시스템에 이르기까지 다양한 소스에서 나올 수 있습니다. 그러나 가장 일반적인 대역폭 사용자는 S3 또는 ADLS와 같은 스토리지 계층에 쓰는 것입니다. 네트워크 비용을 줄이기 위해 Databricks 워크스페이스는 리전 및 가용성 영역 간에 전송되는 데이터 양을 최소화하는 것을 목표로 배포해야 합니다. 여기에는 가능한 경우 데이터의 대다수와 동일한 리전에 배포하는 것이 포함되며, 필요한 경우 리전별 워크스페이스를 시작하는 것이 포함될 수 있습니다.
AWS에서 Databricks 워크스페이스에 고객 관리 VPC를 사용할 때, VPC와 AWS 서비스 간의 연결을 인터넷 게이트웨이나 NAT 장치 없이 가능하게 하는 VPC 엔드포인트를 활용하여 네트워킹 비용을 절감할 수 있습니다. 엔드포인트를 사용하면 네트워크 트래픽으로 발생하는 비용을 줄이고 연결을 더욱 안전하게 만들 수 있습니다. 특히 게이트웨이 엔드포인트는 S3 및 DynamoDB 연결에 사용할 수 있으며, 인터페이스 엔드포인트는 컴퓨팅 인스턴스가 Databricks 제어 영역에 연결하는 비용을 줄이는 데 유사하게 사용할 수 있습니다. 이러한 엔드포인트는 워크스페이스가 보안 클러스터 연결을 사용하는 한 사용할 수 있습니다.
마찬가지로 Azure에서는 NAT 비용을 줄이기 위해 ADLS와 같은 서비스와 통신하도록 Databricks에 Private Link 또는 서비스 엔드포인트를 구성할 수 있습니다. GCP에서는 Private Google Access (PGA)를 활용하여 Google Cloud Storage (GCS)와 Google Container Registry (GCR) 간의 트래픽이 공개 인터넷 대신 Google의 내부 네트워크를 사용하도록 하여 NAT 장치 사용을 우회할 수 있습니다.
서버리스 컴퓨팅
분석 워크로드의 경우, 서버리스 옵션이 활성화된 SQL 웨어하우스를 사용하는 것을 고려해 볼 수 있습니다. 서버리스 SQL을 사용하면 Databricks 플랫폼이 워크로드가 시작될 때마다 사용자에게 할당할 준비가 된 컴퓨팅 인스턴스 풀을 관리합니다. 따라서 기본 인스턴스의 비용은 DBU 컴퓨팅 비용과 기본 클라우드 컴퓨팅 비용의 두 가지 별도 요금이 아닌 Databricks에서 전적으로 관리합니다.
서버리스는 쿼리가 실행될 때 즉시 컴퓨팅 리소스를 제공하여 유휴 클러스터의 비용을 줄임으로써 비용상의 이점을 제공합니다. 마찬가지로 서버리스는 더 정확한 자동 확장을 가능하게 하여 워크로드를 효율적으로 완료할 수 있으며, 결과적으로 성능을 향상시켜 비용을 절감합니다. 서버리스 옵션은 아직 정책을 통해 직접 시행할 수는 없지만, 관리자는 SQL 웨어하우스 생성 권한이 있는 모든 사용자에게 옵션을 활성화할 수 있습니다.
사용량 모니터링
클러 스터 정책 및 워크스페이스 배포 구성을 통해 비용을 제어하는 것 외에도 관리자가 비용을 모니터링할 수 있는 기능이 중요합니다. Databricks는 사용량 분석을 기반으로 알림 및 경고를 자동화하는 기능을 갖춘 몇 가지 옵션을 제공합니다. 특히 관리자는 Databricks 계정 콘솔을 사용하여 빠른 사용량 개요를 확인하고, 사용량 로그를 분석하여 더 세분화된 보기를 얻고, 새로운 예산 API를 사용하여 예산을 초과할 때 활성 알림을 받을 수 있습니다.
계정 콘솔 사용
Databricks Enterprise 2.0 아키텍처를 사용하면 계정 콘솔에 관리자가 DBU 또는 달러 금액별 사용량을 시각적으로 확인할 수 있는 사용량 페이지가 포함됩니다. 차트는 집계 보기, 워크스페이스별 또는 SKU별로 그룹화된 소비량을 표시할 수 있습니다. SKU별로 그룹화하면 작업 클러스터, 모든 용도 클러스터 또는 SQL 컴퓨팅별 사용량이 표시됩니다. 워크스페이스별로 세분화된 경우 DBU 소비량 기준 상위 9개 워크스페이스 그룹과 나머지 워크스페이스의 합계 그룹이 표시됩니다. 각 워크스페이스의 더 세분화된 세부 정보를 개별적으로 이해하려면 페이지 하단에 각 워크스페이스와 SKU별 DBU/$USD 금액을 나열하는 테이블이 있습니다. 이 페이지는 관리자가 계정의 모든 워크스페이스에 걸쳐 사용량과 비용을 전체적으로 파악하는 데 적합합니다.
Databricks는 Azure 플랫폼의 기본 서비스이므로 Azure 비용 관리 도구를 사용하여 (Azure의 다른 모든 서비스와 함께) Databricks 사용량을 모니터링할 수 있습니다. AWS 및 GCP용 Databricks 배포에 대한 계정 콘솔과 달리 Azure 모니터링 기능은 태그 세분화 수준까지 데이터를 제공합니다. Azure의 사용자 지정 태그는 클러스터 수준뿐만 아니라 워크스페이스 수준에서도 생성할 수 있습니다. 이러한 태그는 사용량 데이터를 분석할 때 그룹 및 필터로 표시됩니다. 이러한 보고서 내에서 Databricks 컴퓨팅에서 생성된 사용량은 기본 인스턴스 사용량과 함께 동일한 보기에서 편리하게 표시됩니다. 또한 다음 섹션에서 설명한 대로 더 자동화된 분석 및 알림을 위해 예약에 따라 스토리지 컨테이너로 로그를 전송할 수 있습니다.
관리자는 계정 콘솔 사용량 페이지 또는 계정 API에서 수동으로 사용량 로그를 다운로드할 수 있습니다. 그러나 이러한 사용량 로그를 분석하는 더 효율적인 프로세스는 클라우드 스토리지(AWS, GCP)로 자동화된 로그 전달을 구성하는 것입니다. 이렇게 하면 각 워크스페이스의 사용량이 포함된 일일 CSV가 세분화된 스키마로 생성됩니다.
세 클라우드 중 하나에서 사용량 로그 전달이 구성되면, 일반적인 모범 사례는 Databricks 내에서 데이터 파이프라인을 생성하여 이 데이터를 매일 수집하고 예약된 워크플로를 사용하여 Delta 테이블에 저장하는 것입니다. 그런 다음 이 데이터는 사용량 분석 또는 비용 센터 지출을 책임지는 관리자나 팀 리더에게 소비량이 설정 임계값에 도달했음을 알리는 알림을 트리거하는 데 사용할 수 있습니다.
예산 API
Databricks 컴퓨팅 비용 예산을 더 쉽게 세울 수 있도록 하는 곧 출시될 기능 중 하나는 계정 API 내의 새로운 예산 엔드포인트(현재 비공개 미리 보기)입니다. 이를 통해 Databricks 워크스페이스를 사용하는 누구나 워크스페이스, SKU 또는 클러스터 태그로 필터링된 사용자 지정 기간의 예산 임계값에 도달하면 알림을 받을 수 있습니다. 따라서 이 API를 통해 모든 워크스 페이스, 비용 센터 또는 팀에 대한 예산을 구성할 수 있습니다.
요약
Databricks Lakehouse Platform은 다양한 사용 사례와 사용자 페르소나를 포괄하지만, 관리자가 비용 제어와 사용자 경험의 균형을 맞추는 데 도움이 되는 통합 도구 세트를 제공하는 것을 목표로 합니다. 이 블로그에서는 이러한 균형에 접근하기 위한 몇 가지 전략을 제시했습니다.
- 클러스터 정책을 사용하여 사용자가 클러스터를 생성할 수 있는지 여부와 해당 클러스터의 크기 및 범위를 제어합니다.
- Databricks 워크스페이스에서 발생하는 스토리지 및 네트워킹 비용과 같은 DBU 이외의 비용을 최소화하도록 환경을 설계합니다.
- 모니터링 도구를 사용하여 비용 예상치가 충족되고 효과적인 관행이 마련되었는지 확인합니다.
이 기사 전체에 연결된 다른 관리자 중심 블로그를 확인하고, Private Link(AWS | Azure) 및 예산 책정과 같은 새로운 기능을 사용해 보세요!
(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)