Netflix 엔지니어, AI 에이전트와 병렬 실험으로 Spark OOM 디버깅 자동화

실험 병렬화 및 자동화

Netflix 엔지니어는 Git 브랜치를 활용해 실험을 격리하고 Dataflow와 Maestro를 통해 프로덕션 데이터를 샘플링 없이 병렬로 실행하는 방식을 도입했다. 이를 통해 수 시간 걸리던 순차적 디버깅 사이클을 병렬 실행으로 단축했으며, 전체 실행 시간은 가장 느린 단일 작업의 소요 시간과 동일해졌다. 이 과정에서 AI 에이전트를 활용해 스케줄러 설정, 배포, 지표 폴링 등 운영 작업을 자동화했다. 엔지니어는 자연어로 "가장 OOM에 가까운 실행은 무엇인가?"라고 쿼리할 수 있었으며, 이 워크플로우는 사전 점검부터 자동 진단까지 처리하는 재사용 가능한 스킬(/sandbox-deploy-and-run)로 패키징되었다. Netflix의 Workbench 클라우드 환경에서 tmux 세션을 통해 불안정한 Wi-Fi에서도 원격으로 실험을 모니터링할 수 있었다.

근본 원인: 이벤트 백 구조의 메모리 압력

조사 결과, OOM의 원인은 전체 데이터셋의 용량이 아니라 collect_list로 집계된 개별 이벤트 백의 메모리 점유율이었다. 이벤트 무게를 증가시킨 두 가지 주요 요인은 다음과 같다.

• 데이터 타입 오버헤드: 레거시 아키텍처에서 Scala Option 타입으로 업그레이드하면서 Spark가 원시 타입을 JVM 객체로 래핑하게 되었고, 이는 가비지 컬렉션 압력을 높였다.
• 불필요한 속성: 리퍼러 URL 등 저가치 문자열 필드가 이벤트당 상당한 무게를 추가했으며, 이는 collect_list 연산에서 배가되었다.

Option 타입을 일반 원시 타입으로 언박싱하면 실행자 메모리 사용량이 크게 줄었다. 또한 세션 불변 메타데이터를 상위로 끌어올려 이벤트 백을 슬림화하면 메모리 압력을 더욱 완화할 수 있다.

Adaptive Query Execution(AQE)의 함정

Spark의 Adaptive Query Execution(AQE)과 관련된 두 가지 중요한 인사이트가 도출되었다.

1. 브로드캐스트 조인 누적: AQE는 정렬 병합 조인을 브로드캐스트 해시 조인으로 재작성했다. 개별 조인은 400 MB 한도를 넘지 않았지만, 누적 고정 메모리가 실행자당 3.1 GB에 달해 OOM을 유발했다.
2. 윈도우 연산자 버퍼링: Window 연산 후 이벤트를 잘라내는 단순한 수정은 실패했다. Spark가 윈도우 연산 평가 전에 전체 파티션을 버퍼링하기 때문이다. 메모리 급증을 방지하려면 Window 단계 이전에 이벤트를 제한해야 했다.

spark.sql.aqe.broadcastThreshold를 10 MB로 조정하면 브로드캐스트 조인을 전역적으로 비활성화하지 않고도 누적 문제를 해결할 수 있다. 저자는 튜닝이 시간을 벌어주지만, 무한한 이벤트 스트림을 단일 행으로 집계하는 데이터 모델에는 근본적인 확장성 한계가 있음을 강조한다.