[논문 리뷰] Quasar: Resource-Efficient and QoS-Aware Cluster Management

“Quasar: Resource-Efficient and QoS-Aware Cluster Management” 논문을 개인 공부 및 리뷰를 위해 쓴 글입니다.

논문 링크 : Quasar paper

1. Introduction

• 클라우드 플랫폼은 사용자와 클라우드 운영자에게 유연성(flexibility)와 비용 효율성(cost efficiency)이라는 두 가지 이점을 제공한다.
• 사용자는 짧은 단일 프로세스 애플리케이션에서 대규모 multi-tier 서비스에 이르는 다양한 작업을 신속하게 시작할 수 있으며, 각 지점에서 사용한 리소스에 대해서만 비용을 지불하면 된다.
• 클라우드 운영자는 대규모 데이터 센터(DC)를 구축하고 여러 사용자와 워크로드 간에 리소스를 공유하여 규모(scale) 경제를 달성할 수 있다.
• 그럼에도 불구하고 대부분의 클라우드 시설은 비용 효율성을 크게 고려하여 매우 낮은 사용률(utilization)로 운영된다.
• Fig 1 에서는 한달 동안 Mesos에서 관리하는 수천 대의 서버가 있는 트위터의 프로덕션 클러스터에 대한 사용률 분석을 보여준다.
  • Apache mesos : 다수의 노드를 가진 하나의 클러스터에 대한 리소스를 관리해 주는 프레임워크 ¹
  • 클러스터(cluster) : 여러 대의 컴퓨터들이 연결되어 하나의 시스템처럼 동작하는 컴퓨터들의 집합 ²
• 예약(reservation)이 총 용량의 최대 80%에 도달하더라도 총 CPU 사용률은 지속적으로 20% 미만이다. (Fig 1.a)
  • 예약(reservation) : 가상 시스템에 보장된 최소 할당량을 지정하는 것을 의미한다. ³
• Fig 1.d 는 적절한 양의 리소스를 예약하는 워크로드가 거의 없음을 보여준다.
  • 여기에 표시된 컴퓨팅 리소스는 메모리와 유사하다.
  • 대부분의 워크로드(70%)는 예약을 최대 10배까지 과대평가하는 반면, 다른 것들은(20%) 예약을 최대 5배까지 과소평가한다.
  • 워크로드(workload) : 리소스에서 실행할 수 있는 특정한 애플리케이션, 서비스, 기능 또는 특정한 작업량이다. 가상 머신, 데이터베이스, 컨테이너, 하둡 노드 및 애플리케이션이 모두 워크로드로 간주된다. ⁴

• 다양한 분석에 따르면 산업 전반의 사용률은 6%에서 12% 사이이다.
• 전반적으로 낮은 사용률은 클라우드 시설의 주요 과제이다.
• 관리자는 사용 가능한 리소스의 사용률을 최대화하면서 성능(performance) 목표를 달성하는 방식으로 다양한 워크로드에 리소스를 제공할 책임이 있다.
• 관리자는 두 가지 주요 결정을 내려야 한다.
  • 각 워크로드에 적절한 양의 리소스를 할당한 다음(resource allocation), 지정된 할당을 충족할 특정 서버를 선택(배정)한다.(resource assignment)

• 클러스터 매니저 프레임워크는 애플리케이션 성능과 리소스 활용 목표를 동시에 충족하는 데 있어 사용률을 제한하는 이슈가 여전히 존재한다.
  1. 각 워크로드에 필요한 리소스를 결정하는 것이 특히 어렵다.
     • user-facing 서비스의 부하(load)는 복잡성과 데이터셋 크기에 따라 다르다.
     • 부하(load) : 시스템에서 원하는 어떤 효과를 얻기 위해 취하는 행동에 필요한 동작이나 자원을 말한다. ⁵
• 예약 크기가 작으면(undersized) 애플리케이션 성능이 저하되고, 예약 크기가 크면(oversized) 리소스 사용률이 낮아진다.
• 마찬가지로 중요한 것은 리소스 할당과 리소스 배정이 기본적으로 연결되어 있다는 것이다.
  1. 리소스의 이질성(heterogeneity)으로, DC(data center)의 15년 수명 동안 서버가 설치 및 교체됨에 따라 상당히 높다.
  2. 코로케이션(co-located) 워크로드 간의 간섭(interference)으로 인해 심각한 성능 손실을 초래할 수 있다.
     • 이는 낮은 부하에서 예기치 않은 스파이크(spike)에 이르는 광범위한 트래픽 시나리오에서 엄격한 테일 레이턴시(tail-latency) 요구 사항을 충족해야 하는 user-facing 서비스에 특히 문제가 된다.
     • 우선 순위가 낮은 이러한 서비스들을 코로케이션하는 것과 유휴 리소스를 소비하는 배치 태스크는 부하가 낮더라도 허용할 수 없는 지연 시간이 발생할 수 있다.
       • 코로케이션(co-location) : IDC 공간을 임대하여 여러 서버 랙을 한대 모아두고 관리하는 형태이다. ⁶
     • 이것이 클라우드 운영자가 대부분 낮은 사용률로 작동하는 전용 서버에 짧은 지연시간(low-latency) 서비스를 배포하는 이유이다.
       • 짧은 지연시간(low-latency) : 최소 지연으로 응답을 제공하는 컴퓨팅 시스템 기능이다. ⁷
     • 작업 부하 간에 리소스를 공유하는 시설에서 사용자는 간섭으로 인한 예측 불가능한 성능을 피하기 위해 리소스 예약을 과장하는 경우가 많다.
  3. 대부분의 클라우드 시설은 규모가 크고 수천 대의 서버와 워크로드를 포함하므로 의사 결정에 소요될 수 있는 복잡성과 시간에 엄격한 제약이 있다.

