[18 CLOUD] Estimating Cloud Application Performance Based on Micro-Benchmark Profiling

ycchae 2022. 3. 2. 17:13

0. ABSTRACT

클라우드 컴퓨팅 시장의 지속적인 성장은 클라우드 서비스의 전례없는 다양성으로 이어졌다. 마이크로 벤치마크는 적절한 서비스를 선택하기 위해 널리 사용된다. 하지만 이러한 합성(synthetic) 마이크로 벤치마크가 실제 어플리케이션의 성능에 대한 통찰을 얻는데 얼마나 관련이 있는지가 불분명하다. 그러므로 이 논문에서는 마이크로 벤치마크를 사용하여 어플리케이션을 프로파일링 하고 어플리케이션의 성능을 예측하는데 사용하는 클라우드 벤치마킹 방법을 개발한다.

Amazon EC2 환경에서 23개 마이크로 벤치마크의 38개 메트릭과 서로 다른 도메인의 2개의 어플리케이션을 사용하여 성능 추정 모델을 정량적으로 평가하기 위한 연구를 진행하였다. 그 결과 클라우드 서비스 성능 변동성(performance variability)이 매우 낮았고, 선택된 마이크로 벤치마크를 통해 10% 미만의 상대 오차(relative error)로 scientific computing application의 시간을 추정할 수 있었고 10%~20% 사이의 오차로 Web serving application의 response time을 추정할 수 있었다. 결론적으로, 이 논문은 클라우드 벤치마킹의 중요성을 강조하고 논문에서 선정한 마이크로 벤치마크들이 특정 어플리케이션의 성능을 추정하는데 관련성이 높았음을 보여준다.

1. INTRODUCTION

IaaS(Infrastructure-as-aService)에서 CPU processing time, disk space, networking capability와 같은 리소스는 API를 통해 일반적으로 VM의 형태로 acquire 및 release 될 수 있다. VM은 일반적으로 instance type, machine type 또는 flavor라고도 하는 다양한 구성 또는 size로 사용할 수 있다. 1개 미만의 (shared) CPU 코어와 1GB RAM을 가진 작은 크기의 VM(e.g., f1-micro)에서부터 128개의 CPU 코어와 1952GB RAM가 있는 VM(e.g., x1.32xlarge)에 이르기까지 다양한 구성을 만들 수 있다.

이처럼 서비스를 다양하게 설정할 수 있기 때문에 어플리케이션에 적합한 VM 구성을 선택하는 것은 어렵다. functional property의 경우 Cloudorado[link]와 같은 도구를 사용하여 비교하는 것도 가능하지만, performance와 같은 non-functional property는 정량화하기 위해 많은 비용이 든다. Amazon의 ECU(Elastic Compute Unit)와 같이 이전에 공개되던 provider-defined performance metric은 관례적으로 on-premise 데이터 센터에서 vCPU 수와 프로세서 종류를 지정하기 위해 더 이상 공개되지 않는다. 또한 instance type(e.g., compute-, memory-, I/O-opimized)의 특성화가 점점 진행됨에 따라, 리소스를 사용하는데 쓰는 금액이 어플리케이션의 성능을 최적화 하는데 충분한 잣대는 되지 못하는 것으로 판단된다. 클라우드 리소스 성능을 동적으로 평가하는 다른 방법은 클라우드 벤치마킹이다. 이 연구 분야는 다양한 클라우드 서비스 간의 성능 차이를 객관적으로 측정하고 비교한다. 많은 연구들[2]-[8]에서 micro-level의 resource-specific (e.g., CPU integer operation)하거나 real world application-level의 domain-specific(e.g., Web serving)한 성능 측정 결과를 보였다.

기존 연구들은 주로 어플리케이션 벤치마크나 마이크로 벤치마크를 각각 분리된 시각으로 사용하는 것에 초점을 두고 있다. 연구자들은 새로운 cloud-specific 어플리케이션 벤치마크를 제안[9][10]하여 클라우드 환경에서 그 성능을 평가[11]-[13]한다. 확장된 연구들은 다양한 VM 구성[2]-[4][14]에서 마이크로 벤치마크 측정을 수행한다. 하지만 이러한 벤치마크가 real-world의 어플리케이션의 성능에 대한 통찰력을 얻는데 얼마나 도움이 되는지는 아직 불분명하다.

이 논문의 목적은 여러 종류의 instacne에서 클라우드 어플리케이션의 성능을 추정하는 마이크로 벤치마크가 얼마나 유용한지를 조사한다. 이 연구가 있기 이전에 클라우드 벤치마킹에 대한 기반 연구로써[2][3] 동일하게 구성된 서비스에서 performance variability를 조사하였다. 이는 높은 변동성이 추정치에 대한 의미를 크게 왜곡할 수 있기 때문에 변동성을 낮게 유지하는 것이 매우 중요하기 때문이다. 선행 연구를 통해 해결해야 할 두가지 사항들을 알 수 있었다.

