스토리지가 HPC 성능의 숨은 열쇠
HPC/GPU 클러스터를 운영하다 보면 많은 분들이 CPU 사용률이나 GPU 점유율만 주로 살펴보곤 합니다. 하지만 실제로 Job이 느려지는 원인의 상당수는 스토리지 I/O 병목 때문입니다.
- 딥러닝 학습 Job이 데이터 로딩에서 오래 걸리는 경우
- 수천 개의 작은 파일을 동시에 읽을 때 성능 저하가 발생하는 경우
- 병렬 파일시스템(Lustre, BeeGFS 등)에서 특정 노드만 지연이 발생하는 경우
이 모든 상황은 I/O 성능 모니터링으로 원인을 찾을 수 있습니다. 이번 글에서는 Linux에서 흔히 사용하는 세 가지 도구, iostat, iotop, sar을 중심으로 HPC 환경에서 스토리지를 진단하는 방법을 다뤄보겠습니다.
iostat – 디스크 I/O 성능 측정
iostat는 CPU와 블록 디바이스의 I/O 통계를 보여주는 도구입니다. HPC 환경에서는 Job 실행 중 디스크 사용률과 응답 시간을 확인할 때 필수적으로 사용됩니다.
주요 활용법
# 2초 간격으로 5회 측정
iostat -dx 2 5
# MB 단위로 출력
iostat -m
# 모든 디바이스 정보 출력
iostat -p ALL
주요 지표 해석
- %util: 해당 디스크가 바쁘게 사용된 비율 (100% 근접 시 병목)
- r/s, w/s: 초당 읽기/쓰기 요청 수
- await: 평균 응답 시간 (ms 단위)
- svctm: 서비스 처리 시간
HPC 운영 포인트
- Lustre, BeeGFS 같은 병렬 파일시스템에서도 각 OSS/Object Storage Target의 디스크 busy율을 확인할 수 있습니다.
- 특정 노드에서만 I/O가 느리다면, iostat 결과를 비교하여 하드웨어적 결함 여부를 빠르게 파악할 수 있습니다.
iotop – 프로세스별 I/O 추적
iotop은 I/O 활동을 프로세스 단위로 보여주는 도구입니다. CPU top 명령어의 I/O 버전이라 생각하면 이해하기 쉽습니다.
주요 활용법
# 실시간 모니터링
iotop
# 특정 PID만 모니터링
iotop -p 12345
# 누적 I/O 합계 보기
iotop -a
HPC 운영 포인트
- 특정 Job이 GPU는 거의 사용하지 않는데 I/O만 많이 발생하는 경우, iotop으로 원인을 바로 파악할 수 있습니다.
- 다중 사용자 환경에서 누가 스토리지 과부하를 일으키는지 확인할 때 유용합니다.
- Slurm과 연계하면, Job ID와 PID 매핑을 통해 Job 단위의 I/O 소비 패턴을 추적할 수 있습니다.
sar – 장기적인 I/O 성능 분석
sar은 시스템 활동 보고 도구로, CPU, 메모리, 네트워크, I/O 등 다양한 자원을 시간 단위로 기록·분석할 수 있습니다. 특히 I/O 부문에서는 장기적인 추세를 파악하는 데 강점이 있습니다.
주요 활용법
# 디스크 I/O 통계 보기
sar -d 1 5
# 블록 장치별 상세 보기
sar -p -d 1 5
# 저장된 로그에서 과거 기록 확인
sar -f /var/log/sa/sa15
HPC 운영 포인트
- 특정 시간대(예: 야간 배치 Job 실행 시간)에 스토리지 사용률이 급증하는 패턴을 확인할 수 있습니다.
- iostat과 달리 sar은 장기간 데이터를 보관할 수 있어, 일간·주간·월간 추이를 분석하기 좋습니다.
- 스토리지 업그레이드 전후 비교 시 성능 향상을 수치로 증명할 수 있습니다.
세 도구 비교
| 구분 | iostat | iotop | sar |
| 관점 | 디바이스 단위 | 프로세스 단위 | 시간 축 기반, 장기 분석 |
| 장점 | 디스크 병목 신속 파악 | 과부하 프로세스 즉시 확인 | 추세 분석 및 장기 기록 |
| 한계 | 프로세스별 식별 불가 | 단기 관찰 중심 | 실시간 대응에는 부적합 |
| HPC 활용 예 | OSS 디스크 busy율 확인 | 특정 Job의 I/O 부하 추적 | 주기적 배치 Job의 I/O 패턴 분석 |
HPC 운영 실제 사례
- 병렬 학습 성능 저하: 딥러닝 Job이 GPU는 여유 있는데 속도가 떨어지는 현상이 있었습니다. iostat 결과, 디스크 %util이 99%로 나타나며 스토리지 병목이 원인이었음을 확인했습니다.
- 사용자 과도한 I/O 사용: 다중 사용자 환경에서 한 사용자의 Job이 작은 파일 수십만 개를 읽어들이며 스토리지를 과부하시키는 문제가 있었습니다. iotop으로 해당 프로세스를 확인하고, Slurm 정책으로 제한을 걸어 해결했습니다.
- 야간 패턴 발견: sar 로그 분석 결과, 특정 시각대에 I/O가 폭증하는 패턴이 반복되고 있음을 발견했습니다. 이는 연구팀의 자동 데이터 전처리 Job 때문이었고, 예약 스케줄을 조정하여 클러스터 전체 성능을 개선했습니다.
로그 및 모니터링 통합 전략
스토리지 성능 모니터링을 단발성 도구 실행에만 의존하기보다는, 중앙 모니터링 시스템과 연계하는 것이 이상적입니다.
- Prometheus + Grafana: iostat/sar 데이터를 Exporter를 통해 수집 후 대시보드화
- ELK/Loki: I/O 관련 로그를 중앙 집중화하여 알람 시스템과 연결
- 자동 알림: iotop에서 특정 Job이 I/O 초과 사용 시 Slack/이메일로 알림 발송
정리하며
HPC 클러스터에서 GPU와 CPU만 보더라도 성능 병목을 다 파악할 수는 없습니다. 스토리지 I/O는 보이지 않는 지연 요소로, 종종 전체 Job 성능을 좌우합니다.
- iostat은 디바이스 busy 상태를,
- iotop은 프로세스별 I/O 사용을,
- sar은 장기 추세를 확인할 수 있는 도구입니다.
이 세 가지를 종합적으로 활용하면, HPC 운영자는 스토리지 병목을 조기에 발견하고 사용자 Job 성능을 안정적으로 보장할 수 있습니다.