• Quasar 클러스터 관리자는 각 워크로드에 대한 성능 및 QoS 제약 조건을 충족하면서 리소스 활용을 극대화해준다.
  • Qos(quality of service) : 트래픽을 생성하는 애플리케이션의 필수 동작에 맞게 라우터나 스위치 같은 네트워크 디바이스가 해당 트래픽을 전달할 수 있도록 트래픽을 조작하는 것이다. 즉, 네트워크 디바이스가 트래픽을 구별한 후에 트래픽에 서로 다른 동작을 적용할 수 있도록 해준다. ⁸
  • QoS 또 다른 정의 : 다른 응용 프로그램, 사용자, 데이터 흐름 등에 우선 순위를 정하여 데이터 전송에 특정 수준의 성능을 보장하기 위한 능력을 말한다. ⁹
• Quasar에는 세 가지 주요 기능이 있다.

1. 클러스터 관리를 위해 예약 중심에서 성능 중심 접근 방식으로 전환한다.
   • 사용자가 관리자에게 낮은 수준의 리소스 요청을 표시하는 대신 Quasar를 통해 처리량(throughput) 또는 지연 시간(latency) 측면에서 애플리케이션의 성능 제약을 전달할 수 있다.
   • 이 높은 수준의 사양(specification)을 통해 Quasar는 사용 가능한 서버 및 활성 워크로드 측면에서 클러스터의 현재 상태를 감안할 때 성능 제약을 충족하는 데 필요한 사용 가능한 리소스의 최소량을 결정할 수 있다.
   • 할당은 시간이 지남에 따라 워크로드 또는 시스템 변경 사항에 맞게 조정된다.
2. Quasar는 워크로드 성능에 대한 다양한 리소스 할당 및 배정의 영향을 결정하기 위해 빠른 분류(classification) 기술을 사용한다.
   • 워크로드 자체의 소량 프로파일링(profiling) 정보와 이전에 예약된 워크로드의 대량 데이터를 결합함으로써 Quasar는 애플리케이션에 대한 사전 분석 없이 효율적인 리소스 할당 및 배정에 필요한 정보를 빠르고 정확하게 생성할 수 있다.
   • 특히 Quasar는 각 애플리케이션에 대해 네 가지 병렬 분류를 수행하여 리소스 할당 및 배정의 네 가지 주요 측면을 평가한다.
     • scale-up 영향 : 서버당 리소스 양
     • scale-out 영향 : 워크로드당 서버 수
     • server configuration 및 interference 영향 : 워크로드가 코로케이션될 수 있다.
3. Quasar는 리소스 할당과 배정을 공동으로 수행한다.
   • 분류 결과는 작업 부하에 할당된 적절한 양과 특정 리소스 집합을 결정하는 데 사용된다.
   • 또한 Quasar는 워크로드 실행 전반에 걸쳐 성능을 모니터링한다.
   • 성능이 표현된 제약 조건에서 벗어나면 Quasar는 작업 부하를 재분류하고 할당 및 배정 결정을 조정하여 성능 제약 조건을 충족하거나 사용되는 리소스를 최소화한다.
   • 로컬 40개 서버 클러스터와 전용 EC2 서버의 200개 노드 클러스터를 관리하는 Quasar의 프로토타입을 구현하고 평가했다.
   • 분석 프레임워크(하둡, 스톰, 스파크), 지연 시간이 중요한 상태 저장(stateful) 서비스(memcached, 카산드라), 배치 워크로드를 비롯한 다양한 워크로드를 사용한다.
     • memcached : 고성능 캐시 또는 세션 스토어로 사용할 수 있는 사용이 간편한 분산 인 메모리 키-값 스토어 ¹⁰
   • Quasar는 200개 서버 클러스터의 고부하에서 안정적인 상태에서 서버 사용률을 평균 47% 향상시키는 동시에 개별 워크로드의 성능을 향상시킨다.
   • Quasar는 또한 처리량 및 지연 시간 제약 조건이 밀접하게 충족되도록 이질성(heterogeneity)과 간섭(interference)을 고려하는 할당을 선택할 수 있다.

2. Motivation

2.1 Cluster Management Overview

• 클러스터 관리 프레임워크는 보안, 장애 허용(fault tolerance), 모니터링을 포함한 다양한 서비스를 제공한다.
• 여기서는 리소스 할당과 들어오는 워크로드의 리소스 배정에 중점을 둔다.
  • 이전 작업은 대부분 두 가지를 별도로 취급했다.

Resource allocation

• 할당(allocation)은 작업 부하에서 사용하는 리소스의 양(서버 수, 코어 수, 서버 당 메모리 및 대역폭 리소스 양)을 결정하는 것을 말한다.
  • Mesos는 이러한 요청을 처리하고 가용성 및 공정성 문제를 기반으로 프레임워크가 수락하거나 거부할 수 있는 개별 프레임워크에 리소스를 제공한다.

Resource assignment

