다음을 통해 공유

운영 우수성에 대한 모범 사례

  • 아티클

이 문서에서는 다음 섹션에 나열된 아키텍처 원칙에 따라 구성된 운영 우수성의 모범 사례를 설명합니다.

1. 빌드 및 릴리스 프로세스 최적화

전용 Lakehouse 운영 팀 만들기

일반적인 모범 사례는 데이터 팀이 하나 이상의 데이터 플랫폼에서 작업할 수 있도록 플랫폼 운영 팀을 만드는 것입니다. 이 팀은 내부적으로 청사진 및 모범 사례를 만들 책임이 있습니다. 인프라 자동화 및 셀프 서비스 액세스와 같은 도구를 제공하고 보안 및 규정 준수 요구 사항을 충족하는지 확인합니다. 이렇게 하면 중앙 팀에서 플랫폼 데이터를 보호해야 하는 부담이 있으므로 분산된 팀이 데이터 작업에 집중하고 새로운 인사이트를 생성하는 데 집중할 수 있습니다.

엔터프라이즈 SCM(소스 코드 관리) 사용

SCM(소스 코드 관리)을 사용하면 개발자가 보다 효과적으로 작업할 수 있으므로 릴리스 속도가 빨라지고 개발 비용이 절감될 수 있습니다. 변경 내용을 추적하고, 코드 무결성을 유지하고, 버그를 검색하고, 이전 버전으로 롤백하는 데 도움이 되는 도구를 사용하는 것은 전체 솔루션 아키텍처의 중요한 구성 요소입니다.

Databricks Git 폴더 를 사용하면 사용자가 Git 리포지토리에 Notebook 또는 기타 파일을 저장할 수 있으며, 리포지토리 복제, 커밋 및 푸시, 끌어오기, 분기 관리 및 파일 차이 보기와 같은 기능을 제공합니다. 더 나은 코드 표시 유형 및 추적을 위해 Git 폴더를 사용합니다.

DevOps 프로세스 표준화(CI/CD)

CI/CD(지속적인 통합 및 지속적인 업데이트)는 자동화된 파이프라인을 사용하여 짧고 빈번한 주기로 소프트웨어를 개발하고 배포하는 것을 의미합니다. 이는 수십 년 동안 전통적인 소프트웨어 엔지니어링에서 유비쿼터스되어 온 새로운 프로세스는 아니지만 데이터 엔지니어링 및 데이터 과학 팀에 점점 더 필요한 프로세스가 되고 있습니다. 데이터 제품이 유용하려면 적시에 제공되어야 합니다. 또한 소비자는 이러한 제품 내 결과의 유효성에 대한 확신을 가져야 합니다. 개발 팀은 코드를 빌드, 테스트 및 배포하는 프로세스를 자동화하여 여전히 많은 데이터 엔지니어링 및 데이터 과학 팀을 지배하는 수동 프로세스보다 릴리스를 더 자주 안정적으로 제공할 수 있습니다. Azure Databricks에서 CI/CD란?을 참조하세요.

Databricks Git 폴더를 사용하는 코드 개발 모범 사례에 대한 자세한 내용은 Git 및 Databricks Git 폴더(Repos)를 사용하는 CI/CD 기술을 참조하세요. Databricks REST API와 함께 GitHub 작업, Azure DevOps 파이프라인 또는 Jenkins 작업을 사용하여 자동화된 배포 프로세스를 만들 수 있습니다.

MLOps 프로세스 표준화

MLOps 프로세스는 ML 파이프라인의 재현성을 제공하여 데이터 팀 간에 보다 긴밀하게 결합된 협업을 가능하게 하고, devops 및 IT와의 충돌을 줄이고, 릴리스 속도를 가속화합니다. MLops 프로세스를 표준화하면 주요 비즈니스 의사 결정을 내리는 데 많은 모델이 사용되기 때문에 모델을 일관되고 안정적으로 개발, 테스트 및 배포할 수 있습니다.

ML 모델 빌드 및 배포는 복잡합니다. 이를 위해 사용할 수 있는 많은 옵션이 있지만 잘 정의된 표준에는 거의 없습니다. 그 결과 지난 몇 년 동안 MLOps(기계 학습 작업)가 등장했습니다. MLOps는 ML 시스템의 성능 안정성과 장기적인 효율성을 개선하기 위해 모델, 데이터 및 코드를 관리하기 위한 프로세스 및 자동화 집합입니다. 데이터 준비, EDA(예비 데이터 분석), 기능 엔지니어링, 모델 학습, 모델 유효성 검사, 배포 및 모니터링을 다룹니다.

