비중단 스케줄링 전환을 위한 운영 전략

본 논문은 GWU의 Pegasus HPC 클러스터(205대 노드, 42대 GPU 노드, 8,600 CPU 코어, 280 TB 메모리, 2 PB 스토리지, 800명 연구자)를 사례로, 기존의 노드 전용(node‑exclusive) 스케줄링에서 Slurm의 소비형 자원(TRES) 기반 스케줄링으로 전환하는 전 과정을 상세히 기술한다. 1. **배경 및 문제점** 노드 전용 모델에서는 파티션을 이용해 메모리·GPU 등 특수 자원을 구분했으며, 이는 파티션 수의 급증과 사용자 입장에서 복잡한 제출 환경을 초래했다. 실제 사용 로그 분석 결과, CPU 코어의 포장 효율이 낮고, GPU가 할당된 작업 중 실제 GPU 사용률이 0%에 가까운 경우가 다수 발견되었다. 이러한 비효율은 자원 파편화와 대기시간 증가로 이어졌다. 2. **전환 전략 설계** - **시간 제한 호환 레이어**: 90일 동안 레거시 sbatch 명령을 자동으로 TRES 형식으로 변환하는 경량 래퍼 스크립트를 제공하였다. 레거시 제출은 허용하되, 변환된 작업에 대한 메타데이터를 기록해 추후 분석에 활용했다. - **관측 기반 피드백**: Slurm 회계 데이터와 Zabbix 에이전트를 연동해 CPU·GPU 코어 활용률, 메모리 사용량, 대기시간 퍼센타일 등을 실시간 수집하였다. 특히 GPU 사용률이 낮은 작업을 시각화해 타운홀 및 1:1 상담에서 직접 보여줌으로써 사용자가 자신의 비효율을 인식하도록 했다. - **사용자 참여**: 전환 가이드 문서를 배포하고, 오피스 아워와 타운홀을 통해 “파티션 대신 자원 선언”이라는 개념을 강조했다. 초기 피드백을 수집해 스크립트와 문서를 지속적으로 개선하였다. 3. **관측 인프라 및 메트릭** - **대기시간 퍼센타일**(P50, P75, P90) - **CPU 포장 효율**(코어당 사용률) - **GPU 할당 대비 활용률** - **메모리 요청 대비 실제 사용** 이러한 메트릭은 전환 전후의 성능 변화를 정량화하고, 사용자에게 맞춤형 개선 제안을 제공하는 데 활용되었다. 4. **성과 측정** - **CPU 작업**: 전환 전 P50 대기시간 277 분 → 전환 후 3 분 이하, P90 3000 분 → 800 분 이하. - **GPU 작업**: 전환 전 P50 81 분 → 3.4 분, P90 5567 분 → 500 분 이하. - **레거시 작업**: 전환 후에도 레거시 방식으로 제출된 GPU 작업은 평균 대기시간 344 분으로 크게 불리했다. - **채택률**: 전환 기간 동안 TRES 기반 제출 비율이 점진적으로 상승했으며, Kaplan–Meier 분석 결과 초기 몇 번의 작업 이후 이탈하는 사용자를 제외하면 장기적으로 높은 유지율을 보였다. 5. **운영 교훈** - **호환 레이어의 필요성**: 완전 차단 없이 단계적 전환이 가능하도록 함으로써 서비스 중단을 방지했다. - **관측 데이터의 역할**: 실시간 메트릭이 사용자 행동을 교정하고, 스케줄러 설정 변경의 효과를 빠르게 검증할 수 있게 했다. - **사용자 교육의 중요성**: 기술적 변화를 사용자 경험과 연결시켜, 새로운 모델에 대한 신뢰와 채택을 촉진했다. 6. **결론** 소비형 자원 스케줄링 도입은 단순히 슬럼 설정을 바꾸는 것이 아니라, 운영팀과 사용자 사이의 협업, 관측 기반 피드백, 그리고 명확한 전환 로드맵이 결합될 때 성공한다는 점을 입증했다. 이 전략은 다른 대규모 생산 HPC 환경에서도 적용 가능하며, 자원 활용 효율과 사용자 만족도를 동시에 향상시킬 수 있다.