튜토리얼: Databricks Asset Bundles를 사용하여 AI/BI 대시보드 변경 사항을 대규모로 안전하게 배포하는 방법

오류로 가득 찬 대시보드로 이사회가 시작된다는 생각은 분석팀을 밤잠 설치게 할 것입니다. 채용 계획, 제품 출시 또는 수익 예측이 잘못된 메트릭을 기반으로 했다는 사실을 나중에 발견하는 것도 마찬가지입니다. 또는 대시보드가 고객의 구매 내역을 잘못 표시하여 지원팀이 너무 많은 환불을 처리했을 수도 있습니다.

이러한 실패는 잘못된 분석으로 인해 발생하는 경우가 거의 없습니다. 모든 프로덕션 시스템과 마찬가지로, 데이터 모델과 요구 사항이 발전함에 따라 버전 관리, 신뢰할 수 있는 검토 프로세스 또는 환경 전반에 걸쳐 변경 사항을 적용할 수 있는 반복 가능한 방법 없이 대시보드를 수동으로 업데이트하는 데서 문제가 비롯되는 경우가 많습니다.

이 블로그 게시물은 간단한 사례를 제시합니다. 비즈니스를 주도하는 프로덕션급 대시보드는 프로덕션 코드와 동일한 원칙으로 관리되어야 합니다. Databricks AI/BI 는 데이터 파이프라인 및 거버넌스 레이어와 동일한 데이터 인텔리전스 플랫폼 에서 실행되므로 팀에서는 버전 관리, 환경별 구성, 제어된 배포와 같은 프로덕션 사례를 대시보드에도 동일하게 적용할 수 있습니다.

이를 구체적으로 설명하기 위해 애널리스트가 일상적인 대시보드 작성 방식을 변경하지 않고 프로덕션급 Databricks 기능을 사용하는 방법을 소개합니다.

구체적으로 이 흐름을 통해 다음을 수행하는 방법을 보여드리겠습니다.

• 대시보드에 대한 각 변경 사항 검토 및 승인
• 대시보드 기록을 추적하고 코드 변경 사항을 비즈니스 요구 사항에 연결합니다.
• 대시보드를 이전 버전으로 롤백

필수 구성 요소:

이 워크플로는 대부분의 조직에 이미 마련되어 있는 일회성 인프라 설정이 필요합니다. 아직 이러한 설정이 없는 경우 내부 DevOps 또는 IT 그룹에 설정을 도와달라고 요청하세요:

• 대시보드를 작성, 테스트, 배포하기 위한 최소 두 개의 Databricks 워크스페이스 (예: 개발 및 프로덕션 워크스페이스)
• Databricks의 Git 지원 폴더 (AWS | Azure | GCP)는 대시보드 정의의 버전을 관리하는 데 사용됩니다.
• 프로젝트에 대해 구성된 Databricks Asset Bundles(DAB) (AWS | Azure | GCP)

소개: 대시보드 변경 사항을 안전하게 배포하기 위한 구조화된 워크플로

현실적인 시나리오를 살펴보겠습니다. 귀하는 재무 및 영업 리더십 팀에서 매주 사용하는 영업 실적 대시보드를 소유하고 있습니다. 처음에는 워크스페이스에서 직접 구축된 인턴 프로젝트로 시작했지만, 시간이 지나면서 발전하여 지금은 여러 경영진 검토에 사용되고 있습니다.

이사회 회의에서 우선순위가 변경되어 새로운 요구 사항이 생겼습니다. 이제 재무팀은 단일 집계 판매 메트릭 대신 확정된 판매 금액과 미확정된 판매 금액을 추적해야 하며, 대시보드는 다음 예측 검토 전에 새로운 정의를 반영해야 합니다.

이 값들은 보상 및 보너스 계산을 포함한 실제 비즈니스 의사 결정에 직접적인 영향을 미치므로, 이 대시보드를 처음으로 체계적인 배포 경로에 올려 보겠습니다.

1단계: 대시보드를 Databricks 자산 Bundle에 추가

프로세스를 시작하기 전에 IT 그룹과 협력하여 빈 'Databricks 자산 Bundle'이 포함된 Git 리포지토리, 번들을 자동으로 배포하기 위한 CI/CD 스크립트 등 몇 가지 기본 코드 도구를 설정하세요.

Git 리포지토리는 파일 변경 사항을 추적하는 도구입니다. 시작하려면 대시보드 구성의 변경 사항을 추적할 수 있도록 Databricks에 연결해야 합니다. Databricks 작업 공간에서 Git 폴더를 만들고 설정 대화 상자에 리포지토리 URL을 붙여넣습니다. 이렇게 하면 Databricks가 리포지토리를 인식하게 되어 다음 단계에서 대시보드를 추가할 수 있습니다.

