Spark

Unified Memory Manager — 힙을 4개로 나누는 방법

executor의 JVM 힙 전체가 Spark 연산에 다 쓰이는 게 아니다. Spark는 먼저 300MB를 '예약 메모리(Reserved Memory)'로 떼어 놓는다(로그, 내부 메트릭, 자체 구조체용으로 하드코딩된 고정값). 나머지(Usable Memory = 전체 힙 - 300MB)를 spark.memory.fraction(기본 0.6)만큼 'Execution+Storage' 풀로, 나머지 1-0.6=0.4만큼을 'User Memory'(UDF, 사용자 객체, Arrow 버퍼처럼 Spark가 추적하지 않는 영역)로 나눈다.

Execution+Storage 풀(전체의 60%) 안에서는 다시 spark.memory.storageFraction(기본 0.5)으로 절반씩 Execution과 Storage 몫을 정한다. 결과적으로 기본값 기준 대략 힙의 30%가 Execution, 30%가 Storage, 40%가 User Memory로 나뉘는 셈이다. 이 비율은 실행 계획(셔플/조인/집계가 많은지, 캐싱이 많은지)에 따라 조정할 필요가 생길 수 있다.

Execution이 Storage보다 우선한다 — 캐시가 '안전하지 않은' 이유

Execution 메모리(셔플, 조인, 정렬, 집계 등 '연산'에 쓰이는 메모리)와 Storage 메모리(cache()/persist()로 저장한 데이터)는 같은 풀을 동적으로 나눠 쓰지만, 둘 사이 관계는 대등하지 않다 — Execution이 항상 Storage보다 우선권을 갖는다. Execution 쪽에서 메모리가 더 필요해지면 Spark는 Storage에 캐시된 블록을 밀어내서(evict) 그 공간을 Execution에 내준다.

이게 실무적으로 의미하는 바는: df.persist(StorageLevel.MEMORY_ONLY)로 뭔가를 캐시해뒀더라도, 그 뒤에 무거운 셔플이 발생하는 wide transformation(조인, groupBy 등)을 실행하면 Spark가 조용히 캐시된 블록 일부를 축출할 수 있고, 나중에 그 캐시를 다시 참조하면 Spark는 원본 연산을 처음부터 재계산해야 한다는 것이다. '한 번 캐시하면 계속 메모리에 남아있다'는 가정은 틀렸다 — Execution 압박이 있으면 캐시는 언제든 밀려날 수 있는 이등 시민이다.

태스크 단위로 내려가면 — 동시 실행 태스크들의 메모리 분배

Execution 메모리 풀은 executor 하나 안에서 동시에 실행 중인 모든 태스크가 공유한다. TaskMemoryManager는 현재 동시 실행 중인 태스크 개수를 n이라 할 때, 태스크 하나가 요청할 수 있는 메모리를 대략 (전체 Execution 메모리)/(2n) ~ (전체 Execution 메모리)/n 사이로 소프트 제한한다 — 엄격한 하드 격리가 아니라, 태스크마다 최소한의 몫은 보장하면서도 상황에 따라 유동적으로 더 받을 수 있게 하는 방식이다.

이 구조의 함정은, 태스크 간에 하드 격리가 없다 보니 먼저 실행을 시작한 태스크가 필요 이상으로 많은 메모리를 선점해버리면, 뒤늦게 시작한 태스크가 굶주릴 수 있다는 점이다. executor당 코어 수(=동시 태스크 슬롯 수)를 늘릴수록 n이 커져서 태스크 하나가 받는 몫은 작아진다 — 이게 바로 '코어 수를 늘렸더니 OOM/스필이 오히려 늘었다'는 현상의 근본 원인 중 하나다. 반대로 코어 수를 줄이면 n이 작아져 태스크당 가용 메모리가 늘어난다.

실제 '세그먼트' 단위 — 페이지(MemoryBlock)와 pageTable

TaskMemoryManager가 실제로 메모리를 배분하는 최소 물리 단위가 바로 '페이지(page)'다. 페이지 하나는 MemoryBlock이라는 객체로 표현되고, TaskMemoryManager는 최대 PAGE_TABLE_SIZE(=8192개, 13비트로 인덱싱)개의 페이지를 pageTable이라는 배열에 등록해 관리한다. 페이지 하나의 최대 크기(pageSizeBytes)는 spark.buffer.pageSize로 직접 지정할 수도 있고, 지정하지 않으면 사용 가능한 Execution 메모리와 코어 수를 기준으로 Spark가 자동 계산한다(이론적 상한은 MAXIMUM_PAGE_SIZE_BYTES, 약 15GB — 페이지 내부 오프셋 인코딩에 51비트를 쓰는 주소 체계의 한계에서 나오는 값이다).

메모리를 요청하는 쪽(BytesToBytesMap, UnsafeExternalSorter, ShuffleExternalSorter 같은 MemoryConsumer들)은 allocatePage()를 호출해 페이지를 받고, 다 쓰면 freePage()로 반납한다. allocatePage가 요청한 만큼의 execution 메모리를 확보하지 못하면(다른 태스크/컨슈머들이 이미 많이 쓰고 있으면), TaskMemoryManager는 현재 등록된 MemoryConsumer들에게 메모리 사용량 순으로 스필(디스크로 밀어내기)을 요청해서 공간을 확보한 뒤 재시도한다. 즉 Spark UI에서 보이는 'Spill to Disk'는 이 페이지 할당이 실패해서 어떤 컨슈머가 자기 데이터(정렬 버퍼, 해시 맵 등)를 디스크에 임시로 밀어낸 결과다.

이 '페이지' 개념까지 이해하고 나면, 왜 파티션 수를 늘리거나(태스크당 처리할 데이터량↓, 필요한 페이지 수↓) executor당 코어 수를 줄이는(동시 태스크 수 n↓, 태스크당 가용 Execution 메모리↑) 튜닝이 스필을 줄이는지가 '경험칙을 외우는 것'이 아니라 '메모리 할당 메커니즘에서 논리적으로 도출되는 결론'으로 이해된다.