이 비교가 중요한 이유

AI와 고성능 컴퓨팅 (HPC)이 계속해서 융합됨에 따라, 거의 모든 인프라 논의에서 한 가지 질문이 등장합니다:

Kubernetes를 사용해야 할까요, 아니면 Slurm을 사용해야 할까요?

그 답은 단순히 하나를 다른 하나보다 선택하는 것만큼 간단한 경우가 거의 없습니다.

Kubernetes는 클라우드 네이티브 (Cloud native) 애플리케이션 배포를 지배하고 있는 반면, Slurm은 수십 년 동안 과학적 컴퓨팅 (Scientific computing) 및 슈퍼컴퓨터의 선택을 받아온 스케줄러 (Scheduler)였습니다. 오늘날 AI 학습, 머신러닝 (Machine learning), 시뮬레이션 (Simulations), 계산 화학 (Computational chemistry), CFD, 그리고 금융 모델링 (Financial modeling)을 실행하는 조직들은 종종 어떤 플랫폼이 자신들의 워크로드 (Workloads)에 더 잘 맞는지 결정해야 합니다.

이 기사는 각 플랫폼이 어디에서 뛰어나고, 어디에서 어려움을 겪으며, 언제 두 가지를 함께 사용하는 것이 가장 합리적인지를 설명합니다.

서로 다른 목표의 이해

두 시스템 모두 클러스터 (Clusters) 전체에 워크로드를 스케줄링하지만, 완전히 다른 목적을 가지고 구축되었습니다.

Kubernetes는 대규모 환경에서 컨테이너 (Containers)와 마이크로서비스 (Microservices)를 오케스트레이션 (Orchestrate)하기 위해 설계되었습니다.

그 우선순위는 다음과 같습니다:

• 고가용성 (High availability)
• 오토 스케일링 (Auto scaling)
• 셀프 힐링 애플리케이션 (Self healing applications)
• 롤링 업데이트 (Rolling updates)
• 서비스 디스커버리 (Service discovery)
• 클라우드 네이티브 배포 (Cloud native deployments)

반면, Slurm은 컴퓨팅 효율성을 극대화하는 것이 주요 목표인 HPC 환경을 위해 특별히 구축되었습니다.

그 우선순위는 다음과 같습니다:

• 효율적인 자원 할당 (Efficient resource allocation)
• 공정 스케줄링 (Fair scheduling)
• 작업 큐잉 (Job queuing)
• 대규모 MPI 작업 (Large MPI jobs)
• GPU 스케줄링 (GPU scheduling)
• 높은 클러스터 활용도 (High cluster utilization)

둘 다 워크로드를 스케줄링하지만, 완전히 다른 문제를 최적화합니다.

아키텍처 비교

자원 스케줄링

이 부분이 가장 큰 차이점이 나타나는 곳입니다.

Kubernetes 스케줄링

Kubernetes는 다음을 기반으로 Pod를 스케줄링합니다:

• CPU 요청 (CPU requests)
• 메모리 요청 (Memory requests)
• 레이블 (Labels)
• 어피니티 규칙 (Affinity rules)
• 테인트 및 톨러레이션 (Taints and tolerations)
• 커스텀 스케줄러 (Custom schedulers)
• 우선순위 클래스 (Priority classes)

이는 주로 다음 질문에 답합니다:

"이 컨테이너는 어디에서 실행되어야 하는가?"

스케줄러는 이용률 (utilization)을 극대화하기보다는 클러스터의 상태 (health)에 집중합니다.

Slurm 스케줄링 (Slurm Scheduling)

Slurm은 훨씬 더 많은 정보를 고려합니다.

예시:

• 가용 CPU (Available CPUs)
• 메모리 (Memory)
• GPU
• 라이선스 (Licenses)
• 파티션 (Partitions)
• QoS (Quality of Service)
• 예약 (Reservations)
• 노드 토폴로지 (Node topology)
• NUMA 레이아웃 (NUMA layout)
• 작업 우선순위 (Job priority)
• 페어 쉐어 (Fair share)
• 백필 기회 (Backfill opportunities)

대신, Slurm은 다음과 같이 답합니다:

"어떻게 하면 모든 컴퓨팅 작업 (compute job)을 가능한 한 효율적으로 실행할 수 있는가?"

HPC 환경에서 이러한 차이점은 매우 중요합니다.

GPU 관리 (GPU Management)

