Spark on Kubernetes로 가자!

Context

뱅크샐러드의 데이터 분석 환경은 EMR 클러스터 기반 YARN에서 매일 수백~천 종의 서로 다른 크기의 Spark job을 실행했으나, YARN과 EMR 설정이 복잡하고 사내 DevOps 전문 인력 부재로 문제 해결이 어려웠습니다. 인스턴스 종료로 driver 프로세스 중단, autoscaling 민감도 제어 불가, Spark SQL 서버 알 수 없는 hang 등 운영 문제가 반복적으로 발생했습니다.

Technical Solution

• EMR 기반 Spark에서 Kubernetes 기반 Spark로 마이그레이션: Airflow KubernetesPodOperator를 이용해 Spark driver를 Pod으로 실행하고 executor Pod을 자동 생성하는 구조로 변경
• Kubernetes 리소스 최적화: spot instance를 위한 Auto Scaling Group 추가 및 aws-cluster-autoscaler로 autoscaling 관리, node selector와 toleration으로 Spark job을 spot instance에 할당
• Glue Catalog 연동 구현: aws-glue-data-catalog-client-for-apache-hive-metastore 저장소의 jar를 Spark image에 포함시켜 Kubernetes 환경에서 Glue 테이블 메타데이터 접근 가능하게 구성
• S3 프로토콜 변환: Glue의 s3:// 주소를 s3a://로 자동 변환하는 fork 코드를 반영해 INSERT OVERWRITE TABLE 등 DML 쿼리 실행 가능하게 수정
• Spark image 빌드 최적화: Spark 공식 Dockerfile에 Kubernetes 옵션을 추가해 빌드한 후, Python library 및 버전 커스터마이징을 위해 Python을 추가로 레이어화
• Spark driver 네트워크 설정: headless service를 job 제출 전 생성하고 spark.driver.host와 spark.driver.port 설정으로 executor와의 통신 안정화
• 파일 생성 최적화: Spark job 결과로 생성되는 작은 파일 다수 문제 해결을 위해 강제 shuffle hint를 추가해 파일 개수 감소 및 파일 크기 증대

Impact

• 피크 시간 기준 EC2 인스턴스 비용 45% 절감
• Kubernetes 기반 autoscaling이 YARN 기반 autoscaling 대비 민감도가 향상되어 인스턴스 확장·축소 반응성 개선

Key Takeaway

복잡한 managed service(EMR)에서 이해하기 쉬운 자체 구축 플랫폼(self-hosted Kubernetes)으로 이전할 때, 기존 사용자 인터페이스는 유지하되 내부 실행 시스템만 교체하는 방식을 택하면 학습곡선을 낮추고 팀의 기존 전문성을 활용할 수 있습니다.