RQ1. 마이크로 벤치마크가 어플리케이션의 성능을 얼마나 정확하게 예측할 수 있는가?

RQ2. 어떤 마이크로 벤치마크를 사용하는 것이 가장 정확하게 예측할 수 있는가?

이 질문에 대답하기 위해, Amazon EC2(Elastic Compute Cloud)환경에서 클라우드 벤치마킹 연구를 진행하였다. 11개의 instance type에서 9개의 마이크로 벤치마크 제품군(e.g., StressNg, iperf)의 23개의 마이크로 벤치마크에서 38개의 메트릭을 측정하였다. 그리고 두개의 어플리케이션 벤치마크(scientific computing application과 WordPress에서 개발한 Web application)를 사용하였다. 이러한 마이크로 벤치마크와 어플리케이션 벤치마크 구성[15]은 Web-based cloud benchmark manger 인 CWB(Cloud WorkBench)[16][17]에 의해서 자동화 되었다. 선행 연구를 통해 동일한 instance type에서의 performance variability가 이전의 연구보다 더 낮은 것으로 나타났다. 이는 cloud provider가 performance model을 근본적으로 변경하였음을 나타낸다. 이 연구의 결과는 마이크로 벤치마크가 10% 미만의 오차로 scientific computing application의 수행 시간을 추정할 수 있고 10%에서 20% 사이의 오류로 Web service application의 response time을 추정할 수 있음을 보여준다. 또한 이전에 볼 수 없었던 instance type에서 어플리케이션의 성능을 추정하기 위해 일반적으로 사용되는 기준인 vCPU의 수[18], provider-defined performance metric[19], resource cost와 같은 기준보다 적절한 마이크로 벤치마크를 선택하는 것이 훨씬 더 좋은 결과를 보인다는 것을 보여준다. 그러나 연구에 따르면 적절한 마이크로 벤치마크를 선택하는 것은 configuration 파라미터를 세심하게 고려해야 하며 동일한 리소스를 테스트하는 마이크로 벤치마크 테스트를 서로 쉽게 대체하여 사용하지는 못한다는 것을 보여준다.

2. RELATED WORK

Cloud provider가 제공하는 성능의 안정성을 광범위하게 분석한 연구들이 있다. 클라우드 환경의 변동성을 해결하기 위한 최초의 연구 중 하나는 한달 이상 주기적으로 측정값을 수집하였으며, CPU, I/O 및 네트워크 성능에 대해 약 20%의 큰 변동성이 있다는 것을 발견하였다[5]. 다른 연구에서도 같은 종류의 인스턴스에 대해 높은 변동성이 있음을 확인하였으며[6][7][21], CPU 공유 및 멀티 테넌시로 인한 노이즈 외에 CPU 성능을 변화시키는 주요 원인[22]으로 하드웨어의 heterogeneity가 있음을 확인하였다[23][24]. 추가 연구 자료[2][25]를 통해서 performance variability는 여전히 존재하며, 이는 특히 더 작은 instance type에서 두드러지는 것을 확인할 수 있었다.

마이크로 벤치마크는 CPU, I/O, memory, network와 같은 개별 자원들에 대한 클라우드 서비스 성능을 측정하는 것을 목표로 한다. 초기 연구[8]에서 확장된 연구[3][4]들이 매우 중요한 기여를 해왔다. 현재 클라우드 서비스의 성능을 평가 및 비교하는 것은 사업수단이 되어 CloudHarmony나 ClouadSpectator와 같은 회사는 비교 서비스를 제공하고 자체 분석 보고서를 게시하기도 한다[26].

클라우드에 대한 보다 현대적인 워크로드를 위한 초기의 노력 중 하나는 상호작용이 많은 새로운 Web 2.0 워크로드를 제안하는 Cloudstone 벤치마크[27]이다. CloudSuite[9]는 점진적으로 scale-out 워크로드를 만드는 것에 기여하고 있고[10] SPEC CloudTM IaaS 2016[28]은 IaaS 클라우드의 성능을 측정하는 것에 특히 목표를 갖고 작업하였다. YCSB[29]는 데이터베이스 시스템을 위한 대규모 scale-out 워크로드를 제작한다. 여러 개념적인 기여[30][31]들은 클라우드 환경에 대한 어플리케이션 벤치마크를 설계하고 구현하는 방법에 대한 아이디어와 지침을 제안한다.

