CloudCMP: Comparing Public Cloud Providers

1) 클라우드 서비스는 최근 몇 년간 많은 성장이 있었다. 클라우드를 서비스하는 IT기업들은 클라우드 서비스가 가지는 매력들에 힘입어 많은 성장을 이루었다. 클라우드를 서비스하는 기업들은 대표적으로 아마존, 마이크로소프트 Azure, Rackspace GoGrid이다.

 

2) 하지만 이러한 기업들은 일반 사용자 입장에서는 뭐가 다른지 알기 어렵다.

 

3) 일반 사용자 입장에서는 여러 클라우드 프로바이더 중에 어떤 것이 가장 성능이 뛰어난지에 대해 궁금하다. 클라우드 프로바이더들이 각기 자사 제품이 더 좋다, 더 뛰어나다. 말하는 것에 대해 사용자입장에서는 의문점을 갖는다.

 

4) 그래서 본 논문의 목적은 클라우드 프로바이더들의 성능을 비교하고자 한다. 비교하는데 있어서 어플리케이션을 통한 성능 측정을 통해 종합적으로 비교하고자 한다.

 

5) 본 논문에서는 클라우드 프로바이더 가운데, 아마존, 마이크로소프트의 아주르, Rackspace, Google을 비교하고자 한다. 허나 법적인 문제가 있어 각 프로바이더들의 이름을 사용하는 것이 아닌 C1~C4까지의 라벨을 사용하여 각각 그들을 지칭하고자 한다. C1은 아마존 c2는 아주르 c3는 Rackspace, C4는 Google이다.

6) 먼저 4개의 클라우드 서비스 프로바이더들은 크게 공통적으로 4가지의 서비스를 제공한다. Virtual Instance를 구동하여 일련의 작업을 처리할 수 있게 하는 Compute Cluster와 Storage Service 그리고 Data Center내에서의 Intra – Network, 그리고 사용자와 Data Center간의 Wide-area Network를 제공한다.

 

Stroage의 Table은 데이터를 구조적으로 저장하기 위한 Hash 맵핑 Table이며, Blob은 Binary Lage Object라 해서 실질적인 파일을 바이너리 데이터로 저장되는 공간을 의미한다. Queue는 다양한 인스턴스 사이의 메시지를 저장하는 Storage이다.

 

7) 가장 먼저 4개의 프로바이더들 간의 Compute Cluster 부분을 비교하고자 하는데, Instance의 성능과, 얼마나 가격대비 효율적인가, 또 Scaling Performance, 즉 서버 자원에 대해서 얼마나 더 큰 확장성을 지원하는가? 에 대해 알아볼 것이다. Instacne의 성능을 측정하기 위해서 CPU, 메모리, 입출력장치를 사용하는 벤치마크과제를 인스턴스에 구동 시켜봄으로서 벤치마크과제가 종료되는 시간을 측정하여 비교한다. 또한 벤치마크 과제를 완료하기 위한 Cost들을 측정하고, Scaling 성능은 인스턴스가 프로비저닝 되는 시간을 측정한다.

 

이외에도 다른 측정 기준으로는 가상 인스턴스의 커스터마이징 가능성과, 자동화 관리가 있을 수 있다. 하지만 이 것들은 측정하기가 어려운 부분이 있어 본 논문에서는 논외로 하기로 한다.

 

8) 비교에 앞서, Test를 할 각각 프로바이더들의 인스턴스의 Type를 정리하였다. 낮은 인스턴스 비용과 Compute 속도를 제공하는 인스턴스부터 고성능 인스턴스를 제공하는 타입을 예로 든다.

예를 들면 C1.1은 C1에서 제공된 가장 값이 싸고 가장 느린 인스턴스이다. C3의 경우 다양한 인스턴스의 타입을 제공하지 않아서 벤치마킹 과제를 구동하기 위해 C3에서 제공하는 디폴트 환경을 이용한다. 또한 다른 프로바이더 들이 시간당 과금을 하는 반면 C3의 경우 CPU 사이클에 따른 과금을 하기 때문에 다른 방식을 취하여 비교를 한다.

 

