Spark Connect on Kubernetes #2: Operator로 만드는 Control Plane

안녕하세요. 토스증권 Data Infra팀 박지원입니다.지난 편에서는 Spark Connect 서버를 여러 replica로 나누고 Gateway로 요청을 분산시켰습니다. 한 Driver에 몰리던 사용자를 분산해 장애와 리소스 경합을 줄이기 위해 새 세션은 한가한 서버에 배치하고, 기존 세션은 원래 서버로 보냈어요.그런데 Gateway가 요청을 보낼 서버들은 누가 만들고 관리할까요? Driver가 죽으면 다시 띄워야 하고, 이미지나 설정을 바꾸려면 실행 중인 서버를 교체해야 해요. 이미 세션이 붙어 있는 서버를 그냥 내릴 수는 없고요.이번 편은 이 서버들의 생명주기를 관리하는 Control Plane 이야기입니다. 개별 서버의 실행과 복구는 Apache Spark Operator에 맡기고, 여러 서버를 하나의 서비스로 운영하는 Spark Tenant Operator를 만들었어요. 두 계층의 역할과 서버 교체 과정을 살펴본 뒤, 장기 실행 중 겪은 Driver 메모리 문제도 다룰게요.여러 Spark Connect 서버를 어떻게 관리할까대화형 분석과 무거운 파이프라인을 같은 서버에서 실행하면 자원 경합이 생겨요. 그래서 용도별로 서버를 묶고 이미지, 자원, Spark 설정과 replica 수를 지정했어요. 이 서버 그룹을 테넌트라고 부릅니다. 아래 표는 용도에 따라 테넌트 설정을 나눈 예시예요.Driver 사양(CPU / Heap)2 cores / 4 GiB4 cores / 8 GiBExecutor 사양(CPU / Heap)2 cores / 4 GiB4 cores / 16 GiBspark.dynamicAllocation.maxExecutors1050spark.sql.shuffle.partitions2001000두 Operator의 역할 나누기테넌트를 운영하려면 개별 서버의 장애를 복구하고 테넌트 전체의 서버 수를 유지해야 해요. 스펙이나 설정이 바뀌면 서버를 교체해야 하고요. 저희는 이 역할을 두 Operator로 나눴습니다.Kubernetes에서 Deployment가 여러 Pod의 수와 교체를 관리하는 것처럼, 저희는 Spark Tenant Operator가 여러 SparkApplication을 관리해요. SparkTenant에 원하는 설정과 서버 수를 선언하면 Tenant Operator가 그에 맞춰 SparkApplication을 생성하고 교체해요. 각 Application의 Driver를 실행하고 상태를 관측...