왜 Gang Scheduling이 필요한가
HPC와 대규모 GPU 클러스터에서는 단일 Job이 수십~수천 개의 노드와 GPU를 동시에 필요로 합니다. 특히 딥러닝 분산 학습(예: Transformer 기반 모델)이나 MPI(Message Passing Interface) 기반 과학 계산에서는 Job이 모든 프로세스가 동시에 시작하지 않으면 정상적으로 진행되지 않습니다. 한 노드에서만 리소스가 준비되고 다른 노드가 대기하면 전체 Job이 지연되거나 Deadlock 상태에 빠집니다.
이 문제를 해결하기 위해 Gang Scheduling과 Co-Scheduling 기법이 사용됩니다. 두 방식 모두 “여러 태스크를 하나의 그룹(Gang)으로 묶어 동시에 실행”하도록 하는 전략이지만, 접근 방식과 목적에는 차이가 있습니다.
Gang Scheduling과 Co-Scheduling의 차이
두 용어는 유사하게 쓰이지만 실제 운영 개념은 다소 다릅니다.
| 구분 | Gang Scheduling | Co-Scheduling |
| 정의 | 다수의 태스크를 하나의 그룹으로 묶고, 그룹 내 모든 태스크가 동시에 실행되도록 스케줄링합니다. | 여러 Job 또는 태스크 그룹을 시간 단위(time-slice)로 번갈아 실행하여 자원 공정성을 보장합니다. |
| 적용 환경 | 대규모 MPI Job, 분산 학습(NCCL AllReduce 등) | 멀티테넌시 환경, 대화형 워크로드와 배치 Job 혼합 |
| 운영 초점 | “All-or-Nothing” 실행 보장 | **공정성(Fairness)**과 응답성(Responsiveness) 확보 |
| 장점 | 효율적인 동기화, 성능 극대화 | 다양한 워크로드 공존 가능, 자원 활용률 개선 |
| 단점 | 대기열이 길어질 수 있으며 자원 파편화가 증가합니다. | Job 성능 예측이 어려우며 스케줄러 복잡성이 커집니다. |
작동 원리와 데이터 흐름
Gang Scheduling의 핵심은 자원 확보 → 그룹 실행 → 그룹 종료의 순환 구조입니다. 예를 들어 128개의 GPU가 필요한 Job이 제출되면, 스케줄러는 모든 GPU가 확보될 때까지 대기시킵니다. 모든 자원이 준비되면 동시에 시작하여 학습이 진행됩니다.
반면 Co-Scheduling은 한정된 GPU를 여러 그룹이 번갈아 사용하는 방식입니다. 예를 들어 4개의 GPU 환경에서 두 그룹이 각각 4GPU Job을 제출하면, 각 그룹이 일정 시간 동안 GPU 전체를 점유한 후 교대로 실행됩니다. 이 방식은 자원 공정성을 보장하지만 Context Switching에 따른 성능 손실이 발생할 수 있습니다.
Slurm에서의 Gang Scheduling
Slurm 23.x는 기본적으로 JobStep 단위 동시 실행을 지원하며, srun 명령을 통해 Gang Scheduling을 구현할 수 있습니다.
# 4노드, 각 노드당 8GPU를 동시에 확보 후 실행
srun --nodes=4 \
--gres=gpu:8 \
--ntasks=32 \
--exclusive \
python train_distributed.py또한 Slurm에서는 PriorityWeightAge, PriorityWeightFairshare와 같은 우선순위 파라미터를 조정하여 Gang Job이 대기열에서 지나치게 밀리지 않도록 제어할 수 있습니다. 많은 기관에서는 Backfilling과 Gang Scheduling을 혼합하여 Idle 자원을 소규모 Job에 활용하면서도, 대규모 Gang Job이 들어오면 빠르게 실행되도록 정책을 구성합니다.
Kubernetes/Volcano에서의 Co-Scheduling
기본 Kubernetes 스케줄러는 Gang Scheduling 개념이 약합니다. 그러나 Volcano 같은 확장형 스케줄러는 이를 네이티브로 지원합니다. Volcano의 PodGroup CRD(Custom Resource Definition)를 활용하면 특정 수 이상의 Pod가 동시에 스케줄링될 때만 Job이 시작됩니다.
apiVersion: scheduling.volcano.sh/v1beta1
kind: PodGroup
metadata:
name: dist-training
spec:
minMember: 16 # 최소 16개 Pod가 동시에 스케줄링될 때만 실행
minResources:
cpu: "64"
nvidia.com/gpu: "16"이 설정을 통해 분산 학습 Job이 Deadlock에 빠지지 않고 안정적으로 실행됩니다. 또한 최근에는 Kueue와 연계하여 쿠버네티스 환경에서도 HPC 스타일의 Gang Scheduling을 구현하는 사례가 늘고 있습니다.
산업별 적용 사례
- AI 스타트업: 대규모 언어 모델(LLM) 학습 시 Gang Scheduling을 적용하여 모든 GPU 노드가 동시에 학습을 시작하게 함으로써 학습 시간을 수십 % 단축합니다.
- 제약 연구소: 분자 시뮬레이션 Job에서 MPI 통신 실패를 줄이기 위해 Co-Scheduling을 활용하고, 다양한 Job을 시간 분할로 운영하여 자원 낭비를 최소화합니다.
- 클라우드 GPUaaS 업체: 고객 Job을 PodGroup 기반으로 동시 실행시켜 GPU 리소스를 효율적으로 활용하면서 SLA(Service Level Agreement)를 충족합니다.
장점과 단점
장점
- 동기화 문제를 해결하여 Deadlock을 방지합니다.
- 분산 학습, MPI Job에서 성능을 극대화합니다.
- 멀티테넌트 환경에서도 공정성을 보장합니다.
단점
- Gang Scheduling: 대규모 Job으로 인해 대기 시간이 길어질 수 있습니다.
- Co-Scheduling: Context Switching에 따른 성능 변동성이 존재합니다.
- 운영 복잡성이 증가하고 정책 튜닝이 필요합니다.
실무 팁과 주의사항
- 대규모 Job 우선순위 관리
- Gang Scheduling Job은 대기열 독점 위험이 있으므로 QoS와 Fairshare 정책을 반드시 병행해야 합니다.
- Hybrid 전략
- Idle 자원 활용을 위해 Backfilling을 함께 구성하는 것이 효과적입니다.
- 모니터링 도구 활용
- Slurm의 sdiag와 Volcano Metrics API를 통해 대기 시간, 실행 시간, 자원 활용률을 지속적으로 관찰해야 합니다.
- Kubernetes 환경 주의
- 기본 스케줄러는 제한적이므로 Volcano, Kueue 같은 확장형 스케줄러를 반드시 고려해야 합니다.
정리하며
Gang Scheduling과 Co-Scheduling은 HPC/GPU 클러스터에서 대규모 분산 Job의 성능과 안정성을 보장하는 핵심 기법입니다. Gang Scheduling은 All-or-Nothing 실행을 보장하며, Co-Scheduling은 공정성과 응답성을 확보합니다.
운영자는 두 방식을 워크로드 특성에 맞게 선택하거나 혼합하여 자원 활용률과 사용자 만족도를 극대화해야 합니다. Slurm, Kubernetes/Volcano, Kueue 등 다양한 툴에서 이를 지원하므로, 정책과 모니터링을 잘 결합하는 것이 성공적인 운영의 열쇠입니다.