Spark Connect on Kubernetes #1: 견고한 Spark Connect 만들기
Summary
토스증권이 Spark Connect를 '절대 죽지 않는' 서비스로 만든 비결
단일 장애점부터 리소스 경합까지, Kubernetes 환경에서 Spark Connect를 운영하며 마주한 난관과 해결책
본 아티클은 토스증권 데이터 인프라 팀이 Spark Connect를 실제 운영 환경에 도입하면서 겪은 기술적 도전과 이를 극복하기 위한 아키텍처 개선 과정을 다룹니다. 특히 여러 사용자가 공유하는 멀티테넌트 환경에서 안정성을 확보하기 위해 Spark의 기본 설정을 어떻게 최적화하고 다중화했는지에 대한 실무적인 통찰을 제공합니다.
- 01Spark Connect의 핵심 아키텍처와 기존 클래식 배포 모드와의 차이점 분석
- 02서버 전체를 다운시키는 글로벌 실행기 실패 카운터 로직의 취약점 및 해결 방법
- 03Driver의 OOM을 방지하기 위한 결과값 크기 제어 및 조기 차단 전략
- 04복수 레플리카 구성을 통한 SparkContext 격리 및 시스템 가용성 확보
- 05Spark Connect에서 누락된 Fair Scheduler 풀 전파 기능의 수동 구현 사례
RECOMMENDATION
대규모 데이터 플랫폼을 Kubernetes 위에서 운영하려는 데이터 엔지니어나, 안정적인 멀티테넌트 분석 환경을 구축하고자 하는 인프라 엔지니어에게 실무적인 가이드라인을 제공합니다.
The Problem
Spark Connect는 드라이버를 상시 실행 서버로 운영하여 편리하지만, 하나의 SparkContext를 여러 사용자가 공유하기 때문에 특정 쿼리의 실패가 서버 전체를 종료시키는 단일 장애점(SPOF) 문제를 안고 있다. 또한 기본 FIFO 스케줄링 구조로 인해 특정 사용자가 리소스를 독점할 경우 다른 사용자의 작업이 지연되는 경합 문제가 발생한다.
The Solution
글로벌 실행기(Executor) 실패 카운터를 비활성화하고 작업 단위의 결함 허용 설정을 강화하여 서버 생존력을 높였으며, 서버를 여러 레플리카로 다중화하여 장애 범위를 최소화했다. 또한 Spark Connect에서 누락된 Fair Scheduler 풀 전파 기능을 직접 구현하여 사용자별 작업 우선순위를 관리할 수 있도록 개선했다.
The Result
특정 사용자의 쿼리 실패가 전체 서비스 중단으로 이어지지 않게 되었으며, 사용자는 서버 종료 대신 원인 파악이 가능한 구체적인 에러 메시지를 받게 되어 운영 안정성이 크게 향상되었다. 레플리카 구성을 통해 부하 분산과 가용성 확보가 가능해졌으며 워크로드에 따른 유연한 리소스 배분이 가능해졌다.
Trade-off
문제 쿼리를 조기에 차단하기 위해 실패 임계치를 낮춘 설정은 일시적인 네트워크 이슈 등으로 인한 정상적인 쿼리까지 중단시킬 위험이 있다. 또한 결과값 크기 제한은 쿼리 단위로 적용되므로, 다수의 사용자가 동시에 큰 데이터를 요청할 경우 드라이버의 메모리 부족 위험을 완전히 배제하기는 어렵다.
Key Concepts
More from 토스
View all posts from 토스
1%가 겪은 버그 고쳐야할까요?
HotfixProgressive DeliveryQA Platform1일 전
토스증권 추천과 검색은 어떻게 진화하고 있을까?
Vector DatabaseRAGEmbedding Model4일 전
LLM 서빙, 띄우는 것과 잘 띄우는 것 사이
LLM ServingvLLMObservability1주 전
전체 데이터를 브라우저에 두는 광고 대시보드 만들기
State ManagementPerformance OptimizationAPI Design1주 전
토스는 어떻게 광고 속에 게임을 넣었을까
MRAIDWebViewJS Bridge1주 전