• 배정(assignment)은 배정을 충족하는 특정 리소스를 선택하는 것을 말한다.
• 배정의 가장 큰 두 가지 문제는 사용률을 높이기 위해 서버를 공유할 때 서버 이질성(heterogeneity)과 코로케이션 워크로드 간의 간섭(interference)이다.
  • 알려지지 않은 워크로드에 대한 리소스 할당이 주어지면 Paragon은 분류 기술을 사용하여 성능에 대한 이질성과 간섭의 영향을 빠르게 추정한다.
  • Paragon은 이 정보를 사용하여 최상의 성능을 제공하는 서버 유형에 각 작업 부하를 할당하고 서로 간섭하지 않는 작업 부하를 배치한다.

2.2 The Case for Coordinated Cluster Management

• 클러스터 관리 기술의 발전에도 불구하고 대부분의 퍼블릭(public)과 프라이빗(private) 클라우드에서 리소스 사용률은 상당히 낮다. (Fig 1 참조)
• 현재 클러스터 매니저에는 두 가지 주요 단점이 있다.
  1. 사용자 또는 작업 부하가 리소스 요구 사항을 이해하고 예약으로 표현하는 것이 어렵다.
  2. 리소스 할당 및 배정은 근본적으로 연결되어 있다.
     • 효율적인 할당은 사용 가능한 리소스의 양과 유형, 클러스터에서 실행 중인 다른 워크로드의 동작에 따라 달라진다.

• Fig 2는 두 가지 대표적인 애플리케이션(Netflix 데이터 셋에서 추천 알고리즘을 실행하는 대규모 하둡 작업(배치)과 읽기 집약적인 부하에서 memcahced 서비스를 활용한 지연 시간)에 대한 다양한 할당 및 배정 및 워크로드 측면의 영향을 분석하여 문제들을 보여준다.
• 하둡의 경우 사용 가능한 모든 코어와 메모리를 사용하여 서버 구성 A의 단일 노드에 대한 속도 향상을 보고한다.
  • 각 바이올린 플롯의 변동성(variability)은 각 서버 내에 할당된 리소스(코어 및 메모리)의 양이 다르기 때문에 저렇게 보여준다.
• memcached의 경우 지연 시간 처리량 그래프를 보고한다.
  • 실제 memcahced 배포는 처리량을 제한하여 0.2ms에서 1ms 사이의 99번째 백분위수 지연 시간을 달성한다.

• Fig 2의 첫 번째 행은 하둡의 동작을 보여준다.
  • heterogeneity 그래프는 서버 구성을 선택하면 최대 7배의 성능 가변성(variability)이 발생하는 반면, 각 서버에 할당된 리소스의 양은 최대 10배의 가변이 발생함을 보여준다.
  • interference 그래프는 서버 A의 경우 사용된 리소스의 양에 따라 하둡이 특정 유형의 간섭 또는 속도 저하에 최대 10배까지 둔감할 수 있음을 보여준다.
  • scale-out 그래프는 서버당 리소스의 양에 따라 스케일링이 sublinear 또는 superlinear 일 수 있음을 보여준다.
  • dataset 그래프는 데이터 셋 복잡성과 크기가 하둡 성능에 3배 영향을 미칠 수 있음을 보여준다.

3. Quasar

3.1 Overview

• Quasar는 세 가지 주요 특징이 있다.
• 첫째, 리소스 예약에서 벗어나 성능 중심 접근 방식을 채택한다.
  • 인터페이스는 워크로드 유형에 따라 다르다.
  • 지연 시간이 중요한 워크로드의 경우 제약 조건은 QPS(초당 쿼리 수) 대상 및 지연 시간 QoS 제약 조건으로 표현된다.
  • 하둡과 같은 분산 프레임워크의 경우 제약 조건은 실행(execution) 시간이다.
  • 단일 노드, 단일 스레드 또는 멀티 스레드 워크로드의 경우 제약 조건은 IPS(초당 명령 수)의 낮은 수준 메트릭이다.
  • 성능 제약이 지정되면 이를 충족하는 리소스 할당 및 배정을 찾는 것은 Quasar에 달려 있다.
• 둘째, Quasar는 빠른 분류 기술을 사용하여 다양한 리소스 할당 및 배정 결정이 워크로드 성능에 미치는 영향을 빠르고 정확하게 추정한다.
  • 승인 시 워크로드와 데이터 셋은 짧은 시간 동안 몇 대의 서버에서 프로파일링된다.
  • 이 제한된 프로파일링 정보는 분류 기술을 사용하여 시스템에서 이전에 예약된 오프라인으로 특수화된 소수의 작업 부하 및 많은 작업 부하 정보와 결합된다.
  • 분류 결과는 서버의 유형 또는 수, 서버 내 리소스의 양, 다른 워크로드의 간섭을 다양화할 때 애플리케이션 성능을 정확하게 추정한 것이다.
  • 분류를 사용하더라도 모든 할당-배정 조합에 대한 성능을 철저하게 추정하는 것은 불가능하다.
  • 대신 Quasar는 할당 및 배정의 네 가지 주요 구성 요소로 문제를 분해하는데, 이것은 분류 문제의 복잡성을 극적으로 줄여준다.
• 셋째, Quasar는 분류 결과를 활용하여 리소스 할당과 배정을 공동으로 수행하여 할당 과제를 알지 못한 채 할당을 수행하는 고유의 비효율성을 제거한다.
  • 그리디(greedy) 알고리즘은 네 가지 독립적인 분류의 결과를 결합하여 성능 제약을 충족할 리소스의 수와 특정 집합을 선택한다.

3.2 Fast and Accurate Classification

