Barrier Execution Mode — Spark 안에 MPI 스타일 분산 학습을 끼워넣기
Spark Continuous Processing 및 Barrier Execution Mode 공식 문서 종합 (웹 리서치, 2026) — Apache Spark 공식 문서(streaming/performance-tips.html) + Apache Spark JIRA(SPARK-24374, Project Hydrogen) Apache Spark JIRA SPARK-24374(Project Hydrogen)
이 모듈을 다 읽으면
- Barrier Execution Mode가 일반 태스크 스케줄링과 근본적으로 다른 지점(전원 동시 실행+전원 재시작)을 설명할 수 있다
- 이 모드가 왜 분산 딥러닝 학습과 잘 맞는지 설명할 수 있다
spark-learn-22에서 다룬 일반적인 태스크 스케줄링(태스크 하나가 실패하면 그 태스크만 재시도)과 근본적으로 다르게 동작하는, MapReduce 실행 모델 위에 갱 스케줄링(gang scheduling)을 얹어 분산 딥러닝 학습 같은 워크로드를 Spark 파이프라인에 끼워넣을 수 있게 해주는 Barrier Execution Mode를 정리한다.
일반 태스크와 다른 점 — '전부 같이 뜨고, 하나 죽으면 전부 재시작'
RDD.barrier()를 호출해 어떤 스테이지를 배리어 스테이지로 지정하면, Spark 스케줄러는 그 스테이지의 모든 태스크를 반드시 한꺼번에(동시에) 실행시킨다 — 일부만 먼저 뜨고 나머지는 자원이 빌 때까지 기다리는 일반적인 방식과 다르다. 게다가 그 중 태스크 하나라도 실패하면, 일반 모드처럼 그 태스크 하나만 재시도하는 게 아니라 스테이지 전체를 중단하고 모든 태스크를 통째로 다시 실행한다 — 이는 Project Hydrogen이라는 계획의 일부로 도입된 갱 스케줄링(gang scheduling) 방식이다.
핵심 포인트
- RDD.barrier()로 지정한 스테이지는 모든 태스크가 반드시 동시에 실행(gang scheduling) — 일부만 먼저 뜨는 일반 스케줄링과 다름
- 태스크 하나라도 실패하면 그 하나만 재시도하지 않고 스테이지 전체를 중단 후 전부 재실행
왜 이런 방식이 필요한가 — MPI 스타일 통신을 흉내낸다
일반적인 MapReduce 모델의 태스크는 서로 독립적이라고 가정하고 설계돼, 태스크끼리 지속적으로 통신하며 상태를 주고받는 분산 딥러닝 학습(여러 워커가 그래디언트를 동기화하는 등)과는 근본적으로 안 맞는다. Barrier Execution Mode는 태스크 안에서 워커의 호스트명과 파티션 식별자에 접근할 수 있게 해주고, MPI의 MPI_Barrier 함수와 비슷한 배리어 호출도 제공한다 — 이 정보와 도구를 조합해, 분산 딥러닝 학습 프레임워크를 Spark 파이프라인 안에 자연스럽게 끼워넣을 수 있게 해주는 게 목적이다.
핵심 포인트
- 일반 MapReduce 모델은 태스크 간 독립성을 가정 — 지속적으로 통신해야 하는 분산 딥러닝 학습과 근본적으로 안 맞음
- Barrier Execution Mode는 워커 호스트명/파티션 식별자 접근 + MPI_Barrier와 유사한 배리어 호출을 제공해 MPI 스타일 통신을 Spark 안에서 흉내냄