[21 Transactions on Cloud Computing] PerfSim: A Performance Simulator for Cloud Native Computing

ycchae 2022. 3. 2. 17:06

클라우드 네이티브 컴퓨팅 패러다임은 마이크로서비스 기반 애플리케이션을 확장 가능하고 재사용 가능하며 상호 운용 가능한 방식으로 클라우드 인프라를 활용할 수 있도록 한다. 그러나 클라우드 네이티브 시스템의 방대한 수의 구성 매개변수와 매우 세분화된 리소스 할당 정책은 애플리케이션의 성능 및 배포 비용에 상당한 영향을 미칠 수 있다. 이러한 영향을 easy, quick, and cost-effective way로 이해하고 분석하기 위해 사용자 정의 시나리오에서 클라우드 네이티브 서비스 체인의 성능을 근사화하고 예측하기 위한 이산 이벤트 시뮬레이터인 PerfSim을 제시한다. 이를 위해 마이크로서비스 엔드포인트에 위치한 function의 성능을 성능 메트릭과 네트워크 추적을 수집하고 분석하여 모델링하는 방법을 제안한다. 추출된 모델과 사용자 정의 시나리오의 조합을 통해 PerfSim은 주어진 기간 동안 서비스 체인의 성능 동작을 시뮬레이션하고 request의 평균 응답 시간과 같은 시스템 KPI에 대한 근사치를 제공할 수 있다. 논문에서는 단일 랩톱의 처리 능력을 사용하여 104개의 일반적인 시나리오에서 PerfSim의 시뮬레이션 정확도와 속도를 모두 평가하고 시뮬레이션 결과를 실제 Kubernetes 클러스터의 동일한 배포와 비교한 결과 들어오는 request의 평균 응답 시간을 81~99%의 정확도로 추정할 수 있었다. 또한, 직접 실험을 해보는 것 보다 시뮬레이션을 통해 16~1200 배의 시간 비용을 줄일 수 있었다.

2 RELATED WORKS

이 섹션에서는 (1) 시뮬레이션 플랫폼, (2) 에뮬레이션 도구 (3) 분석 성능 모델링 접근 방식으로 나누어 기존 연구들을 간략하게 설명한다.

2.1 Simulation tools