Databricks 플랫폼 의 MLOps는 ML(기계 학습) 시스템의 성능 및 장기 효율성을 최적화하는 데 도움이 될 수 있습니다.

  • 비즈니스 목표를 항상 염두에 두세요. 비즈니스에서 ML의 핵심 목적은 데이터 기반 의사 결정 및 제품을 사용하도록 설정하는 것과 마찬가지로, MLOps의 핵심 목적은 데이터 기반 애플리케이션이 안정적으로 유지되고, 최신 상태로 유지되고, 비즈니스에 긍정적인 영향을 계속 미치는 것입니다. MLOps에서 기술 작업의 우선 순위를 지정하는 경우 비즈니스 영향을 고려합니다. 새 비즈니스 사용 사례를 사용할 수 있나요? 데이터 팀의 생산성이 향상됩니까? 운영 비용 또는 위험을 줄이나요?
  • 특수하지만 열린 도구를 사용하여 ML 모델 관리: ML 모델 수명 주기를 위해 설계된 MLflow를 사용하여 ML 모델을 추적하고 관리할 수 있습니다. MLflow를 사용하여 ML 수명 주기 관리를 참조하세요.
  • 모듈식으로 MLOps 구현: 모든 소프트웨어 애플리케이션과 마찬가지로 ML 애플리케이션의 경우 코드 품질이 가장 중요합니다. 모듈화된 코드를 사용하면 개별 구성 요소를 테스트할 수 있으며 향후 코드 리팩터링으로 인해 발생하는 어려움을 완화할 수 있습니다. 명확한 단계(예: 학습, 평가 또는 배포), 슈퍼 단계(예: 학습-배포 파이프라인) 및 ML 애플리케이션의 모듈식 구조를 명확히 하는 책임을 정의합니다.

Databricks ebook The Big Book of MLOps에 자세히 설명되어 있습니다.

환경 격리 전략 정의

조직에서 Databricks와 같은 데이터 플랫폼을 사용하는 경우 환경(예: 개발 및 프로덕션) 또는 조직 운영 단위 간에 데이터 격리 경계가 필요한 경우가 많습니다.

격리 표준은 조직에 따라 다를 수 있지만 일반적으로 다음과 같은 기대치가 포함됩니다.

  • 사용자는 지정된 액세스 규칙에 따라 데이터에만 액세스할 수 있습니다.
  • 데이터는 지정된 사용자 또는 팀에서만 관리할 수 있습니다.
  • 데이터는 스토리지에서 물리적으로 구분됩니다.
  • 지정된 환경에서만 데이터에 액세스할 수 있습니다.

Databricks에서 작업 영역은 기본 데이터 처리 환경이며 별도의 작업 영역이 전체 설정을 개선하는 몇 가지 시나리오가 있습니다. 예를 들면 다음과 같습니다.

  • 작업 영역 관리자를 공유하지 않고 Databricks의 자산이 사업부 간에 의도치 않게 공유되지 않도록 하려면 고유한 작업 영역으로 다른 사업부를 격리합니다.
  • 소프트웨어 개발 수명 주기 환경(예: 개발, 스테이징 및 프로덕션)을 격리합니다. 예를 들어 별도의 프로덕션 작업 영역을 사용하면 프로덕션에 적용하기 전에 새 작업 영역 설정을 테스트할 수 있습니다. 또는 프로덕션 환경에는 개발 환경보다 더 엄격한 작업 영역 설정이 필요할 수 있습니다. 다른 가상 네트워크에 개발, 스테이징 및 프로덕션 환경을 배포해야 하는 경우 세 가지 환경에 대해 다른 작업 영역도 필요합니다.
  • 리소스 제한을 극복하기 위해 작업 영역을 분할합니다. 클라우드 계정/구독에는 리소스 제한이 있습니다. 작업 영역을 다른 구독/계정으로 분할하는 것은 각 작업 영역에 충분한 리소스를 사용할 수 있도록 하는 한 가지 방법입니다. 또한 Databricks 작업 영역에는 리소스 제한 사항도 있습니다. 작업 영역을 분할하면 각 작업 영역의 워크로드가 항상 전체 리소스 집합에 액세스할 수 있습니다.