어플리케이션 프로파일링은 시스템 레벨 모니터링 도구[32][33] 또는 프로그램 유사성[34]을 사용하여 다양한 플랫폼에서 어플리케이션의 성능을 파악하는 것을 목표로 한다. CloudProphet은 on-premise Web 어플리케이션의 리소스 추적을 수집하여 클라우드 환경에서 다시 실행하여 클라우드 instance type에 대한 어플리케이션의 성능을 정확하게 예측한다. CloudProphet[35]은 소수의 instance type에 대한 정확한 예측에 중점을 두지만 이 논문에서는 다양한 instance type에 대해 대략적인 추정치를 제공하는 것을 목표로 한다. 따라서 이러한 접근 방식은 상호 보완적이라고 할 수 있으며, 이 두 방법을 결합하여 많은 instance type에서 테스트 할 수 있을 뿐만 아니라(CloudProphet 개선) 모델을 training하는 비용을 줄일 수 있다(이 논문의 접근방법 개선). CherryPick[18] 시스템은 클라우드 configuration을 선택하는 것을 도와주고 Bayesian Optimization 모델을 사용하여 분산 빅데이터 작업에 대한 런타임 및 비용을 예측을 반복적으로 다듬는데 사용한다. 이에 비해서 논문에서 수행한 작업에는 초기 training sample이 덜 필요하다. Stewart, Shen[36]은 큐잉 모델을 시스템 수준 리소스 모니터링과 결합하여 multi-component 서비스의 throughput과 response time을 예측하는 performance model을 제안한다. 그들은 3가지 서버에서 모델을 평가했지만, 논문에서는 11개 종류의 클라우드 인스턴스에서 평가한다.

3. METHODOLOGY

클라우드 벤치마킹에 대한 기존 치짐[30][31][37][38]을 바탕으로 다양한 클라우드 리소스 및 어플리케이션 도메인을 테스트 할 수 있는 벤치마크를 선택하였고, CWB(Cloud WorkBench) 실행 환경에 포함시켰다. CWB에 넣은 벤치마크에 대한 자세한 내용은 [15]에서 확인할 수 있다. 자동화된 벤치마크는 클라우드 환경에서 반복적으로 실행되어 performance metric이 수집된다. 수집된 raw performance data는 앞에 소개된 RQ에 대한 대답을 위해 분석되기 전에 전처리 과정을 거친다.

Figure 1은 클라우드 벤치마킹 방법론의 추상화된 구조를 보여주고, 선택된 벤치마크를 나열하고 있다. Benchmark Manager는 모든 벤치마크 실행의 lifecycle을 조정한다. Scheduler는 새로운 실행을 trigger하고 Cloud Manager는 cloud Provider API, Cloud VM provisioning, 클라우드의 VM과의 통신에 대한 정보를 갖고 관리한다. Provider API를 통해서 SUT(System Under Test)로 표시된 VM들을 획득(실행)한다. CWB Client는 벤치마크의 실행을 조정한다. Chef Client가 Provisioning Service에서 VM의 provisioning configuration을 가져와 적용하여 모든 Micro 그리고 App 벤치마크를 설치 및 설정한다. CWB Client는 실행 순서를 설계하고 REST API를 통해 결과 metric 전송과 같은 Benchmark Manager와의 통신을 처리한다. iperf와 WPBench(WordpressBench)와 같은 Multi-VM 벤치마크는 task 워크로드를 생성하는 Load Generator에 task를 전달한다.

Figure 2는 CWB Web 인터페이스에 있는 benchmark configuration의 예시를 보여준다. 벤치마크 설정은 provider-specific resource(e.g., the geographic region), execution schedule (i.e., run every 3 hours) 그리고 실행할 벤치마크 제품과 같은 정보를 포함하고 있다. rmit-combined 라는 벤치마크 제품은 모든 마이크로 벤치마크 및 어플리케이션 벤치마크를 번들로 묶고 벤치마크 순서를 무작위로 실행하여 경쟁 상황을 공정하게 비교하기 위해 RMIT(Randomized Multiple Interleaved Trials) 실행 방법론으로 구현되었다. 마이크로 벤치마크는 사전 연구에서 사용해본 결과를 토대로 선택되었으며, computation, I/O, network, memory 범위의 리소스들을 광범위하게 테스트 하는 것을 목표로 하지만 개별 리소스도 구체적으로 평가한다(e.g., I/O를 low-level disk I/O와 higher-level file I/O로 분할하여 여러 operation 종류와 sizes로 테스트 함). 어플리케이션 벤치마크는 scientific computing 테스트를 위한 MDSim(Molecular Dynamics Simulation)과 웹 서비스 테스트를 위한 WPBench를 사용하여 수행한다. MDSim은 이전 연구[14]에서 과학 컴퓨팅 어플리케이션의 예로 사용되었으며 WordPress는 상위 1천만 명 중 30%가 사용하는 가장 인기 있는 CMS(Content Management System) 소프트웨어(시장 점유율 60%, 10 million개 웹사이트의 30%가 WordPress를 사용:W3Techs5의 2017년 3월 기준)이며 이전에 클라우드 VM을 벤치마킹[13]하는 데에도 사용되었기 때문에 선택되었다. WPBench는 짧은 읽기, 검색, 쓰기 시나리오를 수행할 수 있다. 자세한 설명은 [40]을 참조하면 된다. 추가로 논문에서 구현한 벤치마크들은 오픈 소스로 제공하고 있다.