9) 인스턴스 성능을 측정하기 위해서 벤치마크 과제를 사용하는데 이과제에는 암호화연산이나, 과학적 계산과 같은 CPU를 집중적으로 사용하는 태스크를 포함한다.

하지만 인스턴스의 성능을 측정하기 위한 벤치마크 과제를 구동하기 위해서는 한가지 제약사항이 있다. 구글 앱엔진의 경우, 샌드박스 환경에서 어플리케이션을 구동 시키는데 프로그래밍 언어의 제약사항뿐만 아니라 애플리케이션은 싱글 쓰레드 상에서 구동되며, 제한된 시간내에 끝나야 한다는 제약이 있다.

이와 같은 이유로 모든 클라우드 프로바이더에서 지원이 가능한 JAVA를 통해서 벤치마크 과제를 만든다. 각각 벤치마크 과제는 1개의 쓰레드에서 동작되며, 30초내에 끝나도록 만들었다.

허나 다중 CPU 코어를 사용하는 인스턴스를 위해서는 다중 쓰레드에서 벤치마크 과제를 구동 시킴으로서 과제의 종료 시간을 측정함으로서 다중 쓰레딩 성능을 측정한다.

스레드의 수는 이용 가능한 CPU 코어의 수에 해당하도록 설정한다.

10) 각각 프로바이더들은 다른 방식으로 과금을 매긴다. 시간당 과금, CPU 싸이클 마다 과금

먼저 시간에 따라 청구하는 프로바이더들에 대해 계산하기 위해서 벤치마크 과제가 종료된 시간에 Price를 곱하여 계산한다.

Cpu 싸이클마다 가격을 과금하는 구글 앱엔진의 경우, 구글 앱엔진에서 제공하는 Billing API를 이용하여 CPU 사이클 과 해당 하는 가격을 곱하여 계산한다.

 

11) 스케일링 레이턴시를 측정하기 위해서 새로운 인스턴스를 생성하는 스크립트를 작성하고, 요구된 시점부터 새로운 인스턴스가 생성되기까지의 시간을 측정한다. 생성하려는 인스턴스의 타입은 Windows와 리눅스 기반의 인스턴스로 측정한다.

또한 Google App Engine의 경우 Scaling 부분에 대해서는 측정하지 않는데, 왜냐하면 Scaling이 자동화 되어 있어 수동적인 조작이 어려워 논외로 한다.

 

12) 다음 결과는 인스턴스의 성능을 나타낸 그래프이다. Y축은 벤치마크 과제에 대한 종료시간을 나타내며 X축은 각기 인스턴스들을 나타낸다. 성능 측정을 위해 인스턴스 타입당 과제 200개의 샘플을 테스트하였으며, 20번을 반복 하였다.

결과를 보면 C1 프로바이더의 경우 C1.1은 낮은 성능을 보이는 반면 C2. C3는 성능이 확연하게 높게 나오는 것을 알 수 있다. 이 이유는 더 많은 CPU를 가지고 있는 것외에도, 최고급 인스턴스는 더 빠른 CPU를 가지고 있기 때문이라 할 수 있다.

 

C4의 경우 벤치마크 과제의 종료시간이 CPU 코어가 많아 진다 해도 성능이 뚜렷하게 좋아지고 있지는 않다. 이는 C4의 모든 인스턴스가 물리적으로 같은 CPU의 유형을 공유하고 있기 때문이며, 자원 분배나 간섭을 회피하는등의 일이 좋지 않다는 것을 의미한다.

 

독특한 것은 C2의 경우 성능이 가격에 상관 없이 똑 같은 성능을 가지고 있다는 것이다. 이것은 C2의 Workconserving CPU 공유 정책에 의해 설명될 수 있다. WorkConserving은 CPU들이 IDLE모드를 허용하지 않는 다는 것인데, 즉 인스턴스가 Physical Machine 상에서 공동 배치된 다른 인스턴스들과 경쟁을 벌여 Physical Machine의 모든 CPU를 사용할 수 있게 해준다는 것을 말한다.