그러나 다음과 같이 고려해야 하는 공유 작업 영역에는 몇 가지 단점이 있습니다.

  • Notebook 협업은 작업 영역에서 작동하지 않습니다.

  • 여러 작업 영역의 경우 설치 및 유지 관리를 모두 완전히 자동화해야 합니다(Terraform, ARM, REST API 또는 기타 수단을 통해). 이는 마이그레이션을 위해 특히 중요합니다.

  • 각 작업 영역을 네트워크 계층에서 보호해야 하는 경우(예: 데이터 반출로부터 보호하기 위해) 필요한 네트워크 인프라는 특히 많은 작업 영역의 경우 매우 비쌀 수 있습니다.

격리의 필요성과 협업의 필요성과 이를 유지하는 데 필요한 노력 사이의 균형을 찾는 것이 중요합니다.

엔터프라이즈에 대한 카탈로그 전략 정의

조직은 환경 격리 전략과 함께 메타데이터와 데이터를 구조화하고 분리하기 위한 전략이 필요합니다. 개인 식별 정보, 지불 또는 건강 정보를 포함한 데이터는 잠재적 위험이 높으며, 데이터 위반의 위협이 계속 증가함에 따라 어떤 조직 전략을 선택하든 중요한 데이터를 분리하고 보호하는 것이 중요합니다. 중요한 데이터를 논리적 및 물리적으로 중요하지 않은 데이터와 분리합니다.

조직은 특정 유형의 데이터를 클라우드 테넌트에 있는 특정 계정 또는 버킷에 저장하도록 요구할 수 있습니다. Unity 카탈로그 메타스토어를 사용하면 메타데이터를 3개 수준 catalog > schema > tables/views/volumes 네임스페이스로 구성할 수 있으며, 이러한 요구 사항을 충족하도록 메타스토어, 카탈로그 또는 스키마 수준에서 스토리지 위치가 구성됩니다.

조직 및 규정 준수 요구 사항은 특정 환경에서만 특정 데이터를 유지하도록 규정하는 경우가 많습니다. 프로덕션 데이터를 개발 환경에서 격리하거나 특정 데이터 집합과 도메인이 병합되지 않도록 할 수도 있습니다. Databricks에서 작업 영역은 기본 컴퓨팅 환경이며 카탈로그는 기본 데이터 도메인입니다. 관리자와 카탈로그 소유자는 Unity 카탈로그 메타스토어를 사용하여 카탈로그를 특정 작업 영역에 바인딩할 수 있습니다. 이러한 환경 인식 바인딩은 사용자에게 부여된 특정 데이터 개체 권한에 관계없이 특정 카탈로그만 작업 영역 내에서 사용할 수 있도록 하는 데 도움이 됩니다.

이러한 항목에 대한 전체 토론은 Unity 카탈로그 모범 사례를 참조 하세요.

2. 배포 및 워크로드 자동화

배포 및 유지 관리를 위해 IaC(Infrastructure as Code) 사용

IaC(Infrastructure as Code)를 사용하면 개발자와 운영 팀이 하드웨어 디바이스, 운영 체제, 애플리케이션 및 서비스를 수동으로 구성하는 대신 리소스를 자동으로 관리, 모니터링 및 프로비전할 수 있습니다.

HashiCorp Terraform은 여러 클라우드 공급자에서 안전하고 예측 가능한 클라우드 인프라를 만들기 위한 인기 있는 오픈 소스 도구입니다. Databricks Terraform 공급자는 유연하고 강력한 도구를 사용하여 Azure Databricks 작업 영역 및 관련 클라우드 인프라를 관리합니다. Databricks Terraform 공급자의 목표는 모든 Azure Databricks REST API를 지원하여 데이터 플랫폼을 배포하고 관리하는 가장 복잡한 측면의 자동화를 지원하는 것입니다. Databricks Terraform 공급자는 클러스터 및 작업을 안정적으로 배포 및 관리하고, Azure Databricks 작업 영역을 프로비전하고, 데이터 액세스를 구성하는 데 권장되는 도구입니다.

컴퓨팅 구성 표준화

