시작하며
안녕하세요, Data Engineering 부서에서 일하고 있는 장문영입니다.
저희 팀은 KT의 Azure Data Platform을 구축,운영하는 역할을 담당하고 있습니다. 오늘은 Databricks workspace Migration의 경험과 그 과정에서 얻은 Lesson Learn을 공유하고자 합니다.
문제점
Landing Zone내에 존재하는 resource는 정책에 의하면 Landing Zone 통합 DNS를 사용해야 했지만 개별 Private DNS를 사용하고 있었습니다. (그 이유는 정책이 만들어지기도 전에 서비스를 구성해야만 했었기 때문입니다.) Landing Zone 정책을 수용하기 위하여 Databricks resource를 통합 Vnet으로 이관해야 했습니다.
마이그레이션 전략 수립
마이그레이션을 하기위해 Databricks 관련 Migration Tool을 리서치 하여 본 결과 아래와 같은 Tool이 존재하였고 특징은 아래와 같습니다.
|
도구 |
특징 |
|---|---|
| Databricks Migration Tool |
Databricks Migration Tool은 Databricks 워크스페이스의 리소스(사용자, 노트북, 클러스터, 잡, 메타스토어 등)를 백업하거나, 다른 Databricks 워크스페이스로 마이그레이션할 수 있도록 지원하는 오픈소스 Python 패키지입니다. 마이그레이션 컴포넌트는 하기 링크 참고하시기 바랍니다.
|
| Databricks Terraform Experimental Exporter |
Databricks Terraform Experimental Exporter는 기존 Databricks 워크스페이스의 리소스를 Terraform 코드(*.tf)로 내보내고, 이를 Terraform 상태에 가져올 수 있는 import 스크립트(import.sh)까지 자동 생성하는 도구입니다. 이 도구는 Databricks 리소스의 IaC(코드로서의 인프라) 전환, 워크스페이스 간 마이그레이션, 백업 등에 활용할 수 있습니다. |
| Databricks CLI |
소규모 마이그레이션 시 Databricks CLI의 workspace import_dir/export_dir 명령어 조합이 간편한 솔루션으로 작동합니다
|
도구선정
결론부터 말씀드리면 Databricks Terraform Experimental Exporter를 선택하였습니다. (databricks terraform provider version: 1.66.0)
그 이유는 아래와 같습니다.
-
광범위한 리소스 커버리지: 클러스터, 잡, 노트북, 사용자/그룹, 시크릿, Unity Catalog, 외부 스토리지, 권한 등 Databricks 워크스페이스 및 계정 레벨의 대부분 리소스를 지원
-
IaC 전환 및 재현성: 추출된 Terraform 코드는 버전 관리 시스템(Git 등)에 저장 가능. 다양한 환경(테스트, 스테이징, 운영 등)에서 재현 및 배포가 용이
-
증분 마이그레이션 및 유연성: 일부 리소스에 대해 증분(Incremental) export가 가능. 특정 리소스만 선택적으로 추출 가능. 실제 운영 환경에서의 유연한 마이그레이션 전략 수립이 가능하다고 판단함
-
Databricks SA 추천: SA분으로 부터 레퍼런스 공유 가능
실제 적용 및 운영
첫번째 시도! 장애를 내다.
처음 시도는 Databricks의 SA의 가이드 대로 아래와 같은 순서로 진행을 하였습니다.
그리고 옵션은 아래 그림과 같이 모든 것을 ‘Yes’로 설정하고 진행하였습니다.
Data Engineering팀이 운영하는 모든 workspace는 같은 메타스토어를 사용하고 있습니다. 메타스토어는 이미 존재하고 있었기 해당 terraform file을 적용(apply)하면 기존 resource 생성을 skip 하거나 이미 존재한다고 에러가 나올 것으로 예상했습니다.
그러나 메타스토어 중 system catalog가 초기화 되고 Allowed JARs/Init Scripts 가 초기화 되는 현상이 발생하였습니다. 그리고 메타스토어에 등록된 Allowed JAR를 사용하는 Dataflow에서 장애를 겪게 되었습니다.
Lesson Learn
메타스토어와 같이 공유 인프라에 영향을 주는 리소스는 전체 적용 시 예기치 못한 초기화나 장애가 발생할 수 있습니다.
자동화 도구의 일괄 적용은 항상 위험성을 내포하고 있습니다.
두번째 시도! 선택적 적용
1. 메타스토어의 초기화를 방지하기 위해서 Databricks Terraform Experimental Exporter로 특정 리소스만 선택적으로 적용하기로 결정 하였습니다.-
unity catalog 관련 terraform(.tf) 파일을 적용하지 않기로 결정하였습니다.(관련 영향도가 파악할 수 없어 적용하지 않기로 결정)
-
아래 그림은 terraform 파일의 의존성을 도식화 한 결과 입니다. (예를 들어 group.tf가 동작하기 위해서는 user.tf 적용이 선행되어야 합니다.)
-
테라폼 파일들을 분석하고 의존성을 제거하는 작업을 진행하였습니다.
2. Workspace 노트북의 이관은 Databricks CLI을 활용하였습니다.
-
Databricks Terraform Experimental Exporter 사용 시 Job 관련 Notebooke만 이관이 되는 현상 확인하였습니다.
-
대안으로 Databricks CLI workspace import_dir/export_dir 명령어 사용하여 이관 하였습니다.
Lesson Learn
Databricks Terraform Experimental Exporter, Databricks CLI, 수동이관의 조합으로 Workspace Migration을 완료하였습니다.
첫번째 시도의 경험을 바탕으로 각 도구의 특성과 한계를 명확히 파악하고, 상황에 따라 조합하여 유연하게 전략을 수립했습니다.
마치며
이번 Databricks Workspace Migration 통해, 단순히 리소스 이전을 넘어 데이터 플랫폼 운영의 안정성과 유연성을 확보하는 데 많은 인사이트를 얻었습니다.
가장 큰 교훈은 "자동화 도구의 강력함과 위험성은 동전의 양면"이라는 점이었습니다.
Databricks Terraform Experimental Exporter와 같은 도구는 대규모 리소스 이관 및 IaC(코드로서의 인프라) 전환에 매우 유용하지만, 실제 운영 환경에서는 예상치 못한 초기화나 의존성 문제 등 잠재적 위험을 항상 내포하고 있었습니다. 특히, 메타스토어와 같이 공유 인프라에 영향을 주는 리소스의 경우, 전체 적용이 아닌 선택적 적용과 사전 의존성 분석이 필수적임을 절실히 느꼈습니다. 또한, Databricks CLI, 수동 이관 등 다양한 방법론을 조합하여 상황에 맞는 유연한 전략을 수립하는 것이 중요했습니다. 자동화 도구만을 맹신하기보다는, 각 도구의 특성과 한계를 명확히 이해하고, 필요 시 수동 검증과 단계적 적용을 병행하는 접근이 장애 예방에 효과적이었습니다.
이번 경험을 바탕으로, 앞으로도 데이터 플랫폼의 신뢰성과 확장성을 높이기 위해 도구의 선택과 적용 방식, 그리고 운영 정책의 정교화에 더욱 힘쓰겠습니다.
마지막으로 같이 옆에서 같이 삽질(?)해준 팀원 분들에게 다시 한 번 감사드립니다.