환경 이동, CI/CD, 모니터링, 비용, 롤백

​

4. 환경 간 이동 (dev → staging → prod)

​

전략: 환경별 app.yaml 분리

my-app/
├── app.py
├── app.yaml              # 기본 설정 (dev)
├── app.staging.yaml      # 스테이징 설정
├── app.prod.yaml         # 프로덕션 설정
└── requirements.txt

​

환경별 리소스 매핑 예시

# 스테이징 배포
databricks apps deploy my-app-staging --source-code-path ./my-app

# 프로덕션 배포
databricks apps deploy my-app-prod --source-code-path ./my-app

참고 환경 분리 전략: 가장 간단한 방법은 환경별로 별도 앱을 생성하는 것입니다 (my-app-dev, my-app-staging, my-app-prod). 각 앱에서 UI Configure 화면에서 해당 환경의 리소스를 연결하면 됩니다.

​

5. CI/CD 파이프라인 구성 예시

​

GitHub Actions 예시

# .github/workflows/deploy-app.yml
name: Deploy Databricks App

on:
  push:
    branches: [main]
    paths: ['my-app/**']

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install Databricks CLI
        run: pip install databricks-cli

      - name: Configure Databricks Auth
        env:
          DATABRICKS_HOST: ${{ secrets.DATABRICKS_HOST }}
          DATABRICKS_TOKEN: ${{ secrets.DATABRICKS_TOKEN }}
        run: |
          databricks configure --token <<EOF
          $DATABRICKS_HOST
          $DATABRICKS_TOKEN
          EOF

      - name: Deploy App
        run: |
          databricks apps deploy my-app \
            --source-code-path ./my-app

• paths: ['my-app/**']로 앱 코드가 변경될 때만 배포가 트리거됩니다.
• DATABRICKS_HOST와 DATABRICKS_TOKEN은 GitHub Secrets 에 저장됩니다. 절대 코드에 직접 넣지 마세요.
• 배포 후 상태 확인 단계를 추가하면 더 안전합니다.

​

Azure DevOps 예시

# azure-pipelines.yml
trigger:
  branches:
    include:
      - main
  paths:
    include:
      - my-app/**

pool:
  vmImage: 'ubuntu-latest'

steps:
  - task: UsePythonVersion@0
    inputs:
      versionSpec: '3.10'

  - script: pip install databricks-cli
    displayName: 'Install Databricks CLI'

  - script: |
      export DATABRICKS_HOST=$(DATABRICKS_HOST)
      export DATABRICKS_TOKEN=$(DATABRICKS_TOKEN)
      databricks apps deploy my-app --source-code-path ./my-app
    displayName: 'Deploy App'
    env:
      DATABRICKS_HOST: $(DATABRICKS_HOST)
      DATABRICKS_TOKEN: $(DATABRICKS_TOKEN)

주의 보안 주의: CI/CD에서 Databricks 인증 정보는 반드시 GitHub Secrets 또는 해당 CI 도구의 시크릿 관리 기능을 사용하세요. 코드에 토큰을 직접 넣지 마세요.

참고 CI/CD 고급 패턴: 프로덕션 배포 파이프라인에서는 다음 단계를 추가하는 것이 좋습니다:

1. 린트/테스트: 코드 품질 검사 및 단위 테스트 실행
2. 스테이징 배포: 프로덕션 전 스테이징 환경에 먼저 배포
3. 스모크 테스트: 스테이징에서 기본 기능 동작 확인
4. 승인 게이트: 수동 승인 후 프로덕션 배포
5. 프로덕션 배포: 메인 앱 배포
6. 상태 검증: 배포 후 앱 상태가 Running인지 확인

​

6. 모니터링과 로깅

​

앱 로그 확인

# CLI로 로그 확인
databricks apps logs <app-name>

​

오류 디버깅 패턴

참고 효과적인 로깅 패턴: 앱 코드에서 Python의 logging 모듈을 사용하면 로그 레벨을 제어할 수 있습니다. print()보다 logging.info(), logging.error()를 사용하고, 로그 레벨을 app.yaml의 env로 제어하세요 (LOG_LEVEL=INFO). 이렇게 하면 프로덕션에서는 중요 로그만, 디버깅 시에는 상세 로그를 볼 수 있습니다.

​

7. 스케일링

참고 Scale to Zero (App Spaces)는 현재 Private Preview입니다. GA 전까지는 Databricks Jobs로 업무 시간 외에 앱을 자동 중지하는 스크립트를 구성하세요. Horizontal Scaling 은 Private Preview로, 최대 5개 인스턴스까지 수평 확장이 가능합니다. 자세한 내용은 고급 기능 페이지를 참고하세요.

​

8. 비용 구조

주의 비용 주의사항: 앱 컨테이너는 Running 상태에서 트래픽이 없어도 과금 됩니다. 이는 앱이 항상 대기 상태로 유지되기 때문입니다. 개발/테스트 앱은 사용하지 않을 때 반드시 Stop하세요.

참고 비용 최적화 체크리스트:

1. 개발/테스트 앱은 퇴근 시 Stop (CLI 스크립트 또는 cron 활용)
2. Medium 사이즈로 시작, 필요할 때만 Large 업그레이드
3. SQL Warehouse는 Serverless 사용 (유휴 시 비과금)
4. 불필요한 앱은 삭제 (SP도 함께 정리됨)

​

9. 롤백 방법

​

Git 기반 롤백 (권장)

# 이전 커밋으로 소스 코드 되돌리기
git checkout <previous-commit-hash> -- my-app/

# 이전 버전으로 재배포
databricks apps deploy my-app --source-code-path ./my-app

​

블루-그린 배포

1. 새 버전을 별도 앱으로 배포 (my-app-v2)
2. 테스트 후 문제 없으면 기존 앱 중지, 새 앱으로 트래픽 전환
3. 문제 발생 시 기존 앱 재시작

참고 블루-그린의 한계: 앱 URL이 이름에 포함되므로(my-app-v1.xxx.databricksapps.com vs my-app-v2.xxx.databricksapps.com), 사용자에게 URL 변경을 안내해야 합니다. 현재 Databricks Apps에서는 커스텀 도메인을 직접 지원하지 않습니다.

​

10. 의존성 관리

​

requirements.txt 모범 예시

# 프레임워크
streamlit==1.32.0

# Databricks SDK
databricks-sdk==0.20.0

# 데이터 처리
pandas==2.2.0
plotly==5.18.0

주의 파일 크기 제한: 앱 파일은 개별 10 MB를 초과할 수 없습니다. 초과 시 배포가 실패합니다. 대용량 파일(모델 가중치, 데이터 파일 등)은 Unity Catalog Volume에 저장하고 런타임에 다운로드하세요.

참고 의존성 버전을 반드시 명시하세요. 버전을 지정하지 않으면 배포할 때마다 최신 버전이 설치되어, 어제 작동하던 앱이 오늘 갑자기 깨질 수 있습니다.

주의 의존성 충돌 디버깅: ModuleNotFoundError나 ImportError가 발생하면, 로컬에서 pip install -r requirements.txt를 깨끗한 가상환경에서 실행하여 재현하세요. 로컬에서는 작동하지만 배포 후 실패하는 경우, 로컬에 이미 설치된 패키지가 requirements.txt에 누락되었을 가능성이 높습니다.