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

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

이러한 실패는 분석을 잘못해서 발생하는 경우가 거의 없습니다. 다른 프로덕션 시스템과 마찬가지로, 데이터 모델과 요구 사항이 발전함에 따라 대시보드가 수동으로 업데이트되는 과정에서 발생하는 경우가 많습니다. 즉, 버전 관리도 없고, 신뢰할 수 있는 검토 프로세스도 없으며, 여러 환경에 걸쳐 변경 사항을 반영할 수 있는 반복 가능한 방법도 없기 때문입니다.

이 블로그 게시물에서는 간단한 주장을 하고자 합니다. 비즈니스를 이끄는 프로덕션급 대시보드는 프로덕션 코드와 동일한 규율로 관리되어야 합니다. Databricks AI/BI는 데이터 파이프라인 및 거버넌스 레이어와 동일한 Data Intelligence Platform에서 실행되므로, 팀은 버전 관리, 환경별 구성, 제어된 배포와 같은 동일한 프로덕션 방식을 대시보드에도 적용할 수 있습니다.

이를 구체화하기 위해, 분석가가 일상적으로 대시보드를 작성하는 방식을 바꾸지 않고도 프로덕션급 Databricks 기능을 사용하는 방법을 소개합니다.

구체적으로, 이 흐름을 통해 다음과 같은 작업을 수행하는 방법을 보여드립니다.

• 대시보드의 각 변경 사항 검토 및 승인
• 대시보드 이력 추적 및 코드 변경 사항을 비즈니스 요구 사항과 연결
• 대시보드를 이전 버전으로 롤백

전제 조건

이 워크플로를 사용하려면 대부분의 조직에서 이미 갖추고 있는 일회성 인프라 설정이 필요합니다. 아직 설정되어 있지 않다면 내부 DevOps 또는 IT 부서에 도움을 요청하여 다음을 설정하세요.

• 대시보드를 작성, 테스트 및 배포할 수 있는 최소 2개의 Databricks 워크스페이스(예: 개발 및 프로덕션 워크스페이스)
• 대시보드 정의의 버전을 관리하는 데 사용되는 Databricks의 Git 기반 폴더(AWS | Azure | GCP)
• 프로젝트용으로 구성된 Declarative Automation Bundles (DABs)(AWS | Azure | GCP)

소개: 대시보드 변경 사항을 안전하게 배포하기 위한 체계적인 워크플로

실제 시나리오를 살펴보겠습니다. 귀하는 재무 및 영업 경영진이 매주 사용하는 Sales Performance 대시보드를 소유하고 있습니다. 이 대시보드는 처음에는 워크스페이스에서 직접 구축한 인턴 프로젝트로 시작되었지만, 시간이 지나면서 발전하여 현재는 여러 임원 검토 회의에서 사용되고 있습니다.

이사회에서 우선순위가 변경되면서 새로운 요구 사항이 생겼습니다. 이제 재무 부서에서는 단일 집계 영업 지표 대신 확정(committed) 및 미확정(uncommitted) 영업 금액을 추적해야 하며, 다음 예측 검토 전에 대시보드에 이 새로운 정의가 반영되어야 합니다.

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

1단계: Declarative Automation Bundles에 대시보드 추가하기

프로세스를 시작하기 전에 IT 부서와 협력하여 기본적인 코드 도구를 설정하세요. 여기에는 비어 있는 'Declarative Automation Bundles'가 포함된 Git 리포지토리와 번들을 자동으로 배포하기 위한 일부 CI/CD 스크립트가 포함됩니다.

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

Declarative Automation Bundles는 코드 파일(이 경우 대시보드)을 함께 그룹화하는 방법입니다. 리포지토리에 이미 번들이 포함되어 있는 경우 자동으로 감지되며 화살표 아이콘을 사용하여 열 수 있습니다. 그렇지 않은 경우 Git 폴더의 Create 메뉴에서 새 번들을 생성할 수 있습니다.

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

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

