Data Eng Wiki

Apache Spark Troubleshooting Agent for Amazon EMR on EKS

8 min read

Introducing Apache Spark troubleshooting agent for Amazon EMR on EKS

Author: AWS Big Data Blog | Source: aws.amazon.com/blogs/big-data | Published: 2026-08-04

한 줄 요약

Spark driver/executor pod 로그, Spark 이벤트 로그, 컨테이너 종료 신호를 사람이 수동으로 상관지어야 했던 디버깅을, 관리형 MCP 서버로 노출된 read-only 에이전트가 자동으로 수집·분석해 근본 원인과 (코드 문제라면) 코드 수정까지 제안한다.

핵심 주장/내용

  • 문제 — 여러 곳의 신호를 한 번에 상관지어야 한다: Spark driver·executor pod 로그, Spark 이벤트 로그, 그리고 명확한 Spark 에러가 아니라 pod exit code로 표면화되는 컨테이너 종료 신호. 단일 OOM 실패가 Kubernetes exit code 137로 나타나면서 그것을 유발한 코드 라인이나 설정과의 명백한 연결이 없다. 이 cross-system 조사가 인시던트 MTTR을 며칠로 늘리고 깊은 Spark·Kubernetes 전문성을 요구한다
  • 에이전트의 구조: EMR on EKS, EMR on EC2, EMR Serverless, AWS Glue, SageMaker 노트북에 걸쳐 실패한 Spark 애플리케이션을 진단하는 단일 인터페이스를 노출. 서비스마다 다른 콘솔·API·로그 위치를 헤매는 대신 자연어로 실패한 잡을 기술하면 에이전트가 나머지를 처리한다. EMR 콘솔이나 MCP 호환 AI 어시스턴트(Kiro CLI, Kiro IDE, Claude Code)에서 접근
  • 거버넌스 설계 — 관리형 MCP 서버: 로컬 MCP 서버를 배포·유지할 필요가 없다. single-tenant 설계로 애플리케이션 데이터와 코드를 격리하고, 연산이 read-only이며 IAM 권한으로 통제된다 — 에이전트는 내 IAM 역할이 부여한 리소스와 액션에만 접근할 수 있다. 툴 호출이 CloudTrail에 자동 로깅되어 완전한 감사 가능성 확보
  • EMR on EKS 특유의 입력 수집: driver·executor 로그가 잡의 모니터링 설정에 따라 S3, CloudWatch Logs, 또는 둘 다로 배달될 수 있고 에이전트가 자동으로 둘 다 처리한다
    • S3의 pod 로그 — Spark 이벤트 로그와 컨테이너별 stderr/stdout을 읽고 executor pod 로그를 발견하는 것까지 포함
    • CloudWatch의 컨테이너 로그 — driver·executor 컨테이너 로그 스트림을 직접 읽음
    • Spark History Server 데이터 — 쿼리 플랜, executor 타임라인, stage 메트릭, 설정 같은 더 풍부한 SHS 신호를 위해 EMR Persistent UI에 연결
  • 분석 방식: 수백만 Spark 애플리케이션을 운영한 경험을 바탕으로 이 소스들에서 관련 피처·신호를 추출한다 — 원래는 S3·CloudWatch·Spark UI에 걸친 수동 상관이 필요했을 작업. 그다음 RAG로 Spark·AWS 트러블슈팅 전문성의 관리형 지식 베이스에 grounding된 Bedrock LLM을 써서 근본 원인 분석과, 실패가 코드 관련이면 코드 권장을 생산. LLM·지식 베이스·둘을 잇는 검색이 전부 에이전트의 일부로 완전 관리되어 프로비저닝·호스팅·튜닝할 것이 없다
  • 두 개의 툴이 협업: analyze_spark_workload(워크로드 분석과 근본 원인)와 spark_code_recommendation(코드 수정). 전자가 근본 원인을 식별하고, 실패가 애플리케이션 코드에서 비롯되면 후자가 정확한 수정 편집을 반환한다. 사용자가 권장을 검토하고 변경에 대한 완전한 통제권을 가지고 적용 — 에이전트는 분석과 권장만 제공
    • analyze_spark_workload의 자동 수행: ① EMR on EKS API를 호출해 잡 실행 설정을 가져오고 로그 저장 위치 판단 ② 로깅 설정에 따라 S3 또는 CloudWatch에서 Spark 로그 검색 ③ EMR Persistent UI에 연결해 실행 플랜·stage 메트릭·executor 타임라인 등 Spark UI 피처 추출 ④ 상관된 신호를 분석해 근본 원인 설명 반환
  • 사례 1 — driver OOM (콘솔에서): 애플리케이션이 큰 데이터셋을 생성하고 collect()를 호출해 driver로 끌어와 설정된 spark.driver.maxResultSize 512 MiB를 초과. 에이전트가 24번 라인의 collect()가 전체 결과셋을 driver에 materialize하려다 안전 한도를 초과했고, 실제 driver OOM 크래시 전에 잡을 실패시켰다고 식별. 코드 문제이므로 before-after diff로 collect()를 목적지 경로로의 분산 write로 대체하는 코드 권장까지 반환 — executor들이 driver를 통해 데이터를 깔때기로 넣는 대신 각자 파티션을 병렬로 영속화
  • 사례 2 — SQL 함수 에러 (Claude Code에서): CSV를 읽어 임시 뷰로 등록하고 UPPERX(Name)을 호출하는 작은 PySpark 앱(UPPER의 오타). 에이전트가 근본 원인을 “Spark SQL 쿼리가 사용 가능한 함수 카탈로그(system.builtin, system.session, spark_catalog.default)에 없는 UPPERX 함수를 참조. 카테고리 SQL_ERROR” 로 반환하고, 코드 관련이므로 spark_code_recommendation으로 연쇄해 구체적 before-after 수정 생산

주요 수치 / 사실

  • 인시던트 MTTR을 며칠에서 분 단위로 줄일 수 있다고 주장
  • EMR on EKS 고객은 추가 비용 없이 에이전트 사용 가능. Bedrock을 통한 LLM 사용 포함해 추가 요금 없고 기존 EMR on EKS 리소스와 권장 변경 검증에 쓴 리소스만 지불
  • 필요한 IAM 권한 4종: EMR on EKS 읽기(DescribeJobRun, DescribeVirtualCluster, ListJobRuns, ListVirtualClusters), EMR Persistent UI(CreatePersistentAppUI, DescribePersistentAppUI, GetPersistentAppUIPresignedURL), S3 로그 읽기, CloudWatch 로그 읽기
  • 지원하는 실패 카테고리: OOM·리소스 고갈(collect() 같은 연산에서 오는 driver 측 실패와 Kubernetes pod exit code(137 등)로 표면화되는 executor 종료 포함), 데이터 skew와 셔플 이슈(불균등 파티셔닝, 소수 executor에 작업을 집중시키는 셔플 실패), 설정 에러, 코드 레벨 이슈(잘못된 API 사용, 무제한 collect(), UDF 에러 — 에이전트가 코드 수정을 권장할 수 있는 범주)
  • 코드 권장은 EMR on EKS, EMR on EC2, EMR Serverless, AWS Glue의 PySpark 워크로드에 지원

관련 위키

Source: 원문 보기

그래프 뷰

백링크