• 협업 필터링(collaborative filtering) 기술은 매우 희소(sparse) 입력을 가진 추천 시스템에서 자주 사용된다.
• 가장 널리 알려진 용도 중 하나는 SVD(singular value decomposition) 기술을 사용하여 rating만 평가한 사용자에게 영화 추천을 제공하는 Netflix 였다.
  • SVD에 대한 입력은 사용자를 행으로, 영화를 열로, 레이팅을 요소로 포함하는 매우 희소 행렬이다.
  • SGD(Stochastic Gradient Descent)를 사용한 PG 재구성(reconstruction)은 $\sum ,U\ ,V$ 를 사용하여 A의 누락된 항목을 재구성한다.
• Paragon에서는 간섭 및 이질성과 관련하여 작업 부하를 빠르게 분류하기 위해 협업 필터링이 사용되었다.
• 몇 가지 애플리케이션은 서로 다른 서버와 다양한 간섭 양에서 성능을 도출하기 위해 완전히 오프라인으로 프로파일링된다.
• 애플리케이션은 2개의 공유 리소스에 대한 간섭이 있거나 없은 많은 서버 구성 중 2개에서 1분 동안 프로파일링된다.
• SVD 및 PQ 재구성은 나머지 서버 구성과 나머지 유형의 리소스에 대한 간섭으로 작업 부하의 성능을 정확하게 추정하는 데 사용된다.
• 즉, Paragon은 협업 필터링이 수십 개의 서버 구성과 수십 개의 간섭 소스와 관련하여 알려지지 않은 애플리케이션을 빠르고 정확하게 분류할 수 있음을 보여주었다.

• Quasar의 분류 엔진은 Paragon의 분류 엔진을 두 가지 방식으로 확장한다.
• 첫째, 협업 필터링을 사용하여 애플리케이션 성능에 대한 리소스 scale-out와 scale-up의 영향을 추정한다.
  • 이러한 추가 분류는 리소스 할당에 필요하다.
• 둘째, 다양한 워크로드 유형에 맞게 분류를 조정한다.
  • 이는 워크로드 유형에 따라 제약 조건과 할당이 다르기 때문에 필요하다.
    • 웹 서버에서는 scale out과 scale in을 모두 적용할 수 있으며 QPS(초당 쿼리 수)와 지연 시간을 모니터링해야 한다.
    • 하둡의 경우 노드 당 매퍼(mapper) 수, 힙 크기 및 압축과 같은 워크로드 매개변수도 구성할 수 있다.

Scale-up classification

• 이 분류는 서버 내에서 사용되는 리소스의 양에 따라 성능이 어떻게 달라지는 살펴본다.
  • 현재 컴퓨팅 코어, 메모리 및 스토리지 용량에 중점을 두고 있다.
• 워크로드가 제출되면 무작위로 선택된 두 개의 scale-up 할당으로 간략하게 프로파일링한다.
• 프로파일링의 매개변수 및 duration은 워크로드 유형에 따라 다르다.
  • memcached 서비스같은 경우 두 가지 다른 코어/스레드 수와 메모리 할당을 사용하여 라이브 트래픽에서 5 ~10초 동안 프로파일링된다.
  • 하둡과 같은 워크로드의 경우 가장 중요한 프레임워크 매개변수(ex. 노드당 매퍼, JVM 힙 크기, 블록 크기, 작업당 메모리, 복제 요소 및 압축)의 두 가지 다른 할당 및 구성을 사용하여 맵(Map) 작업의 작은 서브셋을 프로파일링한다.
    • 프로파일링은 맵 작업이 완료의 최소 20%에 도달할 때까지 지속된다.
• 프로파일링은 각 애플리케이션의 성능 목표(ex. 예상 완료 시간 또는 QPS) 형식으로 성능 측정치를 수집하고 워크로드를 행으로, scale-up을 열로 포함하는 매트릭스 A에 삽입한다.
  • 구성(figuration)에는 컴퓨팅, 메모리 및 스토리지 할당 또는 하둡과 같은 워크로드에 대한 프레임워크 매개변수 값이 포함된다.
• SVD 및 PQ 재구성을 사용한 분류는 모든 scale-up 할당에서 워크로드의 성능을 도출한다.

Scale-out classification

• 이 유형의 분류는 분산 프레임워크(ex. 하둡, 스파크), 상태 비저장(stateless) (ex. 웹서핑), 상태 저장(stateful) (ex. memcached, 카산드라) 분산 서비스와 같이 여러 서버를 사용할 수 있는 워크로드에만 적용할 수 있다.
• scale-out 분류에는 이를 위해 수행되는 단일 노드 실행 외에 한번 더 실행해야 한다.
• 이렇게 하면 행렬 A에 대해 두 개의 항목이 생성된다.
  • 여기서 행은 워크로드이고, 열은 scale-out 이다.
• 그런 다음 협업 필터링은 모든 노드 수에서 누락된 성능 항목을 복구한다.
• scale-out 분류에는 프로파일링을 위한 추가 서버가 필요하다.
  • 시스템이 온라인 상태일 때 분류 오버헤드가 증가하는 것을 방지하기 위해 애플리케이션은 scale-out 분류를 위해 1~4개의 노드에서만 프로파일링된다.

Heterogeneity classification

• 이 분류에는 동일한 워크로드 매개변수를 사용하고 scale-up 실행과 동일한 기간 동안 무작위로 선택된 다른 서버 유형에서 프로파일링을 한번 더 실행해야 한다.
• 협업 필터링은 다른 모든 서버 유형에서 워크로드 성능을 추정한다.

Interference classification

