Databricks 플랫폼 아키텍처 상세 가이드

NewNewDaddy·2026년 1월 27일

DATABRICKS

목록 보기

3/3

0. INTRO

왜 Databricks 아키텍처를 이해해야 할까?

Databricks를 처음 사용하는 개발자나 관리자에게 가장 혼란스러운 부분 중 하나는 "데이터가 어디에 저장되는가?", "컴퓨팅 리소스는 어디서 실행되는가?", "보안은 어떻게 구성되는가?"와 같은 아키텍처 관련 질문입니다.

Databricks는 전통적인 단일 계정 구조가 아니라, Databricks 계정과 고객 계정으로 분리된 하이브리드 아키텍처를 사용합니다. 이 구조를 이해하지 못하면, 네트워크 설정, 보안 정책, 비용 관리 등에서 예상치 못한 문제에 직면할 수 있습니다.

이 글에서는 Databricks의 데이터 인텔리전스 플랫폼 아키텍처를 계층별로 설명하고, 각 구성 요소의 역할과 상호작용을 이해할 수 있도록 정리합니다.

Databricks 아키텍처의 핵심 개념

Databricks 플랫폼은 크게 두 가지 계정 영역으로 나뉘어 운영됩니다:

Databricks 계정 (Databricks Account)
- Databricks가 직접 관리하는 영역
- Control Plane과 Serverless Compute가 배포됨
- 고객의 클라우드 계정과 분리되어 운영
고객 계정 (Customer Account)
- 고객의 클라우드 환경(AWS, Azure, GCP) 내에 존재
- 데이터 저장소(Cloud Storage)와 Classic Compute가 실행됨
- 고객이 직접 관리하는 네트워크 및 보안 설정 적용

이러한 분리 구조는 다음과 같은 이점을 제공합니다:

보안 격리: Control Plane과 데이터 저장소를 분리하여 보안 강화
유연한 배포: Serverless와 Classic Compute를 선택적으로 사용 가능
비용 최적화: 사용 패턴에 따라 적절한 컴퓨팅 모델 선택 가능

1. 전체 플랫폼 구조 (High-Level Architecture)

1) 아키텍처 다이어그램 개념

┌─────────────────────────────────────────────────────────┐
│              Databricks 계정 (Databricks Account)   │
│  ┌──────────────────────────────────────────────────┐   │
│  │         Control Plane (컨트롤 플레인)          │   │
│  │  - Web App                                   │   │
│  │  - Unity Catalog                             │   │
│  │  - Workflow Management                       │   │
│  │  - Intelligence Engine                       │   │
│  └──────────────────────────────────────────────────┘   │
│  ┌──────────────────────────────────────────────────┐   │
│  │    Serverless Compute Plane (서버리스 컴퓨팅)  │   │
│  │  - Serverless SQL Warehouse                  │   │
│  │  - Model Serving                             │   │
│  │  - Vector Search                             │   │
│  │  - Online Tables                             │   │
│  └──────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────┘
                          │
                          │ 네트워크 연결
                          │
┌─────────────────────────────────────────────────────────┐
│            고객 계정 (Customer Cloud Account)        │
│  ┌──────────────────────────────────────────────────┐   │
│  │         Classic Compute Plane                │   │
│  │  - Workspace Clusters                        │   │
│  │  - Classic SQL Warehouse                     │   │
│  └──────────────────────────────────────────────────┘   │
│  ┌──────────────────────────────────────────────────┐   │
│  │              Cloud Storage                   │   │
│  │  - S3 / ADLS / GCS                           │   │
│  │  - Delta Tables                              │   │
│  └──────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────┘

2) 계정 간 데이터 흐름

사용자 요청: 사용자가 Web App을 통해 쿼리나 작업을 요청
Control Plane 처리: Unity Catalog가 권한을 확인하고 작업을 스케줄링
Compute 실행: Classic 또는 Serverless Compute에서 실제 데이터 처리
Storage 접근: Compute가 고객 계정의 Cloud Storage에서 데이터 읽기/쓰기
결과 반환: 처리 결과를 사용자에게 반환

2. 주요 구성 요소 상세 설명

1) Control Plane (컨트롤 플레인)

