예상 소요 시간: 약 20분

TL;DR

• Jobs 탭에서 느린 Job을 찾고, Stages 탭에서 병목 Stage를 확인하세요
• Tasks 탭에서 Duration Min/Max 차이가 10배 이상이면 데이터 스큐입니다
• SQL 탭에서 Exchange 노드가 많으면 셔플을 줄여야 합니다

문제 정의#

Spark UI에 접속했지만 탭이 여러 개 있고, 각 탭에서 무엇을 봐야 하는지 모르겠습니다. 이 가이드를 따르면 Jobs → Stages → Tasks 순서로 성능 병목을 찾을 수 있습니다.

이 가이드가 다루는 것:

• Spark UI 각 탭의 핵심 메트릭 읽는 법
• 병목 원인을 좁혀가는 순서

이 가이드가 다루지 않는 것:

• Prometheus/Grafana 기반 모니터링 설정 → 모니터링 설정
• OOM 오류 해결 → OutOfMemoryError 해결하기

전제 조건#

환경 확인#

# Spark 버전 확인
spark-submit --version

# Spark UI 접근 확인 (애플리케이션 실행 중일 때)
curl -s http://localhost:4040/api/v1/applications | head -1

예상 출력:

[{"id":"local-1234567890","name":"MyApp",...}]

출력이 없으면 트러블슈팅 섹션을 확인하세요.

Step 1/7: Spark UI 접속하기#

환경에 따라 접속 URL이 다릅니다.

접속 확인#

# 로컬 환경
curl -s -o /dev/null -w "%{http_code}" http://localhost:4040

# YARN 환경 — 앱 목록 확인
yarn application -list 2>/dev/null | grep RUNNING

# Kubernetes 환경 — Driver Pod 포트 포워딩
kubectl port-forward svc/spark-driver 4040:4040

HTTP 응답이 200이면 정상입니다. 다음 단계로 진행하세요.

Step 2/7: Jobs 탭 — 전체 그림 파악#

Jobs 탭을 클릭하세요. 여기서 전체 작업 목록을 확인합니다.

무엇을 봐야 하는가#

Job = Action 하나입니다. count(), collect(), save() 같은 Action 호출마다 Job이 하나 생성됩니다.

판단 기준#

• 특정 Job의 Duration이 다른 Job보다 3배 이상 길다면 해당 Job을 클릭하세요
• Stages 열에서 Failed 숫자가 0이 아니라면 즉시 확인하세요

느린 Job을 찾았다면 해당 Job을 클릭하여 Stage 목록으로 이동하세요.

Step 3/7: Stages 탭 — 병목 구간 찾기#

Stages 탭을 클릭하세요. 또는 Step 2에서 느린 Job을 클릭하면 해당 Job의 Stage 목록이 나타납니다.

핵심 메트릭#

Spill이 발생하면 디스크 I/O로 인해 성능이 급격히 저하됩니다. Executor 메모리를 증가시키거나 파티션 수를 늘리세요.

판단 기준#

느린 Stage를 찾았다면 해당 Stage를 클릭하여 Task 상세 정보를 확인하세요.

Step 4/7: Tasks 탭 — 개별 작업 분석#

Stage를 클릭하면 Task 목록과 통계가 나타납니다. 여기서 병목의 근본 원인을 찾습니다.

핵심 메트릭#

데이터 스큐 진단#

Task Duration의 Min과 Max 차이가 10배 이상이면 데이터 스큐입니다.

import static org.apache.spark.sql.functions.*;

// 파티션별 데이터 분포 확인
df.groupBy(spark_partition_id().alias("partition"))
  .count()
  .orderBy(col("count").desc())
  .show(10);

예상 출력 (스큐가 있는 경우):

+---------+-------+
|partition| count |
+---------+-------+
|        5|1000000|  <-- 비정상적으로 큼
|        3|   5000|
|        1|   4800|
+---------+-------+

데이터 스큐를 발견했다면 → 데이터 스큐 해결하기를 참조하세요.

GC 문제 진단#

GC Time이 전체 Task Duration의 10% 이상이면 메모리 부족입니다.

# <app-id>는 Jobs 탭 상단 또는 다음 명령어로 확인:
# curl -s http://localhost:4040/api/v1/applications | python3 -m json.tool

# REST API로 Stage 메트릭 확인
curl -s http://localhost:4040/api/v1/applications/<app-id>/stages \
  | python3 -m json.tool | grep -E "gcTime|executorRunTime"

GC 문제를 발견했다면 → OutOfMemoryError 해결하기를 참조하세요.

Step 5/7: Storage 탭 — 캐시 확인#

Storage 탭을 클릭하세요. cache() 또는 persist()로 캐시한 RDD/DataFrame 목록이 나타납니다.

확인 항목#

Fraction Cached가 100% 미만이면 메모리가 부족하여 일부 파티션이 캐시에서 제거된 것입니다. MEMORY_AND_DISK로 Storage Level을 변경하세요.