• 이 분류는 CPU, 캐시 계층, 메모리 용량 및 대역폭, 스토리지 및 네트워크 대역폭을 포함하여 다양한 공유 리소스에서 발생하고 허용되는 간섭에 대한 워크로드의 민감도를 수량화한다.
• 이 분류에는 추가 프로파일링 실행이 필요하지 않다.
• 대신, scale-up의 첫 번째 복제본을 활용하여 특정 공유 리소스에서 경쟁(contention)을 생성하는 두 개의 마이크로벤치마크를 한번에 하나씩 주입한다.
  • 마이크로벤치마크가 주입되면 Quasar는 워크로드 성능이 허용 가능한 QoS 수준 아래로 떨어질 때까지 강도를 조정한다.
  • 이 지점은 해당 행렬 A의 새 행에 이러한 유형의 간섭에 대한 작업 부하의 민감도로 기록된다.
  • 행렬의 열은 간섭의 다른 소스이다.
  • 그런 다음 나머지 간섭 소스에 대한 민감도를 도출하기 위해 분류가 적용된다.
  • 프로파일링 실행이 완료되면 다양한 유형의 분류가 누락된 항목을 재구성하고 각 워크로드에 대한 효율적인 할당 및 배정에 대한 권장 사항을 제공한다.

Multiple parallel versus single exhaustive classification

• 분류는 정확성(accuracy)과 효율성(efficiency)을 위해 네 가지 구성 요소로 분해된다.

Validation

• Table 2는 Quasar에서 분류 엔진의 정확성 검증을 요약한 것이다.
• 각 애플리케이션 및 분류 유형에 대한 평균, 90번째 백분위 수 및 최대 오류를 보여준다.
  • 오류(error)는 추정된 성능과 측정된 성능 또는 간섭에 대한 민감도 간의 편차를 보여준다.
• 평균적으로 분류 오류는 모든 애플리케이션 유형에서 8% 미만이고 최대 오류는 17% 미만이므로 클러스터 관리 결정을 이끄는 정보가 정확함을 보장한다.

• 또한 선택한 프로파일링 실행 횟수, 즉 입력 행렬의 밀도에 따라 분류 정확도가 어떻게 변하는지 검증한다.
• Fig 3(a-d)는 해당 입력 행렬의 밀도가 증가함에 따라 분류 오류의 90번째 백분위수가 어떻게 변하는지 보여준다.
  • 네 가지 분류 유형 모두 분류당 단일 프로파일링을 실행하면 높은 오류가 발생한다.
  • 입력 행당 2개 이상의 항목을 입력하면 오류가 감소하지만 4-5개 항목 후에는 어떤 지점에 도달한다.

3.3 Greedy Allocation and Assignment

• 분류 출력(output)은 할당된 리소스의 양, 유형 및 정확한 셋을 공동으로 결정하는 그리디 스케줄러에 제공된다.
  • 스케줄러의 목표는 워크로드의 성능 목표를 충족하는 데 필요한 최소한의 리소스를 할당하는 것이다.
  • 이렇게 하면 스케줄러가 통과하는 공간이 크게 줄어들어 더 적은 양의 리소스가 성능 제약을 충족하므로 더 높은 품질의 리소스를 먼저 검사할 수 있다.
• 스케줄러는 분류 출력을 사용하여 리소스 품질을 낮추어 사용 가능한 서버의 우선 순위를 지정한다.
  • 즉, 간섭이 최소화된 고성능 플랫폼이 먼저이다.
• 다음으로 성능 제약 조건이 충족될 때까지 사용 가능한 리소스를 기반으로 할당 크기를 조정한다.
• 할당 크기를 조정할 때 알고리즘은 먼저 노드당 리소스를 늘려(scale-up) 소수의 서버에서 작업을 더 잘 압축한 다음 부하를 시스템 전체에 분산한다.(scale-out)

3.4 Putting it All Together

• Fig 4는 Quasar에서 클러스터 관리의 다양한 단계를 보여준다.
• 워크로드가 도착하면 Quasar는 scale-out, scale-in, heterogeneity, interference에 대한 프로파일링 데이터를 수집한다.
  • 이를 위해서는 병렬로 발생하는 최대 4개의 프로파일링 실행이 필요하다.
• 모든 프로파일링 복제본은 샌드박스 처리되며, 사용된 두 플랫폼은 A와 B이며(A의 두 노드는 scale-out 분류에 사용됨), 각 프로파일링 유형은 워크로드의 해당 속도 향상 그래프에서 두 지점을 생성한다.
• 프로파일링 실행은 워크로드의 실제 데이터셋에서 발생한다.
• 프로파일링 결과를 사용할 수 있게 되면 분류에서 전체 워크로드 특성화(속도 향상 그래프)를 제공한다.
• 다음으로 그리디 스케줄러는 특정 서버를 워크로드에 할당한다.
• Quasar는 워크로드별 및 서버별 상태를 유지한다.
• 작업 부하 상태에는 분류 출력이 포함된다.

4. Implementation

• Quasar API에는 제출된 작업 부하의 성능 제약 조건 및 유형을 표현하는 기능과 작업 상태를 확인하거나 취소하거나 제약 조건을 업데이트하는 기능이 포함된다.

4.1 Dynamic Adaptation

• 일부 워크로드는 phase 변경 또는 사용자 트래픽의 변화로 인해 런타임 중에 동작을 변경한다.
  • 트래픽(traffic) : 서버와 스위치 등 네트워크 장치에서 일정 시간 내에 흐르는 데이터의 양을 말한다. ¹¹
