Skip to main content

코드 업데이트 배포

기존에 배포된 앱에 새 코드를 적용하려면 databricks apps deploy 명령을 다시 실행합니다.
# 기본 배포 — 현재 디렉토리의 코드를 기존 앱에 재배포
databricks apps deploy my-app --source-code-path ./my-app-code

# 특정 소스 경로 지정
databricks apps deploy my-app --source-code-path /path/to/updated/code
상황동작비고
코드만 변경새 컨테이너 빌드 후 교체기존 설정 유지
requirements.txt 변경의존성 재설치 후 배포캐시 미스 시 시간 증가
app.yaml 변경설정 반영 후 재배포리소스·환경변수 포함
배포 후 상태를 확인하려면 databricks apps get my-app 명령을 사용하세요. state 필드가 RUNNING이면 정상 배포된 것입니다.

설정 변경

app.yaml 수정 후 재배포

app.yaml의 설정을 변경한 뒤 databricks apps deploy를 실행하면 변경사항이 자동 반영됩니다.
# app.yaml 예시 — 환경변수 변경
command:
  - "uvicorn"
  - "main:app"
  - "--host"
  - "0.0.0.0"
  - "--port"
  - "8000"

env:
  - name: LOG_LEVEL
    value: "DEBUG"            # INFO → DEBUG로 변경
  - name: FEATURE_FLAG_V2
    value: "true"             # 신규 환경변수 추가

환경변수 변경

방법명령 / 위치반영 시점
app.yaml env 섹션 수정databricks apps deploy재배포 시
UI에서 직접 변경워크스페이스 → Apps → 앱 선택 → Settings앱 재시작 시

리소스 바인딩 변경

SQL Warehouse, Model Serving Endpoint, Secret Scope 등의 리소스 바인딩을 변경할 때도 app.yamlresources 섹션을 수정합니다.
resources:
  - name: sql-warehouse
    sql_warehouse:
      id: "abc123def456"       # 새 warehouse ID로 교체
      permission: CAN_USE

  - name: serving-endpoint
    serving_endpoint:
      name: "my-model-v2"     # 새 모델 엔드포인트로 교체
      permission: CAN_QUERY
# 리소스 변경 후 재배포
databricks apps deploy my-app --source-code-path ./my-app-code

롤백

문제가 발생하면 이전 버전으로 빠르게 되돌려야 합니다.

Git 기반 롤백 (권장)

코드를 Git으로 관리하고 있다면 가장 안전하고 빠른 롤백 방법입니다.
# 1. 이전 커밋으로 체크아웃
git log --oneline -5          # 최근 커밋 확인
git checkout <이전-커밋-해>

# 2. 해당 버전으로 재배포
databricks apps deploy my-app --source-code-path .

# 3. 확인 후 main 브랜치로 복귀
git checkout main

수동 롤백

Git을 사용하지 않는 경우, 이전에 동작하던 코드를 직접 배포합니다.
# 이전 코드 백업이 있는 경우
databricks apps deploy my-app --source-code-path ./my-app-code-backup-v1
롤백 방법장점단점
Git checkout + deploy정확한 버전 추적, 감사 이력Git 사용 필수
수동 코드 교체Git 없이 가능버전 추적 어려움, 실수 가능성
DABs 번들 재배포CI/CD 파이프라인 연동초기 설정 필요
주의 Databricks Apps는 현재 자체 버전 관리나 원클릭 롤백 기능을 제공하지 않습니다. 반드시 Git으로 코드를 관리하여 안정적인 롤백이 가능하도록 하세요.

무중단 업데이트 전략

블루-그린 배포 패턴

프로덕션 앱의 다운타임을 최소화하려면, 별도 앱으로 먼저 테스트한 뒤 전환하는 블루-그린 방식을 활용합니다.
# 1. 스테이징 앱에 새 버전 배포 (Blue → Green)
databricks apps deploy my-app-staging --source-code-path ./my-app-code-v2

# 2. 스테이징 앱에서 테스트
# → https://<workspace-url>/apps/my-app-staging 접속하여 검증

# 3. 검증 완료 후 프로덕션 앱에 동일 코드 배포
databricks apps deploy my-app --source-code-path ./my-app-code-v2
단계앱 이름상태트래픽
배포 전my-app (v1)RUNNING프로덕션
테스트 중my-app-staging (v2)RUNNING내부 테스트만
전환 후my-app (v2)RUNNING프로덕션
스테이징 앱은 프로덕션과 동일한 리소스(SQL Warehouse, Serving Endpoint)를 바인딩하되, 별도의 테스트 데이터를 사용하는 것이 안전합니다. Service Principal을 분리하면 권한 격리도 가능합니다.

버전 관리 모범 사례

Git + DABs 활용

Databricks Asset Bundles (DABs)를 사용하면 앱 코드와 인프라 설정을 하나의 번들로 관리할 수 있습니다.
my-app-bundle/
├── databricks.yml          # DABs 설정
├── resources/
│   └── app.yml             # 앱 리소스 정의
├── src/
│   ├── app.yaml            # 앱 런타임 설정
│   ├── main.py
│   └── requirements.txt
└── tests/
    └── test_main.py
# databricks.yml
bundle:
  name: my-app-bundle

targets:
  dev:
    workspace:
      host: https://my-workspace.cloud.databricks.com
  prod:
    workspace:
      host: https://my-workspace.cloud.databricks.com
# 개발 환경 배포
databricks bundle deploy -t dev

# 프로덕션 환경 배포
databricks bundle deploy -t prod

CI/CD 파이프라인 연동

GitHub Actions 등의 CI/CD와 연동하면 코드 변경 시 자동으로 배포할 수 있습니다.
# .github/workflows/deploy-app.yml
name: Deploy Databricks App
on:
  push:
    branches: [main]
    paths: ['src/**', 'app.yaml', 'requirements.txt']

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: databricks/setup-cli@main
      - run: databricks bundle deploy -t prod
        env:
          DATABRICKS_HOST: ${{ secrets.DATABRICKS_HOST }}
          DATABRICKS_TOKEN: ${{ secrets.DATABRICKS_TOKEN }}

버전 관리 체크리스트

항목권장 사항
코드 관리Git 필수, 태그로 릴리스 버전 표시
의존성 고정requirements.txt에 버전 pinning (pandas==2.1.0)
설정 분리app.yaml은 환경별로 분리 (dev/prod)
시크릿 관리하드코딩 금지, Secret Scope 또는 환경변수 활용
배포 자동화DABs + CI/CD로 수동 배포 최소화
테스트배포 전 스테이징 환경에서 검증
모니터링배포 후 databricks apps get으로 상태 확인