컴퓨팅 환경을 표준화하면 모든 환경에서 동일한 소프트웨어, 라이브러리 및 구성이 사용됩니다. 이러한 일관성을 통해 환경을 통해 결과를 보다 쉽게 재현하고, 문제를 디버그하고, 시스템을 유지 관리할 수 있습니다. 표준화된 환경을 통해 팀은 환경을 처음부터 구성하고 설정할 필요가 없도록 하여 시간과 리소스를 절약할 수 있습니다. 또한 수동 설치 중에 발생할 수 있는 오류 및 불일치의 위험을 줄입니다. 표준화를 사용하면 모든 환경에서 일관된 보안 정책 및 사례를 구현할 수 있습니다. 이를 통해 조직은 위험을 더 잘 관리하고 규정 요구 사항을 준수할 수 있습니다. 마지막으로, 표준화를 통해 조직은 낭비를 줄이고 리소스 사용률을 최적화하여 비용을 더 효율적으로 관리할 수 있습니다.

표준화는 환경 설정과 지속적인 리소스 관리를 모두 포함합니다. 일관된 설정을 위해 Databricks는 인프라를 코드로 사용하는 것이 좋습니다. 시간이 지남에 따라 시작된 컴퓨팅 리소스가 일관되게 구성되도록 하려면 컴퓨팅 정책을 사용합니다. Databricks 작업 영역 관리자는 정책 규칙 집합에 따라 사용자 또는 그룹의 컴퓨팅 생성 권한을 제한할 수 있습니다. Spark 구성 설정을 적용하고 클러스터 범위 라이브러리 설치를 적용할 수 있습니다. 컴퓨팅 정책을 사용하여 프로젝트의 티셔츠 크기 클러스터(S, M, L)를 표준 작업 환경으로 정의할 수도 있습니다.

작업에 자동화된 워크플로 사용

작업에 대한 자동화된 워크플로를 설정하면 작업을 만들고 배포하는 DevOps 프로세스를 통해 불필요한 수동 작업을 줄이고 생산성을 향상시킬 수 있습니다. 데이터 인텔리전스 플랫폼은 다음 두 가지 방법을 제공합니다.

  • Databricks 워크플로:

    Databricks 워크플로는 Databricks Data Intelligence 플랫폼의 데이터 처리, 기계 학습 및 분석 파이프라인을 오케스트레이션합니다. Databricks 플랫폼과 통합된 완전히 관리되는 오케스트레이션 서비스입니다.

    • Databricks 작업은 Databricks 작업 영역에서 데이터 처리 및 분석 애플리케이션을 실행하는 방법입니다. 작업은 단일 작업 또는 복잡한 종속성이 있는 대규모 다중 작업 워크플로일 수 있습니다. Databricks는 모든 작업에 대한 작업 오케스트레이션, 클러스터 관리, 모니터링 및 오류 보고를 관리합니다.
    • Delta Live Tables 는 안정적이고 유지 관리 가능하며 테스트 가능한 데이터 처리 파이프라인을 빌드하기 위한 선언적 프레임워크입니다. 데이터에 대해 수행하려는 변환을 정의하고 Delta Live Tables는 작업 오케스트레이션, 클러스터 관리, 모니터링, 데이터 품질 및 오류 처리를 관리합니다.

  • 외부 오케스트레이터:

    포괄적인 Azure Databricks REST API는 외부 오케스트레이터가 Databricks 자산, Notebook 및 작업을 오케스트레이션하는 데 사용됩니다. 참조

Databricks의 모든 작업 종속성에 Databricks 워크플로를 사용하고 필요한 경우 이러한 캡슐화된 워크플로를 외부 오케스트레이터에 통합하는 것이 좋습니다.

자동화된 파일 및 이벤트 기반 파일 수집 사용

이벤트 기반(일정 기반) 파일 수집에는 효율성, 향상된 데이터 새로 고침 및 실시간 데이터 수집을 비롯한 몇 가지 이점이 있습니다. 이벤트가 발생할 때만 작업을 실행하면 리소스를 낭비하지 않으므로 비용을 절감할 수 있습니다.

자동 로더는 클라우드 스토리지에 도착할 때 새 데이터 파일을 증분하고 효율적으로 처리합니다. JSON, CSV, PARQUET, AVRO, ORC, TEXT 및 BINARYFILE과 같은 많은 파일 형식을 수집할 수 있습니다. 클라우드 스토리지에 입력 폴더를 사용하면 자동 로더가 도착하는 새 파일을 자동으로 처리합니다.

일회성 수집의 경우 대신 명령을 COPY INTO 사용하는 것이 좋습니다.

데이터 파이프라인에 ETL 프레임워크 사용