• Quasar는 이러한 변경을 감지하고 리소스 할당 및 배정을 조정하여 성능 제약을 유지한다.

phase detection

• Quasar는 클러스터의 모든 활성 워크로드의 성능을 지속적으로 모니터링한다.
• Quasar는 애플리케이션을 현재 상태로 재분류하고 필요에 따라 리소스를 조정한다.
• 또한 몇 가지 활성 워크로드를 주기적으로 샘플링하고 간섭하는 마이크로 벤치마크를 주입하여 phase 변경 및 잘못된 분류/스케줄링을 사전에 테스트한다.
  • 이를 통해 부분 간섭 분류가 가능하다.
• 원래 분류 결과와 비교하여 큰 변화가 있는 경우 Quasar는 phase 변경을 알린다.
• 반응 전용 방식으로 Quasar는 phase 변화의 94%를 감지한다.
• 10분마다 활성 워크로드의 20%를 샘플링하여 8%의 FP 확률로 변경 사항의 78%를 사전에 감지한다.

Allocation adjustment

• phase가 감지되거나 user-facing 작업 부하에 대한 부하가 크게 증가하면 Quasar는 할당을 변경하여 더 많은 리소스를 제공하거나 사용하지 않는 리소스를 회수한다.
• 먼저 현재 점유하고 있는 각 서버의 워크로드에 지정된 리소스를 확장하거나 축소한다.
• scale-up이 불가능하거나 성능 요구 사항을 해결할 수 없는 경우 scale-out 및 다른 서버로의 마이그레이션이 사용된다.

4.2 Side Effect Free Profiling

• 분류에 필요한 프로파일링 데이터를 얻으려면 들어오는 응용 프로그램의 여러 복제본을 시작해야 한다.
• 이로 인해 중간 결과의 불일치, 데이터베이스의 중복 항목 또는 파일 시스템의 데이터 손상이 발생할 수 있다.
• 이러한 문제를 제거하기 위해 Quasar는 프로파일링 중에 학습 복제본에 샌드박싱(sandbox)을 사용한다.
  • 샌드박스(sandbox) : 외부로부터 들어온 프로그램이 보호된 영역에서 동작해 시스템이 부정하게 조작되는 것을 막는 보안 형태 ¹²
• chroot와 함께 Linux 컨테이너를 사용하여 프로파일링 실행을 샌드박스하고 파일을 평소와 같이 읽고 쓸 수 있도록 copy-on-write 스냅샷을 만든다.
  • 컨테이너를 사용하면 cgroup을 통한 리소스 사용 제한을 포함하여 학습 실행이 시스템의 나머지 부분과 상호 작용하는 방식을 완전히 제어할 수 있다.

4.3 Stragglers

• 하둡 또는 스파크와 같은 프레임워크에서 개별 태스크는 poor 작업 파티셔닝부터 네트워크 간섭 및 시스템 불안정성에 이르기까지 다양한 이유로 완료하는 데 훨씬 더 오래 걸릴 수 있다.
• 이러한 스트래글링(straggling) 작업은 일반적으로 적시에 작업을 완료할 수 있도록 프레임워크에 의해 식별되고 다시 시작된다.
• Quasars는 하둡에서 TaskTracker API를 호출하고 성능이 낮은 작업을 확인한다. (중앙값보다 최소 50% 느린)
• 이러한 작업을 위해 Quasar는 해당 서버에 두 개의 마이크로벤치마크를 삽입하고 간섭이 발생하고 허용되는지 여부에 따라 이를 재분류한다.
• 분류 결과가 원본과 20% 이상 차이가 나는 경우 작업을 스트래글러로 알리고 Hadoop JobTracker에 새로 할당된 서버에서 작업을 다시 시작하도록 알린다.

4.4 Discussion

• Cost target
  • 성능 목표 외에도 사용자는 워크로드에 대한 비용 제약, 우선 순위 및 유틸리티 기능을 지정할 수도 있다.
• Resource partitioning
  • Quasar는 하드웨어 리소스를 명시적으로 파티셔닝하지 않는다.
  • 대신 공유 리소스와 경쟁하지 않는 워크로드를 함께 배치하여 간섭을 줄인다.
• Fault tolerance
  • 마스터-워커 미러링을 사용하여 Quasar 스케줄러를 실행하는 서버에 장애 허용을 제공한다.
  • 모든 시스템 상태(활성 애플리케이션 목록, 할당, QoS 보장)는 지속적으로 복제되며 상시 대기인 마스터에서 사용할 수 있다.
  • Quasar는 맵리듀스와 같은 프레임워크의 장애 허용을 명시적으로 추가하지 않는다.
  • 장애가 발생한 경우 클러스터 관리자는 개별 프레임워크에 의존하여 누락된 워커 데이터를 복구한다.

5. Methodology

Cluster

• 40개 서버 로컬 클러스터에서 Quasar를 평가했고, EC2에서 200개 서버 클러스터를 평가했다.

Single Batch Job

• 하둡, 스톰, 스파크와 같은 분석 프레임워크는 프라이빗 및 퍼블릭 클라우드에서 리소스를 많이 사용한다.
• 이러한 프레임워크에는 다양한 프레임워크 매개변수(ex. 노드당 매퍼 및 블록 크기)를 설정하고 리소스 할당(사용된 서버 수)을 결정하는 개별 스케줄러가 있다.
• 각 스케줄러에 의한 할당은 두 가지 이유로 차선책이다.
  1. 스케줄러는 제출된 작업 및 데이터셋의 복잡성을 완전히 이해하지 못한다.
  2. 스케줄러는 사용 가능한 서버의 세부 정보를 인식하지 못하므로 할당량이 부족하거나 초과 프로비저닝된다.
     • 프로비저닝(provisioning) : 사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해 두는 것을 말한다. ¹³

