알리바바 데이터센터 동시 작업 분석: 장기 서비스와 배치 잡의 공존

초록

알리바바가 공개한 1313대 머신의 24시간 트레이스를 분석해, 장기 실행 컨테이너 서비스와 일시적 배치 잡이 어떻게 공동 배치되고 자원을 공유하는지 조사하였다. 주요 결과는 CPU는 과다 할당되지만 실제 사용량은 낮고, 메모리는 과다 예약·오버커밋 현상이 빈번하며, 배치 잡의 스트래글러와 오래된 자원 예측 오류가 여전히 존재한다는 점이다. 또한 두 스케줄러 간 협조 부족이 성능 간섭을 야기한다는 시사점을 제공한다.

상세 분석

본 논문은 알리바바 클라우드 데이터센터에서 수집한 공개 트레이스를 최초로 정밀 분석함으로써, 동일 클러스터 내에 공존하는 두 종류의 워크로드—장기 실행 사용자‑대면 컨테이너 서비스와 비‑컨테이너형 일시적 배치 잡—의 자원 요구·사용 패턴을 다차원적으로 조명한다. 먼저 전체 클러스터의 CPU 활용도는 4050% 수준으로 중간 정도이며, 메모리 사용률은 50% 이상을 지속해 메모리가 더 ‘희소’한 자원임을 확인한다. 장기 서비스 컨테이너는 배포 단계에서 드물게 CPU 오버북킹이 발생하지만, 대부분 64코어 한계 내에서 예약된다. 메모리 예약 비율은 74% 머신에서 6080% 수준으로 높으며, 실제 사용량은 평균 2% 이상으로 지속적인 최소 메모리 확보가 필요함을 보여준다. 흥미롭게도 전체 컨테이너의 약 60%가 CPU 사용률 1% 미만으로 ‘휴면’ 상태이며, 메모리 사용만이 일정 수준을 유지한다. 이는 전통적인 웹·스토리지 서비스가 메모리 중심으로 동작한다는 기존 연구와 일치한다.

배치 잡 측면에서는 Fuxi 스케줄러가 관리하는 비‑컨테이너 작업이 짧은 시간에 급격히 파동을 이루며, CPU·메모리 사용량이 컨테이너와 상쇄되는 형태를 보인다. 그러나 배치 작업에서도 여전히 ‘스트래글러’ 현상이 관찰되어, 일부 태스크 인스턴스가 평균 요청 대비 10% 이하의 자원만 사용하거나, 실행 시간이 비정상적으로 길어지는 문제가 존재한다. 이는 기존 배치 시스템에서 제시된 해결책(예: 작업 재시작, 스펙터링)과 동일한 과제임을 시사한다.

스케줄러 협조 측면에서는 Sigma(장기 서비스)와 Fuxi(배치) 사이의 전역 Level‑0 컨트롤러가 존재하지만, 실제 자원 매칭·조정이 충분히 통합되지 않아 간헐적인 성능 간섭이 발생한다. 예를 들어, 메모리 과다 예약된 컨테이너가 배치 잡의 메모리 요구를 억제하거나, CPU 오버프러비저닝이 배치 작업의 스케줄링 여유를 감소시키는 현상이 보고된다. 이러한 비협조적 동작은 향후 ‘통합형 코-로케이션 최적화 스케줄러’ 설계의 필요성을 강조한다.

요약하면, 알리바바 데이터센터는 CPU는 과다 할당·오버프러비저닝이 일반적이며, 메모리는 실제 사용보다 크게 예약·오버커밋되는 구조를 가지고 있다. 장기 서비스는 대부분 저부하 상태이지만 메모리 확보를 위해 최소 자원을 유지하고, 배치 잡은 여전히 스트래글러와 자원 예측 오류에 취약하다. 두 스케줄러 간의 협조 부족은 성능 간섭을 야기하므로, 보다 통합된 자원 관리 프레임워크가 요구된다.