HPC 환경에서 SLRUM -> K8S 마이그레이션 연구

[기존]

slurm 이라는 오픈소스를 활용하여 HPC job을 스케줄링.
(시뮬레이션, 검증, DFT 등의 작업을 수행할 때 수억 개의 트랜지스터, 게이트, 배선, 테스트 패턴 등을 메모리에 로드해야함, 대부분의 EDA툴이 대량의 데이터를 캐싱 및 실시간 연산 수행 - 리소스 사용량이 엄청남 -> 베어메탈 서버에 메모리 4TB씩 꼽고 사용중..)

문제점: Priority에 따른 scheduling 로직 고도화 및 세부 job 상태 monitoring을 위한 TaskManager 모듈 추가구현.

이에 따라 관리 point가 TM, Slurm 두군데가 되어버림. 이를 k8s 전환을 통해 하나의 아키텍처에서 관리 목표 (k8s crd 활용)

베어메탈 vs VM vs 컨테이너(K8S)

방식장점단점반도체 EDA 환경에서 적합 여부

방식	장점	단점	반도체 EDA 환경 적합 여부
베어메탈 서버 (Bare Metal)	성능 최적화, 모든 리소스를 단일 워크로드에 사용 가능	확장성 제한, 유연성 부족	가장 일반적인 방식 (고성능 요구 환경에 적합)
가상머신 (VM, Virtual Machine)	리소스 분할 가능, 다중 환경 지원	오버헤드 발생, 단일 워크로드에 적합하지 않음	메모리 사용량이 극심한 반도체 환경에서는 비효율적
컨테이너 & Kubernetes (K8S)	분산 환경에서 유연한 리소스 관리, 확장성 뛰어남	단일 프로세스에 대량 메모리 할당 어려움	특정 워크로드(예: 병렬 시뮬레이션)에는 가능, 그러나 제한적

 

K8S에서 반도체 설계 & 검증 Job을 컨테이너화할 때 고려할 점

✔ K8S는 "작은 워크로드의 오토스케일링"에 강점이 있음
✔ 하지만, 반도체 검증/EDA 환경에서는 단일 Job이 대량의 메모리를 필요로 하므로, 기존 HPC 방식이 더 적합할 수도 있음.
✔ EDA 툴이 컨테이너에서 정상 동작하는지 검토 필요 (라이선스 이슈, 성능 이슈 발생 가능)

 

SLURM과 Kubernetes는 각기 다른 목적으로 설계된 시스템이라, 단순 비교보다는 어떤 환경에서 더 적합한지가 중요

기능	SLURM(AS_IS)	Kubernetes(TO_BE)
주요 목적	HPC(High Performance Computing) 워크로드 스케줄링	클라우드 네이티브 컨테이너 오케스트레이션
리소스 관리 방식	물리적인 CPU/GPU/RAM 기반 예약	컨테이너 단위 리소스 요청(Request/Limits)
스케줄링 정책	FairShare, Priority, Preemption 지원	PriorityClass 및 Custom Scheduler 가능
병렬 워크로드 지원	MPI, OpenMP 기반 병렬 작업 최적	병렬 컴퓨팅도 가능하지만 MPI 최적화 부족
워크로드 유형	HPC, AI, EDA, 연구용 클러스터	일반적인 배포 시스템, ML, 데이터 처리
노드 장애 처리	Slurm 자체적으로 장애 감지 및 재시작	K8S에서 Pod 자동 재시작 가능
세밀한 정책 제어	제한적 (Priority 기반 설정 어려움)	스텀 스케줄러 적용 가능 (유연성 높음)
확장성	대규모 클러스터 확장 가능	자동 확장 가능 (HPA, VPA, Cluster Autoscaler)
라이선스 관리	라이선스 제한 있는 경우 많음	컨테이너 기반 라이선스 관리 필요

SLURM은 기존 HPC 환경에서 사용하기 최적화되어 있지만, Kubernetes는 더 유연한 스케줄링 및 확장성을 제공할 수 있음.

 

SLURM → Kubernetes 마이그레이션의 장점

Priority 기반 세밀한 스케줄링 가능

• PriorityClass, Custom Scheduler, Taints & Tolerations 등 다양한 방법으로 우선순위 조정 가능

자동 확장(Auto Scaling) 가능

• Cluster Autoscaler, Vertical Pod Autoscaler(VPA) 사용 가능

노드 장애 복구 & 고가용성

• SLURM도 장애 감지는 가능하지만, K8S는 Pod 단위로 자동 복구

다양한 스토리지 & 네트워크 옵션 지원

• PersistentVolume, CSI, CNI 활용 가능

클라우드 네이티브 환경에서 활용 가능

• 클라우드 리소스 연계가 쉬워짐 (예: AWS EKS, GCP GKE 등)

---

SLURM → Kubernetes 마이그레이션의 단점 (문제점)

MPI 기반 병렬 컴퓨팅 최적화 부족

• SLURM은 MPI(OpenMPI, MPICH) 최적화되어 있음 → K8S에서는 추가 설정 필요
• 해결책: KubeFlow MPI Operator 활용 가능

EDA 툴 컨테이너화 검증 필요

• 기존 SLURM 환경에서는 물리 서버에서 실행됨 → K8S에서 컨테이너화할 경우 라이선스 이슈 & 성능 저하 가능
• 해결책: EDA 툴 컨테이너 실행 테스트 필수

SLURM의 FairShare, QoS 같은 세밀한 정책 직접 구현 필요

• SLURM의 FairShare, Preemption 정책을 K8S에서 직접 구현해야 함
• 해결책: K8S Custom Scheduler + PriorityClass 활용

즉, SLURM → K8S 마이그레이션은 가능하지만, EDA 툴 라이선스/성능 검증이 필수적이며, 일부 기능은 직접 구현해야 함.

 

최종 결론

SLURM vs Kubernetes 마이그레이션 가능 여부

✔ SLURM을 Kubernetes로 대체하는 것이 가능하지만, 몇 가지 고려할 점이 있음.
✔ SLURM이 제공하는 FairShare, Preemption, QoS 기능을 K8S에서는 Custom Scheduler, PriorityClass, Taints & Tolerations 등으로 직접 구현해야 함.
✔ EDA 툴이 컨테이너 환경에서 정상 동작하는지 먼저 검증 필수

✔ SLURM + K8S 하이브리드 환경 유지?

• 예: SLURM에서 일부 워크로드 실행, Kubernetes에서 일부 워크로드 실행
  ✔ K8S에서 SLURM 기능을 완전히 대체하려면 Custom Scheduler 개발 필요