가격이 비싼 최고급 인스턴스들은 경쟁에서 더 높은 우선 순위를 받는다.

이러한 정책으로 인해 높은 성능을 관찰할 때도 있지만 낮은 성능을 관찰 할 수도 있을 거라 예상하였지만, 본 논문의 테스트에서는 발견되지 않았다.

 

13. 다음 그래프는 가격대비 효율성을 나타내고 있다. 단일 스레드로 테스트 한결과, 대부분의 프로바이더의 가장 작은 타입의 인스턴스가 가장 비용 효율적이다.

단 c1.1의 경우 c1.2 보다 효율적이지 못한데, 이유는 c1.2이 c1.1보다 CPU가 더 높은 성능을 가지고 있기 때문에 C1.2가 C1.1 보다 가성비가 좋다.

 

다중 CPU를 가진 인스턴스 들을 멀티 테스트 한 결과 놀랍게도 C1.3 과 C4.4와 같은 최고급 인스턴스들은 저사양의 인스턴스보다 비용효율적이지 못하다.

 

이에 2가지 이유가 있다. 첫 번째는 최고급 인스턴스의 가격은 CPU 코어의 수에 비례하는데, 코어 수는 어떤 비용상의 이점을 주지 못한다. 두 번째는 최고급 인스턴스가 많은 수의 코어를 할당받을지어도, 그것들은 여전히 메모리 버스와 입출력 대역폭과 같은 시스템 자원을 다른 인스턴스와 공유하고 있기 때문이다. 그러므로 메모리 또는 입출력을 집중적으로 사용하는 어플레키에션은 메모리 또는 디스크 공간을 다 소비하고 있지 않는 한 비용효율적이지 못하다.

 

그러므로 최고급 인스턴스보다 더 저급의 인스턴스를 이용하는 것이 더 비용효율적이라고 말할 수 있다.

 

14. 다음 그래프는 인스턴스의 스케일링 레이턴시를 비교한 그래프이다. 실험 테스트 비용을 줄이기 위해 본 논문에서는 프로바이더들의 가장 작은 인스턴스를 위한 스케일링 레이턴시를 측정하였다.

OS별로 얼마나 스케일링 레이턴시에 차이점이 있는지에 대해 연구하기 위해 윈도우와 리눅스 모두 테스트 해본다.

 

리눅스 인스턴스는 Ubuntu 9.04 윈도우는 윈도우 서버2008을 구동한다.

테스트는 각각 OS타입 별로 연속적으로 20개 인스턴스를 생성 시키고, 새로운 인스턴스가 생성되기 까지의 시간을 측정한다.

 

C3의 경우 오토스케일링 정책으로 인해 수동적으로 인스턴스를 생성 시킬 수 없기 떄문에 본 실험에서는 제외하기로 한다.

 

모든 클라우드 프로바이더는 10분 아래로 새로운 인스턴스를 생성할 수 있다.

C1과 C2는 리눅스 인스턴스의 경우 100초 내에 레이턴시를 달성할 수 있다.

윈도우 OS타입의 인스턴스는 리눅스 OS타입의 인스턴스보다 레이턴시가 더 크다.

C4의 레이턴시가 상대적으로 큰 이유는 C4의 경우 프로비저닝에 대한 어떠한 인프라가 상대적으로 다른 프로바이더들에 비해 덜 구축되어있기 때문이다.

 

15. 프로바이더들의 스토리지를 비교하기 위해 스토리지 서비스의 3가지 타입을 측정하고 비교한다. Table, Blob Queue,

비교를 위해 본 논문에서는 스토리지 서비스로부터 Table, Blob, Queue에 해당하는 연산작업을 통해 성능을 평가한다.

측정 대상은 스토리지 서비스의 3가지 타입별로 쓰이는 동작의 레이턴시를 측정하였다. 이는 클라이언트가 오퍼레이션 연산을 실시한 시점부터, 연산에 따른 작업이 완료되기까지의 시간을 측정한다.