ETL 작업을 수동으로 수행할 수 있지만 프레임워크를 사용하는 경우 많은 이점이 있습니다. 프레임워크는 ETL 프로세스에 일관성과 반복성을 제공합니다. 프레임워크는 미리 빌드된 함수 및 도구를 제공하여 일반적인 작업을 자동화하여 시간과 리소스를 절약할 수 있습니다. ETL 프레임워크는 대량의 데이터를 처리할 수 있으며 필요에 따라 쉽게 확장 또는 축소할 수 있습니다. 이렇게 하면 리소스를 보다 쉽게 관리하고 변화하는 비즈니스 요구에 대응할 수 있습니다. 많은 프레임워크에는 기본 제공 오류 처리 및 로깅 기능이 포함되어 있어 문제를 보다 쉽게 식별하고 해결할 수 있습니다. 또한 데이터가 데이터 웨어하우스 또는 데이터 레이크에 로드되기 전에 특정 표준을 충족하는지 확인하기 위해 데이터 품질 검사 및 유효성 검사를 포함하는 경우가 많습니다.

Delta Live Tables는 안정적이고 유지 관리 가능하며 테스트 가능한 데이터 처리 파이프라인을 빌드하기 위한 선언적 프레임워크입니다. 데이터에 대해 수행하려는 변환을 정의하고 Delta Live Tables는 작업 오케스트레이션, 클러스터 관리, 모니터링, 데이터 품질 및 오류 처리를 처리합니다.

Delta Live Tables를 사용하면 SQL 또는 Python에서 엔드 투 엔드 데이터 파이프라인을 정의할 수 있습니다. 데이터의 데이터 원본, 변환 논리 및 대상 상태를 지정합니다. Delta Live Tables는 종속성을 유지하고 작업을 실행할 인프라를 자동으로 결정합니다.

데이터 품질을 관리하기 위해 Delta Live Tables는 시간에 따른 데이터 품질 추세를 모니터링하고 미리 정의된 오류 정책을 사용하여 유효성 검사 및 무결성 검사를 통해 잘못된 데이터가 테이블에 입력되지 않도록 방지합니다. 델타 라이브 테이블이란?을 참조하세요.

ML 워크로드에 대한 배포 코드 접근 방식 따르기

코드 및 모델은 종종 소프트웨어 개발 단계를 통해 비동기적으로 진행됩니다. 두 가지 방법으로 이 작업을 수행할 수 있습니다.

  • 배포 코드: ML 프로젝트는 개발 환경에서 코딩되고 이 코드는 테스트되는 스테이징 환경으로 이동됩니다. 테스트에 성공하면 프로젝트 코드가 실행되는 프로덕션 환경에 배포됩니다.
  • 모델 배포: 모델 학습은 개발 환경에서 실행됩니다. 그런 다음, 프로덕션 환경에 모델을 배포하기 전에 생성된 모델 아티팩트가 모델 유효성 검사를 위해 스테이징 환경으로 이동됩니다.

모델 배포 패턴을 참조 하세요.

Databricks는 대부분의 사용 사례에 대한 배포 코드 접근 방식을 권장합니다. 이 모델의 주요 이점은 다음과 같습니다.

  • 이는 Git 및 CI/CD 시스템과 같은 친숙한 도구를 사용하여 기존의 소프트웨어 엔지니어링 워크플로에 적합합니다.
  • 잠긴 환경에서 자동화된 재학습을 지원합니다.
  • 프로덕션 환경에서만 prod 학습 데이터에 대한 읽기 액세스 권한이 있어야 합니다.
  • 학습 환경을 완전히 제어하여 재현성을 간소화할 수 있습니다.
  • 이를 통해 데이터 과학 팀은 모듈식 코드 및 반복 테스트를 사용하여 대규모 프로젝트의 조정 및 개발을 지원할 수 있습니다.

Databricks ebook The Big Book of MLOps에 자세히 설명되어 있습니다.

모델 레지스트리를 사용하여 코드 및 모델 수명 주기 분리

모델 수명 주기는 코드 수명 주기에 일대일로 일치하지 않으므로 Unity 카탈로그를 사용하면 호스트된 MLflow 모델 레지스트리 버전에서 ML 모델의 전체 수명 주기를 관리할 수 있습니다. Unity 카탈로그 의 모델은 작업 영역에서 중앙 집중식 액세스 제어, 감사, 계보 및 모델 검색을 포함하여 Unity 카탈로그의 이점을 ML 모델로 확장합니다. Unity 카탈로그의 모델은 오픈 소스 MLflow Python 클라이언트와 호환됩니다.

