이 문서는 컴퓨트 섹션의 일부입니다.
Pool vs Serverless 비교
Databricks Serverless Compute도 빠른 시작 시간을 제공합니다. 두 옵션을 비교해 보겠습니다.| 비교 항목 | Instance Pool | Serverless Compute |
|---|---|---|
| 시작 시간 | 30초~2분 | 수초~1분 |
| 인프라 관리 | Pool 설정 필요 (인스턴스 유형, 크기 등) | 관리 불필요 (완전 자동) |
| 비용 모델 | 유휴 인스턴스 비용 + 사용 비용 | 사용한 만큼만 과금 |
| 커스터마이징 | 인스턴스 유형, GPU, 스토리지 등 세밀한 설정 가능 | 제한적 |
| GPU 지원 | 지원 | 제한적 |
| 적합한 시나리오 | GPU 워크로드, 특수 인스턴스 필요 시 | 일반 SQL/Python 워크로드 |
💡 Serverless가 지원되는 워크로드 라면 Serverless를 우선 사용하고, GPU나 특수 인스턴스가 필요한 경우에만 Instance Pool을 사용하는 것이 관리 부담을 줄이는 좋은 전략입니다.
Pool 사이징 공식 (유휴 인스턴스 수 최적화)
Pool의min_idle_instances를 너무 높게 설정하면 유휴 비용이 낭비되고, 너무 낮으면 시작 시간 이점이 없어집니다. 최적 값을 계산하는 공식을 알아보겠습니다.
최적 Min Idle 계산
실무 사이징 예시
| 팀 규모 | 동시 클러스터 | 평균 Worker | 최적 Min Idle | 월 유휴 비용 (m5.xlarge) |
|---|---|---|---|---|
| 소규모 (5명) | 2~3개 | 3개 | 3~5개 | $100~170 |
| 중규모 (20명) | 5~8개 | 4개 | 8~12개 | $270~410 |
| 대규모 (50명+) | 10~20개 | 5개 | 15~25개 | $510~850 |
시간대별 동적 사이징
업무 시간과 비업무 시간의 Min Idle를 다르게 설정하면 비용을 크게 절감할 수 있습니다. Databricks API를 활용한 자동화가 가능합니다.Pool vs Serverless 비용 비교 시나리오
상세 비용 비교
| 시나리오 | Pool (m5.xlarge, Min Idle 5) | Serverless Compute |
|---|---|---|
| 월 고정 비용 (유휴) | 691** | $0(사용한 만큼만) |
| 시작 시간 | 30초~2분 | 수초~1분 |
| DBU 단가 | Standard DBU 단가 | Serverless DBU 단가 (약 2~2.5x) |
| 인스턴스 선택 | 원하는 유형 자유 선택 | 자동 선택 (제한적) |
| GPU 지원 | 지원 | 제한적 |
손익 분기점 분석
💡 판단 기준: 월 DBU 사용량이 5,000 DBU 이상 이고 GPU/특수 인스턴스가 필요 하면 Pool이 유리합니다. 그 이하거나 관리 부담을 줄이고 싶다면 Serverless를 권장합니다.
멀티 Pool 전략 (Dev/Staging/Prod)
엔터프라이즈 환경에서는 용도별로 Pool을 분리하여 비용 추적과 리소스 격리를 확보합니다.환경별 Pool 설계
| Pool | 인스턴스 유형 | Min Idle | Max Capacity | Spot | 용도 |
|---|---|---|---|---|---|
| dev-general-pool | m5.xlarge | 2 | 20 | Spot | 개발/탐색 클러스터 |
| dev-gpu-pool | g4dn.xlarge | 0 | 5 | Spot | ML 실험 |
| staging-pool | r5.2xlarge | 1 | 15 | Spot w/ Fallback | 스테이징 ETL Job |
| prod-driver-pool | m5.xlarge | 3 | 10 | On-Demand | 프로덕션 Driver 전용 |
| prod-worker-pool | r5.2xlarge | 5 | 50 | Spot w/ Fallback | 프로덕션 Worker 전용 |
| prod-ml-pool | g5.2xlarge | 0 | 10 | On-Demand | ML 서빙/추론 |
Pool과 Cluster Policy 연동
Cluster Policy로 특정 Pool 사용을 강제하면 비용 거버넌스가 강화됩니다.Pool 모니터링 (시스템 테이블)
감사 로그로 Pool 사용 현황 분석
Pool 효율성 핵심 지표
| 지표 | 계산 | 건강 기준 |
|---|---|---|
| Pool Hit Rate | Pool에서 할당 / 전체 요청 | > 80% (Pool 용량 충분) |
| 유휴 비용 비율 | 유휴 비용 / 전체 Pool 비용 | < 30% (너무 높으면 Min Idle 줄이기) |
| 평균 시작 시간 | 클러스터 시작 요청 ~ 사용 가능 | < 2분 (Pool 사용 시) |
| Max Capacity 도달 빈도 | 피크 시 Pool 포화 횟수 | 주 1회 미만 (자주 달하면 Max 증가) |
Spot Pool 구성 상세
Spot Pool 설계 시 고려사항
| 항목 | 권장 | 이유 |
|---|---|---|
| Driver Pool | On-Demand 전용 Pool | Driver 안정성 확보 |
| Worker Pool | Spot with Fallback | 비용 절감 + 안정성 |
| Min Idle + Spot | Min Idle 인스턴스도 Spot으로 | 유휴 비용 추가 절감 |
| Zone | auto | Spot 가용성이 높은 AZ 자동 선택 |
Spot Pool의 함정: 유휴 인스턴스 Eviction
⚠️ 주의: Pool의 유휴 Spot 인스턴스도 클라우드에 의해 회수될 수 있습니다. 이 경우 Pool의 유휴 인스턴스가 0이 되어 다음 클러스터 시작 시 Pool의 이점이 사라집니다.
| 대응 전략 | 설명 |
|---|---|
| Min Idle 여유분 | 예상보다 1~2개 더 높게 설정하여 Spot 회수에 대비 |
| Spot + On-Demand 혼합 | Driver Pool은 On-Demand, Worker Pool만 Spot 사용 |
| Fallback 설정 | SPOT_WITH_FALLBACK으로 Spot 부족 시 자동 On-Demand 전환 |
| 모니터링 | Pool의 실제 유휴 인스턴스 수를 모니터링하고 알림 설정 |
정리
| 개념 | 핵심 내용 |
|---|---|
| Instance Pool | 유휴 인스턴스를 미리 확보하여 클러스터 시작 시간을 단축합니다 |
| Min Idle | 항상 유지할 최소 유휴 인스턴스 수를 설정합니다 |
| Max Capacity | 풀의 최대 인스턴스 수를 제한하여 비용을 관리합니다 |
| 유휴 타임아웃 | 사용되지 않는 인스턴스를 자동 종료하여 비용을 절감합니다 |
| Runtime 사전 로드 | Spark Runtime을 미리 설치하여 추가 시간을 절약합니다 |
| Spot 조합 | Pool에 Spot 인스턴스를 사용하면 비용을 더 절감합니다 |
| 사이징 공식 | 동시 클러스터 수 x 평균 Worker 수 x 0.7로 Min Idle를 계산합니다 |
| 멀티 Pool | Dev/Staging/Prod 환경별로 Pool을 분리하여 거버넌스를 확보합니다 |
| Pool 모니터링 | Hit Rate, 유휴 비용 비율, 시작 시간을 핵심 지표로 추적합니다 |
| Spot Pool 주의 | 유휴 Spot 인스턴스도 회수될 수 있으므로 여유분을 설정합니다 |