스토리지 서비스의 API는 HTTP기반에서 접근이 가능하기 때문에 자바 클라이언트 상에서 스토리지 API를 호출 할 수 있도록 구현을 하였다.

또한 스토리지 오퍼레이션 연산에 따른 비용을 측정하기 위해 빌링 API를 통해서 가격을 계산한다.

가격 선정의 경우 AWS와 엡엔진의 경우 오퍼레이션 당 CPU 싸이클에 따른 과금을 하고 있어, 복잡한 질의는 더 많은 비용이 초래한다. 아주르와 CloudServer는 오퍼레이션의 복잡성에 상관없이 고정 된 비용을 지불한다.

 

 

16. 스토리지 서비스의 Table, Blob Queue의 오퍼레이션 연산을 나타내는 표이다. 각각 해당하는 연산 API를 자바 클라이언트상에서 구현하여 테스트하였다. Table은 RDB와 같은 구조화된 데이터를 저장하고 제공하기 위한 서비스이다. 테이블 및 에트리뷰트의 생성, 삭제 및 데이터 저장 및 선택을 위한 인터페이스가 구현되어 있다. 연산은 테이블을 생성하거나, 삭제 또는 쿼리 워퍼레이션 기능이다.

Blob은 데이터를 Bianry 형태로 저장하는 서비스이며, 데이터를 다운로드 하거나 업로드하는 연산을 가지고 있다.

마지막으로 Queue는 임의의 서비스를 작동시 런타임 메시지를 저장, 제공하는 기능을 수행한다. 엔터프라이즈 서비스 버스(ESB)를 자체적인 구현이 아닌 제공되는 큐를 통하여 구형하고 관리 받는 서비스이다. 아마존의 SQS와 Azure의 Queue 서비스를 말한다. 두 서비스 모두 메시지 큐의 생성 및 삭제, 메시지 전송 및 획득에 대한 인터페이스가 구성되어 있다.

 

17. 가장 먼저 스토리지 서버스의 테이블 스토리지 서비스를 비교한다. C2의 경우 테이블 서비스를 제공하지 않아 논외로 한다. 테이블 서비스의 성능을 테스트 하기위해 GET, PUT, Query 작동을 테스트하였다. 각각 오퍼레이션은 미리 정의해 놓은 2개의 테이블 상에서 작동된다. 하나는 1K엔트리를 갖고, 다른 하나는 100K엔트리를 갖는다.

 

위 그림은 오퍼레이션 별로 반응 시간의 분포도를 나타낸다. 오퍼레이션당 100회씩 반복하였다.

그림을 보면 모든 테이블 서비스가 반응 시간에 대해 모두 높다고 할 수 있다. 예를 들어 GET 오퍼레이션의 경우 최소 반응 시간은 50Ms이고 100MS에서 끝이난다.

3가지 서비스 모두 비슷하게 작동하는데, C3가 다른 프로바이더들에 비해 다소 천천히 작동한다.

그러나 쿼리 오퍼레이션의 경우 C1은 다른 프로바이더들 보다 현저하게 짧은 반응시간을 보이고 있다. C4의 서비스는 다른 프로바이더 다른 프로바이더들에 비해 매우 긴 반응 시간을 보이고 있다 C4의 서비스는 다른 서비스보다 인덱싱 전략이 좋지 않고 C1은 다른 서비스보다 인덱싱이 좋다는 것을 의미한다.

18. 이 테이블은 각 프로바이더들의 테이블 오퍼레이션 연산당 평균 비용이다.

프로바이더별로 과금 모델이 다양할지어도 비용은 비슷하다고 할 수 있다. C1과 C3는 연산마다 가격이 점점 올라가는데 각 오퍼레이션을 하기위한 CPU 싸이클에 따라 가격이 측정 되기 때문이다. C4의 경우 3개 모두 똑 같은 비용을 측정하고 있다.

 