ML 실험 추적 자동화

ML 실험 추적은 각 실험에 대한 관련 메타데이터를 저장하고 실험을 구성하는 프로세스입니다. 이 메타데이터에는 실험 입력/출력, 매개 변수, 모델 및 기타 아티팩트가 포함됩니다. 실험 추적의 목표는 ML 모델 개발 프로세스의 모든 단계에서 재현 가능한 결과를 만드는 것입니다. 이 프로세스를 자동화하면 실험 수를 더 쉽게 스케일링할 수 있으며 모든 실험에서 캡처된 메타데이터의 일관성을 보장합니다.

Databricks 자동 로깅 은 MLflow 자동 로깅을 확장하여 Azure Databricks에서 기계 학습 학습 세션에 대한 자동 실험 추적을 제공하는 코드 없는 솔루션입니다. Databricks 자동 로깅은 MLflow 추적 실행으로 기록된 학습 실행을 사용하여 모델을 학습할 때 모델 매개 변수, 메트릭, 파일 및 계보 정보를 자동으로 캡처합니다.

동일한 인프라를 다시 사용하여 ML 파이프라인 관리

ML 파이프라인에 사용되는 데이터는 일반적으로 다른 데이터 파이프라인에 사용되는 데이터와 동일한 원본에서 가져옵니다. ML 및 데이터 파이프라인은 둘 다 비즈니스 사용자 분석 또는 모델 학습을 위해 데이터를 준비한다는 측면에서 비슷합니다. 또한 둘 다 확장 가능하고 안전하며 적절하게 모니터링되어야 합니다. 두 경우 모두 사용되는 인프라는 이러한 활동을 지원해야 합니다.

Databricks Terraform 공급자를 사용하여 ML 환경의 배포를 자동화합니다. ML을 사용하려면 유추 작업, 서비스 엔드포인트 및 기능화 작업과 같은 인프라를 배포해야 합니다. 모든 ML 파이프라인은 작업을 사용하는 워크플로로 자동화할 수 있으며, 많은 데이터 중심 ML 파이프라인은 보다 특수화된 자동 로더를 사용하여 이미지 및 기타 데이터 및 델타 라이브 테이블을 수집하여 기능을 컴퓨팅하거나 메트릭을 모니터링할 수 있습니다.

ML 모델의 엔터프라이즈급 배포에 모델 서비스를 사용해야 합니다.

복잡한 데이터 및 ML 프로젝트에 선언적 관리 활용

MLOps 내의 선언적 프레임워크를 통해 팀은 대략적인 용어로 원하는 결과를 정의하고 시스템에서 실행 세부 정보를 처리하여 ML 모델의 배포 및 크기를 간소화할 수 있습니다. 이러한 프레임워크는 지속적인 통합 및 배포를 지원하고, 테스트 및 인프라 관리를 자동화하며, 모델 거버넌스 및 규정 준수를 보장하여 궁극적으로 출시 시간을 단축하고 ML 수명 주기 전반에 걸쳐 생산성을 향상합니다.

DAB(Databricks Asset Bundles )는 Databricks 플랫폼에 대한 복잡한 데이터, 분석 및 ML 프로젝트의 개발을 간소화하기 위한 도구입니다. 번들을 사용하면 단일 간결하고 선언적인 YAML 구문을 사용하여 소프트웨어 개발 워크플로에서 CI/CD 기능을 제공하여 활성 개발 중에 복잡한 프로젝트를 쉽게 관리할 수 있습니다. 번들을 사용하여 프로젝트의 테스트, 배포 및 구성 관리를 자동화하면 조직 전체에서 소프트웨어 모범 사례를 템플릿 프로젝트로 승격하면서 오류를 줄일 수 있습니다.

3. 용량 및 할당량 관리

서비스 제한 및 할당량 관리

서비스 제한 및 할당량을 관리하는 것은 잘 작동하는 인프라를 유지하고 예기치 않은 비용을 방지하는 데 중요합니다. 클라우드에서 시작된 모든 서비스는 액세스 속도 제한, 인스턴스 수, 사용자 수 및 메모리 요구 사항과 같은 제한을 고려해야 합니다. 클라우드 공급자의 경우 클라우드 제한을 확인 합니다. 솔루션을 디자인하기 전에 이러한 제한을 이해해야 합니다.

특히 Databricks 플랫폼의 경우 다음과 같은 다양한 유형의 제한이 있습니다.