Control Plane은 Databricks의 두뇌 역할을 하며, 플랫폼의 모든 관리 및 오케스트레이션 기능을 제공합니다.

Web App

역할: 사용자가 Databricks 플랫폼에 접속하는 주요 인터페이스

주요 기능:

노트북 작성 및 실행
SQL 쿼리 실행
작업(Jobs) 관리 및 모니터링
Unity Catalog를 통한 데이터 탐색
클러스터 및 워크스페이스 관리

실무 관점:

Web App은 Databricks 계정에 배포되어 있으므로, 인터넷 연결만 있으면 어디서든 접근 가능
SSO(Single Sign-On)를 통해 기업 인증 시스템과 통합 가능

Unity Catalog

역할: 데이터 거버넌스의 핵심으로, 모든 데이터 객체에 대한 중앙 집중식 메타데이터 및 권한 관리

주요 기능:

접근 제어(Access Control): 테이블, 뷰, 함수 등에 대한 세밀한 권한 관리
메타데이터 관리: 데이터 객체의 스키마, 통계, 리니지 정보 저장
데이터 리니지: 데이터의 출처와 변환 과정 추적
데이터 검색: 메타데이터 기반 데이터 검색 및 탐색

실무 관점:

Unity Catalog는 Databricks 계정에 위치하지만, 고객 계정의 스토리지에 대한 메타데이터를 관리
여러 워크스페이스에서 동일한 메타스토어를 공유하여 데이터 일관성 유지

Workflow Management

역할: 데이터 파이프라인과 작업 워크플로우를 오케스트레이션

주요 기능:

Jobs: 스케줄링된 작업 실행 및 관리
Delta Live Tables (DLT): 선언적 데이터 파이프라인 구축
의존성 관리: 작업 간 의존성 및 실행 순서 관리
모니터링: 작업 실행 상태 및 성능 모니터링

실무 관점:

Workflow Management는 작업을 스케줄링하고 모니터링하지만, 실제 실행은 Compute Plane에서 수행
작업 실패 시 자동 재시도 및 알림 기능 제공

Intelligence Engine

역할: 머신러닝 모델을 사용하여 플랫폼을 최적화하고 관리

주요 기능:

자동 최적화: 쿼리 성능 및 리소스 사용량 최적화
예측 분석: 리소스 사용 패턴 예측 및 자동 스케일링
비용 최적화: 비용 효율적인 리소스 할당 제안
문제 감지: 성능 저하나 오류 패턴 자동 감지

실무 관점:

Intelligence Engine은 백그라운드에서 작동하여 사용자가 명시적으로 설정하지 않아도 자동으로 최적화 수행
시간이 지날수록 더 정확한 최적화 제안 제공

2) Compute Plane (컴퓨팅 플레인)

Compute Plane은 실제 데이터 처리가 일어나는 계층입니다. Databricks는 두 가지 컴퓨팅 모델을 제공합니다.

Classic Compute (클래식 컴퓨팅)

특징:

고객의 클라우드 계정 내 가상 네트워크(VNet/VPC)에서 실행
고객이 직접 네트워크 및 보안 설정 관리
완전한 제어권과 커스터마이징 가능

주요 구성 요소:

Workspace Clusters: 노트북 실행 및 작업 실행용 클러스터
Classic SQL Warehouse: SQL 쿼리 실행용 전용 웨어하우스

장점:

네트워크 격리 및 보안 정책을 완전히 제어 가능
기존 클라우드 인프라와의 통합 용이
특정 규정 준수 요구사항 충족 가능

단점:

클러스터 시작 시간이 상대적으로 김 (수 분 소요)
유지보수 및 패치 관리를 고객이 담당해야 함
초기 설정 및 구성이 복잡할 수 있음

실무 활용:

엄격한 보안 요구사항이 있는 조직
기존 클라우드 네트워크와의 통합이 필요한 경우
장기 실행 작업이나 대용량 데이터 처리

Serverless Compute (서버리스 컴퓨팅)

특징:

Databricks 계정 내에서 실행
Databricks가 인프라 관리 및 유지보수 담당
빠른 시작 시간과 자동 스케일링

주요 구성 요소:

Serverless SQL Warehouse: 서버리스 환경에서 실행되는 SQL 웨어하우스
Model Serving: 실시간 ML 모델 서빙
Vector Search: 벡터 검색 서비스
Online Tables: 실시간 데이터 동기화

장점:

빠른 시작: 클러스터 시작 시간이 수 초 내로 단축
유지보수 부담 감소: Databricks가 패치 및 업데이트 관리
자동 스케일링: 워크로드에 따라 자동으로 리소스 조정
비용 효율성: 사용한 만큼만 비용 지불

단점:

네트워크 제어가 제한적 (Private Link로 일부 해결 가능)
특정 커스터마이징 제한
다중 테넌트 환경 (격리는 보장되지만)

실무 활용:

빠른 쿼리 응답이 필요한 BI 및 분석 작업
간헐적인 워크로드
유지보수 부담을 줄이고 싶은 경우
실시간 AI 애플리케이션

3. 서비스 모델별 아키텍처 특징

1) Databricks SQL: Classic vs. Serverless

Classic SQL Warehouse

아키텍처:

고객 클라우드 계정
  └─ VNet/VPC
      └─ 로드 밸런서
          └─ 컴퓨팅 클러스터 (고객 관리)
              └─ Cloud Storage 접근

특징:

고객의 클라우드 계정 내에서 실행
로드 밸런서 뒤에서 실행되는 컴퓨팅 클러스터 사용
네트워크 및 보안 설정을 고객이 완전히 제어
VNet/VPC 피어링을 통한 온프레미스 시스템과의 통합 가능

실무 관점:

기존 클라우드 네트워크와의 통합이 필요한 경우
특정 IP 대역이나 방화벽 규칙이 필요한 경우
장기 실행 쿼리나 대용량 데이터 처리

Serverless SQL Warehouse

아키텍처:

Databricks 계정
  └─ 다중 테넌트 인프라
      └─ VM 격리 (테넌트별)
          └─ 네트워크 격리 (테넌트별)
              └─ Cloud Storage 접근 (Private Link)

특징:

컴퓨팅 리소스가 Databricks 클라우드 계정에서 실행
다중 테넌트(Multi-tenant) 구조
각 테넌트 간 VM 및 네트워크 수준에서 엄격히 격리
Private Link를 통한 안전한 스토리지 접근

실무 관점:

빠른 쿼리 시작이 필요한 경우
유지보수 부담을 줄이고 싶은 경우
Azure 환경에서는 Private Link로 보안 연결 가능

보안 고려사항:

다중 테넌트 환경이지만 격리는 보장됨
Azure에서는 Private Link를 통해 스토리지와의 통신을 비공개로 유지 가능
AWS와 GCP에서도 유사한 프라이빗 연결 옵션 제공

2) Serverless 확장 서비스

Model Serving & Vector Search

역할: 실시간 AI 애플리케이션을 위한 서버리스 인프라 제공

Model Serving:

ML 모델을 REST API 엔드포인트로 노출
자동 스케일링 및 고가용성 보장
A/B 테스팅 및 모델 버전 관리 지원

Vector Search:

벡터 임베딩을 인덱싱하여 유사도 검색 제공
RAG(Retrieval-Augmented Generation) 애플리케이션 지원
실시간 업데이트 및 검색 가능

실무 활용:

챗봇 및 생성형 AI 애플리케이션
추천 시스템
이미지 및 텍스트 유사도 검색

Online Tables

역할: Delta Table과 실시간으로 동기화되는 온라인 테이블 제공

특징:

Delta Table의 변경사항을 실시간으로 동기화
낮은 지연 시간의 읽기 접근 제공
서버리스 인프라에서 자동 관리

실무 활용:

실시간 추천 시스템
실시간 대시보드
실시간 의사결정 애플리케이션

4. 보안 및 사용자 관리

1) Identity Provider (IDP) 통합

역할: 고객의 중앙 사용자 관리 시스템과 Databricks를 통합

지원하는 IDP:

Azure AD / Microsoft Entra ID: Azure 환경에서 주로 사용
Okta: 엔터프라이즈 SSO 솔루션
Google Workspace: GCP 환경에서 주로 사용
SAML 2.0 호환 IDP: 기타 SAML 2.0을 지원하는 모든 IDP