• 첫 번째 시나리오에서는 작은 클러스터에서 단일 하둡 작업이 한 번에 실행된다.
• 이 간단한 시나리오를 통해 하둡이 선택한 리소스 할당을 단일 작업 기준으로 Quasar의 할당/배정과 비교할 수 있다.

Multiple Batch Jobs

• 두 번째 시나리오는 배치 처리 클러스터에 대한 현실적인 설정을 나타낸다.
• 클러스터는 여러 분석 프레임워크(하둡, 스톰, 스파크)의 작업 간에 공유된다.
• 여기서는 머하웃 라이브러리에서 실행되는 16개의 하둡 애플리케이션, 스톰의 실시간 텍스트 및 이미지 처리를 위한 4개의 워크로드, 스파크의 회귀, 텍스트 처리 및 기계학습를 위한 4개의 워크로드를 사용한다.
• 이러한 작업은 도착 간 시간이 5초로 클러스터에 온다.
• 여기서는 Quasar를 프레임워크 자체(하둡, 스파크, 스톰 스케줄러)에 의해 수행된 할당과 코어 및 메모리 사용을 고려하지만 이질성 또는 간섭을 고려하지 않는 최소 부하 스케줄러에 의한 할당과 비교한다.

Low-Latency Service

• latency-critical 서비스는 클라우드 시설의 주요 테넌트이다.
  • 테넌트(tenant) : 클라우드 서비스 이용자가 가지게 되는 자신만의 환경을 말한다. ¹⁴
• 아파치 웹 서버, PHP의 애플리케이션 로직, MySQL에 저장된 데이터를 포함하는 HotCRP 회의 관리 시스템을 사용하여 웹서빙 시나리오를 구성했다.
  • HotCRP : 학술 회의를 위한 리뷰 프로세스를 관리하기 위한 소프트웨어이다.¹⁵
• HotCRP 트래픽에는 논문 초록 작성, 저자 정보 업데이트, 논문 업로드 또는 읽기 요청이 포함된다.
• 처리량 제약 외에도 HotCRP에는 요청당 100msec의 지연 시간이 필요하다.
• Auto-scale은 현재 로드가 70%를 초과할 때 HotCRP에 대해 최소 로드 서버를 추가로 할당하고 트래픽의 고정한 공유를 새 서버 인스턴스로 리디렉션한다.
• Best-effort 작업은 최소 로드(LL) 스케줄러에 의해 할당된다.
• Quasar는 기존 할당을 scale-up 하거나 두 가지가 성능에 미치는 영향에 따라 scale-out하여 HotCRP의 부하 변경을 처리한다.

Stateful Latency-Critical Services

• 이 시나리오는 위의 시나리오를 두 가지 방식으로 확장한다.

  1. 여러 저지연 서비스가 있다.
  2. 이러한 서비스에는 상당한 양의 상태가 포함된다.

• 특히 latency-critical NoSQL 서비스인 메모리 기반 memcached 및 디스크 기반 카산드라의 배포를 조사한다.

Large-Scale Cloud Provider

• 마지막으로 모든 유형의 워크로드 1200개가 1초 간격으로 전용 EC2 서버의 200개 노드 클러스터에 무작위 순서로 제출되는 일반적인 경우에 모든 것을 모았다.
• 이 시나리오는 이상적인 리소스 할당에서 초과 할당을 일으키지 않고 정상 상태에서 거의 모든 시스템 코어를 사용하도록 설계되었다.
  • 그러나 할당이 불완전할 때 머신 초과 할당을 방지하기 위해 허용 제어(admission control)를 사용한다.
• Quasar는 모든 워크로드에 대한 할당 및 배정을 처리한다.
• 비교를 위해 지연 시간이 중요한 워크로드의 리소스 할당에 autoscaling 방식을 사용한다.
• 하둡 및 스톰과 같은 프레임워크의 경우 프레임워크는 리소스 요구 사항을 추정하고 이를 예약으로 처리한다.

6. Evaluation

6.1 Single Batch Job

• Performance
• Fig 5는 하둡 자체가 아닌 Quasar에서 리소스를 할당했을 때 10개의 하둡 작업 실행 시간 감소를 보여준다.
• Quasar는 모든 작업의 성능을 평균 29%에서 최대 58%까지 향상시킨다.
• 노란색 점은 제출 시 지정된 작업의 성능 목표를 달성하는 데 필요한 실행 시간 개선을 나타낸다.
• 목표는 다른 서버 플랫폼에서 매개변수 스위프 후에 달성된 최상의 성능으로 설정된다.
• Quasar는 리소스 할당 및 배정이 성능에 미치는 영향에 대한 정보를 활용하여 평균적으로 제약 조건의 5.8% 이내에서 성능을 달성한다.

• Efficiency
• Table 3은 20GB 데이터셋과 함께 머하웃을 사용하는 추천 시스템인 하둡 작업에 대해 Quasar와 Hadoop이 선택한 다양한 매개변수 설정을 보여준다.
• Quasar는 매퍼 간의 간섭이 낮다는 것을 감지하고 노드당 매퍼를 12로 늘린다.
• 마찬가지로 힙 크기가 이 작업에 중요하지 않다는 것을 감지하고 크기를 줄여 다른 워크로드를 위한 리소스를 확보한다.
• 또한 Quasar는 두 가지 가장 적합한 서버 유형(E, F)에 작업을 할당하는 반면 하둡은 사용 가능한 모든 서버 유형 중에서 선택한다.

