토스증권, Spark Connect 서버 관리를 위한 Spark Tenant Operator 공개
핵심 내용
Apache Spark Operator와 함께 테넌트 단위 서버 교체 및 메모리 누수 문제를 해결했다.
자세히 보기
토스증권 Data Infra팀은 Spark Connect 서버의 생명주기를 관리하기 위해 Spark Tenant Operator를 개발했다. 기존 Apache Spark Operator가 개별 Driver의 실행과 복구를 담당한다면, Tenant Operator는 여러 SparkApplication을 하나의 테넌트로 묶어 서버 수 유지와 설정 변경을 관리한다.
두 Operator의 역할 분담과 Blue-Green 교체
Tenant Operator는 사용자가 선언한 설정에 맞춰 SparkApplication을 생성하고 교체한다. 서버 교체 시에는 Blue-Green 방식을 적용해 신규 세션만 새 서버로 전환하고, 기존 서버는 세션이 종료될 때까지 drain 상태로 유지한다. 이를 통해 실행 중인 작업의 중단을 방지한다.
기동 준비 상태 확인과 DNS 문제 해결
Connect 서버의 실제 준비 상태를 확인하기 위해 gRPC 연결을 시도하는 exec probe를 도입했다. 또한 Executor가 Driver의 Service DNS를 조회할 때 Ready 상태를 기다리는 로직으로 인한 데드락을 방지하기 위해 spark.kubernetes.executor.useDriverPodIP=true 설정을 적용했다. 추가로 spark.kubernetes.driver.service.publishNotReadyAddresses 설정을 통해 Executor 연결과 Connect 요청 수용 준비를 분리했다.
장기 실행 환경의 메모리 누수 해결
Heap 사용량은 안정적이지만 전체 메모리가 증가해 OOMKilled로 종료되는 문제를 해결했다. glibc의 메모리 할당 경합을 줄이는 arena 수를 제한(MALLOC_ARENA_MAX=2)함으로써 72시간 관측 시 메모리 증가 현상을 차단했다. 운영 환경에서는 코어 수를 고려해 max(4, cores) 값을 적용했다.
이 한국어 요약은 AI가 자동으로 만들었습니다. 원문의 주장과 맥락은 원문에서 확인해 주세요. 저작권은 원저작자에게 있습니다.