클라우드 네이티브 시스템에는 복잡한 프로비저닝 및 배포 요구 사항이 있습니다. 이러한 서비스의 성능을 평가 및 예측하고, 프로비저닝 정책의 영향을 연구하고, 워크로드 모델을 달성 가능한 성능과 연관시키는 것은 시스템 상호 작용의 다양성과 복잡성으로 인해 간단하지 않습니다. 실제 테스트베드에서 이러한 상호작용을 연구하는 것이 가장 정확한 결과를 제공하지만 여러 연구자와 회사는 컴퓨터 시뮬레이션이 여러 시나리오를 테스트하고 다양한 정책을 다양한 수준에서 시행하기 전에 평가하는 강력한 방법이 될 수 있다고 주장합니다[13]–[16]. 최근 몇 년 동안 컴퓨터 시뮬레이션을 사용하여 서비스 성능을 예측하여 동적 방식으로 필요한 서비스 품질(QoS)을 충족하기 위해 다양한 수준에서 적절한 리소스 정책 및 기타 결정을 개발하는 여러 작업을 목표로 하고 있습니다.
CloudSim[14]은 클라우드 컴퓨팅 인프라를 시뮬레이션하도록 설계된 이 범주에서 가장 널리 사용되는 시뮬레이터 중 하나입니다. 다양한 데이터 센터, 워크로드 스케줄링 및 할당 정책을 모델링할 수 있습니다. 많은 시나리오에서 CloudSim을 사용하면 프로덕션 환경에 애플리케이션을 배포할 필요 없이 클라우드 컴퓨팅 패러다임에서 혁신적인 방법과 알고리즘의 개발을 촉진할 수 있습니다. 최근 몇 년 동안 CloudSim을 기반으로 여러 도구와 모듈이 설계되었습니다. 예를 들어, iFogSim 툴킷[17]은 CloudSim의 기능을 상속하고 IoT 및 Edge/Fog 환경을 모델링하는 기능으로 기능을 확장합니다. [18]의 저자는 또한 CloudSim을 기반으로 에지/포그 컴퓨팅 사양을 시뮬레이션하고 필요한 기능을 지원합니다. 포그 또는 에지 환경에서 다양한 사용 사례를 시뮬레이션하기 위한 몇 가지 다른 CloudSim 기반 시뮬레이터가 있습니다[19,20].
CloudSim 및 CloudSim 기반 모듈/플러그인/도구는 연구원이 서비스 브로커, 데이터 센터 및 일정 정책을 모델링하기 위해 클라우드/에지/포그 컴퓨팅 인프라를 시뮬레이션할 수 있는 정교하고 직접적인 방법을 제공합니다. 그러나 클라우드 네이티브 애플리케이션의 컨테이너화된 서비스에 존재하는 매우 세분화된 리소스 할당 및 배치 정책에 따라 마이크로서비스의 엄격한 성능 테스트를 시뮬레이션할 목적으로 설계되지 않았습니다. 또한 서비스 체인 세트를 효과적으로 시뮬레이션하려면 모든 체인 내의 각 마이크로 서비스 간의 링크와 연결을 정확하게 지정한 다음 사용자 정의 트래픽 시나리오 및 네트워크 토폴로지 모델 세트를 기반으로 요청을 라우팅해야 합니다. 시뮬레이터의 CloudSim 범주가 해결하도록 설계되지 않은 것입니다.
CloudSim 외에도 클라우드 시뮬레이션과 관련된 다른 시뮬레이터가 있습니다. Yet Another Fog Simulator(YAFS)[21]는 맞춤형 전략을 통해 에지/포그 컴퓨팅 환경에서 애플리케이션 배포의 영향을 시뮬레이션할 수 있는 Simpy 기반 이산 이벤트 시뮬레이터입니다. YAFS를 사용하면 애플리케이션, 인프라 구성 및 네트워크 토폴로지 간의 관계를 모델링할 수 있습니다. 이러한 관계를 사용하여 경로 라우팅 및 서비스 스케줄링과 같은 동적 및 맞춤형 시나리오에서 네트워크 처리량 및 대기 시간을 예측합니다. YAFS는 대규모 네트워크 토폴로지의 성능을 시뮬레이션하는 새로운 접근 방식을 제공하지만 클러스터의 호스트 집합에 대한 복잡한 서비스 체인 컨텍스트 내에서 마이크로서비스의 성능을 시뮬레이션하도록 설계되지 않았습니다.
클라우드/에지/포그 시뮬레이터 외에도 에너지 효율성 또는 네트워크 모델링 및 최적화와 같은 클라우드 컴퓨팅 패러다임의 특정 측면에 초점을 맞춘 다른 시뮬레이터가 있습니다. 예를 들어 GreenCloud[13]는 연구원이 에너지 인식 데이터 센터를 설계할 수 있는 환경을 제공하기 위한 목적으로 데이터 센터 구성 요소의 에너지 발자국을 캡처하기 위한 패킷 수준 시뮬레이터입니다[22], [23]. 다른 예로는 주로 다양한 유형의 네트워크 및 토폴로지를 시뮬레이션하도록 설계된 NS-3[16], OMNet++[24] 및 NetSim[25]이 있습니다. 이러한 시뮬레이터는 설계된 클라우드 시스템의 특정 측면(예: 네트워킹 및 에너지 효율성)을 원활하게 시뮬레이션할 수 있지만 클라우드 네이티브 애플리케이션의 성능을 시뮬레이션하는 데 사용할 수는 없습니다. 또는 최소한 네트워크 성능 또는 배치 효율성과 같은 서비스 체인의 특정 측면을 시뮬레이션하는 데에만 사용할 수 있습니다.

2.2 Performance emulators

