이 문서는 Databricks 아키텍처 의 네트워크/운영 편입니다.
네트워크 트래픽 흐름 상세
주요 통신 경로
엔터프라이즈 환경에서 네트워크 구성을 이해하는 것은 매우 중요합니다.| 경로 | 방향 | 프로토콜 | 용도 |
|---|---|---|---|
| User → Control Plane | Inbound | HTTPS (443) | UI 접속, API 호출 |
| Control Plane → Compute Plane | Inbound (Classic) | SSH, HTTPS | 클러스터 관리, 명령 전달 |
| Compute Plane → Control Plane | Outbound | HTTPS (443) | SCC 터널, 결과 전송, 메타데이터 조회 |
| Compute Plane → Cloud Storage | Outbound | HTTPS (443) | 데이터 읽기/쓰기 (S3, ADLS, GCS) |
| Compute Plane → External | Outbound | 다양함 | PyPI 패키지 다운로드, 외부 DB 연결 등 |
| Compute Plane 내부 | Internal | 다양함 | Worker 간 Shuffle 통신, Driver-Worker 통신 |
PrivateLink / Private Endpoint 구성
엔터프라이즈 고객은 인터넷을 경유하지 않는 전용 연결을 요구합니다.| 연결 유형 | AWS | Azure | 용도 |
|---|---|---|---|
| 프론트엔드 연결 | VPC Endpoint (Interface) | Private Endpoint | 사용자 → Workspace UI/API 접근 |
| 백엔드 연결 | VPC Endpoint (Interface) | Private Endpoint | Compute Plane → Control Plane 통신 |
| 스토리지 연결 | VPC Endpoint (Gateway/Interface) | Private Endpoint | Compute Plane → S3/ADLS 통신 |
⚠️ 비용 고려사항: PrivateLink/Private Endpoint는 시간당 과금 + 데이터 처리량 과금이 발생합니다. AWS에서 VPC Interface Endpoint는 AZ당 약 0.01/GB입니다. 대용량 데이터 처리 시 상당한 비용이 될 수 있으므로, S3 Gateway Endpoint(무료)를 우선 사용하는 것이 좋습니다.
방화벽/NSG 최소 규칙
Classic Compute Plane을 사용하는 경우, 다음과 같은 네트워크 규칙이 필요합니다.리전별 가용성과 고가용성 (HA)
Databricks 리전별 가용성
Databricks는 주요 클라우드 리전에서 서비스를 제공합니다.| 클라우드 | 주요 리전 | 비고 |
|---|---|---|
| AWS | us-east-1, us-west-2, eu-west-1, ap-northeast-1(도쿄), ap-southeast-1(싱가포르) 등 20+ 리전 | ap-northeast-2(서울) 지원 |
| Azure | East US, West Europe, Japan East, Korea Central, Southeast Asia 등 30+ 리전 | Korea Central(서울) 지원 |
| GCP | us-central1, europe-west1, asia-northeast1(도쿄) 등 15+ 리전 | 한국 리전 미지원 (도쿄 사용) |
💡 한국 고객: AWS ap-northeast-2(서울)과 Azure Korea Central을 사용할 수 있습니다. GCP 사용 시에는 asia-northeast1(도쿄)이 가장 가까운 리전입니다.
Control Plane 고가용성
| HA 메커니즘 | 설명 |
|---|---|
| 멀티 AZ 배포 | Control Plane 서비스는 최소 3개 가용 영역(AZ)에 분산 배포됩니다 |
| 데이터 복제 | 메타데이터 DB는 동기식 복제로 데이터 손실을 방지합니다 |
| 자동 장애 조치 | Control Plane 노드 장애 시 자동으로 다른 AZ의 노드로 전환됩니다 |
| SLA | Databricks Premium/Enterprise Plan에서 99.95% 가용성 SLA를 제공합니다 |
⚠️ Control Plane 장애 시 영향: Control Plane이 다운되면 새 클러스터 시작, 작업 스케줄링, UI 접속 이 불가합니다. 단, 이미 실행 중인 클러스터와 작업은 계속 실행 됩니다(Compute Plane은 독립적). 이것이 Control/Compute Plane 분리 아키텍처의 핵심 이점입니다.
재해 복구 (DR) 패턴
Databricks DR 전략
Databricks 환경의 재해 복구는 크게 세 가지 수준으로 나뉩니다.| DR 수준 | RPO | RTO | 비용 | 설명 |
|---|---|---|---|---|
| Level 1: 데이터 DR | 수 분 | 수 시간 | 낮음 | 데이터(Delta Lake)만 복제, Workspace는 수동 재구성 |
| Level 2: 설정 포함 DR | 수 분 | 1~2시간 | 중간 | 데이터 + Workspace 설정(Terraform/DABs)을 코드로 관리 |
| Level 3: Active-Active | ~0 | 수 분 | 높음 | 두 리전에 동시 운영, 즉시 전환 가능 |
💡 RPO(Recovery Point Objective) 는 “데이터를 얼마나 잃어도 되는가”, RTO(Recovery Time Objective) 는 “복구에 얼마나 걸려도 되는가”입니다.
실전 DR 아키텍처 패턴
| 구성 요소 | Primary Region (서울) | Secondary Region (도쿄) | 복제 방식 |
|---|---|---|---|
| Workspace | Active | Standby / Active | Terraform / DABs (Git) |
| Delta Lake (S3/ADLS) | 원본 | 복제본 | DEEP CLONE |
| Unity Catalog Metastore | 원본 | 공유 또는 동기화 | 리전 간 Metastore 공유 |
| 설정 관리 | Terraform / DABs (Git 저장소) | 동일 코드 기반 배포 | Git 저장소 |
DR 구현 핵심 요소
| 요소 | 권장 방법 | 설명 |
|---|---|---|
| Delta 테이블 복제 | DEEP CLONE + 스케줄링 | 주기적으로 DR 리전에 테이블을 복제합니다 |
| 스토리지 복제 | S3 Cross-Region Replication / Azure GRS | 클라우드 네이티브 복제를 활용합니다 |
| Workspace 설정 | Terraform Provider for Databricks | 모든 Workspace 설정을 IaC로 관리합니다 |
| 노트북/코드 | Git 연동 (GitHub/Azure DevOps) | 코드는 항상 Git에 저장하여 리전 독립적으로 관리합니다 |
| UC 메타데이터 | 리전 간 Metastore 공유 또는 동기화 | 같은 클라우드 내에서 메타스토어를 공유할 수 있습니다 |
| 시크릿 | Vault/AWS Secrets Manager 멀티 리전 | 자격증명도 DR 리전에 동기화합니다 |
⚠️ DR 비용 고려: Active-Active 구성은 거의 2배의 비용 이 발생합니다. 대부분의 고객에게는 Level 2(설정 포함 DR)가 비용 대비 효과가 가장 좋습니다. 금융, 의료 등 규제 산업에서만 Level 3를 권장합니다.
Delta Lake DEEP CLONE을 활용한 DR
비용 최적화 관점
아키텍처 선택은 비용에 직접적인 영향을 미칩니다.| 최적화 영역 | 전략 | 예상 절감 |
|---|---|---|
| Serverless vs Classic | 간헐적 워크로드는 Serverless, 상시 워크로드는 Classic | 20~50% |
| Spot/Preemptible Instance | Classic 모드에서 Worker에 Spot Instance 사용 | 60~80% (Worker 비용) |
| Auto Scaling | min/max worker 적절히 설정, 유휴 시 자동 축소 | 30~50% |
| Auto Termination | 클러스터 비활성 시 자동 종료 (기본 120분 → 30분 권장) | 가변적 |
| Photon 엔진 | SQL 워크로드에서 Photon 활성화 (처리 속도↑, 총 비용↓) | 20~40% |
| 적절한 VM 유형 | 메모리 집약 vs 컴퓨팅 집약 워크로드에 맞는 VM 선택 | 15~30% |