AI 워크로드의 성패는 GPU 이용률 (utilization)에 달려 있습니다.

Kubernetes

GPU 지원은 다음을 통해 이루어집니다:

• NVIDIA Device Plugin
• GPU Operator
• MIG 지원 (MIG support)
• 장치 공유 (Device sharing)
• 동적 프로비저닝 (Dynamic provisioning)

다음 작업에 탁월합니다:

• AI 추론 (AI inference)
• 모델 서빙 (Model serving)
• MLOps 파이프라인 (MLOps pipelines)
• Kubernetes 네이티브 AI 플랫폼 (Kubernetes native AI platforms)

Slurm

GPU 스케줄링은 수년 동안 HPC의 일부였습니다.

다음 기능을 지원합니다:

• GRES (Generic Resource Scheduling)
• GPU 어피니티 (GPU affinity)
• 독점 GPU 할당 (Exclusive GPU allocation)
• 멀티 노드 GPU 작업 (Multi node GPU jobs)
• GPU 토폴로지 인식 (GPU topology awareness)
• CUDA 인식 스케줄링 (CUDA aware scheduling)

대규모 분산 학습 작업 (Large distributed training jobs)은 일반적으로 Slurm과 자연스럽게 통합됩니다.

멀티 노드 분산 학습 (Multi node Distributed Training)

현대적인 LLM 학습은 종종 수십 개 또는 수천 개의 GPU에 걸쳐 이루어집니다.

Kubernetes

다음 도구들을 사용하여 가능합니다:

• Kubeflow
• Ray
• Volcano Scheduler
• MPI Operator
• Kueue

이러한 프로젝트들이 상당히 성숙해졌지만, 분산 AI 학습은 종종 핵심 Kubernetes 이상의 추가 구성 요소가 필요합니다.

Slurm

분산 워크로드 (Distributed workloads)가 네이티브로 지원됩니다.

수천 개의 MPI 프로세스를 실행하는 것은 다음과 같이 간단합니다:

srun -N 64 -n 512 ./application

또는 GPU 학습:

srun torchrun ...

MPI, NCCL, UCX, 그리고 InfiniBand는 Slurm 환경과 자연스럽게 통합됩니다.

네트워킹 (Networking)

고성능 네트워킹은 또 다른 주요 차별화 요소입니다.

Kubernetes

보통 다음을 중심으로 설계됩니다:

• CNI 플러그인 (CNI plugins)
• 오버레이 네트워크 (Overlay networks)
• 서비스 메시 (Service meshes)
• 네트워크 정책 (Network policies)

RDMA와 InfiniBand가 지원되기는 하지만, 종종 추가적인 설정이 필요합니다.

Slurm

다음 항목들을 사용하는 클러스터를 위해 설계되었습니다:

• InfiniBand
• HDR/NDR 패브릭 (fabrics)
• RoCE
• UCX
• MPI
• 저지연 통신 (Low latency communication)

네트워크 성능이 일급 시민 (first class citizen)으로 취급됩니다.

작업 수명 주기 (Job Lifecycle)

Kubernetes

애플리케이션은 종종 지속적으로 실행됩니다.

예시:

• 웹 API (Web APIs)
• 데이터베이스 (Databases)
• AI 추론 서버 (AI inference servers)
• 모니터링 서비스 (Monitoring services)

Pod는 장애 발생 후 자동으로 재시작됩니다.

Slurm

작업 (Jobs)은 일시적입니다.

전형적인 수명 주기:

1. 제출 (Submit)
2. 대기 (Queue)
3. 리소스 할당 (Allocate resources)
4. 실행 (Execute)
5. 종료 (Finish)
6. 리소스 해제 (Release resources)

이는 과학 계산 (scientific computing)에 완벽하게 부합합니다.

오토 스케일링 (Auto Scaling)

Kubernetes

Kubernetes의 가장 큰 강점 중 하나입니다.

지원 항목:

• 수평 Pod 오토스케일러 (Horizontal Pod Autoscaler)
• 수직 Pod 오토스케일러 (Vertical Pod Autoscaler)
• 클러스터 오토스케일러 (Cluster Autoscaler)
• 클라우드 자동 프로비저닝 (Cloud auto provisioning)

동적인 워크로드 (dynamic workloads)에 이상적입니다.

Slurm

전통적으로 고정된 클러스터를 위해 구축되었습니다.

