콘텐츠로 이동
Study NoteDatabricks

1. 세 plane과 두 compute

“Databricks가 AWS에서 돈다”는 말은 맞지만, 어떤 compute를 고르느냐에 따라 실행 계정과 network path가 달라진다

이 장에서 처음 나오는 말4개
control planeControl plane
workspace UI, REST API와 orchestration 같은 Databricks 관리 기능이 있는 영역이다.
classic compute planeClassic compute plane
회사 AWS 계정의 VPC에서 EC2 기반 compute가 실행되는 영역이다.
serverless compute planeServerless compute plane
Databricks가 관리하는 account와 network에서 compute가 실행되는 영역이다.
workspaceWorkspace
사용자가 notebook·SQL·job·compute를 함께 다루는 협업·운영 경계다.
Databricks 관리 영역의 control plane·Unity Catalog·serverless compute와 회사 AWS 계정의 classic compute·S3·RDS, 그리고 온프렘 DB가 어떤 경로로 이어지는지 보여주는 구조도

이 장의 질문은 두 개다. “우리 AWS 계정에서 실제로 생성되는 resource는 무엇인가”, 그리고 “CX/DX를 통해 온프렘에 바로 갈 compute는 무엇인가”다.

control plane에는 workspace web application, API와 관리 기능이 있다. notebook의 code와 SQL을 실제로 실행하는 것은 compute plane이다. 이 분리는 UI 주소가 어디에 있는지와 data traffic이 어디로 흐르는지를 따로 설계해야 한다는 뜻이다.

classic workspace에는 회사 AWS 계정의 workspace storage bucket도 있다. 그러나 이를 모든 business data를 무분별하게 쌓는 bucket으로 보지 않는다. Unity Catalog의 managed storage와 external location을 별도 bucket·prefix와 IAM role로 설계하는 편이 ownership과 lifecycle을 분명하게 만든다.

판단Classic computeServerless compute
실행 위치회사 AWS account의 VPCDatabricks 관리 compute plane
VPC route·SG 통제회사가 직접 통제회사 VPC route를 자동 상속하지 않음
온프렘 DX 접근VPC/TGW route로 자연스럽게 구성NCC와 지원되는 private endpoint pattern을 별도 설계
준비·운영subnet IP, EC2 quota, policy와 시작 시간 관리infrastructure 운영을 Databricks가 더 많이 담당
적합한 첫 workload민감한 hybrid source, custom network control빠른 SQL·job·notebook, 운영 단순화
확인할 것egress, PrivateLink, subnet 크기, cluster policyNCC, egress policy, resource별 private connectivity 지원

workspace 하나에서 모든 compute를 같은 방식으로 고를 필요는 없다. 예를 들어 classic job이 온프렘 DB에서 증분 data를 읽어 S3 Delta table에 적재하고, serverless SQL warehouse가 허용된 S3 table을 조회할 수 있다. 다만 같은 table을 본다고 해서 network policy까지 같은 것은 아니다.

온프렘 DB에서 classic ingest job이 증분을 읽어 S3 Delta에 쓰고 Unity Catalog에 반영한 뒤, serverless SQL이 권한을 확인하고 읽는 순서도