주요 기능:

SSO (Single Sign-On): 기업 인증 시스템을 통한 자동 로그인
SCIM 프로비저닝: 사용자 및 그룹 자동 동기화
역할 기반 접근 제어: IDP 그룹을 Databricks 그룹으로 매핑

실무 관점:

사용자 생명주기 관리를 IDP에서 중앙 집중식으로 관리
퇴사자나 역할 변경 시 자동으로 Databricks 접근 권한 업데이트
여러 워크스페이스에서 동일한 사용자 및 그룹 구조 공유 가능

2) Network Security

Private Link (Azure)

역할: 서버리스 컴퓨팅 플레인에서 고객의 스토리지 계정으로의 보안 연결 제공

작동 방식:
1. Databricks가 고객의 VNet에 Private Endpoint 생성
2. 서버리스 컴퓨팅이 Private Endpoint를 통해 스토리지 접근
3. 모든 트래픽이 Microsoft 백본 네트워크를 통해 전송
4. 공용 인터넷을 거치지 않아 보안 강화

장점:

공용 인터넷을 거치지 않는 안전한 연결
네트워크 격리 및 방화벽 규칙 적용 가능
데이터 유출 위험 감소

실무 활용:

엄격한 보안 요구사항이 있는 조직
규정 준수 요구사항 충족
민감한 데이터 처리

VNet/VPC 피어링 (Classic Compute)

역할: Classic Compute가 고객의 기존 네트워크와 직접 통신

작동 방식:
1. Databricks VNet/VPC와 고객 VNet/VPC 간 피어링 설정
2. Classic Compute가 피어링된 네트워크를 통해 리소스 접근
3. 온프레미스 시스템과의 VPN/ExpressRoute 연결 가능

실무 활용:

온프레미스 데이터베이스 접근
기존 클라우드 리소스와의 통합
하이브리드 클라우드 아키텍처

5. 실무 활용 가이드

1) 시나리오 1: 엄격한 보안 요구사항이 있는 금융 기관

요구사항:

모든 데이터가 고객 계정 내에만 존재
네트워크 격리 및 방화벽 규칙 적용
온프레미스 시스템과의 통합 필요

아키텍처 선택:

Classic Compute 사용
VNet/VPC 피어링을 통한 온프레미스 연결
Private Link는 사용하지 않음 (모든 리소스가 고객 계정 내)

구성:

고객 계정 (Azure)
  ├─ VNet (피어링됨)
  │   ├─ Classic SQL Warehouse
  │   └─ Workspace Clusters
  ├─ Storage Account (Private Endpoint)
  └─ 온프레미스 연결 (ExpressRoute)

2) 시나리오 2: 빠른 프로토타이핑이 필요한 스타트업

요구사항:

빠른 시작 및 유지보수 최소화
비용 효율성
실시간 AI 기능 필요

아키텍처 선택:

Serverless Compute 우선 사용
Model Serving 및 Vector Search 활용
Classic Compute는 대용량 배치 작업에만 사용

구성:

Databricks 계정
  ├─ Serverless SQL Warehouse (일반 쿼리)
  ├─ Model Serving (실시간 추론)
  └─ Vector Search (RAG 애플리케이션)

고객 계정
  └─ Cloud Storage (Delta Tables)

3) 시나리오 3: 하이브리드 워크로드가 있는 대기업

요구사항:

다양한 워크로드 지원 (배치, 스트리밍, 실시간)
보안과 성능의 균형
비용 최적화

아키텍처 선택:

Classic Compute: 장기 실행 배치 작업, 엄격한 보안 요구사항
Serverless Compute: 빠른 쿼리, 실시간 AI, 간헐적 워크로드
Private Link: Serverless에서 스토리지 접근 시 사용

구성:

Databricks 계정
  ├─ Serverless SQL Warehouse (BI 쿼리)
  ├─ Model Serving (실시간 AI)
  └─ Private Link (스토리지 접근)

고객 계정
  ├─ Classic SQL Warehouse (대용량 배치)
  ├─ Workspace Clusters (데이터 엔지니어링)
  └─ Cloud Storage (Delta Tables)