19. 다음 그림은 블롭을 다운 로드, 업로드 하기 위한 반응 시간의 누적 분포도이다. 여기서는 C1, C2, C4의 블롭 스토리지 서비스를 비교한다. C3는 Blob Service를 제공하지 않는다.

Blob 저장소의 성능을 측정하기 위해 2개의 블럽 크기 1KB와 10KB을 고려 한다.

블록의 사이즈가 작을 때는 한번에 처리 될 수 있지만 블록의 사이즈가 큰 경우 서비스 처리용량, 네트워크 대역폭등에 영향을 받을 수 있다.

Blob 크기가 작을 때 C4는 다른 프로바이더 들보다 최고 성능을 보인다. Blob이 클때는 C1의 평균 성능이 다른 것보다 좋다.

또 C2의 경우 다운로드와 업로드의 성능 2배이상 차이가 난다. 이것은 C2의 저장소가 많은 작업을 위해 속도를 조절했을거라 보인다.

Blob Service에 따른 과금은 3 프로바이더 모두 유사하고 Operation 연산의 수와 Blob의 사이즈를 기반으로 비용이 측정된다.

 

20. 다음은 C1과 C4의 큐 서비스를 비교한 그래프이다..

그래프c는 큐 서비스의 전파지연의 분포를 나타내며, C1의 메시지의 경우 메시지가 큐를 통하여 전파하기 위해 긴 시간인 200MS가 걸리며, C4의 큐서비스는 중간 지점까진는 비슷한 전파 지연을 보이나 C1에 비해 더 낮은 변화를 보이고 있다.

그림 a와 b를 보면 메시지를 보내거나 검색하는거에 대한 반응 시간의 누적 분포도를 보여주고 있다.

큐서비스는 8KB 크기까지의 메시지를 전송하기 위해 설게 되며 이번 테스트에서는 50바이트의 메시지 크기를 선택하여 테스트한다.

C4 가 c1보다 메시지를 보내는 것은 빠르다.

C1이 메시지를 검색하는 것은 더 빠르다.

 

큐 서비스의 반응 시간은 테이블 서비스와 블롭 서비스를 비교한 그래프와 비교해볼 때 이것은 큐 서비스가 다른 스토리지 서비스에 비해 더 효율적으로 설계될지어도 스토리지 성능이 크게 변화가 없다는 것을 의미한다.

비용은 두 프로바이더 모두 10k 마다 1센트씩 지불된다.

 

21. 다음은 각 프로바이더들의 데이터 센터 내의 네트워크 성능을 보여주고 있는 그래프이다. 이테스트를 위해 Iperf와 같은 tool을 사용하고 Ping을 측정한다. 또한 데이터 센터내에서 한쌍의 인스턴스를 배정하고 2개의 인스턴스 사이에 그 툴을 배정한다. 또한 데이터 센터내에 같은 Physical Machine위에서 인스턴스가 같이 배정 받는 것을 방지하기 위해 인스턴스의 위치를 조절한다.

또한 TCP 처리량이 흐름 제어에 의해 영향을 받지 않게 하기 위해 TCP 윈도우 사이즈를 조절한다.

이에 TCP클라이언트에서 측정된 TCP처리량을 측정한다.

C3의 경우 인스턴스와 직접적인 통신을 허용하지 않기 떄문에 C3의 테스트는 제외한다. 이 테스트는 똑 같은 센터에서 2개의 인스턴스 사이의 TCp처리량을 보여준다. C1과 c4는 1GBP에 근접한 높은 처리량을 제공하고 있다. C2의 경우 처리량이 낮은 이유는 스로틀링 떄문인데, 시스템의 작업 네트워크 처리량이 적은 경우에 네트워크 대역폭을 줄여버리기 때문이다.

데이터 센터내의 네트워크 대역폭은 모든 프로바이더들이 높은 성능을 보인다.

 

22. Wide-area 네트워크는 클라우드 데이터 센터와 외부 인터넷 호스트 사이의 네트워크 경로와 집합으로 정의 된다.