클라우드 시스템의 성능을 평가하는 또 다른 인기 있는 실험 접근 방식은 에뮬레이션입니다. 에뮬레이션을 사용하여 사용자는 시뮬레이션을 사용하는 것보다 더 현실적인 방법으로 사용 가능한 하드웨어에서 지원하는 시스템 성능 동작을 분석할 수 있습니다[26].
Mininet [27], [28]은 가상 스위치, 라우터, 컨트롤러, 링크 및 호스트의 네트워크를 형성할 수 있는 널리 사용되는 네트워크 에뮬레이터 중 하나입니다. Mininet의 호스트는 표준 Linux 네트워크 소프트웨어를 실행할 수 있는 반면 스위치는 유연한 사용자 지정 라우팅 및 SDN을 제공합니다. Mininet의 밝은 평판은 많은 연구자들이 Mininet을 다양한 방식으로 확장하도록 영감을 주었습니다. 예를 들어, MaxiNet[29]은 MiniNet을 확장하여 여러 호스트에 걸쳐 에뮬레이트된 네트워크를 지원합니다. 그런 다음 EmuFog [30]는 MaxiNet을 확장하여 포그 컴퓨팅 배포 모델을 지원합니다. Fogbed[31]라고 하는 또 다른 MaxiNet 기반 에뮬레이터를 사용하면 다양한 네트워크 구성에서 포그 노드를 소프트웨어 컨테이너로 에뮬레이션하여 에지/포그 환경을 모방할 수 있습니다.
Mininet이 네트워크 및 프로세스 에뮬레이션에 컨테이너를 사용하는 아이디어를 도입한 후 다른 작업에서도 유사한 개념을 채택하기 시작했습니다. 예를 들어 Dockemu[32]는 네트워크 노드를 에뮬레이션하기 위해 Docker를, 네트워크 트래픽을 시뮬레이션하기 위해 NS3를 모두 채택했습니다. 클라우드 기반 네트워크 에뮬레이션 플랫폼인 NEaaS[33]는 Docker와 가상 머신을 모두 사용하여 다양한 네트워킹 시나리오를 에뮬레이트합니다.
그러나 이러한 에뮬레이터의 광범위한 인기는 배포된 기본 하드웨어의 사용 가능한 계산 능력 및 대역폭에 제한되어 결과적으로 리소스 사용률을 예측하는 데 효율적으로 사용할 수 없다는 다소 떨리는 사실과 극명하게 대조됩니다. 대규모 및 복잡한 클라우드 네이티브 애플리케이션의 측면. 또한 에뮬레이션은 다양한 리소스 할당 또는 배치 정책을 평가하는 속도를 크게 향상시킬 수 없으므로 철저한 정책 테스트에 사용할 수 없습니다.

2.3 Analytical performance modeling approaches

분석 프레임워크를 기반으로 하는 클라우드 네이티브 애플리케이션의 성능을 모델링하는 접근 방식의 세 번째 범주가 있습니다. 클라우드 애플리케이션의 다양한 성능 측면을 모델링 및 시뮬레이션할 때 상향식 접근 방식을 사용하는 시뮬레이션/에뮬레이션 기술과 달리 분석 방법은 클라우드 애플리케이션에서 다양한 스트레스 테스트를 실행하여 애플리케이션 KPI를 수집 및 분석하여 해당 목적을 위해 하향식 접근 방식을 채택합니다. 시스템 또는 과거 성능 측정을 사용합니다.
예를 들어 [34]에서 제안한 작업은 스트레스 테스트를 기반으로 마이크로 서비스의 응답 시간을 모델링하고 미리 정의된 간격에 대한 성능 추적을 동시에 수집하여 응답 시간 요구 사항을 충족하도록 예측 자동 스케일링 모델을 학습하는 것을 목표로 합니다. 이러한 성능 추적은 회귀 분석 접근 방식을 사용하여 리소스 프로비저닝 정책 모델을 학습하는 데 사용됩니다. [35]에서는 서비스 기반 샌드박싱을 사용하여 마이크로 서비스를 개별적으로 테스트하여 해당 모델을 구성하고 분석된 데이터와 성능 모델을 사용자에게 제공합니다. 모델링 처리량 및 대기 시간을 고려하여 이전 작업[36]에서 스트레스 테스트 및 회귀 모델링 접근 방식의 조합을 사용하여 마이크로서비스 리소스 구성의 영향을 이해하고 더 작은 성능 테스트에서 KPI와 리소스 구성 간의 상관 관계를 모델링했습니다. 더 큰 프로덕션 환경(PE)에서 성능을 예측하기 위한 환경(PTE).

앞서 언급한 방법들은 실제 시스템에 대한 정확한 성능 측정의 이점이 있고 생산 환경의 성능 엔지니어링에서 가장 널리 사용되는 기술로 간주될 수 있지만 세 가지 주요 제한 사항이 있습니다. 첫 번째 한계는 유용한 성능 측정을 정확하게 제공할 수 있는 환경을 준비하는 데 드는 높은 비용입니다. 정확한 성능 통찰력을 수집하려면 프로덕션 환경이나 이를 모방한 성능 테스트 환경에서 테스트를 수행해야 합니다. 이는 두 경우 모두 높은 배포 비용을 부과합니다. 두 번째 한계는 정확한 결과를 얻기 위해 몇 시간의 성능 테스트가 필요하므로 며칠 또는 몇 주가 아닌 느린 스트레스 테스트 절차입니다. 마지막으로 가장 중요한 한계는 최적의 정책을 학습, 훈련 또는 찾기 위해 수많은 재배포가 필요한 딥 러닝 기반 조합 최적화 휴리스틱 또는 메타 휴리스틱과 같은 고급 최적화 기술을 활용하는 데 적용할 수 있다는 것입니다.

3 PERFSIM DESIGN AND IMPLEMENTATION

