Skip to main content
이 문서는 Databricks 아키텍처 의 네트워크/운영 편입니다.

네트워크 트래픽 흐름 상세

주요 통신 경로

엔터프라이즈 환경에서 네트워크 구성을 이해하는 것은 매우 중요합니다.
경로방향프로토콜용도
User → Control PlaneInboundHTTPS (443)UI 접속, API 호출
Control Plane → Compute PlaneInbound (Classic)SSH, HTTPS클러스터 관리, 명령 전달
Compute Plane → Control PlaneOutboundHTTPS (443)SCC 터널, 결과 전송, 메타데이터 조회
Compute Plane → Cloud StorageOutboundHTTPS (443)데이터 읽기/쓰기 (S3, ADLS, GCS)
Compute Plane → ExternalOutbound다양함PyPI 패키지 다운로드, 외부 DB 연결 등
Compute Plane 내부Internal다양함Worker 간 Shuffle 통신, Driver-Worker 통신
엔터프라이즈 고객은 인터넷을 경유하지 않는 전용 연결을 요구합니다.
연결 유형AWSAzure용도
프론트엔드 연결VPC Endpoint (Interface)Private Endpoint사용자 → Workspace UI/API 접근
백엔드 연결VPC Endpoint (Interface)Private EndpointCompute Plane → Control Plane 통신
스토리지 연결VPC Endpoint (Gateway/Interface)Private EndpointCompute Plane → S3/ADLS 통신
⚠️ 비용 고려사항: PrivateLink/Private Endpoint는 시간당 과금 + 데이터 처리량 과금이 발생합니다. AWS에서 VPC Interface Endpoint는 AZ당 약 0.01/hr+0.01/hr + 0.01/GB입니다. 대용량 데이터 처리 시 상당한 비용이 될 수 있으므로, S3 Gateway Endpoint(무료)를 우선 사용하는 것이 좋습니다.

방화벽/NSG 최소 규칙

Classic Compute Plane을 사용하는 경우, 다음과 같은 네트워크 규칙이 필요합니다.
# Outbound 규칙 (Compute Plane → 외부)
1. Control Plane (Webapp)     → HTTPS 443  — 필수
2. Control Plane (SCC Relay)  → HTTPS 443  — 필수
3. S3/ADLS/GCS               → HTTPS 443  — 필수
4. Unity Catalog Metastore    → HTTPS 443  — 필수
5. 패키지 저장소 (PyPI 등)     → HTTPS 443  — 선택
6. Worker 간 Shuffle          → 내부 통신   — 필수 (Security Group 내부)

# Inbound 규칙 (외부 → Compute Plane)
7. SCC 사용 시: 없음 (모든 인바운드 차단 가능)
8. SCC 미사용 시: Control Plane → SSH 2200, HTTPS 443

리전별 가용성과 고가용성 (HA)

Databricks 리전별 가용성

Databricks는 주요 클라우드 리전에서 서비스를 제공합니다.
클라우드주요 리전비고
AWSus-east-1, us-west-2, eu-west-1, ap-northeast-1(도쿄), ap-southeast-1(싱가포르) 등 20+ 리전ap-northeast-2(서울) 지원
AzureEast US, West Europe, Japan East, Korea Central, Southeast Asia 등 30+ 리전Korea Central(서울) 지원
GCPus-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의 노드로 전환됩니다
SLADatabricks Premium/Enterprise Plan에서 99.95% 가용성 SLA를 제공합니다
⚠️ Control Plane 장애 시 영향: Control Plane이 다운되면 새 클러스터 시작, 작업 스케줄링, UI 접속 이 불가합니다. 단, 이미 실행 중인 클러스터와 작업은 계속 실행 됩니다(Compute Plane은 독립적). 이것이 Control/Compute Plane 분리 아키텍처의 핵심 이점입니다.

재해 복구 (DR) 패턴

Databricks DR 전략

Databricks 환경의 재해 복구는 크게 세 가지 수준으로 나뉩니다.
DR 수준RPORTO비용설명
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 (도쿄)복제 방식
WorkspaceActiveStandby / ActiveTerraform / 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

-- 테이블 단위 DR 복제
CREATE OR REPLACE TABLE dr_catalog.schema.orders
DEEP CLONE production.ecommerce.orders
LOCATION 's3://dr-bucket/ecommerce/orders/';

-- 증분 복제 (변경분만)
CREATE OR REPLACE TABLE dr_catalog.schema.orders
DEEP CLONE production.ecommerce.orders;
-- DEEP CLONE은 자동으로 마지막 복제 이후 변경분만 복사합니다

비용 최적화 관점

아키텍처 선택은 비용에 직접적인 영향을 미칩니다.
최적화 영역전략예상 절감
Serverless vs Classic간헐적 워크로드는 Serverless, 상시 워크로드는 Classic20~50%
Spot/Preemptible InstanceClassic 모드에서 Worker에 Spot Instance 사용60~80% (Worker 비용)
Auto Scalingmin/max worker 적절히 설정, 유휴 시 자동 축소30~50%
Auto Termination클러스터 비활성 시 자동 종료 (기본 120분 → 30분 권장)가변적
Photon 엔진SQL 워크로드에서 Photon 활성화 (처리 속도↑, 총 비용↓)20~40%
적절한 VM 유형메모리 집약 vs 컴퓨팅 집약 워크로드에 맞는 VM 선택15~30%