데이터 전처리 단계에서는 filtering(e.g., 실패한 실험 폐기), restructuring(e.g., pivoting), converting units(e.g., Kb/sec to Mb/sec), replacing missing values가 수행된다. 메트릭 파싱의 조정과 약간의 일시적 오류로 인한 결측값이 발생한 4가지 경우에 대한 적절한 replacement method가 사용되었다. 자세한 설명과 예시는 [40]을 참조하면 된다. 또한 모든 스크립트와 raw, interim, output data set은 Github에서 확인할 수 있다.

4. BENCHMARKING DATA SET

이전 section의 방법을 사용하여 Amazon EC2 클라우드에 대한 벤치마킹 데이터를 수집했다. 모든 configuration은 Ubuntu 14.04 LTS 이미지를 기반으로 하며 AWS(Amazon Web Services)가 대부분의 워크로드에 권장하는 범용 스토리지 타입인 gp2 를 연결하였다.

Table 1에는 연구에서 사용한 EC2 instance type이 나열되어 있다. 2017년 4월 기준으로 사용가능한 11가지 non-bursting instance type이 포함되어 있다. 모든 instance는 15 GB 미만의 메모리를 갖고 있고, 알 수 없는 이유로 실험이 지속적으로 실패한 c1.medium은 제외되었다. 이 RAM threshold는 I/O 워크로드가 RAM크기가 증가함에 따라 크게 증가하기 때문에 실험 비용을 합리적인 수준으로 유지하기 위해 선택되었다. Table 1은 Amazon에서 자체적으로 제공하는 CPU 성능의 척도인 ECU(EC2 Compute Unit)도 함께 보여준다 (An ECU is equivalent to the CPU power of a m1.small instance or a 1.0-1.2 GHz 2007 Opteron or Xeon processor type [4]. Amazon은 integer operation과 관련된 벤치마크를 수행하여 ECU를 측정한다고 함). 하지만 AWS는 2014년에 이 방식을 더이상 사용하지 않고 on-premise 데이터 센터에서 관례적으로 vCPU 수와 프로세서 종류를 지정하는 보다 전통적인 방식으로 변경하였다. ECU 모델은 burst 가능한 CPU performance에 대한 공식 모델을 따르는 범용 instance type 제품군을 설명하기에는 충분하지 않다[41]. 이러한 bursting instance type은 본질적으로 다양한 성능을 controlled benchmarking 하는 것을 방해하기 때문에 이 연구에는 포함시키지 않았다.

이전 연구[2]의 결과와 비교하기 위해 eu-west-1(Ireland)과 us-east-1(N. Virginia) 지역을 선택하여 사용하였다. 각 configuration은 3시간 마다 한번씩(즉, 하루에 8번) 실행되도록 예약했으며, 한번에 3번의 반복을 수행한다. 모든 반복은 instance type에 따라 45분에서 70분 가량 소요된다. 이는 2개의 low-tier, 2개의 medium-tier 그리고 1개의 large-tier instance type에서 4~8일 사이에 rolling basis(i.e., 이전 instance가 release된 후 새로운 instance를 acquire함)으로 연속적으로 실행하는 것과 거의 비슷하다. 실행 횟수는 m3.medium(eu) 및 m3.large(eu)의 경우 최소 58회, m1.small(eu/us) 및 m3.medium(us)의 경우 최소 33회 실행되었다. 나머지 instance type에 대해서는 최소 1번 이상이 실행되었다. 2017년 4월과 5월 사이 총 62952건의 측정이 244건의 실행에 걸쳐 수집되었다.

5. VARIABILITY FOR THE SAME INSTANCE TYPES

연구에서 제시한 질문에 답하기 전에 동일한 instance type의 여러 instance에 대한 performance variability를 평가해야 한다. 대규모 벤치마킹 연구[2]의 정의에 따라 5% relevancy threshold에 대해 38개의 metric에 대한 RSD(Relative Standard Deviation, 상대 표준 편차)를 비교한다. RSD=100*σm/M 으로 정의되며, 여기서 σm은 absolute standard deviation이고 M은 metric m에 대한 arithmetic mean이다. 5개의 선택된 configuration(i.e., instance type과 region)은 38개의 metric에 대한 33개의 sample이 있고, 선행 연구를 통해 큰 instance type보다 작은 instance type에서 성능이 안정적이지 못했기 때문에 작은 instance type들을 중점적으로 테스트하였다[2][24][25].

