Skip to main content
Databricks Apps의 스케일링, 배포 방식, 모니터링, 의존성 관리에 관한 고급 기능을 다룹니다.

​
Scale to Zero — App Spaces (Private Preview)

App Spaces 는 microVM 기반의 새로운 런타임으로, Scale to Zero를 지원합니다. 약 30분간 트래픽이 없으면 자동으로 중지되고, 새 요청이 들어오면 자동 재시작됩니다.
주의 현재 상태: App Spaces는 Private Preview 입니다. 기존 앱을 App Spaces로 변환할 수 없으며, 새 앱을 생성해야 합니다. GA 전까지는 아래 “현재 비용 절감 방법”을 참고하세요.

​
동작 방식

상태조건과금 여부응답 시간
Active요청 처리 중 또는 최근 트래픽 있음과금즉시
Idle트래픽 없음 (30분 미만)과금즉시
Scaled to Zero30분간 트래픽 없어 자동 중지비과금콜드 스타트 (수 초~수십 초)

​
App Spaces의 현재 제한사항

항목상태
기존 앱 변환불가 — 새 앱 생성 필요
워크스페이스 Network Policy아직 미적용 (SEG, Private Link 미지원)
템플릿 기반 생성미지원 — API로 직접 생성

​
현재 비용 절감 방법 (GA 전까지)

App Spaces GA 전까지는 다음 방법으로 비용을 관리할 수 있습니다: 1. Databricks Jobs로 자동 시작/중지 스케줄링: 
# 앱 자동 중지/시작 Job 예시 (Python SDK)
from databricks.sdk import WorkspaceClient

w = WorkspaceClient()

# 퇴근 시 앱 중지 (7PM Job으로 등록)
w.apps.stop("my-dashboard-app")

# 출근 시 앱 시작 (7AM Job으로 등록)
w.apps.start("my-dashboard-app")
2. CLI 기반 스크립트: 
# cron 또는 Databricks Job으로 실행
# 퇴근 시 (19:00)
databricks apps stop my-dashboard-app

# 출근 시 (07:00)
databricks apps start my-dashboard-app
3. 사용하지 않는 앱 수동 중지: 
# 모든 앱 목록 확인
databricks apps list --output json | jq '.[] | select(.status == "RUNNING") | .name'

# 불필요한 앱 중지
databricks apps stop unused-app-1

​
콜드 스타트 최적화

Scale to Zero에서 앱이 다시 시작될 때 콜드 스타트 시간이 발생합니다. 이를 최소화하는 방법:
최적화 방법효과설명
경량 의존성시작 시간 단축requirements.txt에서 불필요한 패키지 제거
Lazy Loading초기 로드 단축무거운 라이브러리는 필요할 때 import
Serverless Warehouse쿼리 응답 단축Classic Warehouse는 콜드 스타트가 길어 추가 지연 발생
캐싱반복 요청 가속st.cache_data, st.cache_resource 활용
참고 비용 참고: 실제 운영 사례에서 Medium 사이즈 앱의 월 비용은 약 215∗∗입니다(24/7실행기준).업무시간만운영(12시간/일,주5일)하면약∗∗215** 입니다 (24/7 실행 기준). 업무 시간만 운영(12시간/일, 주 5일)하면 약 **65/월 로 절감할 수 있습니다.

​
Horizontal Scaling (수평 스케일링, Private Preview)

단일 컨테이너의 성능 한계를 넘기 위해 최대 5개 인스턴스 로 수평 확장할 수 있습니다.
항목설명
상태Private Preview
인스턴스 수1~5개 (수동 설정)
세션 친화성Stateful session affinity 지원 (업계 최초)
무중단 배포Zero-downtime deployments
빌드 캐시Deployment build caching

​
REST API 설정

{
  "name": "my-scaled-app",
  "description": "Horizontally scaled app",
  "compute_size": "MEDIUM",
  "compute_min_instances": 1,
  "compute_max_instances": 3
}
주의 기존 앱을 Horizontal Scaling으로 업그레이드할 수 없습니다. 새 앱을 생성해야 합니다. 템플릿 기반 생성도 미지원이며, API를 통해 직접 생성해야 합니다.

​
Git 기반 배포 (Public Preview)

소스 코드를 수동으로 업로드하는 대신, Git 레포지토리에서 직접 배포 할 수 있습니다.

​
주요 기능

기능설명
Git 레퍼런스브랜치, 태그, 커밋 해시 지정 가능
소스 코드 경로레포 내 특정 디렉토리 지정 가능
강제 적용워크스페이스 관리자가 Git-only 배포를 강제할 수 있음
# Git 기반 배포 (CLI)
databricks apps deploy my-app \
  --git-url https://github.com/myorg/myrepo \
  --git-ref main \
  --source-code-path ./app
참고 GitHub Enterprise Managed Users(EMU)의 개인 레포는 OAuth 제한으로 인해 PAT를 대안으로 사용해야 합니다.

​
앱 텔레메트리 / 모니터링 (Beta)

OpenTelemetry 기반으로 앱의 로그, 스팬, 메트릭을 Unity Catalog에 자동 수집할 수 있습니다.

​
설정 방법

app.yaml에 텔레메트리 설정을 추가하면 앱 코드 변경 없이 자동으로 계측됩니다: 
command: ['streamlit', 'run', 'app.py']
# 텔레메트리 내보내기 설정 (app.yaml 또는 앱 설정 UI에서)
참고 텔레메트리 데이터는 near real-time으로 Unity Catalog 시스템 테이블에 저장됩니다. 앱 성능 모니터링, 오류 추적, 사용 패턴 분석에 활용할 수 있습니다.

​
uv 의존성 관리 (2026년 3월~)

requirements.txt 대신 uv 를 사용하여 Python 의존성을 관리할 수 있습니다. 
# pyproject.toml
[project]
name = "my-databricks-app"
version = "0.1.0"
requires-python = ">=3.10"
dependencies = [
    "streamlit>=1.32.0",
    "databricks-sdk>=0.20.0",
    "pandas>=2.2.0",
]

# uv.lock 생성
uv lock
참고 uv vs pip: uv는 pip보다 최대 10-100배 빠른 의존성 해결과 설치를 제공합니다. pyproject.toml + uv.lock으로 전환하면 배포 시간이 단축됩니다. 기존 requirements.txt도 계속 지원됩니다.