Spark Connect — 드라이버와 클라이언트를 분리하는 클라이언트-서버 아키텍처
Spark Connect 아키텍처 공식 문서 종합 (웹 리서치, 2026) — Apache Spark 공식 문서(spark-connect-overview.html) Apache Spark 공식 문서 Spark Connect Overview
이 모듈을 다 읽으면
- Spark Connect가 기존 아키텍처와 달리 클라이언트와 드라이버를 어떻게 분리하는지 설명할 수 있다
- 이 분리 구조가 안정성·업그레이드 측면에서 어떤 이점을 주는지 설명할 수 있다
spark-learn-22에서 다룬 Driver/Executor 아키텍처를 전제로, 사용자 애플리케이션 프로세스 안에 드라이버 JVM이 함께 실행되던 기존 구조를 완전히 분리해, 얇은 클라이언트가 원격 드라이버와 gRPC로 통신하는 Spark Connect 아키텍처를 정리한다.
기존 구조의 전제 — 드라이버가 사용자 프로세스 '안'에서 돈다
spark-learn-22에서 다룬 것처럼 기존 Spark 아키텍처는 드라이버 JVM이 사용자 애플리케이션 프로세스와 같은 메모리 공간에서 직접 실행된다 — 이 때문에 클라이언트 애플리케이션이 메모리를 과도하게 쓰거나 크래시하면 드라이버 자체가 함께 죽어버릴 수 있고, Py4J 같은 브리지를 통해 JVM 내부(RDD, SparkContext, private 필드)에 직접 접근할 수 있는 대신 애플리케이션과 드라이버의 생명주기가 강하게 결합된다.
핵심 포인트
- 기존 구조는 드라이버 JVM이 사용자 애플리케이션 프로세스와 같은 메모리 공간에서 실행됨 — 애플리케이션 크래시가 드라이버까지 함께 죽일 수 있음
- Py4J 브리지로 JVM 내부(RDD, SparkContext)에 직접 접근 가능하지만, 그만큼 애플리케이션과 드라이버 생명주기가 강하게 결합됨
Spark Connect의 구조 — 얇은 클라이언트가 미해석 논리계획을 gRPC로 보낸다
Spark Connect는 클라이언트를 드라이버로부터 완전히 분리한다 — 클라이언트는 DataFrame 연산을 미해석(unresolved) 논리 계획으로 변환해 프로토콜 버퍼로 인코딩한 뒤 gRPC로 원격 서버(Spark 드라이버)에 전송한다. 서버는 이 계획을 (SQL을 파싱하듯) 해석·최적화·실행한 뒤 결과를 Apache Arrow로 인코딩된 행 배치로 스트리밍해 돌려준다. 즉 spark.range(10).show() 같은 코드를 실행해도 실제 실행은 클라이언트가 아니라 원격 드라이버에서 일어나고, 클라이언트는 그 계획을 만들어 보내고 결과를 받는 역할만 한다.
핵심 포인트
- 클라이언트는 DataFrame 연산을 미해석 논리계획(프로토콜 버퍼)으로 인코딩해 gRPC로 원격 드라이버에 전송
- 서버가 계획을 해석·최적화·실행하고 결과를 Arrow 인코딩 행 배치로 스트리밍 — 실제 실행은 클라이언트가 아니라 원격 드라이버에서 일어남
이점 — 안정성, 독립적 업그레이드, 네이티브 디버깅
이 분리 구조 덕분에 애플리케이션이 메모리를 과도하게 쓰거나 크래시해도 자기 프로세스 안에서만 영향이 그치고 드라이버는 살아남는다(멀티테넌트 배포에 유리). 서버 측 RPC 정의가 하위 호환을 지키는 한, 드라이버를 애플리케이션과 독립적으로 업그레이드(보안 패치 등)할 수 있어 애플리케이션 재시작 없이 서버만 갱신 가능하다. 또한 클라이언트 코드가 JVM 안에 있지 않으므로 Py4J나 JVM 전용 브리지 디버깅 기법 없이, 애플리케이션 네이티브 IDE 디버거와 로깅 라이브러리로 클라이언트 코드를 그대로 디버깅할 수 있다.
핵심 포인트
- 클라이언트 크래시/메모리 과다사용이 자기 프로세스 안에서만 영향 — 드라이버는 살아남아 멀티테넌트 배포에 유리
- 서버측 RPC가 하위호환을 지키면 드라이버를 애플리케이션과 독립적으로 업그레이드 가능(재시작 불필요), 클라이언트 코드는 JVM 브리지 없이 네이티브 IDE로 디버깅 가능
트레이드오프 — RDD/SparkContext 같은 저수준 API는 못 쓴다
이 아키텍처는 DataFrame/SQL API처럼 선언적으로 논리계획을 표현할 수 있는 연산에 최적화돼 있다 — 반대로 RDD나 SparkContext처럼 JVM에 직접 접근해야 하는 저수준 API는 Spark Connect에서 지원되지 않는다(Python의 df._jdf 같은 내부 필드 접근도 마찬가지). 이는 클라이언트-서버 분리 원칙 자체와 충돌하기 때문으로, Spark Connect를 쓰기로 한 순간 이런 저수준 접근을 포기하는 트레이드오프를 받아들이는 셈이다.
핵심 포인트
- Spark Connect는 DataFrame/SQL 같은 선언적 API에 최적화 — RDD/SparkContext 등 JVM 직접 접근이 필요한 저수준 API는 지원 안 됨
- 저수준 API 미지원은 클라이언트-서버 분리 원칙과 근본적으로 충돌하기 때문 — Spark Connect 채택 시 감수해야 하는 트레이드오프