마지막으로 대시보드를 리포지토리에 커밋(commit)합니다. 이렇게 하면 대시보드의 현재 상태가 기준선(baseline)으로 캡처되고 향후 변경 사항을 추적하고 검토하기 위한 명확한 시작점이 설정됩니다.

대시보드가 리포지토리에 추가된 것을 볼 수 있으며, 자동으로 생성된 몇 개의 구성 파일(.yml로 끝남)도 함께 추가됩니다. 이 파일들은 대시보드가 다양한 환경에 배포되는 방식을 설명하며, 사용자가 직접 편집할 필요는 없습니다.

commit message 필드에 수행한 작업을 설명하는 짧은 메모를 추가한 다음 Commit & Push를 선택합니다. 이렇게 하면 대시보드의 체크포인트(나중에 되돌아갈 수 있는 정상 상태)가 생성되므로 향후 변경 사항을 비교, 검토 및 안전하게 배포할 수 있습니다.

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

이제 기존 대시보드가 커밋되었으므로 이미 프로덕션에 반영된 내용에 영향을 주지 않고 대시보드를 변경할 수 있으며, Git이 구체적인 변경 사항을 추적합니다.

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

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

작성 환경은 전혀 변하지 않으므로, 평소처럼 대시보드 UI 편집기를 사용하여 변경하면 됩니다.

개발 환경에서 대시보드가 올바르게 보이면, 변경 사항을 프로덕션에 반영할 준비가 된 것입니다. 이전과 마찬가지로 상단의 Git 버튼을 사용하여 간단한 커밋 메시지와 함께 변경 사항을 체크인하세요.

3단계: 변경 사항 검토

다음으로, 이 워크플로의 또 다른 핵심 이점을 활용할 수 있습니다. 바로 변경 사항이 프로덕션에 반영되기 전에 다른 사람들이 이를 검토하고 피드백을 제공할 수 있는 공간입니다. 다른 사람의 검토를 받는 것은 일반적인 모범 사례이기도 하지만, 보고서에 영향을 미치기 전에 아이디어를 논의하고 가정을 검증하며 변경 사항을 개선할 수 있는 부담 없는 공간을 제공한다는 점에서도 중요합니다.

검토를 시작하려면 Git 제공업체에서 Pull Request (PR)를 생성하세요. 이는 기본적으로 대시보드 업데이트를 위한 검토 페이지입니다. 검토자는 정확히 무엇이 변경되었는지 확인하고, 해결해야 할 의견을 남기며, 모든 것이 올바르게 보이면 업데이트를 승인할 수 있습니다.

검토하는 동안 프로덕션 대시보드는 변경되지 않은 상태로 유지됩니다. 피드백이 반영되고 변경 사항이 승인된 후에만 다음 단계로 진행됩니다.

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

검토자는 의견을 추가하고 승인할 수 있으며, 이러한 내역이 기록되므로 나중에 변경 사항을 더 쉽게 이해할 수 있습니다.

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

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

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

다행히도 이러한 차이점은 배포 프로세스의 일부로 이미 예상되고 처리됩니다.

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

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

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

대부분의 Git 제공업체에서는 Pull Request에서 배포 자동화를 확인할 수 있으므로, 배포를 모니터링하고 완료 여부(또는 문제 발생 여부)를 확인할 수 있습니다. 문제가 발생하면 기존 프로덕션 대시보드에 영향을 주지 않고 배포가 중단되므로 문제를 해결할 수 있습니다. 배포가 성공적으로 완료되면 업데이트된 대시보드가 프로덕션에 실시간으로 반영되어 이해관계자들에게 제공될 준비가 끝납니다!

보너스 1: 이력을 검토하고 싶다면 어떻게 해야 하나요?

대시보드 업데이트가 실시간으로 반영된 후, 무엇이 언제 왜 변경되었는지 이력을 파악해야 할 수 있습니다. 이 워크플로의 장점 중 하나는 이제 변경 사항을 추적할 수 있다는 점입니다. 워크스페이스에서 직접 일회성으로 편집하는 대신, 저장된 버전의 시퀀스로 표시됩니다.

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

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

