클라우드 서비스 사용자는 VM 유형을 선택해야 되며, VM의 선택은 성능과 비용에 상당한 영향을 미친다. 이 논문에서는 주어진 워크로드와 사용자 목표에 가장 적합한 VM을 정확하고 경제적으로 선택하는 문제를 다룬다. 최적의 VM 선택 문제를 해결하기 위해 새로운 하이브리드 오프라인 및 온라인 데이터 수집 및 모델링 프레임워크를 사용하여 최소한의 데이터 수집으로 정확한 성능 추정치를 제공하는 데이터 기반 시스템인 PARIS를 제시한다. PARIS는 다양한 사용자 지정 메트릭에 대한 워크로드 성능을 예측할 수 있으며, 여러 클라우드 제공업체의 광범위한 VM 유형 및 워크로드에 대한 결과 비용을 예측할 수 있다. 두개의 VM 유형에서 워크로드의 성능을 측정하여 기존 기술인 collaborative filtering과 linear interpolation model을 적용시킨 결과와 비교 했을때, PARIS는 훨씬 더 나은 성능 추정치를 생성했다. 예를 들어, AWS와 Azure의 일부 워크로드에 대해 런타임 예측 오류를 4배 줄였다. 향상된 정확도를 통해 결과적으로 성능을 유지하면서 사용자의 비용을 45%를 줄일 수 있었다.
2 MOTIVATION
Bigger is not always better
좋은 성능을 위해 워크로드에 필요한 것보다 더 많은 리소스를 프로비저닝하는 것이 불필요할 수 있음
Similar configurations can provide different performance
실행 환경의 차이, configuration에 반영되지 않은 하드웨어 또는 소프트웨어의 차이에 따라 성능이 달라질 수 있으므로 클라우드 공급자가 제공한 VM 유형 configuration 만으로는 성능을 예측할 수 없음
Optimizing for mean performance may not optimize for the tail
클라우드 사용자는 좋은 성능이지만 예측 불가능한 처리량보다 예측 가능한 안정적인 성능을 선호할 수 있다. 따라서 평균 성능이 중요한지, Tail 성능에 관심이 있는지 여부에 따라 최선의 VM 유형이 달라질 수 있음
Workload resource requirements are opaque
실행 중 서로 다른 지점에서 서로 다른 리소스를 사용하는 워크로드의 경우 성능에 가장 중요한 리소스를 파악하기 어려울 수 있다[55]. 이는 워크로드가 블랙박스 기능으로 처리되는 AWS-Lambda와 같은 호스팅 컴퓨팅 서비스의 경우 특히 더 파악하기 어렵다. 작업이 실행되는 동안 소비되는 리소스를 모니터링하면 해당 실행에 사용된 리소스를 식별하는 데 도움이 될 수 있지만 다른 하드웨어/소프트웨어/설정에서 성능이 어떻게 영향을 받는지는 알 수 없다. 모든 클라우드 제공업체에서 각 VM의 워크로드를 프로파일링하는 것이 가장 좋긴 하지만 소모되는 비용이 매우 크다. 따라서 모든 VM 유형에서 arbitrary workload의 성능을 정확하게 예측할 수 있는 더 저렴한 방법이 필요하다.
3 SYSTEM OVERVIEW
사용자가 API를 통해 코드와 input data, 그리고 성능 metric을 PARIS에 제공하면, PARIS는 여러 VM 유형에서 이를 테스트하고 가장 최적인 VM 유형을 선택할 수 있도록 한다.
사용자 코드는 Docker 이미지로 제공하고 perfMetric의 경우 PARIS 내부에 구현되어 있는 것을 사용하거나, 사용자가 추가할 수 있다. 또한 테스트를 원하는 VM 유형들도 지정할 수 있다.
성능 예측을 위해 PARIS는 a)와 b)를 모델링해야 한다. a) the resource requirements of the workload b) the impact of different VM types on workloads with similar resource requirements. 하지만 모든 VM 유형에서 사용자의 워크로드를 그대로 프로파일링하는 비용은 너무 크기 때문에 PARIS는 모델링 작업을 두 단계로 나눈다. (Section 4) 1회성, 오프라인, 광범위한 VM 유형 벤치마킹 단계 (Section 5) 온라인, inexpensive 워크로드 프로파일링 단계 -> 그림 4. 아래에서 각 단계에 대해 간단히 설명하고 다음 섹션에서 자세히 설명한다.
(Section 4) 오프라인 VM 벤치마킹 단계에서 PARIS는 프로파일러를 사용하여 각 VM 유형에 대한 벤치마크 제품군을 실행하고 자세한 시스템 성능 메트릭을 수집한다. 벤치마크 제품군은 다양한 리소스를 사용하고 있고 실제 워크로드 패턴을 이행하는지를 기준으로 선택된다. 이 벤치마킹은 클라우드 공급자가 이미 실행해 뒀거나 제 3자가 올려둔 데이터를 사용할 수 있다. 그러므로 새로운 VM 유형 또는 물리적 하드웨어가 도입되면 새로운 VM 유형에서만 벤치마크를 다시 실행하면 된다. 오프라인 단계는 고정된 일회성 비용만을 소모하며 새로운 사용자 워크로드의 성능 특성을 예측할 때는 다시 실행할 필요가 없다.
(Section 5) 온라인 단계에서 사용자는 위에서 설명한 대로 task와 performance metric을 제공해야한다. PARIS는 먼저 2개 정도의 VM 유형에서 task를 실행하고 런타임에 여러 metric을 측정 및 수집하는 Fingerprint-Generator를 호출한다. 이러한 측정은 작업의 리소스 사용 패턴을 캡처하고 워크로드 fingerprint를 형성한다. 리소스가 풍부한 configuration과 리소스가 제한된 configuration 모두에서 워크로드 성능을 캡처하기 위해 configuration 측면에서 가장 멀리 떨어져 있는 VM 유형을 선택하여 실험한다. Fingerprint 생성 프로세스에는 추가 cost가 발생하지만 이 cost는 작고 후보 VM 유형의 개수와는 무관하다.
그런 다음 PARIS는 fingerprint를 오프라인 벤치마킹 데이터와 결합하여 원하는 성능 메트릭과 사용자 워크로드에 대한 해당 성능 메트릭의 90th 값을 정확하게 추정하는 기계 학습 모델을 구성한다. 마지막으로 PARIS는 이러한 추정치를 모든 VM 유형에 대한 performance-cost trade-off 맵으로 조합한다.
4 OFFLINE VM-BENCHMARKING PHASE
오프라인 벤치마킹 단계에서 프로파일러는 벤치마크 워크로드 세트를 사용하여 VM 유형을 특성화한다. 이러한 벤치마크 워크로드는 벤치마크의 유형, 사용하는 성능 지표 및 리소스 요구 사항 측면에서 다양성을 따져 선택한다(Figure 5). 이를 통해 PARIS는 다양한 VM 유형이 다양한 리소스 사용 패턴에 응답하는 방식을 특성화할 수 있다. 벤치마크 워크로드 세트는 완전한 것은 아니지만 워크로드 요구 사항의 공간을 확장하기 위한 것이다. 아래에서 벤치마크 워크로드에 대해 자세히 설명한다.
OLAP-style query의 대표적인 예로 Hive[66]의 join 및 aggregation 쿼리를 사용했다. 이러한 모델은 structured relational table에 대한 복잡한 분석 쿼리를 모델링하고 CPU, 디스크(읽기) 및 네트워크를 실행한다. 클라우드에서 latency-sensitive 서비스 워크로드를 나타내기 위해 Aerospike[1], MongoDB[23], Redis[20] 및 Cassandra[41] 데이터 저장소와 함께 YCSB 핵심 벤치마크 워크로드[25]를 추가했다. 마지막으로 Cmmon cloud-hosted Resource-intensive applicatino의 예시로 multi-stage 워크로드인 squash compression benchmark[9]를 사용하여 호스트된 compresison service를 시뮬레이션하는 벤치마크를 구성했다. 이 벤치마크는 네트워크를 통해 압축 파일을 다운로드한 다음 파일의 압축을 풀고 다시 압축하는 과정으로 거쳐 컴퓨팅, 메모리 및 디스크 리소스를 검사할 수 있다.
The Profiler: Profiler는 각각의 벤치마크의 성능을 여러 메트릭으로 기록한다. 성능 변동성과 p90 값을 추정하기 위해 각 작업은 각 VM 유형에서 10번 실행되며, 10번의 모든 시도에 대해 90th의 성능 값을 사용한다(자세한 내용은 Section 6.2 및 Table 1 참조). 90th를 계산하는 데 필요한 최소 시도 횟수는 10회이므로 논문에서는 10회 시도를 적용하였다. 시도가 많을수록 정확도가 향상되지만 그에 비례하여 cost도 증가한다.
각 실행 중에 profiler는 작업의 리소스 사용량 및 성능 통계를 나타내는 metric을 기록한다. 이것은 대부분의 인프라에 있는 계측 메커니즘을 활용하여 수행된다[59]. 구체적으로, 논문에서는 Ganglia[46]를 사용하여 VM을 계측하여 15초 간격으로 성능 및 리소스 카운터를 캡처하고 작업 실행 동안 이러한 카운터의 평균(또는 카운터에 따라 합계)을 기록하였다. 다음과 같은 약 20개의 리소스 사용률 카운터를 수집했습니다.
(a) CPU utilization: CPU idle, system, user time, and CPU utilization in the last 1, 5, and 15 minutes.
(b) Network utilization: Bytes sent and received.
(c) Disk utilization: Ratio of free to total disk space, I/O utilization in the last 1, 5, and 15 minutes
(d) Memory utilization: Available virtual, physical, and shared memory, and the cache and buffer space.
(e) System-level features: Number of waiting, running, terminated, and blocked threads and the host load in the last 1, 5, and 15 minutes
5 ONLINE PERFORMANCE PREDICTION
Section 3에 설명된 대로 온라인 단계에서 사용자는 PARIS에 어플리케이션의 대표적 워크로드인 task, 성능 metric 그리고 후보 VM 유형을 제공해야한다.
PARIS는 먼저 주어진 후보 VM 유형에서 task를 실행하는 Fingerprint-Generator를 호출하고, 그 과정에서 위에서 설명한 profiler를 사용하여 리소스 사용 및 성능 통계를 수집한다. 사용자 정의 성능 metric은 성능을 측정하는 데 사용된다. 90th 성능을 기록하기 위해 각 VM 유형에 대해 작업을 10번 실행한다. 리소스 사용량 측정과 두 가지 참조 VM 유형에 대한 평균 및 90th 성능은 워크로드 fingerprint라는 벡터 F에 저장된다. 직관적으로 fingerprint는 성능뿐만 아니라 리소스 사용 정보를 기록하기 때문에 이 fingerprint을 통해 task의 리소스 요구사항도 설명할 수 있다. 이를 통해 다른 VM 유형에서 워크로드의 성능을 예측할 수 있다.
Fingerprint는 task에서 사용하는 리소스를 알려주고 VM 유형 구성은 사용 가능한 리소스를 알려준다. 격리된 환경의 단일 작업에 대해 성능과 사용 가능한 리소스 간의 관계를 알고 있으면 이 정보로 성능을 예측하기에 충분하다. 예를 들어, profile에 task가 2GB의 메모리를 사용하고 있으며 메모리가 1GB인 VM 유형에서 제대로 수행되지 않는 것으로 표시된 경우, 2GB 미만의 다른 VM 유형에서는 task가 제대로 수행되지 않을 수 있다는 것을 의미한다. 다른 경우로, task가 많은 디스크 I/O를 수행하고 I/O 관련 시스템 콜에서 block된 시간이 많은 경우 I/O가 병목 현상이 될 수 있다는 것을 의미한다. 이러한 종류의 추론은 일련의 if-then-else 문으로 구성된 decision tree로 나타낼 수 있다(Figure 6). 이러한 decision tree에 워크로드 fingerprint와 후보(또는 대상) VM configuration이 주어지면 tree 아래로 적절한 경로를 따라가며 성능을 예측할 수 있다. 이러한 decision tree는 상당히 복잡하고 비선형적인 사항에 대해서도 결정을 내릴 수 있다.
각 워크로드에 대한 decision tree를 수동으로 지정하는 것은 매우 어려운 작업이므로 광범위한 오프라인 벤치마킹 단계에서 수집된 데이터를 구축된 random forest 알고리즘과 함께 활용하여 각 워크로드에 대한 decision tree들을 자동으로 훈련한다. Random forest는 더 강력한 예측을 위해 decision tree의 reasoning을 a collection of trees로 확장한다[18].
5.1 Training the Random Forest Model
5.2 Interpreting the Learned Models
Figure 7은 random forest가 AWS 및 Azure에서 런타임 예측을 위해 중요하게 생각하는 상위 5가지 feature를 보여준다. 여기서 feature의 중요도는 decision tree가 가장 유익한 feature를 기반으로 초기 분할을 수행한 다음 덜 유익한 feature를 사용하여 점진적으로 예측을 개선할 것이라는 직관에 기반하여 계산되었다. 따라서 중요한 feature는 decision tree의 상단에 자주 나타나는 feature이다. 대상 VM의 CPU 사용량과 CPU 수에 대한 다양한 측정값은 AWS와 Azure 모두에서 두드러지게 나타난다. 일반적으로 CPU가 많을수록 작업에 더 많은 컴퓨팅을 사용할 수 있기 때문에 이는 의미가 있는 값이다. 메모리 사용량과 디스크 활용도의 측정값도 중요하다.
6 EVALUATION
(1) Prediction accuracy (Section 6.3): PARIS는 다양한 metric에 대해 얼마 정도의 예측 정확도를 보이는가?
(2) Robustness (Section 6.4): PARIS는 (a) VM 유형의 수와 선택(6.4.1, 6.4.2), (b) 오프라인 profiling 단계(6.4.5)에서 사용되는 벤치마크 워크로드, 그리고 (c) 모델링 기법(regressor)의 선택(6.4.3 및 6.4.4) 변화에 robust 한가?
(3) Usefulness (Section 6.5, 6.6): (a) PARIS의 성능 추정치를 통해 비용을 줄일 수 있는지?
7 LIMITATIONS AND NEXT STEPS
PARIS는 사용자가 워크로드에 적합한 클라우드 VM 유형을 선택할 수 있도록 지원하는 초기 단계를 수행했습니다. 여기에서는 현재 시스템의 한계와 가능한 미래 방향에 대해 설명합니다. PARIS는 사용자 작업 부하에서 대표적인 작업의 가용성을 가정합니다. 일부 작업은 입력에 크게 의존할 수 있습니다. 입력 크기와 같은 작업별 기능을 포함하도록 PARIS의 모델링 공식을 확장하면 작업 전반에 걸쳐 일반화할 수 있습니다. 분산 애플리케이션 또는 다중 계층 서비스를 위해 PARIS를 확장하려면 추가 작업이 필요합니다. 현재 버전에는 각 클라우드 공급자에 대해 별도의 지문이 필요하지만 여러 공급자에 걸쳐 공통 지문을 사용하도록 모델링 프레임워크를 확장할 수 있습니다. PARIS는 스케일링 동작을 추정하는 것을 목표로 하지 않지만 스케일링 문제를 해결하는 Ernest[69]와 같은 접근 방식과 결합될 수 있습니다. 또한 PARIS는 클라우드에서 사용자 지정 가능한 VM 크기(예: Google Cloud Engine의 사용자 지정 이미지)로 작동하도록 확장될 수 있습니다[7].
8 RELATED WORK
리소스 할당에 대한 이전 연구들에 대해 간략하게 설명한다. PARIS와 달리 기존 접근 방식은 클라우드 환경에서 호스팅되는 모든 VM 유형에서 임의 워크로드의 성능을 예측하는 것을 목표로 하지 않는다.
기존 batch system [13, 30, 31]과 Amazon EC2[2], Eucalyptus[52], Condor[58], Hadoop[8, 74, 75], Quincy[38], Mesos와 같은 최신 클러스터 관리 시스템 모두 [33, 37] 사용자의 리소스 요구 사항이 필요하다. 대조적으로 PARIS는 리소스 요구 사항에 대한 지식이 필요하지 않으며 이러한 시스템을 보완한다.
Performance prediction based on system modeling:
시스템 속성 및 워크로드 패턴을 기반으로 성능을 예측하는 선행 작업이 있었다[16, 21, 49, 53].
Pseudoapp[63]은 동일한 분산 구성 요소 집합으로 슈도 프로그램을 만들고 실제 응용 프로그램과 동일한 시스템 호출 시퀀스를 실행한다. 이것은 실제 응용 프로그램이 수행하는 작업에 대한 완벽한 정보가 있다는 것을 가정하므로 실현시킬 수 없는 경우가 종종 발생한다는 문제가 있다.
Ernest[69]는 클러스터 크기의 함수로 분산 분석 작업의 런타임을 예측한다. 그러나 Ernest는 주어진 VM 유형에서 새 워크로드의 성능을 유추하기 위해서 해당 VM 유형에서 워크로드를 최소 한번은 실행해봐야 한다는 단점이 있다.
Quasar[28]는 몇 번의 profiling을 수행한 후 성능을 extrapolating하여 다양한 리소스 할당으로 인한 워크로드의 성능 변화의 impact를 예측하는 것을 목표로 한다. 이것은 PARIS에서 사용하는 워크로드 fingerprint에 있는 리소스 활용 정보만큼 자세하지 않다.
Interference Prediction:
간섭은 정확한 성능 추정의 주요 장애물입니다. 간섭을 줄이기 위해 특정 리소스에 애플리케이션을 배치하는 작업이 있습니다. 서로 다른 리소스 요구 사항이 있는 애플리케이션을 공동 예약하거나[19, 47, 48, 61, 64, 76, 78] 시행착오를 통해[45, 65, 77]. 그러나 Amazon EC2와 같은 클라우드 서비스에서 VM 유형을 요청하는 사용자는 일반적으로 어떤 애플리케이션이 공동 예약되는지 제어할 수 없습니다.
이전 작업에서는 성능 모델을 사용하여 애플리케이션 간의 간섭을 예측했습니다[27, 28, 34, 40, 62, 67, 70, 71]. 일부 접근 방식은 간섭 예측을 위해 CPI(Cycles Per Instruction) 또는 CMR(Cache Miss Rate)과 같은 동적으로 모니터링되는 하드웨어 수준 기능에 의존합니다. 그러나 그들은 기본 물리적 시스템에 VM을 통합하는 것을 목표로 합니다[22, 43, 44]. 일부 접근 방식은 간섭 예측을 위해 CPI(Cycles Per Instruction) 또는 CMR(Cache Miss Rate)과 같은 동적으로 모니터링되는 하드웨어 수준 기능에 의존합니다. 그러나 그들은 기본 물리적 시스템에 VM을 통합하는 것을 목표로 합니다[22, 43, 44]. 이러한 하드웨어 수준 카운터와 비교하여 PARIS에서 사용하는 20개의 VM 수준 리소스 사용량 카운터는 더 많은 정보를 제공하고 공용 클라우드 환경에서 더 쉽게 사용할 수 있습니다.
Adaptive control systems:
성능을 예측하는 대신 또는 이에 추가하여 일부 시스템은 피드백을 기반으로 리소스를 적응적으로 할당합니다. 예를 들어, EC2용 Rightscale[60]은 애플리케이션 로드가 임계값을 초과할 때 추가 VM 인스턴스를 생성합니다. Yarn[68]은 애플리케이션의 요청을 기반으로 리소스 요구 사항을 결정합니다. 다른 시스템에는 제어 시스템에 더 나은 정보를 제공하기 위한 명시적 모델이 있습니다(예: [17, 32, 50]).
Wrangler[73]는 map-reduce 클러스터에서 과부하된 노드를 식별하고 해당 노드에 대한 스케줄링 작업을 지연시킵니다. Quasar[28]는 이질성, 간섭, 확장 및 리소스 확장에 대한 애플리케이션 성능의 민감도 추정치를 동적으로 업데이트합니다. 이러한 시스템과 달리 PARIS는 온라인 일정 결정을 제어하지 않지만 리소스 관리 시스템에 애플리케이션 요구 사항을 알리는 데 사용할 수 있습니다.
9 CONCLUSION
논문에서는 정확하고 경제적인 성능 추정을 통해 사용자가 자신의 성능 목표와 비용 제약에 적합한 VM 유형을 선택할 수 있는 시스템인 PARIS를 제시한다. PARIS는 워크로드의 특성화에서 VM 유형의 특성화를 분리하여 성능 추정의 O(n^2) 비용을 제거하는 동시에 여러 클라우드 제공자의 VM 유형에 걸쳐 정확한 성능 예측을 제공한다. 논문은 PARIS가 여러 클라우드 전반에 걸쳐 많은 현실적인 워크로드 및 성능 메트릭에 대한 평균 및 tail 성능을 정확하게 예측하고 성능 목표를 달성하면서 보다 비용 효율적인 결정을 내린다는 것을 경험적으로 보여주었다.