Databricks 자산 번들은 코드 파일(이 경우 대시보드)을 하나로 묶는 방법입니다. 리포지토리에 이미 번들이 포함되어 있는 경우, 자동으로 감지되며 화살표 아이콘을 사용하여 열 수 있습니다. 그렇지 않은 경우 Git 폴더의 만들기 메뉴에서 새 번들을 만들 수 있습니다.

Asset Bundle 편집기 내에서 현재 비어 있는 번들에 새 구성 요소와 기존 구성 요소를 모두 추가할 수 있습니다. 대시보드를 포함하려면 추가 메뉴를 열고 기존 대시보드 추가를 선택합니다. 추가한 후 에는 번들의 일부로 src 폴더 안에 대시보드가 나타나는 것을 볼 수 있습니다.

이 시점부터 대시보드는 배포 가능한 자산으로 관리되므로 개발, 테스트 및 프로덕션 워크스페이스 전반에 걸쳐 동일한 대시보드를 쉽게 적용할 수 있습니다.

마지막으로 대시보드를 리포지토리에 커밋 합니다. 이를 통해 대시보드의 현재 상태를 기준선으로 캡처하고 향후 변경 사항을 추적 및 검토하기 위한 명확한 시작점을 설정할 수 있습니다.

대시보드가 몇 가지 자동 생성된 구성 파일(.yml로 끝나는)과 함께 리포지토리에 추가된 것을 볼 수 있습니다. 이 파일들은 여러 다른 환경에서 대시보드를 배포하는 방법을 설명하며 편집할 필요가 없습니다.

커밋 메시지 필드에 수행한 작업을 설명하는 간단한 메모를 추가한 다음, 커밋 및 푸시를 선택합니다. 이렇게 하면 대시보드에 대한 체크포인트, 즉 나중에 다시 돌아갈 수 있는 알려진 양호한 상태가 생성되므로 향후 변경 사항을 비교, 검토하고 안전하게 배포할 수 있습니다.

2단계: 대시보드 업데이트

이제 기존 대시보드가 커밋되었으므로 프로덕션 환경에 영향을 주지 않고 대시보드를 변경할 수 있습니다. git이 사용자가 적용한 특정 변경 사항을 추적할 것입니다.

일반적인 방법은 다른 사람에게 영향을 주지 않고 작업할 수 있는 대시보드 버전인 Git 브랜치를 만드는 것입니다. '브랜치 생성' 버튼을 통해 이 작업을 수행한 다음, 사용자 이름, 기능 또는 변경과 관련된 티켓 번호와 같은 설명적인 이름을 지정할 수 있습니다. 이를 업데이트를 위한 비공개 버전이라고 생각하세요. 대시보드를 자유롭게 편집, 테스트 및 개선한 다음, 변경 사항을 검토하고 배포할 준비가 되었을 때를 별도로 결정할 수 있습니다.

이제 대시보드를 변경할 수 있습니다! 이 경우 왼쪽 상단의 영업 수치를 수정하여 미확정 및 확정 영업 카운터를 모두 추가합니다(가시성을 위해 굵은 파란색과 빨간색 사용).

작성 환경은 아무것도 변경되지 않는다는 점에 유의하세요. 평소와 같이 대시보드 UI 편집기를 사용하여 이러한 변경 작업을 수행하면 됩니다.

개발 환경에서 대시보드가 올바르게 표시되면 변경 사항을 프로덕션으로 가져오는 프로세스를 진행할 준비가 된 것입니다. 이전과 같이 상단에 있는 동일한 Git 버튼을 사용하여 짧은 커밋 메시지와 함께 이러한 변경 사항을 커밋합니다.

3단계: 변경 사항 검토

다음으로, 이 워크플로의 또 다른 주요 이점을 활용할 수 있습니다. 즉, 변경 사항이 프로덕션에 적용되기 전에 다른 사람들이 변경 내용을 검토하고 피드백을 제공할 수 있는 공간이 마련됩니다. 다른 사람의 검토를 받는 것은 일반적인 모범 사례이지만, 그에 못지않게 중요한 것은 보고에 영향을 미치기 전에 아이디어를 논의하고, 가정을 검증하고, 변경 사항을 구체화할 수 있는 부담 없는 공간을 만든다는 점입니다.

검토를 시작하려면 Git 공급자에서 Pull Request(PR) 를 만듭니다. 이는 기본적으로 대시보드 업데이트에 대한 검토 페이지입니다. 검토자는 변경된 내용을 정확하게 확인하고 사용자가 처리할 댓글을 남기며 모든 것이 올바르게 보이면 업데이트를 승인할 수 있습니다.

검토 중에는 프로덕션 대시보드가 변경되지 않은 상태로 유지됩니다. 피드백이 처리되고 변경 사항이 승인된 후에야 다음 단계로 진행됩니다.