6.2 Multiple Batch Frameworks

• Performance
• Fig 6은 Quasar가 리소스 할당 및 배정을 관리할 때 하둡, 스톰, 스파크 작업의 실행 시간 감소를 보여준다.
• 평균적으로 성능은 27% 향상되고 제공된 제약 조건의 5.3% 이내로, 기준선보다 크게 향상된다.
• Quasar는 간섭을 인식하기 때문에 기본 작업을 방해하지 않고 남은 클러스터 용량을 best effort 작업에 사용할 수 있다.

• Utilization
• Fig 7은 시간 경과에 따른 서버별 CPU 사용률을 히트맵 형식으로 보여준다.
• 사용률은 5초마다 샘플링된다.
• 개별 작업 성능을 향상시키는 것 외에도 Quasar는 사용률을 높여 개별 프레임워크 스케줄러를 사용하여 평균 34%에 비해 사용률을 높인다.

6.3 Low-Latency Service

• Performance
• Fig 8a는 입력 트래픽이 일정할 때 Quasar와 autoscaling 시스템으로 달성한 HotCRP의 총 처리량을 보여준다.
• Quasar를 사용하면 HotCRP가 방해받지 않고 실행되고 Best-effort 작업은 최소 5% 이내의 런타임을 달성하는 반면 autoscaling을 사용하면 최소 24% 이내의 런타임을 달성한다.
• 트래픽이 다양할 때 (Fig 8b), Quasar는 목표 QPS를 밀접하게 추적하는 반면 autoscaling은 간섭과 차선의 scale-up 구성으로 인해 평균적으로 18% 더 낮은 QPS를 제공한다.
• Quasar의 원활한 동작은 새로운 QPS 목표를 가장 잘 충족하기 위해 scale-out과 scale-up을 모두 사용하기 때문에 best effort 작업에 가능한 한 많은 코어를 남긴다. (Fig 8c)
• 급격한 스파이크가 있는 부하의 경우 Quasar는 평균 4% 이내의 QPS를 추적하고 (Fig 8d), 거의 모든 요청에 대해 지연 시간 QoS를 충족한다. (Fig 8e)

6.4 Stateful Latency-Critical Services

• Performance
• Fig 9는 시간 경과에 따른 memcached 및 카산드라의 처리량과 쿼리 지연 시간 분포를 보여준다.
• Quasar는 요청의 98.8%에 대해 memcached에 대한 지연 시간 QoS를 충족하고 요청의 80%에 대해서만 autoscaling을 수행한다.
• 카산드라의 경우 Quasar는 요청의 98.6%에 대해 지연 시간 QoS를 충족하고 요청의 93%에 대해 autoscaling을 충족한다.

• Utilization
• Fig 10은 Quasar에서 24시간동아 관리할 때 클러스터 서버 전체의 CPU 활용, 메모리 용량 및 디스크 대역폭을 보여준다.
• 각 열은 6시간 동안의 평균 사용률 스냅샷이다.

6.5 Large-Scale Cloud Provider

• Performance
• Fig 11은 이전에 논의된 모든 유형의 워크로드를 실행하는 200 노드 클러스터를 관리하는 Quasar의 전반적인 평가를 보여준다.
• Fig 11a는 성능 목표에 맞게 표준화된 1200개 워크로드의 성능을 최저 성능에서 최고 성능 순서로 보여준다.

• Utilization
• Fig 11b-c는 Quasar 및 예약+LL 시스템에 대한 시나리오 실행 전반에 걸친 서버별 CPU 사용률을 보여준다.
• Quasar의 평균 사용률은 62%이며 배치 및 지연 시간이 중요한 워크로드 모두에 대한 성능 제약을 충족한다.
• Fig 11d는 Quasar에 할당 및 사용된 리소스를 시간 경과에 따라 예약+LL 관리자가 예약한 자원과 비교하여 보여준다.
• Quasar는 다양한 할당/배정이 성능에 미치는 영향에 대한 자세한 정보를 가지고 있기 때문에 QoS 위반 없이 성능 제약을 충족하면서 할당을 보다 적극적으로 조정할 수 있다.

• Cluster management overheads
• 대부분의 애플리케이션에서 프로파일링, 분류, 그리디 선택 및 적응에서 Quasar의 오버헤드는 평균 실행 시간의 4.1%로 낮다.

References

1. [mesos] Apache Mesos PART 1 - freepsw ↩

2. 컴퓨터 클러스터 - 위키백과 ↩

3. 리소스 할당 예약 - vmware ↩

4. 클라우드 워크로드 - dell ↩

5. 해시넷 - 부하(컴퓨터) ↩

6. 코로케이션 개념, 클라우드와 차이점 및 비용 알아보기 - TECH 블로그피디아 ↩

7. What is Low Latency? - CISCO ↩

8. QoS(Quality of Service) 소개 - Juniper ↩

9. QoS - 위키백과 ↩

10. Amazon ElastiCache - memcached - AWS ↩

11. 트래픽 - 해시넷 ↩

12. 샌드박스(컴퓨터 보안) - 나무위키 ↩

13. 프로비저닝 - 위키백과 ↩

14. 테넌트(tenant), 리전(region), 가용 영역(Availability Zone) ↩

15. kohler/hotcrp - github ↩