6. 아키텍처 선택 가이드

1) Classic vs. Serverless 비교표

기준	Classic Compute	Serverless Compute
시작 시간	수 분	수 초
유지보수	고객 담당	Databricks 담당
네트워크 제어	완전한 제어	제한적 (Private Link로 보완)
비용 모델	예약 인스턴스 가능	사용한 만큼 지불
커스터마이징	높음	제한적
보안	완전한 격리	다중 테넌트 (격리 보장)
온프레미스 통합	VNet 피어링 가능	제한적
적합한 워크로드	장기 실행, 대용량	간헐적, 빠른 응답 필요

2) 선택 기준

Classic Compute를 선택해야 하는 경우:

엄격한 네트워크 격리 요구사항
온프레미스 시스템과의 직접 통합 필요
장기 실행 작업이나 대용량 데이터 처리
특정 규정 준수 요구사항 (예: 데이터가 특정 지역에만 존재해야 함)

Serverless Compute를 선택해야 하는 경우:

빠른 시작 시간이 중요
유지보수 부담을 줄이고 싶음
간헐적인 워크로드
실시간 AI 애플리케이션
비용 효율적인 리소스 사용

하이브리드 접근:

대부분의 조직은 두 방식을 조합하여 사용
워크로드 특성에 따라 적절한 Compute 모델 선택
Classic은 배치 및 데이터 엔지니어링, Serverless는 분석 및 실시간 작업

7. 마무리

Databricks의 데이터 인텔리전스 플랫폼 아키텍처는 Databricks 계정과 고객 계정으로 분리된 하이브리드 구조를 통해 보안, 성능, 유연성을 모두 제공합니다.

핵심 요약:

두 계정 구조: Control Plane과 Serverless Compute는 Databricks 계정에, 데이터와 Classic Compute는 고객 계정에 위치
Compute 선택: Classic은 완전한 제어와 격리, Serverless는 빠른 시작과 유지보수 편의성 제공
보안 계층: IDP 통합, 네트워크 격리, 세밀한 접근 제어를 통해 다층 보안 구현
유연한 구성: 워크로드 특성에 따라 Classic과 Serverless를 조합하여 사용

아키텍처를 올바르게 이해하고 구성하면, 보안을 유지하면서도 성능과 비용을 최적화할 수 있습니다. 처음 구축할 때는 작은 규모로 시작하여 점진적으로 확장하는 것이 좋습니다.

참고 자료:

NewNewDaddy

데이터 엔지니어의 작업공간 / #PYTHON #CLOUD #SPARK #AWS #GCP #NCLOUD

이전 포스트

Databricks 플랫폼 아키텍처 상세 가이드

DATABRICKS

0. INTRO

왜 Databricks 아키텍처를 이해해야 할까?

Databricks 아키텍처의 핵심 개념

1. 전체 플랫폼 구조 (High-Level Architecture)

1) 아키텍처 다이어그램 개념

2) 계정 간 데이터 흐름

2. 주요 구성 요소 상세 설명

1) Control Plane (컨트롤 플레인)

Web App

Unity Catalog

Workflow Management

Intelligence Engine

2) Compute Plane (컴퓨팅 플레인)

Classic Compute (클래식 컴퓨팅)

Serverless Compute (서버리스 컴퓨팅)

3. 서비스 모델별 아키텍처 특징

1) Databricks SQL: Classic vs. Serverless

Classic SQL Warehouse

Serverless SQL Warehouse

2) Serverless 확장 서비스

Model Serving & Vector Search

Online Tables

4. 보안 및 사용자 관리

1) Identity Provider (IDP) 통합

2) Network Security

Private Link (Azure)

VNet/VPC 피어링 (Classic Compute)

5. 실무 활용 가이드

1) 시나리오 1: 엄격한 보안 요구사항이 있는 금융 기관

2) 시나리오 2: 빠른 프로토타이핑이 필요한 스타트업

3) 시나리오 3: 하이브리드 워크로드가 있는 대기업

6. 아키텍처 선택 가이드

1) Classic vs. Serverless 비교표

2) 선택 기준

7. 마무리

Databricks 사용자 역할 완전 가이드: 누가 무엇을 관리하는가?

0개의 댓글