대시보드 변경 사항은 내부적으로 구성 파일로 저장 및 추적되지만, 실제로 무엇이 변경되었는지 파악하기는 어려운 경우가 많습니다. 이 때문에 대부분의 팀은 PR이 열릴 때마다 검토를 위해 대시보드의 임시 테스트 버전을 자동으로 배포하는 작은 자동화를 사용합니다. 이렇게 하면 검토자는 프로덕션에 적용하기 전에 제안된 메트릭, 계산, 레이아웃을 컨텍스트 내에서 확인하고 데이터 로직이나 UI 문제를 발견할 수 있습니다. 개발자나 검토자가 테스트 대시보드에 대한 스크린샷이나 링크를 PR에 직접 포함하면 피드백을 더 빠르고 확실하게 받을 수 있습니다.

검토자는 댓글을 추가하고 승인할 수 있으며, 이는 나중에 변경 사항을 더 쉽게 이해할 수 있도록 기록됩니다.

4단계: 번들을 사용하여 대시보드를 프로덕션에 배포

변경 사항이 승인되었으므로 이제 대시보드를 프로덕션에 배포할 준비가 되었습니다.

대시보드는 개발 환경에서와는 다른 설정이 프로덕션 환경에서 필요한 경우가 많습니다. 예를 들어, 개발 데이터세트 대신 프로덕션 카탈로그나 스키마를 가리키거나 다른 SQL warehouse를 사용하는 경우입니다.

다행인 점은 이러한 차이점이 배포 프로세스의 일부로 예상되며 처리된다 는 것입니다.

대시보드를 자산 Bundle에 추가했을 때 Databricks는 이러한 환경별 설정을 캡처하는 작은 .yml 구성 파일을 생성했습니다. 이 파일을 사용하면 대시보드 로직 자체를 변경하지 않고도 환경별로 값을 재정의할 수 있습니다. 이 예시에서는 카탈로그 이름에 ${variable} 값을 사용하여 프로덕션 환경에서 대시보드가 사용하는 카탈로그를 테스트 환경과 다르게 지정했습니다.

마지막으로, databricks.yml 파일은 모든 번들 리소스를 함께 묶고 각 환경에서 사용되는 카탈로그를 정의하여 개발, 테스트 및 프로덕션 워크스페이스 전반에서 일관된 배포를 쉽게 관리할 수 있도록 합니다.

Pull Request가 승인되어 메인 브랜치에 병합되면 배포 자동화가 실행되고 databricks.yml에 정의된 환경별 값을 사용합니다. 동일한 대시보드 코드가 여러 워크스페이스에서 재사용되는 동안 카탈로그, 스키마, warehouse와 같은 설정은 대상 환경에 따라 적용됩니다. 이렇게 하면 각 워크스페이스에 대해 별도의 대시보드 사본을 유지할 필요가 없으며 변경 사항이 모든 곳에서 예측 가능하게 작동하도록 보장합니다.

대부분의 Git 공급자의 경우, pull request에서 배포 자동화를 볼 수 있으므로 배포를 모니터링하고 완료 시점(또는 문제가 발생하는 경우)을 확인할 수 있습니다. 문제가 발생하면 배포가 기존 프로덕션 대시보드에 영향을 주지 않고 중지되므로 문제를 해결할 수 있습니다. 배포가 성공적으로 완료되면 업데이트된 대시보드가 프로덕션 환경에서 라이브 상태가 되어 이해관계자가 사용할 수 있게 됩니다!

보너스 1: 기록을 검토하고 싶다면 어떻게 해야 할까요?

대시보드 업데이트가 라이브 상태가 되면 무엇이, 언제, 왜 변경되었는지에 대한 기록을 파악해야 할 수 있습니다. 이 흐름의 또 다른 장점은 이제 변경 사항을 추적할 수 있다는 것입니다. 워크스페이스에서 직접 수행하는 일회성 편집 대신 저장된 버전의 시퀀스로 표시됩니다.

각 항목은 작성자 및 타임스탬프와 함께 대시보드 업데이트를 나타냅니다. 항목을 열어 변경 사항을 검토하고 필요한 경우 롤백할 수 있습니다.

보너스 2: 변경 사항을 되돌려야 하는 경우는 어떻게 해야 할까요?

신중하게 검토하고 테스트하더라도 대시보드를 로드하지 못하거나 메트릭 정의가 올바르지 않은 것과 같은 문제가 계속 발생할 수 있습니다.

대시보드는 이 워크플로를 통해 관리되므로 업데이트 배포에 사용된 것과 동일한 제어된 프로세스를 사용하여 정상으로 알려진 버전으로 롤백할 수 있습니다.

