왜 하이브리드 스케줄링이 필요한가
현대의 HPC와 AI 인프라는 단일 워크로드만 다루지 않습니다. 연구 부문에서는 MPI 기반 HPC Job이 돌아가고, AI 부문에서는 딥러닝 학습과 추론이 Kubernetes 기반 MLOps 워크플로우 위에서 운영됩니다. 이러한 환경에서 스케줄링 시스템을 이원화하면, 자원이 비효율적으로 분리되고 관리 복잡도가 급격히 증가합니다.
따라서 Slurm과 Kubernetes를 연계하는 하이브리드 Scheduling이 필요합니다. Slurm은 HPC Job 관리에 강점을 가지고, Kubernetes는 컨테이너화된 ML/서비스 워크로드 관리에 강점을 가집니다. 이를 조합하면 자원 활용률을 극대화하고, 사용자 경험을 단일화할 수 있습니다.
Slurm과 Kubernetes의 역할 차이
| 구분 | Slurm | Kubernetes |
| 주요 대상 | HPC, MPI, 장기 Batch Job | AI/ML, MLOps, 마이크로서비스 |
| 자원 단위 | 노드, CPU, GPU | Pod, Container |
| 스케줄링 정책 | Gang Scheduling, Backfilling, Fairshare | PriorityClass, PodGroup, Queue |
| 강점 | HPC 성능 최적화, Job Dependency, 자원 관리 | DevOps 친화성, CI/CD, 클라우드 네이티브 |
| 약점 | 컨테이너 통합 부족 | HPC Job 관리 미약 |
하이브리드 환경은 두 시스템이 보완 관계로 동작하게 설계하는 것이 핵심입니다.
Volcano와 Kueue의 역할
Kubernetes 네이티브 환경에서 HPC 스타일 Scheduling을 구현하려면 확장형 스케줄러가 필요합니다. 대표적으로 Volcano와 Kueue가 있습니다.
- Volcano: Gang Scheduling, Fairshare, Backfilling을 지원하는 HPC/AI 특화 스케줄러
- Kueue: Job Queue 관리와 ResourceQuota 기반 Scheduling을 지원하는 비교적 경량의 Job 큐 컨트롤러
두 스케줄러는 단독으로도 동작하지만, Slurm과 연계해 하이브리드 구조를 만들 수도 있습니다.
하이브리드 Scheduling 아키텍처
하이브리드 환경의 대표적인 구조는 다음과 같습니다.
- Slurm 관리 노드가 HPC Job을 관리
- Kubernetes 클러스터가 ML/서비스 워크로드를 관리
- 연계 방식
- Kubernetes Job 제출 시 Slurm 플러그인을 호출해 HPC Job을 실행
- Slurm Job이 완료되면 결과를 Kubernetes로 전달
- Volcano/Kueue가 Kubernetes 내 HPC 스타일 Scheduling을 보조
이런 구조를 통해 사용자 입장에서는 단일 인터페이스에서 Job을 제출하지만, 실제로는 Slurm과 Kubernetes가 협력하여 자원을 배분합니다.
구성 예시 – Volcano와 Slurm 연계
Volcano는 PodGroup을 통해 Gang Scheduling을 지원합니다. 이를 Slurm과 연계하면 MPI Job을 Kubernetes에서 제출하더라도 Slurm 자원을 활용할 수 있습니다.
apiVersion: scheduling.volcano.sh/v1beta1
kind: PodGroup
metadata:
name: mpi-job
spec:
minMember: 8
minResources:
cpu: "64"
nvidia.com/gpu: "8"위 PodGroup 정의를 기반으로 Job을 제출하면, Volcano는 Slurm API 플러그인을 통해 실제 GPU 노드를 확보하고 MPI Job을 실행하도록 연계할 수 있습니다.
구성 예시 – Kueue 활용
Kueue는 Queue 단위로 Job을 관리합니다. Slurm과 연계하는 방식은 다소 단순하지만, 효율적입니다. 예를 들어 Training Job은 Kubernetes Queue에 넣고, Slurm Partition으로 매핑하여 실행합니다.
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
name: training-queue
spec:
clusterQueue: gpu-cluster이 방식은 Slurm이 HPC 자원을 관리하고, Kueue가 Kubernetes Job을 Slurm Partition으로 라우팅하는 구조입니다.
실제 적용 사례
- 반도체 기업 연구소: EDA 시뮬레이션 Job은 Slurm으로, AI 기반 설계 최적화는 Kubernetes로 돌리되, Volcano를 통해 단일 Job 제출 포털을 제공했습니다.
- 클라우드 GPU 서비스: 고객 Job을 Kubernetes 기반으로 받아, 내부적으로 Slurm과 연계해 HPC Job을 실행하는 구조를 채택했습니다.
- 제약 연구소: Kubeflow Pipelines와 Slurm을 연계하여 데이터 전처리는 Kubernetes에서, 대규모 학습은 Slurm에서 실행하도록 구성했습니다.
장점과 단점
장점
- HPC와 AI 워크로드를 동시에 운영 가능
- 자원 활용률 극대화 및 단일 사용자 경험 제공
- 기존 Slurm 인프라를 그대로 유지하면서 Kubernetes 도입 가능
단점
- 연계 구성 복잡도가 높습니다.
- Slurm과 Kubernetes 간 자원 동기화가 필요합니다.
- 운영팀이 두 시스템을 모두 이해해야 관리 효율이 떨어질 수 있습니다.
실무 팁과 주의사항
- 사용자 인터페이스 단일화
- Web Portal 또는 CLI Wrapping을 통해 사용자가 Slurm과 Kubernetes를 구분하지 않고 Job을 제출할 수 있도록 해야 합니다.
- 자원 동기화 체계 구축
- Slurm Accounting과 Kubernetes Metrics를 연계해 자원 사용량을 통합 모니터링해야 합니다.
- 워크로드 특성 구분
- HPC Job은 Slurm, 서비스 워크로드는 Kubernetes로 명확히 구분하는 것이 안정적입니다.
- 스케줄링 정책 일관성
- Fairshare, QoS 같은 정책은 Slurm과 Volcano/Kueue에서 동일하게 반영해야 사용자 혼란을 줄일 수 있습니다.
- 점진적 도입
- 초기에는 Slurm 중심으로 운영하면서, Kubernetes 워크로드를 점진적으로 확장하는 방식이 안정적입니다.
정리하며
Slurm과 Kubernetes를 연계한 하이브리드 Scheduling은 HPC와 AI 인프라의 융합을 가능하게 합니다. Volcano와 Kueue 같은 확장형 스케줄러를 활용하면 Gang Scheduling, Queue 관리, Fairness 등을 Kubernetes에서도 구현할 수 있으며, Slurm과의 연계를 통해 자원 활용률을 높일 수 있습니다. 운영자는 두 체계를 보완적으로 구성해 단일 사용자 경험과 높은 효율성을 동시에 달성해야 합니다.