이번 장에서는 PerfSim의 시스템 구조와 구현 그리고 서비스 체인에서 마이크로서비스의 endpoint function을 모델링하는 방법에 대해 설명한다. 먼저 Table 1에 수학적 기호를 정리해두었다. 집합의 크기는 $|<set name>|$으로 표시한다.

3.1 Modelling elements of cloud native systems

패러다임의 거의 모든 시뮬레이터와 마찬가지로 PerfSim에는 클라우드 네이티브 시스템의 다양한 요소와 기본 인프라에 대한 모델이 있다.
이전 섹션에서 설명한 것처럼 클러스터에 대한 서비스 체인의 배치 및 리소스 할당의 문제는 수 많은 요소들이 성능 및 대기 시간에 영향을 미치기 때문에 매우 복잡한 문제이다. 그러나 몇 가지 매개변수는 성능의 예측에 미미한 영향을 미친다. 결과적으로, Kubernetes와 같이 잘 알려진 여러 컨테이너 오케스트레이션 플랫폼에 배포될 때 일반적인 클라우드 네이티브 서비스 체인 아키텍처의 성능을 예측할 수 있을만큼 강력하지만 다루기 쉬운 단순화된 모델을 제공하는 것을 목표로 한다.

3.1.1 Hosts

$h_{k} \in H = \{h_{k}\}^{|H|}_{k=1}$는 Linux 기반 CPU core 머신이다. Host는 특정 clock speed(in Hertz)로 동작하는 CPU core의 개수, memory capacity (in bytes), limited ingress, egress network bandwidth (in bytes per second)를 가지는 NIC 그리고 limited storage read/write bandwith, storage capacity를 가지는 local storage로 정의된다. 각 요소는 $h^{cores}_{k}$, $h^{clock}_{k}$, $h^{mem}_{k}$, $h^{ingress\,bw}_{k}$, $h^{egress\,bw}_{k}$, $h^{blkio\,bw}_{k}$, $h^{blkio\,size}_{k}$로 나타낸다. CPU 리소스는 millicore단위로 측정된다. 각 host인 $h_{k}$는 $h^{cores}_{k}$를 파악하기 위해 OS를 관찰하고 1000을 곱하여 전체 capacity를 표현한다. 그러므로, 각 host의 최대 CPU unit은 $h^{millicores}_{k}=h^{cores}_{k} \times 1000$ 이다. 공식화를 용이하게 하기 위해 host에서 사용할 수 있는 리소스를 $R^H = \{millicores, mem, ingress\,bw, egress\,bw, blkio\,bw, blkio\,size\}$로 표시한다.

3.1.2 Network topology

각 host $h_k$는 하나의 라우터에 연결되어 있다. $\rho_{z} \in P = \{\rho_{z}\}^{|P|}_{z=1}$. 이러한 라우터의 최대 bandwidth를 $\rho^{ingress\,bw}_z$, $\rho^{egress\,bw}_z$로 표기한다. 두 속성은 네트워크 topology $\tau$를 표현할 때 사용되며, $\tau$는 undirected acyclic graph인 $G(\tau)=(P, L)$로 표현된다. $h_k$가 연결되어 있는 라우터는 $P^{h_k}$ $in P \subseteq H$ 그리고 $\rho_z$와 연결되어 있는 모든 host의 집합은 $H^{\rho_z}$ 나타낸다. 각 라우터 $\rho_z$는 매 request마다 $\rho^{latency}_z$ nanosecond의 추가적인 latency를 가진다. 비슷하게, 각 링크 $l_o \in L$는 매 request마다 $l^{latency}_o$ nanosecond의 추가적인 delay를 가진다. 이러한 추가적인 latency들은 다음 섹션에서 논의할 congestion controller에 관련된 delay와는 다른 개념이다.

3.1.3 Services

각 서비스 체인은 $|S|$의 집합으로 구성되어 있으며 컨테이너화된 $service\,S=\{S_i\}^{|S|}_{i=1}$은 $S_i \in S$에 속해있으며 $|S_i|$ 개수 만큼의 single-process/multi-threaded $replicas\,\{\hat{s}^i_j\}^{|S_i|}_{j=1}$를 가진다. Replica들은 $|H|$ host 집합 중 load balance되어 동작하고 $|P|$ 라우터 집합을 통해 연결되어 있다. $S_i$는 endpoint 함수들을 갖고 있으며 $F_i=\{f^{i}_{n}\}^{F_i}_{n=1}$ 함수 $F_i$는 수신되는 request의 종류에 따라 다르게 실행되는 함수이다. 각 endpoint 함수 $f^{i}_{n}$는 몇개의 thread $t_m \in f^{i}_{n}$를 생성한다. 이 thread의 속성에 대해서 section 3.1.10에서 자세히 설명한다.