VM 행동을 예측하는 클라우드 자원 관리 (Resource Central, SOSP 2017)

출처

참고 이 페이지는 원문 번역이 아니라 한국어 해설이에요. 정확한 표현과 수치는 원문을 확인하세요.

한눈에

• 2016년 11월부터 2017년 2월까지 Azure 의 모든 VM 을 분석해, 사용률, 크기, 수명, 배포 크기, 작업 유형이 어떻게 분포하는지 처음으로 대규모로 공개했습니다.
• 같은 구독(subscription)의 VM 들은 과거 행동이 비슷하다는 점을 이용하면, VM 이 만들어지는 순간 그 VM 의 행동을 꽤 정확히 예측할 수 있습니다.
• Resource Central(RC)은 오프라인으로 모델을 학습하고, 클라이언트 라이브러리 안에서 예측을 바로 돌려주는 시스템입니다. 여섯 가지 지표에서 79~90% 의 정확도를 냈습니다.
• 예측된 P95 CPU 사용률로 서버의 CPU 초과 할당을 안전하게 하는 스케줄러 변경을 사례로 보였습니다.

왜 나왔나

클라우드 사업자는 서로 다른 성격의 작업을 같은 서버에 섞어 돌리면서 비용을 낮춰야 합니다. 서버에 VM 을 얼마나 빽빽하게 넣을지, 어느 클러스터에 둘지, 언제 유지 보수를 할지, 전력을 얼마나 초과 할당할지 같은 결정은 VM 이 앞으로 어떻게 행동할지 알면 훨씬 나아집니다. 그러나 사업자는 고객의 VM 안을 들여다볼 수 없고, 프로파일링이나 라이브 마이그레이션에 기대는 이전 연구의 방법은 대규모 운영에 맞지 않았습니다. 또 그때까지 공개된 클라우드 작업 분석은 대부분 Google 의 컨테이너 클러스터 데이터였고, 퍼블릭 클라우드 VM 에 대한 분석은 드물었습니다.

핵심 아이디어

VM 작업 특성 분석

3장은 석 달 동안 수천만 개 VM 의 5분 단위 사용률 데이터를 분석합니다. 주요 관찰은 다음과 같습니다.

• VM 유형: VM 수로는 IaaS 52%, PaaS 48% 였지만 코어 시간으로는 PaaS 가 61% 였습니다. 구독의 96% 는 한 가지 유형만 썼습니다.
• 사용률: VM 의 약 60% 는 평균 CPU 사용률이 20% 미만이었고, 3분의 1 이상은 P95 사용률도 낮았습니다. 초과 할당의 여지가 크다는 뜻입니다.
• 크기: VM 의 약 80% 가 1~2코어, 약 70% 가 메모리 4GB 미만이었습니다.
• 배포 크기: 구독별 지역별 하루 단위로 묶은 배포의 약 40% 는 VM 1개, 80% 는 5개 이하였습니다.
• 수명: 90% 넘는 VM 이 하루 안에 사라졌지만, 하루 넘게 사는 VM 이 코어 시간의 95% 이상을 차지했습니다.
• 작업 유형: 푸리에 변환(FFT)으로 하루 주기성을 찾아 대화형(interactive)과 지연 허용형(delay-insensitive)으로 나눴습니다. 지연 허용형이 코어 시간의 약 68%, 대화형이 약 28% 였습니다.
• 구독 단위 일관성: 대부분의 구독에서 VM 들의 사용률, 크기, 수명의 변동 계수가 1 미만이었습니다. 이것이 예측의 근거가 됩니다.

저자들은 이 데이터의 일부를 연구용으로 공개했습니다.

Resource Central 시스템

4장은 RC 의 구조입니다. 오프라인 파이프라인은 원시 데이터 추출, 정제, 집계, 특징 생성, 학습, 교차 검증, 모델 생성, 검사를 대규모 데이터 처리 클러스터에서 돌리고, 버전이 붙은 모델과 특징 데이터를 데이터 센터마다 있는 고가용 저장소에 게시합니다.

