원문: Databricks Network Configuration delivery to Tens of Millions of Serverless VMs 저자: Manish Bansal, Yankai Zhang, Chen He 게시일: 2026년 8월 12일
요약
- Databricks의 serverless 플랫폼은 매일 수천만 대의 VM을 시작하며, 각 VM은 고객 워크로드를 서빙하기 전에 허용 목적지, 프라이빗 엔드포인트 같은 네트워크 구성이 필요하다. 각 노드가 시작 시 구성을 가져오고 생애 내내 갱신을 폴링하므로, 이는 하루 수십억 건의 네트워크 구성 요청으로 이어진다. 구 아키텍처는 이를 여러 업스트림 서비스에서 동기적으로 가져와 지연 시간과 가용성 병목을 만들었다.
- 우리는 이벤트 기반 파이프라인과 스냅샷 사전 계산으로 네트워크 구성 전달을 재설계하여, RPC 지연 시간을 97.5%(5,000ms → 125ms) 줄이고 99.99% 서비스 가용성을 달성했다.
문제 정의 (Problem Statement)
Databricks의 serverless 컴퓨팅 플랫폼은 SQL warehouse, 노트북, ML 서빙 엔드포인트 등 사실상 우리의 모든 데이터 및 AI 제품을 구동합니다. 이 플랫폼은 AWS, Azure, GCP 전반에 걸쳐 매일 수천만 대의 VM을 시작합니다. 어떤 serverless 워크로드든 실행되기 전에, VM은 자신의 네트워크 구성을 알아야 합니다. 어떤 스토리지 목적지에 접근할 수 있는가? 트래픽을 라우팅해야 할 프라이빗 링크(private link) 엔드포인트가 있는가? Unity Catalog에 새 스토리지 목적지 접근을 부여하는 최근 변경이 있었는가? Delta Sharing을 통해 공유된 새 목적지를 소비하기 시작하는가? 문제는 네트워크 구성이 어느 한 곳에 저장되어 있지 않다는 점입니다. 그것은 여러 업스트림 서비스로부터 조립되어야 하며, 각 서비스가 전체 그림의 한 조각씩을 기여합니다.구 아키텍처 (The Old Architecture)
원래 설계에서는, serverless 클러스터가 시작될 때마다 우리의 네트워크 구성 서비스가 모든 업스트림 서비스를 동기적으로 호출하고, 그 응답들을 집계하여, 워크스페이스별 네트워크 구성을 계산한 뒤, 그것을 serverless 데이터플레인(dataplane)에 반환했습니다. 이 일은 클러스터 생성의 크리티컬 패스(critical path)에서 일어났습니다.
구 아키텍처는 단순하고 작은 규모에서는 잘 작동했지만, 다음과 같이 우리가 운영 대시보드에서 추적하는 지표에 반영된 근본적인 문제를 안고 있었습니다.
- 지연 시간(Latency): 여러 업스트림 서비스가 크리티컬 패스에 있어, 네트워크 구성을 서빙하는 RPC 지연 시간이 p99에서 5,000ms였습니다. 이는 serverless 클러스터 시작 지연 시간에 영향을 주었습니다.
- 서버 성공률(Server Success Rate): 각 업스트림 서비스는 자체 가용성 특성을 갖습니다. 여러 서비스가 직렬로 있으면, 복합 가용성이 빠르게 떨어지고, 이는 연간 serverless 클러스터 시작 실패 가능성 증가로 이어집니다.
해법: 이벤트 기반 사전 계산 (Solution: Event Driven Precomputation)
우리는 Databricks가 네트워크 구성을 전달하는 방식을 근본부터(ground-up) 재설계했습니다. 이는 다음 핵심 원칙 위에 세워졌습니다.- 이벤트 기반 파이프라인(Event-driven pipeline): 모든 업스트림 서비스에 동기 호출을 하는 대신, 새 시스템은 메시지 큐(message queue)를 통해 변경 이벤트를 구독합니다. 고객이 새 Unity Catalog 커넥션을 만들거나 네트워크 정책을 수정하면, 업스트림 서비스가 이벤트를 발행(emit)합니다. 시스템은 이를 처리하고 사전 계산된 구성을 갱신합니다.
- 스냅샷 사전 계산(Snapshot pre-computation): 네트워크 구성은 백그라운드에서 비동기적으로 계산되어 사전 계산된 스냅샷 저장소(snapshot store)에 저장됩니다. 서빙 경로는 업스트림 서비스로부터 완전히 분리된, 단일하고 얇은 스토리지 페치(fetch)가 됩니다.
- 정적 안정성(Static stability): 어떤 업스트림 서비스 장애가 발생하더라도, 우리는 정적 구성(static config)을 유지하여 serverless 클러스터에 정적 안정성을 제공할 수 있습니다.
이 아키텍처는 두 경로를 깔끔하게 분리합니다. 관리 경로(management path)는 백그라운드에서 비동기적으로 실행됩니다. 업스트림 서비스가 변경 이벤트를 메시지 큐로 발행하면, 이벤트 프로세서(event processor)가 이를 소비하여 어떤 워크스페이스가 영향받는지 해석하고 워크스페이스별 갱신 알림을 팬아웃(fan out)합니다. 그러면 로컬 이벤트 관리자(local event manager)가 업스트림에서 관련 세부 정보를 가져와, 워크스페이스의 네트워크 구성을 재계산하고, 그 결과를 사전 계산된 스냅샷 저장소에 저장합니다. 주기적 리컨실러(periodic reconciler)도 백그라운드에서 모든 워크스페이스를 다시 동기화하여, 이벤트가 누락되더라도 최종 일관성(eventual consistency)을 보장합니다. 이와 대조적으로 서빙 경로(serving path)는 크리티컬하고 빠릅니다. serverless 클러스터가 시작되어 네트워크 구성이 필요할 때, 네트워크 구성 서비스는 단일 스토리지 읽기로 스냅샷 저장소에서 직접 이를 서빙하며, 업스트림 서비스 호출이 필요 없고 업스트림 서비스의 부하를 의미 있게 줄입니다.
핵심 설계 결정 (Key Design Decisions)
- 업스트림 서비스가 변경 이벤트를 메시지 큐로 푸시(push)합니다. 시스템은 이 이벤트들을 백그라운드에서 처리합니다. 저빈도(low-frequency) 리컨실러가 안전망(safety net)으로서 주기적으로 모든 워크스페이스를 다시 동기화하여, 푸시의 효율성과 동기 프레임워크의 신뢰성을 함께 제공합니다.
- 네트워크 구성은 각 서비스 파티션 내에서 로컬로 계산·저장되며, 그것이 서빙하는 워크스페이스와 같은 위치(co-located)에 놓입니다. 이는 계산을 분산시키고, 인시던트 발생 시 폭발 반경(blast radius)을 줄이며, 서빙 경로에서 파티션 간 의존성을 제거합니다.
- 이벤트는 워크스페이스와 리소스 식별자만 담습니다. 이는 이벤트를 가볍게 유지하고, 멱등적(idempotent)으로 만들며(어떤 순서로든 재생 가능), 메시징 파이프라인을 통해 민감한 고객 데이터를 전송하는 것을 피합니다.
이벤트가 흐르는 방식 (How Events Flow)
고객이 새 Unity Catalog 커넥션을 만들면, Unity Catalog가 변경 이벤트를 메시지 큐로 발행합니다. 그러면 이벤트 프로세서가 이벤트를 수신하여, 영향받는 메타스토어(metastore)에 어떤 워크스페이스가 연결되어 있는지 판단하고, 워크스페이스별 갱신 알림을 팬아웃합니다. 각 워크스페이스의 파티션에서, 이벤트 관리자가 이 알림을 수신하여, 갱신된 커넥션 세부 정보를 가져오고, 워크스페이스의 네트워크 구성을 재계산하여, 새 버전 표시(version mark)와 함께 저장합니다. 그 시점부터, serverless 클러스터가 네트워크 구성을 요청하면, 업스트림 호출 없이 스냅샷 저장소에서 직접 서빙됩니다.임팩트 (Impact)
새 아키텍처를 롤아웃한 후, 모든 운영 지표에서 결과는 혁신적이었습니다.
핵심 지표를 넘어서:
- 업스트림 호출량이 86% 감소했습니다. 시스템은 매 요청마다가 아니라 이벤트가 변경을 나타낼 때만 업스트림 서비스를 호출합니다.
- 네트워크 구성의 신선도(freshness)에서 의미 있는 개선을 관찰했습니다.
- 레거시 동기 프레임워크가 완전히 폐기(deprecated)되었습니다.