Databricks 플랫폼 제한: Azure Databricks 리소스에 대한 특정 제한입니다. 전체 플랫폼에 대한 제한은 리소스 제한에 설명되어 있습니다.

Unity 카탈로그 제한:Unity 카탈로그 리소스 할당량

구독/계정 할당량: Azure Databricks는 해당 서비스에 클라우드 리소스를 활용합니다. 예를 들어 Azure Databricks의 워크로드는 Databricks 플랫폼이 클라우드 공급자의 VM(가상 머신)을 시작하는 클러스터에서 실행됩니다. 클라우드 공급자는 동시에 시작할 수 있는 VM 수에 대한 기본 할당량을 설정합니다. 필요에 따라 이러한 할당량을 조정해야 할 수 있습니다.

자세한 내용은 VM 제품군 vCPU 할당량 증가를 참조 하세요.

비슷한 방식으로 스토리지, 네트워크 및 기타 클라우드 서비스에는 이해하고 고려해야 하는 제한 사항이 있습니다.

용량 계획에 투자

용량 계획에는 비용을 최적화하면서 성능을 유지하기 위해 스토리지, 컴퓨팅 및 네트워킹과 같은 클라우드 리소스를 관리하는 작업이 포함됩니다. 갑작스런 비즈니스 변화 또는 세계 이벤트를 포함하여 다양한 이유로 발생할 수 있는 예상 부하의 변화를 계획합니다. 예기치 않은 변형을 포함하여 부하 변형을 테스트하여 워크로드의 크기를 조정할 수 있는지 확인합니다. 한 지역이 실패할 경우 모든 지역이 전체 부하를 지원할 수 있도록 충분히 확장할 수 있는지 확인합니다. 고려할 사항은 다음과 같습니다.

  • 기술 및 서비스 제한 사항 및 클라우드 제약 조건. 용량 및 할당량 관리를 참조 하세요.
  • 디자인에 사용할 서비스를 결정하는 SLA입니다.
  • 비용이 증가하면 애플리케이션에서 얼마나 많은 개선이 실현되는지를 결정하는 비용 분석입니다. 가격이 투자 가치가 있는지 여부를 평가합니다.

높은 우선 순위(볼륨) 이벤트에 대한 이해와 계획이 중요합니다. 프로비전된 클라우드 리소스가 충분하지 않고 워크로드의 크기를 조정할 수 없는 경우 이러한 볼륨 증가로 인해 중단이 발생할 수 있습니다.

4. 모니터링, 경고 및 로깅 설정

모니터링 프로세스 설정

데이터 플랫폼에 대한 모니터링 프로세스를 설정하는 것은 여러 가지 이유로 중요합니다. 모니터링 프로세스를 사용하면 데이터 품질 문제, 성능 병목 상태 및 시스템 오류와 같은 문제를 조기에 검색할 수 있으므로 가동 중지 시간 및 데이터 손실을 방지할 수 있습니다. 데이터 플랫폼의 비효율성을 식별하고 낭비를 줄이고 리소스 사용률을 개선하여 비용을 최적화할 수 있습니다. 또한 모니터링 프로세스는 규정 요구 사항을 준수하고 데이터 액세스 및 사용량에 대한 감사 내역을 제공하는 데 도움이 될 수 있습니다.

플랫폼 모니터링에 네이티브 및 외부 도구 사용