온라인 쪽이 흥미롭습니다. RC 는 별도 예측 서버를 두지 않고, 스케줄러 같은 클라이언트 프로세스 안에 들어가는 스레드 안전한 라이브러리(DLL)로 예측을 제공합니다. 라이브러리는 결과 캐시(모델 이름과 입력의 해시), 메모리와 디스크의 모델 캐시, 특징 데이터 캐시를 갖고 있어 네트워크 호출 없이 예측을 돌려줍니다. 업데이트는 기본적으로 푸시 방식으로 받습니다. 예측마다 신뢰도 점수가 붙어, 클라이언트는 신뢰도가 낮은 예측을 무시할 수 있습니다. 예측을 못 하면 "예측 없음"을 돌려주어 클라이언트가 원래 방식으로 동작하게 합니다.

모델은 수치 지표를 구간(버킷)으로 나눠 분류 문제로 풉니다. 예를 들어 CPU 사용률은 025%, 2550%, 5075%, 75100% 네 구간, 수명은 15분 이하, 1560분, 124시간, 24시간 초과 네 구간입니다. 가장 중요한 특징은 그 구독의 과거 구간 분포였습니다.

사례: 예측 기반 CPU 초과 할당

5장은 Azure 스케줄러에 RC 를 적용합니다. 운영(production) VM 과 비운영 VM 을 다른 서버에 나누고, 비운영 VM 만 있는 서버에서만 CPU 를 초과 할당합니다. 새 VM 을 둘 때 예측된 P95 사용률을 더해 서버의 예상 사용률이 한도(MAX_UTIL, 예: 100%)를 넘지 않는지, 할당 합계가 초과 할당 한도(MAX_OVERSUB, 예: 125%)를 넘지 않는지 봅니다. 신뢰도가 0.6 미만이면 VM 이 할당량 전부를 쓴다고 가정합니다. 이 검사를 반드시 지키는 hard 규칙과 가능하면 지키는 soft 규칙 두 가지를 비교합니다.

실험과 결과

6장의 결과입니다.

• 예측 정확도(표 3, 표 4): 두 달로 학습하고 셋째 달로 시험했습니다. 정확도는 평균 CPU 0.81, P95 CPU 0.83, 배포 크기(VM 수) 0.83, 배포 크기(코어 수) 0.86, 수명 0.79, 작업 유형 0.90 이었습니다. 신뢰도 0.6 이상만 쓰면 정밀도가 0.85~0.94 로 올라갔습니다.
• 예측 속도(그림 10, 표 1): 결과 캐시 적중 시 P99 지연 1.3마이크로초, 캐시 미스로 모델을 실행해도 중앙값 95147마이크로초였습니다. 반면 원격 저장소에서 가져오면 중앙값 2.9ms 였습니다. 모델 크기는 152329KB 였습니다.
• 스케줄링 시뮬레이션: 한 달, VM 33.6만 개 도착, 16코어 서버 880대 조건입니다. 초과 할당이 없는 기준선은 100% 초과 사용 순간이 0번이지만 배치 실패가 0.25% 로 허용치 0.1% 의 2.5배였습니다. RC 기반 soft 와 hard 규칙은 배치 실패가 없고 100% 초과 순간이 77번이었으며, 예측 없이 단순히 초과 할당하면 그보다 6배 많았습니다.

지금 Azure 에서는

RC 는 Azure 의 VM 배치와 자원 관리 결정에 예측을 제공하는 내부 서비스로 소개되었고, 이 논문의 데이터는 GitHub 의 Azure Public Dataset 으로 공개되어 클라우드 스케줄링 연구에서 널리 쓰입니다. 고객이 직접 켜고 끄는 제품 기능은 아니므로, 공식 제품 문서에서 이 이름을 찾기는 어렵습니다. 고객 입장에서 보이는 결과는 VM 배치와 용량 관리의 효율이며, 그 배치 서비스 자체는 다음 논문 Protean이 다룹니다.

함께 읽기

• Virtual Machines 와 VM Scale Sets: 이 사이트의 기능 문서
• Protean: Azure 의 VM 배치 서비스 자체를 다룬 논문
• Azure Public Dataset (GitHub)
• Microsoft Research 논문 페이지