1) 결과: 그림 3은 다음과 같은 측면에서 변동성을 요약합니다. 비정규 분포에 대한 속성에 주석이 달린 평균 값이 있는 바이올린 플롯을 사용하여 선택한 각 구성 및 모든 벤치마크에 대한 RSD. 모든 중앙값은 분명히 5% 임계값 아래에 있으며 파란색 다이아몬드로 표시된 거의 모든 평균은 이 관련 변동성 임계값 아래에 있습니다. 따라서 우리는 테스트된 모든 구성에서 대부분의 벤치마크에 대해 성능이 많이 변하지 않는다는 결론을 내렸습니다.

2) 논의: 관찰된 성능 안정성은 상당히 놀랍고 이전에 보고된 성능의 큰 변동성(>10% RSD)에서 동일한 것으로 추정되는 인스턴스[5]–[7], [12], [20]–[24 ], [42] 훨씬 더 안정적인 성능을 제공합니다. Amazon EC2와 관련하여 이러한 모든 연구는 1세대의 인스턴스 유형에만 초점을 맞추었으며 더 최근의 연구는 새로운 세대가 훨씬 더 안정적인 성능을 발휘한다는 추가 증거를 제공합니다[2], [43], [44]. CPU 성능은 0.3% RSD 미만의 수준에서 매우 예측 가능하게 되었으며, 이는 주로 AWS에서 하드웨어 이질성의 관련성이 감소했기 때문입니다(Leitner 및 Cito[2]에서도 보고됨). HDD에서 SSD 지원 파일 I/O 스토리지로의 마이그레이션은 변동성을 20%-100%[2]에서 1.5%-10% 미만으로 줄였습니다. 가장 놀랍게도 네트워크 성능은 2012년의 25% RSD와 대조되는 거의 완벽한 안정성을 달성했습니다[6].
3) 시사점: 본 논문의 결과는 다음과 같다. 인스턴스 탐색 및 배치 게임 접근 방식 [6], [7], [21]은 Amazon EC2의 현재 조건에서 더 이상 가치가 없습니다. 또한 클라우드 벤치마킹 연구는 일반적인 신뢰 구간(즉, 95% 또는 99%) 내에서 통계적으로 그럴듯한 결과를 얻기 위해 관련 샘플 크기를 얻는 데 많은 리소스를 사용했습니다. 우리의 결과는 벤치마킹 노력을 상당히 줄일 수 있고 단일 샘플로도 CPU 또는 intra-Availability Zone(AZ) 네트워크 성능과 같은 매우 안정적인 범주에 대해 99% 신뢰 구간을 달성하기에 충분할 수 있음을 나타냅니다. 이를 통해 클라우드는 광범위한 인스턴스 유형에 대해 적절한 양의 성능 데이터를 수집할 수 있습니다. 또한 퍼블릭 클라우드는 이제 성능 예측 가능성이 핵심인 소프트웨어 성능 테스트와 같은 사용 사례에서도 잠재적으로 사용될 수 있습니다[44].

6. RESULTS AND DISCUSSION

앞서 소개한 질문에 대한 결과를 보여주고 논의한다.

RQ1 – Estimation Accuracy

어플리케이션 성능을 추정하기 위해 23개 마이크로 벤치마크에서 도출한 38개의 메트릭을 사용하여 linear regression 모델을 학습시켰다. 실험은 두 개의 어플리케이션을 사용하여 평가하였다. 5장에서 논의한 이전의 연구에서 나타났듯, sample 필터링을 위해 은 유럽 데이터센터에서 동일한 실험을 수행한 후 3개의 iteration을 선택하여 사용하였다. 가능한 가장 넓은 범위의 예측 모델을 위해 최소 사양과 최대 사양의 instance type을 training 데이터로 사용하였다. Forward feature selection 알고리즘이 LR과 함께 사용되어 결합되어 상대 오차율(RE: Relative Error)이 가장 적은 feature의 집합(여기서는 metric의 집합)을 자동으로 선별한다.

e: absolute error
m: actual mesurement

Forward feature selection은 빈 feature 집합으로 시작하여 이전에 사용되지 않았던 feature를 번갈아가며 추가한다. Candidate feature 집합과 training set으로 linear regression 모델을 만들고 test data를 사용하여 mean relative error를 계산한다. 이러한 작업이 끝나면 relative error가 최소인 performance model을 도출할 수 있게 된다. 이 과정은 feature를 추가하면서 relative error를 더이상 개선시킬 수 없을 때까지 반복된다. 마지막으로, forward feature selection은 weighted feature 목록과 relative error나 Pearson correlation coefficient을 결정 계수로 사용한 R^2 값과 같은 여러 performance indicator를 출력한다.

