목차
- 장애 접수 5분 안에 확보할 정보
- 10분 트리아지(Driver vs Executor vs Spill/Skew)
- 메모리 구조 “운영자가 필요한 만큼만” (Unified Memory / Off-heap / Overhead)
- 자주 터지는 오류 6종: 증상 → 확인 → 즉시조치 → 재발방지
- 캐시 운영 정책(디스크 캐시 vs 스파크 캐시) — 현장 기준안
- Spark UI로 원인 확정하는 최소 체크리스트
- 사전 예방(가드레일) 템플릿
1) 장애 접수 5분 안에 확보할 정보(필수)
아래 7개만 모아도 “메모리 이슈인지/쿼리 구조 문제인지/클러스터 스펙 문제인지”가 빨리 갈립니다.
- Job run ID / Notebook URL
- 실패 시각(타임라인)
- 에러 로그 원문 20~50줄(특히 OOM/GC/ExecutorLostFailure 키워드 포함)
- 클러스터 정보(노드 타입/워커 수/오토스케일 여부)
- 런타임(DBR) 버전
- 입력 데이터 크기(대략) + 증감(최근 배치부터 급증했는지)
- Spark UI 링크(가능하면 Stage/SQL 탭까지)
Driver/Executor 기본 아키텍처를 모르면 트리아지가 느려져서, 운영자는 아래 그림 수준만 알고 있으면 충분합니다. Source
이미지: Apache Spark 문서 Source
2) 10분 트리아지(운영자용 의사결정 트리)
2-1) “어디 메모리”가 터졌는지 먼저 분류
에러 메시지로 1차 분류합니다.
OutOfMemoryError: Java heap space
→ JVM 힙(대개 Executor) 부족 가능성이 큼GC overhead limit exceeded
→ GC 폭주(객체 churn / 캐시+실행 경쟁 / 브로드캐스트 과다) 가능성ExecutorLostFailure ... heartbeat timed out
→ Executor가 “죽었다”기보다 GC/메모리 압박으로 응답 못하는 상태 가능성이 큼(특히 브로드캐스트가 원인인 케이스가 흔함) Source- Spark UI Stage 상단에 Spill 수치가 크다
→ Execution 메모리 부족 → 디스크 스필로 성능/안정성 악화 Source
2-2) Spark UI Stage에서 “Spill → Skew” 순으로 확인
Databricks Spark UI 가이드는 긴 stage 진단 시 먼저 spill을 보고, 다음으로 skew를 보라고 안내합니다. Source
이미지: Databricks Spark UI guide Source
3) 메모리 구조: 운영자가 알아야 하는 핵심만
3-1) Unified Memory(M): Execution + Storage가 같은 풀을 나눠씀
Spark 튜닝 문서는 실행 메모리(joins/sorts/shuffles)와 저장 메모리(cache)가 통합된 영역(M) 을 공유하고, 실행이 필요하면 저장을 일부 밀어낼 수 있다고 설명합니다. 또한 spark.memory.fraction, spark.memory.storageFraction의 의미를 공식적으로 정리합니다. Source
spark.memory.fraction(기본 0.6): (heap-300MiB) 중에서 Execution+Storage가 쓰는 풀(M) 비율 Sourcespark.memory.storageFraction(기본 0.5): M 중에서 캐시가 “최소한으로 보호받는” 구간(R) 비율 Source
이미지: Spark 메모리 관리 해설(다이어그램) Source
3-2) Databricks에서 “executor memory를 무작정 크게”가 위험한 이유(Off-heap)
Databricks KB는 JVM이 커질수록 GC 문제가 나타날 수 있고, 이를 완화하기 위해 일부 클러스터 타입에서 off-heap 모드를 사용한다고 설명합니다. 또한 spark.memory.offHeap.enabled, spark.memory.offHeap.size로 제어된다고 안내합니다. Source
이미지: Databricks KB Source
4) 자주 터지는 오류 6종: 런북(즉시조치/재발방지)
4-1) OutOfMemoryError: Java heap space (Executor 힙 OOM)
운영 관점에서 가장 흔한 패턴은 “특정 stage의 특정 task working set이 과대”입니다. Spark 튜닝 문서는 reduce 태스크(예: groupByKey)에서 작업 셋이 너무 커서 OOM이 날 수 있고, 병렬도(파티션 수) 증가로 태스크당 입력을 줄이는 것이 단순한 해결책이라고 설명합니다. Source
- 즉시조치
- 문제 stage를 Spark UI에서 특정(가장 오래/큰 task) → 해당 연산(join/agg/window/explode) 확인
- 태스크당 데이터량을 줄이도록 파티션 전략 조정(특히 wide transformation 구간)
- 캐시가 과도하면(Storage 탭) 불필요 캐시 해제
- 재발방지
- explode/잘못된 join 조건으로 row 폭발 방지
- 캐시 storage level 재검토(아래 5장 참고)
(참고용 오류 이미지 예시)
이미지: 사례 스크린샷 포함 페이지 Source
4-2) GC overhead limit exceeded (GC 폭주)
Spark 튜닝 문서는 GC 비용이 객체 수에 비례하고, 직렬화 캐시(파티션당 byte array 1개) 가 객체 수를 줄여 GC 문제 완화에 도움이 된다고 설명합니다. Source
- 즉시조치
- “캐시가 필요한데 GC가 지옥”이면: 직렬화 레벨(
*_SER) 검토 - 브로드캐스트/캐시/collect류(드라이버로 당김) 사용 여부 점검
- “캐시가 필요한데 GC가 지옥”이면: 직렬화 레벨(
- 재발방지
- 캐시를 남발하지 말고(특히 MEMORY_ONLY), 재사용이 확실할 때만 운영
- 큰 브로드캐스트 금지(다음 항목)
4-3) ExecutorLostFailure ... heartbeat timed out (브로드캐스트+GC로 executor가 멈춤)
Databricks KB는 큰 테이블을 브로드캐스트하면 모든 executor로 복제되며, executor 메모리가 부족하면 과도한 GC/OOM → heartbeat timeout으로 이어질 수 있다고 설명합니다. Source
- 즉시조치
- 조인에서 broadcast가 걸렸는지 확인(physical plan / Spark UI SQL DAG)
- 자동 브로드캐스트 임계치 조정 또는 AQE에 맡기기
- 재발방지
spark.sql.autoBroadcastJoinThreshold또는spark.databricks.adaptive.autoBroadcastJoinThreshold를 “클러스터에 맞게” 낮추거나 제거(AQE 활용) Source
4-4) Spark UI에서 Spill(메모리/디스크 스필) 급증
Databricks Spark UI 가이드는 spill을 “메모리 부족 시 디스크로 내리는 현상이며 비용이 크다”고 설명합니다. Source
- 즉시조치
- spill이 발생하는 stage가 join/agg/sort인지 확인
- 파티션 수(특히 shuffle partitions) 조정으로 태스크당 메모리 압박 완화
- 재발방지
- skew 먼저 해결(파티션만 늘리면 skew에선 소용없는 경우 많음)
- 불필요 캐시로 execution을 압박하고 있지 않은지 점검(통합 메모리 구조 때문) Source
4-5) Skew(데이터 치우침)로 일부 task만 초장기 실행
Databricks 가이드는 skew를 “일부 task만 오래 걸려 전체 시간이 늘고 클러스터 활용이 나빠지는 현상”으로 설명하며, Stage Summary Metrics에서 Max가 75p 대비 과도하게 크면 skew를 의심하라고 안내합니다. Source
이미지: Databricks Spark UI guide Source
- 즉시조치
- skew key 후보(조인 키/집계 키)에 null/특정 값 쏠림이 있는지 확인
- 재발방지
- AQE skew 최적화 활용(가능 시)
- 최후 수단으로 salting 등 구조적 처방
4-6) “CACHE TABLE/캐시”로 메모리 잠식(Execution 메모리 부족 → spill/OOM)
Databricks SQL CACHE TABLE은 storageLevel을 지정할 수 있고, 지정하지 않으면 기본이 MEMORY_AND_DISK라고 문서에 명시되어 있습니다. Source
- 즉시조치
- 캐시가 정말 재사용되는지 확인(한 번 쓰고 버리면 역효과)
- 필요 없으면 uncache/clear
- 재발방지
- 운영 정책(아래 5장)대로: 캐시는 “재사용이 보장될 때만” + “수명 관리”
5) 캐시 운영 정책(현장 기준안): Disk cache vs Spark cache
5-1) Databricks Disk cache는 “로컬 SSD 파일 캐시”
Databricks 문서는 Disk cache가 원격 Parquet(Delta 포함) 파일을 워커 로컬 스토리지에 복사해 읽기를 가속하고, LRU 방식으로 자동 eviction되며 파일 변경을 감지해 자동 무효화된다고 설명합니다. Source
- 운영 원칙
- 반복 스캔이 많은 ETL/쿼리 워크로드에서는 Disk cache(자동)를 기본 기대치로 둠
- “Spark cache를 켜야만 빨라지는지”는 별도 근거가 있을 때만
5-2) Spark cache(CACHE TABLE / cache/persist)는 “Executor 메모리를 직접 점유”
Databricks SQL CACHE TABLE 문서 기준, 유효한 storage level 목록(MEMORY_ONLY, MEMORY_AND_DISK, DISK_ONLY, OFF_HEAP 등)이 제공됩니다. Source
- 운영 원칙(추천)
- 재사용이 2회 이상 확실할 때만 캐시
- 기본은
MEMORY_AND_DISK로 “살아남는 캐시”를 선호(메모리 부족 시 재계산 폭탄 방지) - 캐시 사용 시에는 반드시 “해제 시점”을 정해 수명 관리(배치 끝나면 unpersist/uncache)
6) Spark UI로 원인 확정하는 최소 체크리스트(운영자용)
1) Stage 페이지 상단: spill이 있는가? Source
2) Summary Metrics: skew 패턴인가(Max가 튀는가)? Source
3) spill/skew가 없는데 느리면: Stage → Associated Job으로 역추적해 상위 잡에서 병목 찾기(가이드에 UI 흐름이 나옴) Source
이미지: Databricks Spark UI guide Source
7) 사전 예방(가드레일) 템플릿(팀 운영 규칙으로 박아두기)
7-1) 브로드캐스트 가드레일
- “큰 테이블 브로드캐스트”는 executor 전체에 복제되어 GC/OOM/heartbeat timeout을 유발할 수 있으므로, 임계치/전략을 반드시 통제합니다. Source
7-2) 캐시 가드레일
CACHE TABLE은 기본 storage level이MEMORY_AND_DISK이며, storageLevel 선택은 운영 표준을 따릅니다. Source- Disk cache와 Spark cache를 혼동하지 않도록, 팀 위키에 차이를 명문화합니다. Source
7-3) 메모리 파라미터 변경 가드레일
spark.memory.fraction,spark.memory.storageFraction은 통합 메모리 정책의 핵심이므로, 변경 시 “왜 바꾸는지(Spill vs Cache vs GC)”를 근거로 남깁니다. Source- executor 힙을 키우는 것만이 답이 아니며, off-heap 모드/GC 관점도 함께 검토합니다. Source
다음 단계(원하시면 제가 더 “운영자 친화”로 커스터마이즈)
아래 3가지만 답 주시면, 위 런북을 귀사 표준 운영 문서 형태(“증상별 Runbook + 설정 표준 + 온콜 체크리스트”)로 더 구체화해드릴게요.
1) 사용 클라우드: AWS / Azure / GCP?
2) 주된 워크로드: 배치 ETL / 스트리밍 / SQL 웨어하우스?
3) 최근 가장 많이 나는 에러 메시지 1개(로그 한 줄 그대로)
(추가 이미지가 더 필요하면, 이미지 생성 도구를 써서 “우리 팀 전용 다이어그램”도 만들 수 있는데, 그건 크레딧/시간이 더 드는 작업이라 원하실 때만 진행하겠습니다. 생성 시 기본 모델은 nano-banana-2를 사용합니다.)