Databricks Data Intelligence 플랫폼에는 기본 제공 모니터링 솔루션이 있으며 외부 모니터링 시스템을 통합합니다.

  • Azure 모니터링 솔루션을 사용한 플랫폼 모니터링

    모니터링은 모든 프로덕션 수준 솔루션에 중요하며, Azure Databricks는 사용자 지정 애플리케이션 메트릭, 스트리밍 쿼리 이벤트 및 애플리케이션 로그 메시지를 모니터링하기 위한 강력한 기능을 제공합니다. Azure Databricks는 이 모니터링 데이터를 여러 로깅 서비스로 보낼 수 있습니다. 다음 문서에서는 Azure Databricks에서 Azure를 위한 모니터링 데이터 플랫폼인 Azure Monitor로 모니터링 데이터를 보내는 방법을 보여줍니다.

  • Databricks Lakehouse 모니터링

    Databricks Lakehouse 모니터링 을 사용하면 계정의 모든 테이블에서 데이터의 통계 속성과 품질을 모니터링할 수 있습니다. 데이터 품질 모니터링은 시간에 따른 데이터 일관성을 추적하고 확인하는 정량적 측정값을 제공하며, 데이터 배포 및 모델 성능의 변화를 사용자를 식별하고 경고하는 데 도움이 됩니다. 모델 입력 및 예측을 포함하는 유추 테이블을 모니터링하여 기계 학습 모델의 성능을 추적할 수도 있습니다.

    Lakehouse 모니터링 비용을 이해하려면 레이크하우스 모니터링 비용 보기를 참조하세요.

  • SQL 웨어하우스 모니터링

    SQL 웨어하우스 모니터링은 시간이 지남에 따라 부하 프로필을 이해하고 SQL 웨어하우스를 효율적으로 관리하는 데 필수적입니다. SQL 웨어하우스 모니터링을 사용하면 웨어하우스에서 처리하는 쿼리 수 또는 웨어하우스에 할당된 클러스터 수와 같은 정보를 볼 수 있습니다.

  • Databricks SQL 경고

    Databricks SQL 경고는 정기적으로 쿼리를 실행하고, 정의된 조건을 평가하고, 조건이 충족되면 알림을 보냅니다. 보고된 데이터가 예상 한도를 벗어나면 비즈니스를 모니터링하고 알림을 보내도록 경고를 설정할 수 있습니다.

또한 모니터 메트릭 테이블의 메트릭을 기반으로 Databricks SQL 경고를 만들어 통계가 특정 범위를 벗어나거나 기준 테이블과 비교하여 데이터가 드리프트된 경우 알림을 받을 수 있습니다.

  • 자동 로더 모니터링

    자동 로더는 스트림의 상태를 검사하기 위한 SQL API를 제공합니다. SQL 함수를 사용하면 자동 로더 스트림에서 검색된 파일에 대한 메타데이터를 찾을 수 있습니다. 자동 로더 모니터링을 참조하세요.

    Apache Spark 스트리밍 쿼리 수신기 인터페이스를 사용하면 자동 로더 스트림을 추가로 모니터링할 수 있습니다.

  • 작업 모니터링

    작업 모니터링은 오류, 지연 또는 성능 병목 상태와 같은 Databricks 작업의 문제를 식별하고 해결하는 데 도움이 됩니다. 작업 모니터링은 작업 성능에 대한 인사이트를 제공하여 리소스 사용률을 최적화하고 낭비를 줄이며 전반적인 효율성을 향상시킬 수 있습니다.

  • 델타 라이브 테이블 모니터링

    모든 Delta Live Tables 파이프라인에 대해 이벤트 로그가 만들어지고 유지 관리됩니다. 이벤트 로그에는 감사 로그, 데이터 품질 검사, 파이프라인 진행률 및 데이터 계보를 포함하여 파이프라인과 관련된 모든 정보가 포함됩니다. 이벤트 로그를 사용하여 데이터 파이프라인의 상태를 추적, 이해 및 모니터링할 수 있습니다.

  • 스트리밍 모니터링

    스트리밍은 수집 및 분석을 위한 가장 중요한 데이터 처리 기술 중 하나입니다. 사용자와 개발자에게 분석 및 트리거 작업을 위한 짧은 대기 시간 및 실시간 데이터 처리 기능을 제공합니다. Databricks Data Intelligence 플랫폼을 사용하면 구조적 스트리밍 쿼리를 모니터링할 수 있습니다.

  • ML 및 AI 모니터링

    프로덕션 워크플로에서 모델의 성능을 모니터링하는 것은 AI 및 ML 모델 수명 주기의 중요한 측면입니다. 유추 테이블 은 엔드포인트를 제공하는 Databricks 모델의 요청 입력 및 응답(예측)을 지속적으로 로깅하고 Unity 카탈로그의 델타 테이블에 저장하여 모델에 대한 모니터링 및 진단을 간소화합니다. 그런 다음 DBSQL 쿼리, Notebook 및 Lakehouse 모니터링과 같은 Databricks 플랫폼의 모든 기능을 사용하여 모델을 모니터링, 디버그 및 최적화할 수 있습니다.

    모니터링 모델 제공에 대한 자세한 내용은 모델 품질 및 엔드포인트 상태 모니터링을 참조 하세요.

  • 보안 모니터링

    보안, 규정 준수 및 개인 정보 보호 - 보안 모니터링을 참조하세요.

  • 비용 모니터링

    비용 최적화 - 비용 모니터링 및 제어를 참조하세요.