1) Results: Table 2는 relative estimation error 측면에서 WPBench와 MDSim의 예측 결과를 보여준 표이다. WPBench에 대해서 read, search, write 세개의 시나리오의 RT(Response Time)를 평가하였다. 추가적으로 throughput 메트릭의 결과는 [40]에서 볼 수 있다. Table 2에서 최대 최소 instance type의 결과는 training 데이터로 사용하였고 instance type별로 예측 오차율을 표시하였다. 3번의 오차율을 평균내서 실제 성능과의 차이를 +,- 값으로 표현하였다. 높은 변동성으로 인해 오차율이 +,- 양쪽으로 위치하는 경우에는 pipe(|)를 사용하여 표현하였다. 요약에서는, Max RE와 Mean RE가 인스턴스 간 성능 추정의 적합성(fitness)을 나타낸다. Max RE는 가장 작은 instance가 가장 나쁜 성능을 보이고 가장 큰 instance가 가장 성능이 좋을 것으로 가정하여 RE의 상한(upper bound)을 추정한다. 이것은 어플리케이션의 최소, 최대 성능이 얼마나 차이가 나는지를 알려준다. 따라서 높은 Max RE는 높은 정확도(즉, 낮은 RE)를 달성하기가 더 어렵다는 것을 의미한다. 반대로, Max RE를 낮게 설정하면 RE가 적게 나와도 정확도에 큰 지장이 없다.

Mean RE의 경우 부호에 상관없이 절대값을 더해서 10으로 나누어서 나온 결과인 것으로 보임

2) Discussion: Table 2의 결과를 통해 가장 정확한 추정치는 MDSim과 WPBench의 read, search 시나리오에서 나타난 것을 볼 수 있다. MDSim의 Duration estimation 결과가 [69.7, 491.7]초(참조, Max RE 600%)의 범위의 값에 대해 8.2% 정확도를 보였다. WPBench의 read, search 시나리오에서는 Response Time이 [65.8, 1457.8] ms 분포로 나타나 가장 큰 범위를 가졌다. 이는 Figure 4에 나와 있으며 read 시나리오에 대한 최대 RE는 2100%으로 나타났다. 그럼에도 불구하고 평균 12.5%와 17.5%의 적당한 RE를 보였다. 또한 이러한 linear regression model은 통계적으로 0.001 수준까지도 중요하므로 RQ1에 언급한 낮은 변동성의 가정에 대한 뒷받침이 된다.

WPBench write 시나리오의 RE는 일반적으로 높으며, 특히 성능 데이터의 분포가 낮았기 때문에 이러한 결과가 더욱 두드러졌다. 또한 동일한 instance type 내에서도 애플리케이션 성능이 동시에 overestimated 및 underestimated되어 절대값(modulus value)으로 제공되어 있다. 또한 regression 모델은 0.05(응답 시간) 및 0.1(처리량) 수준에서 덜 중요하며, 이는 서로 다른 반복 간에 성능 변동성이 존재한다는 의미이다. 이 가설은 RQ1에 사용된 5가지 instance type에 대해 33~61번의 관련 샘플 크기로 통계 테스트를 추가로 수행하여 조사되었다. One-way ANOVA 테스트[45]는 그룹 속성으로 반복 열에 대해 수행한다. 결과를 통해 응답 시간과 처리량이 모두 테스트된 5가지 instance type 모두에 대해 높은 의미(즉, p< 0.001)를 가진 3가지 다른 반복 간에 크게 변한다는 것을 확인할 수 있었다(즉, f 값이 특히 높았음). ANOVA는 옴니버스 테스트이므로 반복 간에 통계적으로 유의한 차이만을 확인할 수 있다 (but does identify the specific iterations that differ statistically significant from each other. ?? 서로 다른 특정 iteration은 인식하지 못한다???). 따라서 Mann Whitney UTest도 수행하여 모든 반복 쌍 간의 차이가 5가지 instance type 모두에 대해 통계적으로 중요하다는 것을 보여주었다. 개별 반복 간의 성능 향상은 Figure 5의 linear regression 모델을 통해 볼 수 있다. 통계 테스트에서도 WPBench를 제외하고는 다른 벤치마크 중 어느 것도 반복 간에 통계적으로 유의한 차이를 나타내지 않았다.

3) Implications: 허용 가능한 정확도로 애플리케이션 성능을 추정하는 기능은 마이크로 벤치마크의 유용성을 보여준다. 이를 통해 마이크로 벤치마크를 사용하여 얻은 성능 특성을 기반으로 클라우드 서비스를 분류하여 배포할 수 있다. 또한 리소스를 가장 많이, 가장 적게 사용하는 두개의 instance type의 데이터를 training 데이터로 사용하여 어플리케이션의 성능과 연관시킬 것을 권장한다. 남은 challenge는 주어진 애플리케이션에 대한 관련된 마이크로 벤치마크 집합을 식별하는 것이다.