사용자들은 인스턴스와의 레이턴시를 줄이기 위해 가장 지리적으로 가까운 데이터 센터를 선택할 수 있다.

예외로 구글엔진의 경우 자동적으로 근접한 위치에 맵핑하기 위하여 DNS기반의 서비스를 제공한다.

Wide-area 레이턴시는 프로바이더의 데이터센터와 사용자간의 최소 레이턴시로 측정한다.

 

23. 다음 그림은 Wide-area 레이턴시의 분포도를 나타낸다.

본 논문에서는 Wide –area 네트워크 레이턴시를 측정하기 위하여 각각 데이터 센터의 인스턴스와 미국내의 PlantLab과의 Ping을 측정한다.

 

 

C3의 경우 DNS 로드 밸런싱 시스템을 적용한 경우와 적용하지 않은 경우 2개를 보여준다. 두 경우 모두 C3가 가장 최적화 되어 있다고 말할 수 있다. 적용하지 않은 경우와 적용한 경우의 갭 차이를 보면 C3의 로드밸런싱 시스템이 매우 훌륭하다는 것을 알 수 있다.

C1과 C4는 비슷한 레이턴시를 보인다. C3보다는 낮지만 C2보다는 더 나은 레이턴시를 보인다.

C2의 레이턴시가 가장 나쁜 이유는 가장 데이터센터 수가 적기 떄문이다. C2의 경우 데이터 센터는 미국내 2개의 데이터센터만 존재한다.

 

25. 지금까지의 벤치마크 결과가 실제 애플리케이션을 구동했을 시 나타내는 성능과 일치하는지를 확인하기 위하여 3가지 어플레케이션을 활용한다.

/*TPC-W는 전자상거래를 대상으로 보안, 쇼핑카트, 신용카드 체크, 로드밸런싱 기능을 담고 있는 벤치마크이다. 주요 테스트는 웹서버의 트랜잭션을 할 때 사용된다. */

26. 블라스트는 DNA 비교를 통해 유사성을 측정하는 병렬 계산 어플리케이션이다. 블라스트 어플리케이션은 작업을 실행하기 위해 다중 인스턴스를 구동하면서 작업을 처리한다. 블라스트 인스턴스 간에는 스토리지의 큐 서비스를 이용하여 서로 통신한다. 그러므로 큐 서비스를 지원하는 두 프로바이더를 고려하여 테스트에 선정한다. C1과 C4

다른 프로바이더는 큐서비스를 지원하지 않는다.

27. CloubCMP 벤치마크를 통해 나타낸 결과인 C4.1이 C1.1보다 성능이 낫다는 결과를 바탕으로 C1.1과 C4.1 양쪽 모두에 블라스트를 활용하고 실행시간을 비교한다.

C4.1이 C1.1를 사용했을 때보다 더 실행시간이 짧다.

이것은 벤치마크 결과와 실제 어플리케이션을 구동햇을때에도 결과는 같다는 것을 의미하며

C4.1이 C1.1보다 가성비가 더 좋다를 의미한다.

 

28. 비교 결과를 정리하면, C2는 가장 비용 효율적인 인스턴스를 가지고 있고, C1은 인스턴스를 스케일링 하는데 있어서 최적화 되어있다. C3는 가장 적은Wide-area Network 레이턴시이며, Intra-Cloud 레이턴시는 C1과 C4가 가장 작다. 스토리지는 경우에 따라서 각각 프로바이더 마다 장점이 있다.

아직까지 클라우드 시장에서 명백한 승자는 없다.

하지만 여기서 나타난 클라우드 마다 가진 장점만을 활용하는 메타클라우드는 클라우드 프로바이더들의 서비스를 능가할 수 있다.

29. 클라우드 프로바이더들을 비교하는 것은 실용적인 문제이며 Cloudcmp는 클라우드 프로바이더가 제공하는 서비스들을 분류하여 비교할 수 있다. 비교 결과는 실제 어플리케이션을 구동하는데 있어서 옳바른 선택을 할 수 있게 해준다.