리포지토리에서 대시보드의 변경 기록을 열고 되돌리려는 업데이트를 찾는 것으로 시작하세요. 여기에서 수정된 내용을 검토하여 진행하기 전에 올바른 변경 사항을 되돌리는 것이 맞는지 확인할 수 있습니다.

변경 세부 정보에서 링크를 따라 검토 페이지로 다시 이동하세요. 업데이트를 롤백하려면 되돌리기를 선택하세요. 이렇게 하면 해당 특정 업데이트만 되돌리는 새로운 '실행 취소' 변경이 생성되어 대시보드를 이전 논리로 복원하면서 나머지 대시보드 기록은 그대로 유지됩니다.

변경 사항이 메인 브랜치에 병합되면, 프로덕션에 대시보드를 배포한 것과 동일한 자동화가 이를 롤백합니다. 이는 이미 마련된 제어 기능을 우회하지 않고도 몇 분 안에 서비스 중단이나 영향이 큰 계산 문제에 대응할 수 있음을 의미합니다.

보너스 3: 데이터 소스에 업데이트가 있는 경우는 어떻게 하나요?

대부분의 대시보드는 데이터 소스와 밀접하게 연결되어 있으며, 이는 대시보드 업데이트가 종종 파이프라인 업데이트와 밀접하게 연결되어 있음을 의미합니다. 다행히 자산 Bundle은 관련 구성 요소를 하나의 패키지로 그룹화하도록 설계되었습니다.

이를 통해 업스트림 데이터 모델 변경으로 인해 예상치 못한 상황이 발생하는 것을 방지할 수 있으며, 시각화 변경에 데이터 모델 업데이트가 필요한 경우 한 번의 배포로 두 가지 변경 사항을 모두 롤아웃할 수 있습니다.

결론

AI/BI 대시보드를 프로덕션급 데이터 제품으로 취급하는 것은 신뢰할 수 있는 비즈니스 결정과 위험 완화에 필수적입니다. 이 워크플로에서는 몇 가지 추가 단계를 통해 일상적인 대시보드 구축 방식을 변경하지 않고도 대시보드 변경 사항을 확인하고, 검토하고, 되돌릴 수 있습니다.

Git 및 Databricks 자산 번들로 대시보드를 관리함으로써 팀은 변경, 검토, 테스트 및 배포라는 일상적이고 예측 가능한 업데이트 워크플로를 구축합니다. 업데이트가 사소한 시각적 조정이든 비즈니스 로직에 대한 의미 있는 변경이든 동일한 프로세스가 적용됩니다.

올바른 배포 원칙이 적용되면 대시보드 변경은 더 이상 위험의 원인이 아니며, 이사회 회의와 같이 중요한 상황에서도 비즈니스와 함께 발전하는 신뢰할 수 있는 인사이트의 원천이 됩니다.

더 알아보기 + 다음 단계

이 워크플로에 사용된 요소에 대해 더 자세히 알아보고 싶다면 다음 리소스를 참고해 보세요.

• '브랜칭 전략' (AWS | Azure | GCP)
  모범 사례를 따르는 브랜칭 모델을 사용하여 변경 사항을 병합하고 배포하는 방법을 알아보세요.
• Databricks 자산 Bundles (AWS | Azure | GCP)
  자산 Bundles를 사용하여 여러 환경에서 Databricks 리소스를 일관되게 패키징하고 배포하는 방법을 알아보세요.
• Databricks에서 자동화된 배포를 위한 CI/CD (AWS | Azure | GCP)
  스타터 Github Actions 스크립트 (AWS | Azure | GCP)로 CI/CD를 구현하는 방법을 알아보세요.
• Databricks Workspace UI에서 자산 Bundles 사용 (AWS | Azure | GCP)
  워크스페이스에서 직접 번들을 생성, 편집 및 배포하는 방법을 알아보세요.
• Databricks의 Git 지원 폴더 (AWS | Azure | GCP)
  Databricks에서 Git 통합이 어떻게 작동하는지, 그리고 버전 제어가 일상적인 분석 워크플로에 어떻게 적용되는지 알아보세요.

Databricks AI/BI로 다음 단계를 진행할 준비가 되셨다면 다음 옵션 중 하나를 선택할 수 있습니다.

• 무료 버전 및 평가판: 무료 버전 또는 평가판에 가입하여 직접 경험해 보세요.
• 설명서: 설명서를 통해 자세한 내용을 알아보세요.
• 웹페이지: 자세한 내용은 웹페이지 를 방문하세요.
• 데모: 데모 동영상을 시청하고, 제품 둘러보기 에 참여하고, 실습 튜토리얼을 통해 이러한 AI/BI가 실제로 작동하는 모습을 확인해 보세요.
• 교육: Databricks Academy를 통해 무료 제품 교육 을 시작해 보세요.

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