하지만 현재는 클라우드 통합을 통해 다음과 같은 도구로 탄력적 컴퓨팅 (elastic compute)이 가능합니다:

• Azure CycleCloud
• AWS ParallelCluster
• AWS PCS
• Google Cloud HPC Toolkit

노드는 대기열 수요에 따라 자동으로 시작 및 중지될 수 있습니다.

생태계 (Ecosystem)

Kubernetes 생태계

생태계가 매우 방대합니다.

인기 있는 AI 도구에는 다음이 포함됩니다:

• Kubeflow
• MLflow
• Argo Workflows
• Ray
• KServe
• Prometheus
• Grafana
• Istio
• Helm

클라우드 제공업체들은 완전 관리형 Kubernetes 서비스를 제공합니다.

Slurm 생태계

HPC에 집중되어 있습니다.

일반적인 통합 항목에는 다음이 포함됩니다:

• OpenMPI
• MPICH
• UCX
• BeeGFS
• Lustre
• GPFS
• Spack
• Lmod
• Apptainer (Singularity)

이 도구들은 많은 연구 기관과 슈퍼컴퓨팅 센터에서 표준으로 사용됩니다.

성능 (Performance)

밀접하게 결합된 (tightly coupled) HPC 작업의 경우, Slurm은 일반적으로 다음과 같은 요소들을 이해하기 때문에 더 나은 성능을 제공합니다:

• CPU 토폴로지 (CPU topology)
• NUMA 도메인 (NUMA domains)
• GPU 지역성 (GPU locality)
• 네트워크 토폴로지 (Network topology)
• 독점 할당 (Exclusive allocations)

Kubernetes는 추가적인 추상화 계층 (abstraction layers)을 도입하며, 이는 클라우드 애플리케이션에는 수용 가능하지만 지연 시간에 민감한 (latency sensitive) HPC 워크로드에는 복잡성을 더할 수 있습니다.

AI 추론 (Inference) 또는 마이크로서비스 (Microservices)의 경우, Kubernetes가 일반적으로 더 강력한 선택지입니다.

운영 복잡성 (Operational Complexity)

두 도구가 함께 작동할 수 있을까요?

물론입니다.

많은 조직이 더 이상 둘 중 하나만을 선택하지 않습니다.

일반적인 아키텍처는 다음과 같습니다:

• Kubernetes 용:
  • AI 추론 (Inference)
  • API
  • MLOps
  • Jupyter notebooks
  • 웹 서비스 (Web services)
  • 모델 배포 (Model deployment)
• Slurm 용:
  • AI 학습 (Training)
  • HPC 시뮬레이션 (Simulations)
  • MPI 애플리케이션 (MPI applications)
  • 대규모 GPU 클러스터 (Large GPU clusters)
  • 과학적 컴퓨팅 (Scientific computing)
  • 배치 처리 (Batch processing)

일부 환경에서는 Kubernetes가 Slurm으로 관리되는 클러스터에 워크로드를 제출하도록 허용하여, 클라우드 네이티브 도구의 유연성과 HPC 스케줄링 (Scheduling)의 효율성을 결합하기도 합니다.

어떤 것을 선택해야 할까요?

마치며

Kubernetes와 Slurm은 전통적인 의미의 경쟁자가 아닙니다. 이들은 서로 다른 문제를 해결하기 위해 설계되었으며, 두 플랫폼 모두 현대적인 AI 인프라를 지원하도록 진화해 왔습니다.

만약 주요 초점이 클라우드 네이티브 애플리케이션, 모델 서빙 (Model serving), 그리고 확장 가능한 AI 서비스에 있다면, Kubernetes는 타의 추종을 불허하는 유연성과 생태계 지원을 제공합니다.

만약 목표가 밀접하게 결합된 (Tightly coupled) 과학적 워크로드나 대규모 분산 AI 학습을 위해 값비싼 CPU 및 GPU의 활용도를 극대화하는 것이라면, Slurm은 여전히 골드 표준 (Gold standard)으로 남아 있습니다.

AI 플랫폼이 계속 성장함에 따라, 가장 효과적인 아키텍처는 둘 중 하나를 강요하기보다 두 기술의 강점을 결합하는 방향으로 점점 더 나아가고 있습니다.

AI 인프라의 미래는 Kubernetes 대 Slurm의 대결이 아닙니다. 각각을 언제 사용해야 하는지를 아는 것입니다.