이 문서는 Databricks 아키텍처 의 기초 편입니다.
왜 아키텍처를 이해해야 하나요?
Databricks를 사용하다 보면 “내 데이터는 어디에 저장되는 거지?”, “클러스터는 누가 관리하지?”, “보안은 어떻게 되는 거지?” 같은 질문이 생깁니다. 이 질문들에 답하려면 Databricks의 아키텍처를 이해해야 합니다. Databricks 아키텍처의 핵심은 Control Plane(제어 평면) 과 Compute Plane(컴퓨트 평면) 의 분리입니다.Control Plane vs Compute Plane
💡 Control Plane(제어 평면) 이란 Databricks가 직접 관리하는 영역으로, 사용자 인터페이스, 작업 스케줄링, 노트북 관리 등 “관리 기능”을 담당합니다. Compute Plane(컴퓨트 평면) 이란 고객의 클라우드 계정에서 실행되는 영역으로, 실제 데이터 처리와 저장이 이루어지는 곳입니다.이 분리가 중요한 이유를 실무 관점에서 설명드리겠습니다. 데이터 주권(Data Sovereignty): 고객의 데이터는 항상 고객의 클라우드 계정(S3, ADLS, GCS)에 저장 됩니다. Databricks Control Plane은 메타데이터와 실행 명령만 관리하고, 실제 데이터는 절대 Databricks 측으로 이동하지 않습니다. 이것은 GDPR, HIPAA, 금융 규제에서 요구하는 데이터 레지던시 요건을 충족하는 핵심 설계입니다. 경쟁사와의 차이: Snowflake는 데이터를 자체 관리 스토리지에 저장하므로, 데이터 이동(egress) 비용과 데이터 이식성이 제한됩니다. Databricks는 오픈 포맷(Delta Lake/Parquet)으로 고객 스토리지에 저장하므로, 언제든 다른 도구에서 직접 읽을 수 있습니다. 실전에서의 의미: Control Plane 장애가 발생해도 데이터는 안전합니다. 고객의 S3 버킷에 그대로 있으므로, 다른 Spark 클러스터나 Trino, Snowflake에서도 Delta/Parquet 파일을 직접 읽을 수 있습니다. 이런 아키텍처 덕분에 특정 벤더에 완전히 종속되는 리스크가 크게 줄어듭니다.
아키텍처 다이어그램
출처: Databricks 공식 문서 — Architecture overview
각 영역의 상세 구성
Control Plane (Databricks 관리 영역) — 메타데이터만 저장
중요: Control Plane에는 고객의 실제 데이터가 저장되지 않습니다. 테이블 이름, 스키마 정의, 권한 정보 같은 메타데이터와 실행 명령만 관리합니다. 고객 데이터는 항상 고객의 클라우드 스토리지(S3/ADLS/GCS)에 있습니다.
| 구성 요소 | 역할 |
|---|---|
| Web Application | 브라우저에서 접속하는 Workspace UI |
| Job Scheduler | 작업 스케줄링과 실행 명령 — 실제 실행은 Compute Plane에서 수행 |
| Notebook Service | 노트북 코드와 설정의 버전 관리 — 실행 결과 데이터는 Compute Plane에 저장 |
| Cluster Manager | 클러스터 생성/스케일링/종료 제어 — 실제 VM은 Compute Plane에 생성 |
| Unity Catalog Metastore | 테이블 이름, 스키마, 권한 등 메타데이터만 저장 — 실제 데이터 파일은 고객 스토리지 |
| IAM (Identity & Access) | 사용자 인증과 권한 관리 |
Compute Plane (고객 클라우드 영역) — 실제 데이터가 있는 곳
핵심: 고객의 실제 데이터와 컴퓨트 리소스가 위치합니다. 데이터는 고객의 클라우드 계정을 절대 벗어나지 않습니다.
| 구성 요소 | 역할 |
|---|---|
| Compute Clusters | Spark 작업을 실행하는 VM 클러스터 — 고객의 클라우드 계정에서 실행 |
| Cloud Storage | Delta Lake 테이블, 파일 등 실제 데이터 저장 (S3/ADLS/GCS) |
| Network (VPC/VNet) | 고객의 가상 네트워크 안에서 안전하게 통신 |
💡 VPC(Virtual Private Cloud)란? 클라우드 안에서 논리적으로 격리된 네트워크 공간입니다. 마치 큰 건물(클라우드) 안에 전용 사무실(VPC)을 빌리는 것과 같습니다. 외부에서 함부로 접근할 수 없고, 허용된 경로로만 통신할 수 있습니다. AWS에서는 VPC, Azure에서는 VNet(Virtual Network)이라고 부릅니다.
Serverless Compute Plane
최근 Databricks는 Serverless 옵션을 통해 Compute Plane의 관리 부담을 더욱 줄이고 있습니다.💡 서버리스(Serverless)란? 사용자가 서버(컴퓨팅 리소스)를 직접 생성하거나 관리할 필요 없이, 작업을 실행하면 시스템이 알아서 적절한 리소스를 할당해 주는 방식입니다. “서버가 없다”는 뜻이 아니라, “서버 관리를 신경 쓰지 않아도 된다”는 의미입니다.
출처: Databricks Docs
| 비교 항목 | 클래식 (Customer-Managed) | 서버리스 (Serverless) |
|---|---|---|
| 리소스 관리 | 고객이 직접 클러스터 설정 | Databricks가 자동 관리 |
| 시작 시간 | 수 분 (클러스터 시작) | 수 초 (즉시 시작) |
| 비용 모델 | 클러스터 실행 시간 기준 | 실제 처리량 기준 |
| 네트워크 격리 | 고객 VPC 안에서 실행 | Databricks 관리 환경에서 고객별 완전 격리 |
| 데이터 격리 | 고객 스토리지 직접 관리 | 고객 스토리지에 접근하되, 컴퓨트는 고객 간 완전 분리 |
| 적합한 경우 | 세밀한 네트워크 제어가 필요할 때 | 빠른 시작, 간편 운영 |
서버리스 격리 보장: 서버리스 Compute Plane은 고객의 워크로드를 다른 고객과 완전히 격리된 환경에서 실행합니다. 각 고객의 컴퓨트 리소스는 전용 컨테이너에서 실행되고, 네트워크도 분리되며, 작업 완료 후 환경이 즉시 폐기됩니다. 다른 고객의 데이터나 네트워크에 접근할 수 없으며, 이는 클래식 Compute Plane에서 고객이 자체 VPC로 격리하는 것과 동등한 수준의 보안입니다.
🆕 최신 동향: Databricks는 SQL Warehouse, Notebooks, Jobs, SDP, Apps 등 대부분의 워크로드에서 Serverless를 지원하며, 점차 기본(default) 모드로 전환하고 있습니다.
클라우드별 아키텍처
세 클라우드에서의 기본 구조는 동일하지만, 사용되는 클라우드 서비스 이름이 다릅니다.| 구성 요소 | AWS | Azure | GCP |
|---|---|---|---|
| 오브젝트 스토리지 | S3 | ADLS Gen2 | GCS |
| 네트워크 | VPC | VNet | VPC |
| 컴퓨트 VM | EC2 | Azure VM | Compute Engine |
| IAM | AWS IAM | Azure AD (Entra ID) | Cloud IAM |
| 네트워크 격리 | PrivateLink | Private Endpoint | Private Service Connect |
Workspace의 개념
💡 Workspace(워크스페이스) 란 Databricks에서 작업을 수행하는 독립적인 작업 환경 입니다. 하나의 조직에서 여러 개의 Workspace를 만들 수 있으며, 각 Workspace는 고유한 URL을 가집니다.Workspace는 다음과 같은 구성 요소를 포함합니다.
| 구성 요소 | 설명 |
|---|---|
| Notebooks | 코드 작성 및 실행 |
| Repos | Git 저장소 연동 |
| Clusters | 컴퓨팅 리소스 |
| Jobs | 스케줄된 작업 |
| SQL Editor | SQL 쿼리 편집기 |
| Dashboards | 시각화 대시보드 |
Workspace 구성 모범 사례
| 전략 | 설명 | 적합한 경우 |
|---|---|---|
| 환경별 분리 | 개발(Dev), 스테이징(Staging), 프로덕션(Prod) 별도 Workspace | 대부분의 기업에 권장됩니다 |
| 팀별 분리 | 데이터 엔지니어링 팀, 분석 팀, ML 팀 별도 Workspace | 팀 간 격리가 필요할 때 |
| 단일 Workspace | 모든 팀이 하나의 Workspace 사용 | 소규모 조직 |
💡 Unity Catalog 는 여러 Workspace에 걸쳐 공유될 수 있습니다. 따라서 Workspace를 분리하더라도 데이터에 대한 통합 거버넌스를 유지할 수 있습니다.
Classic Compute Plane vs Serverless Compute Plane 아키텍처 심화
Classic Compute Plane 상세
Classic Compute Plane에서는 클러스터가 고객의 VPC/VNet 안에서 실행됩니다. 이 모델의 핵심 특징을 살펴보겠습니다.| 구성 요소 | 상세 설명 |
|---|---|
| Driver Node | Spark Application의 마스터 노드입니다. SparkContext를 생성하고, DAG 스케줄링, 태스크 분배를 수행합니다 |
| Worker Nodes | 실제 데이터 처리를 수행하는 Executor가 실행됩니다. Auto Scaling으로 동적 증감합니다 |
| NAT Gateway | Worker → 인터넷 통신 시 NAT Gateway를 경유합니다. Control Plane과의 통신도 이 경로를 사용합니다 |
| SCC Relay | Secure Cluster Connectivity 활성화 시, Compute Plane에서 Control Plane으로의 아웃바운드 연결만 허용됩니다 |
| DBFS Root | Workspace 생성 시 자동으로 만들어지는 S3/ADLS 버킷입니다. 클러스터 로그, 라이브러리 등이 저장됩니다 |
Serverless Compute Plane 상세
Serverless 모드에서는 컴퓨팅이 Databricks가 관리하는 클라우드 계정 에서 실행됩니다. 이 아키텍처에는 중요한 차이가 있습니다.| 항목 | Classic | Serverless |
|---|---|---|
| VM 위치 | 고객 클라우드 계정 | Databricks 관리 계정 |
| 네트워크 격리 | 고객 VPC에 배포 | Databricks 관리 VPC + 전용 네트워크 격리 |
| 데이터 접근 | VPC 내부에서 직접 접근 | Secure Channel을 통해 고객 스토리지에 접근 |
| 비용 구조 | DBU + 클라우드 인프라 비용 별도 | DBU에 인프라 비용 포함 (올인원) |
| Cold Start | 3~10분 (VM 프로비저닝) | 5~15초 (Warm Pool에서 즉시 할당) |
| 패치/업데이트 | 고객이 DBR 버전 관리 | Databricks가 자동 업데이트 |
| 커스터마이징 | Init Script, 커스텀 AMI, 라이브러리 자유 | 제한적 (표준화된 환경) |
💡 Serverless Warm Pool: Databricks는 미리 프로비저닝된 VM 풀(Warm Pool)을 유지하여 Serverless 컴퓨트의 시작 시간을 수 초로 줄입니다. 이는 마치 “대기 중인 택시”와 같아서, 요청이 오면 즉시 할당됩니다.
Serverless 보안 모델
Serverless Compute Plane의 보안에 대해 고객이 자주 우려하는 부분을 정리합니다.| 보안 메커니즘 | 설명 |
|---|---|
| Workload Isolation | 각 고객의 워크로드는 전용 VM에서 실행되며, 다른 고객과 하드웨어를 공유하지 않습니다 (단일 테넌트 VM) |
| 네트워크 격리 | 각 워크로드에 전용 네트워크 네임스페이스가 할당됩니다 |
| 데이터 암호화 | 전송 중(TLS 1.2+) + 저장 시(AES-256) 암호화됩니다 |
| Credential Passthrough | Serverless에서 고객 스토리지 접근 시 임시 자격증명(STS Token)을 사용하여 장기 키를 노출하지 않습니다 |
| 감사 로그 | 모든 Serverless 작업이 고객의 감사 로그에 기록됩니다 |