RQ2 – Micro-Benchmark Selection

RQ1에 대해 설명한 것과 동일한 feature 선택 과정에 따라 가장 중요한 feature(즉, 마이크로 벤치마크 메트릭)를 식별하고 일반적으로 사용되는 세 가지 기준과 비교한다.

1) Results: WPBench의 모든 시나리오에 대한 RT와 MDSim의 수행시간에 대해 forward feature selection에서 Sysbench의 CPU Multi-Thread 마이크로 벤치마크의 결과가 linear regression 모델에 사용되었다. WPBench write 시나리오의 경우 동일한 가중치로 두 개의 추가 벤치마크가 제안되었지만 모델에 대한 기여도가 통계적으로 유의미하지 않았기 때문에 reject 되었다: p=0.393 for fio/8krand-read-latency, p=0.450 for fio/4k-seq-write-bandwidth. 마찬가지로 MDSim의 경우 추가 속성 fio/8k-randread-iops는 p-value 0.0976으로 인해 reject 되었다. 제한된 공간(limited space)으로 인해 StressNg–Network Internet Control Message Protocol (ICMP) Ping이 최상의 estimator로 선택된 WPBench 벤치마크의 throughput metric을 생략한다.

Table 3은 WPBench read와 search의 responst time과 MDSim의 수행시간에 대해, multi-thread Sysbench–CPU 벤치마크가 좋은 estimator로 동작하는 것을 확인하였다. MDSim의 경우 10% 미만, WPBench의 read, search의 경우 10%~20% 사이의 낮은 RE를 보이고 회귀 모델의 거의 완벽한 적합(즉, R^2 > 98.9)인 것을 통해 multi-thread Sysbench CPU 벤치마크가 가장 알맞은 estimator인 것을 알 수 있다. 또한 동일한 벤치마크의 single thread 버전은 결과가 좋지 않았단 것을 통해 적절한 벤치마크를 사용하는 것이 매우 중요하다는 것을 보여준다. 또한 vCPU, ECU 및 시간당 Cost 기준에 대한 개선이 매우 필요한 것을 볼 수 있었다. ECU는 이미 vCPU 수를 사용하는 것보다 50% 더 정확하지만 Sysbench 벤치마크는 RE 측면에서 ECU보다 17~29배 좋은 결과를 보여주었다. CPU 벤치마크는 Baseline 메트릭들과 비교하여 제곱 상관 관계(R^2)가 33% 이상 개선되어 regression line에 훨씬 더 잘 맞았다. 마지막으로 Cost 기준은 모든 메트릭에서 최악의 성능을 보였다.

2) Discussion: 결과는 이러한 추정치가 MDSim과 같은 마이크로 벤치마크와 유사한 리소스 프로필을 가진 애플리케이션에 의미가 있을 수 있다는 추측을 뒷받침하지만 선형 모델은 WPBench와 같은 보다 다양한 애플리케이션에서도 놀랍게도 잘 작동합니다. MDsim 응용 프로그램은 CPU 집약적이며 잠재적으로 주 메모리에 스트레스를 주지만 I/O 작업은 포함하지 않습니다. 무의미한 루프 반복과 같이 MDSim이 낮은 수준의 인공 마이크로 벤치마크 워크로드에 비해 높은 수준의 실제 계산을 수행한다는 사실에도 불구하고 MDSim의 리소스 사용량은 아마도 CPU 마이크로 벤치마크와 매우 유사할 것입니다. 반대로 WPBench 애플리케이션은 훨씬 더 이질적이며 다양한 종류의 시스템 리소스를 사용하여 리소스 풋프린트가 본질적으로 명확하지 않습니다. CPU 기반 요청 처리 외에도 WPBench는 네트워크를 통해 요청을 수신하고 응답을 보내고 파일 시스템에서 읽고 쓰고 스케줄러가 다양한 데이터베이스 또는 웹 서버 프로세스 간에 전환해야 합니다. 따라서 마이크로 벤치마크가 이처럼 다양한 작업 부하를 포착할 수 있는지 여부는 분명하지 않습니다. 그럼에도 불구하고 결과는 선형 모델이 일반적으로 20% 미만의 오류율로 애플리케이션 응답 시간을 놀라울 정도로 잘 평가할 수 있음을 보여주었습니다.