신중하게 검토하고 테스트하더라도 대시보드가 로드되지 않거나 메트릭 정의가 잘못된 것으로 밝혀지는 등의 문제가 여전히 발생할 수 있습니다.

대시보드가 이 워크플로를 통해 관리되기 때문에, 업데이트를 배포할 때 사용했던 것과 동일한 제어된 프로세스를 사용하여 정상 작동이 확인된 이전 버전으로 롤백할 수 있습니다.

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

변경 세부 정보에서 링크를 따라 검토 페이지로 돌아갑니다. 업데이트를 롤백하려면 Revert를 선택합니다. 이렇게 하면 해당 특정 업데이트만 되돌리는 새로운 "실행 취소" 변경 사항이 생성되어, 나머지 대시보드 이력은 그대로 유지하면서 대시보드를 이전 로직으로 복원합니다.

변경 사항이 메인 브랜치에 병합되면 대시보드를 프로덕션에 배포했던 동일한 자동화가 이를 롤백합니다. 즉, 이미 마련된 제어 프로세스를 우회하지 않고도 몇 분 만에 장애나 영향이 큰 계산 문제에 대응할 수 있습니다.

보너스 3: 데이터 소스가 업데이트되면 어떻게 되나요?

대부분의 대시보드는 데이터 소스와 밀접하게 연결되어 있으므로, 대시보드 업데이트는 파이프라인 업데이트와 밀접하게 연관되는 경우가 많습니다. 다행히도 Asset Bundles는 관련 구성 요소를 하나의 패키지로 묶도록 설계되었습니다.

이를 통해 업스트림 데이터 모델 변경으로 인해 당황할 일이 없으며, 시각화 변경을 위해 데이터 모델 업데이트가 필요할 때 두 가지 변경 사항을 한 번의 배포로 모두 적용할 수 있습니다.

결론

AI/BI 대시보드를 프로덕션급 데이터 제품으로 취급하는 것은 신뢰할 수 있는 비즈니스 의사 결정과 리스크 완화를 위해 필수적입니다. 이 워크플로우에서는 몇 가지 추가 단계만으로 매일 대시보드를 빌드하는 방식을 바꾸지 않고도 대시보드 변경 사항을 시각화하고, 검토하고, 되돌릴 수 있게 해줍니다.

Git 및 Declarative Automation Bundles로 대시보드를 관리함으로써 팀은 변경 사항 적용, 검토, 테스트, 배포라는 일상적이고 예측 가능한 업데이트 워크플로우를 구축할 수 있습니다. 업데이트가 사소한 시각적 조정이든 비즈니스 로직의 중요한 변경이든 동일한 프로세스가 적용됩니다.

올바른 배포 규율을 마련하면 대시보드 변경은 더 이상 리스크의 원인이 되지 않으며, 이사회 회의와 같이 중요한 상황에서도 비즈니스와 함께 발전하는 신뢰할 수 있는 인사이트의 원천이 됩니다.

자세히 알아보기 + 다음 단계

영감을 얻어 이 워크플로우에 사용된 요소들을 더 자세히 알아보고 싶으시다면, 다음 리소스를 참고해 보세요.

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

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

• 무료 에디션 및 평가판: 무료 에디션 또는 평가판에 가입하여 직접 체험해 보세요.
• 문서: 문서를 통해 자세한 내용을 확인해 보세요.
• 웹페이지: 자세한 내용을 알아보려면 웹페이지를 방문하세요.
• 데모: 데모 동영상을 시청하고, 제품 투어를 진행하고, 직접 실습할 수 있는 튜토리얼을 통해 AI/BI가 실제로 작동하는 모습을 확인해 보세요.
• 교육: Databricks Academy를 통해 무료 제품 교육을 시작해 보세요.

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