LINE 서비스의 대규모 광고 데이터를 처리하기 위한 Spark on Kubernetes 적용기
문제광고 플랫폼의 대규모 데이터 처리를 YARN 클러스터로 운영하면 자원 활용도와 격리에서 한계가 온다.
접근Spark on Kubernetes 로 마이그레이션. 동적 자원 할당, 네임스페이스 기반 격리, 자동 스케일링까지 K8s 패턴 적용.
결과자원 효율 향상 + 워크로드 격리 강화. YARN → K8s 전환 시 마주친 함정과 해결 패턴 정리.
문제광고 플랫폼의 대규모 데이터 처리를 YARN 클러스터로 운영하면 자원 활용도와 격리에서 한계가 온다.
접근Spark on Kubernetes 로 마이그레이션. 동적 자원 할당, 네임스페이스 기반 격리, 자동 스케일링까지 K8s 패턴 적용.
결과자원 효율 향상 + 워크로드 격리 강화. YARN → K8s 전환 시 마주친 함정과 해결 패턴 정리.
문제Node.js 컨테이너가 SIGTERM 을 받았을 때 in-flight 요청을 끝내지 않고 죽으면 사용자에게 5xx 가 보인다.
접근쏘카가 graceful shutdown 을 제대로 구현 — SIGTERM 핸들러로 새 요청 거부 + 진행 중 요청 완료 대기 + DB 연결 정리. K8s preStop hook 과 readiness probe 를 연동.
결과배포 / 스케일 다운 시 사용자 영향 없이 안전한 종료. Node.js / K8s 운영의 기본기 정리.
문제카카오페이 Kubernetes 환경에서 Pod이 실제 사용량(CPU 0.5 core 미만 80%, Memory 1 Gi 미만 20%)보다 훨씬 큰 자원을 요청해 비용 낭비와 신규 서비스 이관 시 자원 부족이 발생했다.
접근Google Autopilot 논문을 참고해 사용량 히스토그램 95분위에 안전마진 15%를 더한 추천값을 계산한다. MutatingWebhook으로 Pod 라벨을 자동 부여하고, Prometheus Recording Rule로 메트릭을 사전 집계해 쿼리 비용을 줄였다.
결과테스트 환경 약 400개 서비스에 적용해 CPU 238 core(8.8%), Memory 155 Gi(4.7%)를 절감했다. EKS 환경에서는 EC2 노드 감소로 즉각적인 비용 절감이 나타났다.
문제뱅크샐러드 웹은 마이크로서비스 gRPC 호출마다 HTTP 클라이언트를 수작업으로 작성했고 외부망 경유로 IPS 부하와 200ms 수준 지연이 발생했다.
접근@bufbuild/protoplugin으로 코드 생성기를 만들고 buf CLI 빌드에 연결해 .proto 파일에서 TypeScript HTTP 클라이언트를 자동 생성하면서 내부망(k8s 서비스 DNS)과 외부망 호출을 별도 클래스로 분리했다.
결과SSR에서 방화벽을 우회해 응답 속도를 200ms에서 20ms 수준으로 약 90% 줄였고 API 코드 작성과 타입 정의를 자동화해 개발 생산성과 안정성을 함께 올렸다.
문제카카오페이가 개발 지원이 중단된 외부 업체의 레거시 시스템과 연동하면서 망 분리, 설계도 없는 API, 물리서버와 클라우드의 환경 차이, SNI 등의 난관에 부딪혔다.
접근IPSec VPN과 nginx provisioning으로 게이트웨이를 만들고 httpServletRequest 로그를 분석해 SOAP 통신 방식을 역설계했으며 ClassPathResource로 K8s 환경에서 리소스를 임시 디렉토리에 풀고 SNI 제거된 공인 IP를 새로 받았다.
결과프로젝트를 정상 오픈해 기존 수동 안내 메일 업무를 자동화했고 레거시 연동에서 자주 만나는 패턴을 정리해 재사용 가능한 절차로 남겼다.