3) Implications: 동시성은 vCPU 수가 다른 인스턴스 유형 전반에 걸쳐 성능을 추정할 때 중요한 역할을 합니다. Sysbench – CPU 단일 스레드 대 다중 스레드 시나리오는 마이크로 벤치마크가 다중 코어(다중 vCPU 참조) 플랫폼에 대한 최적화 측면에서 추정 대상 애플리케이션과 일치해야 함을 보여주었습니다. 또한 CPU 마이크로 벤치마크가 특정 동시성 수준(예: 단일 스레드)의 워크로드에 대한 최적의 인스턴스 유형을 식별하는 데 적합함을 보여줍니다. 또한 동시성 수준과 같은 벤치마크 매개변수가 결과에 중대한 영향을 미칠 수 있음을 강조합니다. 기준 메트릭 vCPU, ECU 및 비용이 충분하지 않습니다.
특정 응용 프로그램의 성능을 추정합니다. 비용 기준선은 애플리케이션 성능을 추정하는 데 최악이며 애플리케이션 성능을 추정하기 위해 단독으로 사용해서는 안 됩니다. vCPU의 수는 약간 더 좋을 뿐이고 다른 CPU 클록 주파수와 같은 근본적인 기술 차이를 포착하지 못하므로 많은 인스턴스 유형에 대해 큰 상대적 오류를 나타냅니다. ECU 메트릭은 vCPU보다 훨씬 더 나은 추정치를 산출하지만 상대적 오류는 여전히 100%를 초과하여 허용할 수 없을 정도로 높습니다. 따라서 다른 메트릭을 사용할 수 없는 경우 ECU를 사용하여 매우 대략적인 추정치를 얻을 수 있지만 가장 정확한 애플리케이션 성능 추정치를 얻으려면 애플리케이션별 마이크로벤치마크를 선호해야 합니다.

CONCLUSION

이 논문은 실제 어플리케이션의 성능을 추정하기 위해 널리 사용되는 artificial micro-benchmark의 관련성을 조사하였다. 논문에서는 single-instance, multi-instance, 마이크로 벤치마크, 어플리케이션 벤치마크를 결합한 클라우드 벤치마킹 방법론을 설계하였다. 이 방법론은 시장을 선도하는 클라우드 제공업체의 instance로 연구되었으며 linear estimation model을 사용하여 평가를 진행하였다. Performance variability, estimation accuracy, micro-benchmark selection 이라는 세 가지 주제에 대해 60000개 이상의 측정값을 수집하였다.

이전 연구와 달리 결과를 통해 instance 간의 performance가 더 이상 적절하게(relevantly) 변하지 않는다는 것을 보여준다. 낮은 performance variability는 instance type 간의 performance estimation을 연구할 동기로 작용한다. 왜냐하면 작은 샘플 크기만으로도 이러한 접근 방식이 실질적으로 실행 가능하기 때문이다. 우리는 선별한 마이크로 벤치마크가 쓸만한 정확도로 특정 어플리케이션의 performance metric을 추정할 수 있음을 보여주었다. Scientific computing application은 10% 미만의 오류율을 보였고, Web service application의 respont time은 10%에서 20% 사이의 상대 오류를 보였다. 또한 단일 CPU 벤치마크는 Scientific computing application을 수행하는데 걸리는 시간과 Web service application의 response time을 가장 정확하게 추정할 수 있었다. 그러나 동일한 리소스를 테스트하는 벤치마크 끼리 상호 교환하여 사용할 수는 없으므로 벤치마크의 매개변수가 큰 영향을 미치는 것을 보였다.

이 논문는 어플리케이션 성능을 추정하기 위한 마이크로 벤치마크의 적합성을 입증하지만 일부 마이크로 벤치마크만 특정 어플리케이션과 관련이 있음을 강조하고 있다. 또한 benchmark-based metric이 instance type specification-based metric을 사용할 때 보다 정확도를 크게 향상시킬 수 있음을 보여줌으로써 클라우드 벤치마킹의 중요성을 강조하였다. 또한 테스트를 거친 클라우드 공급자가 best effort performance를 제공하는 것에서 예측 가능성이 높은 specifically designed performance level으로 전환한다는 것을 보여주어 클라우드 환경이 역동적으로 변화하고 있다는 것을 보여주었다.
Microsoft Azure와 같이 잘 알려진 공급자[46]가 제공하는 instance type에서 추가적으로 실험하는 것 외에도 특히 흥미로운 확장은 Century Link 또는 Google의 Cloud Platform에서 제공하는 것과 같이 개별적으로 맞춤화 가능한 instance type을 조사하는 것이다. 향후 연구를 위한 또 다른 방법은 분산 애플리케이션 컴포넌트들을 사용하여 워크로드를 scale-out하는 것이다. 마지막으로, 클라우드에서 instance 선택은 estimation model을 훈련하기 위해 runtime performance data를 결합한 scailing strategy의 필수적인 부분으로 인식되어야 한다.