Step 6/7: Environment 탭 — 설정 확인#

Environment 탭을 클릭하세요. 현재 적용된 모든 Spark 설정을 확인할 수 있습니다.

확인할 주요 설정#

# <app-id> 확인: curl -s http://localhost:4040/api/v1/applications | python3 -c "import sys,json;print(json.load(sys.stdin)[0]['id'])"

# REST API로 설정 확인
curl -s http://localhost:4040/api/v1/applications/<app-id>/environment \
  | python3 -m json.tool | grep -E "executor.memory|shuffle.partitions"

의도한 설정이 반영되지 않았다면 spark-submit 옵션, spark-defaults.conf, 코드 내 설정의 우선순위를 확인하세요. 코드 내 .config() 설정이 가장 높은 우선순위를 가집니다.

Step 7/7: SQL 탭 — 실행 계획 분석#

SQL 탭을 클릭하세요. Spark SQL 또는 DataFrame API로 실행한 쿼리의 실행 계획(DAG)이 나타납니다.

핵심 확인 항목#

파티션 프루닝 확인#

// 실행 계획 확인
df.explain(true);

출력에서 PartitionFilters가 비어있으면 파티션 프루닝이 실패한 것입니다.

// 파티션 프루닝 성공
+- FileScan parquet [...] PartitionFilters: [date >= 2026-01-01]

// 파티션 프루닝 실패
+- FileScan parquet [...] PartitionFilters: []

셔플이 과도하다면 → 셔플 최적화하기를 참조하세요.

History Server 설정 (선택)#

앱 종료 후에도 Spark UI를 확인하려면 History Server를 설정하세요.

1. 이벤트 로그 활성화#

SparkSession spark = SparkSession.builder()
    .appName("My App")
    .config("spark.eventLog.enabled", "true")
    .config("spark.eventLog.dir", "/var/log/spark/events")
    .config("spark.eventLog.compress", "true")
    .getOrCreate();

2. History Server 시작#

# 이벤트 로그 디렉토리 생성
mkdir -p /var/log/spark/events

# spark-defaults.conf에 추가
# spark.history.fs.logDirectory=/var/log/spark/events
# spark.history.ui.port=18080

# History Server 시작
$SPARK_HOME/sbin/start-history-server.sh

3. 접속 확인#

curl -s -o /dev/null -w "%{http_code}" http://localhost:18080

200이 출력되면 정상입니다. 브라우저에서 http://localhost:18080에 접속하세요.

트러블슈팅#

의사결정 트리#

성능 문제 발생 시 아래 순서로 진단하세요.

flowchart TD
    A["성능 문제 발생"] --> B["Step 2: Jobs 탭 확인"]
    B --> C{"느린 Job이<br>있는가?"}
    C -->|Yes| D["Step 3: 해당 Job의<br>Stages 탭 확인"]
    C -->|No| E["Step 7: SQL 탭에서<br>실행 계획 확인"]

    D --> F{"Spill이<br>발생하는가?"}
    F -->|Yes| G["Executor 메모리 증가<br>또는 파티션 수 증가"]
    F -->|No| H["Step 4: Tasks 탭 확인"]

    H --> I{"Task Duration<br>Min/Max 차이<br>10배 이상?"}
    I -->|Yes| J["데이터 스큐<br>→ data-skew 가이드"]
    I -->|No| K{"GC Time이<br>10% 이상?"}

    K -->|Yes| L["메모리 부족<br>→ OOM 가이드"]
    K -->|No| M["Step 5: Storage 탭에서<br>캐시 상태 확인"]

    E --> N{"Exchange 노드가<br>많은가?"}
    N -->|Yes| O["셔플 최적화<br>→ shuffle-optimization<br>가이드"]
    N -->|No| P["Step 6: Environment 탭에서<br>설정 확인"]

다이어그램 요약: 성능 문제 → Jobs 탭에서 느린 Job 확인 → Stages 탭에서 Spill 여부 확인 → Tasks 탭에서 스큐(Duration 차이)와 GC 확인 → 원인별 가이드로 분기. Exchange가 많으면 셔플 최적화 필요.

검증#

이 가이드를 완료하면 다음을 달성합니다.

핵심 포인트

• 분석 순서: Jobs → Stages → Tasks → 원인별 분기
• 데이터 스큐: Task Duration Min/Max 차이 10배 이상
• 메모리 부족: GC Time 10% 이상 또는 Spill 발생
• 셔플 과다: SQL 탭에서 Exchange 노드 다수
• 설정 미반영: Environment 탭에서 의도한 값 확인

다음 단계#

• OutOfMemoryError 해결하기 - GC/메모리 문제 해결
• 데이터 스큐 해결하기 - Task 불균등 문제 해결
• 셔플 최적화하기 - 네트워크 I/O 줄이기
• 성능 튜닝 - 종합 성능 최적화