[번역] How Does Project Pacific Deliver 8% Better Performance Than Bare Metal?

출처 : https://blogs.vmware.com/performance/2019/10/how-does-project-pacific-deliver-8-better-performance-than-bare-metal.html

VMworld US 2019에서 VMware는 vSphere를 쿠버넷 네이티브 플랫폼으로 발전시킨 Project Pacific을 발표했다. Project Pacific(다른 여러 가지 사항 중)에서는 가상 시스템과 동일한 수준의 격리(isolation) 기능을 갖춘 ESXi(vSphere Native Pods)에서 기본적으로 Kubernetes 파드(vSphere Native Pods)를 실행할 수 있는 vSphere Supervisor Cluster를 도입한다.

VMworld에서는 하이퍼바이저에 의해 격리된 Project Pacific에서 실행되는 vSphere Native Pods가 베어메탈 Linux Kubernetes 노드의 포드보다 최대 8% 더 뛰어난 성능을 달성할 수 있다고 주장했다. 가상화된 성능이 베어 메탈보다 더 낫다는 것은 다소 직관에 반하는 것으로 들릴 수 있지만, 이것이 어떻게 가능한지 좀 더 깊이 살펴봅시다.

vSphere 네이티브 포드 속도가 더 빠른 이유

이러한 이점은 주로 ESXi가 올바른 CPU에서 기본적으로 실행되는 포드를 더 잘 스케줄링해서, 더 나은 지역화(localization)를 제공하여 원격 메모리 액세스 수를 크게 줄임으로써 얻을 수 있다. ESXi CPU 스케줄러는 파드가 독립적인 엔티티라는 것을 알고 있으며, 메모리 액세스가 각 로컬 NUMA(비일체 메모리 액세스) 도메인 내에 있는지 확인하기 위해 많은 노력을 기울인다. 따라서 파드 내부에서 실행되는 워크로드의 성능이 향상되고 전체 CPU 효율성이 향상된다. 반면에 Linux의 프로세스 스케줄러는 NUMA 도메인 간에 동일한 수준의 격리를 제공하지 않을 수 있다.

vSphere 네이티브 포드의 성능 평가

테스트 설정

성능을 비교하기 위해 2.2GHz 및 512GB의 메모리에서 44개의 코어가 실행되는 동일한 하드웨어에 대해 그림 1에 표시된 테스트베드를 설정했다.

  • 두 개의 ESXi Kubernet 노드가 있는 Project Pacific 기반 vSphere Supervisor 클러스터
  • 기본 제공 설정을 지원하는 2노드 베어메탈 상의 인기 엔터프라이즈 리눅스 클러스터

pp-fig01.png

그림 1: 테스트된 구성

일반적으로 하이퍼스레드 프로세서 코어는 하드웨어 리소스를 공유하는 여러 개의 논리적 코어(하이퍼스레드)를 가지고 있다. 기준사례(테스트베드 2)에서 사용자는 CPU 리소스 요청과 각 포드의 최대 논리적 코어 수를 지정한다. 반면 vSphere Supervisor 클러스터에서는 물리적 코어 수에 따라 파드의 CPU 리소스 규격이 지정된다. CPU 리소스 규격의 이러한 차이를 감안하여 이 비교 실험을 단순화하고 동일한 포드 사양을 사용할 수 있도록 두 테스트 베드에서 하이퍼스레딩을 비활성화했다. 각 클러스터에서는 2개의 Kubernetes 노드 중 하나를 테스트 대상 시스템으로 사용하며, 다른 노드에서 Kubernetes Master가 실행되고 있다.

벤치마크 구성

pp-fig02.png

그림 2: 포드 구성

  • 그림 2와 같이 표준 Java 트랜잭션 벤치마크를 실행하는 각 장치에 각각 8개의 CPU, 42GB RAM 및 단일 컨테이너로 구성된 10개의 Kubernetes 파드를 배치한다. 우리의 실험에 사용된 작업부하의 복잡성과 특성을 고려할 때, 우리는 이 실험을 위해 큰 파드를 사용해 파드에 걸친 관리 및 점수 집계를 용이하게 했다.
  • 파드는 파드의 사양을 사용해 각 테스트 베드의 대상 쿠버네티스 노드에 삽입된다.
  • 시험 대상 시스템의 성능을 평가하기 위해 10개의 파드 전체에 걸쳐 집계된 벤치마크 점수(최대 처리량)를 사용한다. 벤치마크 처리량 점수는 10ms, 25ms, 50ms, 75ms 및 100ms의 다양한 서비스 수준 계약 목표에서 트랜잭션 지연에 민감하다.
  • 사용된 벤치마크는 입출력이나 네트워크 활동이 거의 없고, 모든 실험은 하나의 쿠버네티스로 제한된다. 따라서 이 글에서 I/O나 네트워크 성능 측면에 대해서는 논의하지 않는다.
결과

그림 3은 널리 사용되는 엔터프라이즈 Linux 기반 베어메탈 노드 사례를 기반으로 표준화된 vSphere Supervisor Cluster(녹색 막대)의 성능을 보여준다.

베어메탈 엔터프라이즈 Linux에 비해 vSphere Supervisor 클러스터에서 8% 향상된 성능

pp-fig03-1024x295.png

그림 3: 베어메탈 엔터프라이즈 Linux와 비교한 vSphere Supervisor 클러스터의 하드웨어 카운터 데이터

 vSphere Supervisor Cluster가 베어메탈 사례에 비해 전체 Aggregate 성능을 최대 8%까지 향상할 수 있다고 본다. 우리는 run-to-run 편차를 평균화하기 위해 각 테스트 베드에 대해 여러 번 반복했다.

분석 및 최적화

시스템 통계를 보면 베어메탈 테스트베드에서 실행 중인 워크로드가 vSphere Supervisor Cluster 사례와 비교하여 많은 원격 NUMA 노드 메모리 액세스로 인해 어려움을 겪고 있음을 알 수 있다. vSphere Supervisor Cluster의 성능은 CPU 스케줄링 개선을 포함하지만 가상화의 성능 오버헤드를 포함하기도 한다.

보다 심도 있는 통찰력을 얻기 위해 동일한 작업 부하를 일정한 처리량으로 실행하고, 두 테스트 베드에 대한 하드웨어 성능 카운터 데이터를 수집하여 로컬 D램과 원격 D램의 최종 레벨 캐시(L3) 누락 비율을 확인했다. 로컬 DRAM 액세스는 원격 DRAM 액세스에 비해 메모리 액세스 지연 시간이 훨씬 더 낮다.

그림 4와 같이 로컬 DRAM에서 발생한 L3 misses hit는 절반 정도고, 나머지는 베어메탈 엔터프라이즈 리눅스의 경우 원격 메모리가 제공한다. 그러나 vSphere Supervisor 클러스터의 경우 ESXi에서 CPU 스케줄링이 뛰어나 로컬 DRAM에서 동일한 파드 및 워크로드 구성에 대해 L3의 99.2%가 missed hit. 원격 메모리 액세스를 방지함으로써 메모리 액세스 지연 시간이 낮아지는 것은 vSphere Supervisor 클러스터의 성능 향상에 기여한다.

Linux에서 절반 정도의 L3 misses hit가 발생 vs Project Pacific에서 대부분 적중

pp-fig04-1024x303.png

그림 4: 베어메탈 엔터프라이즈 Linux와 vSphere Supervisor 클러스터의 하드웨어 카운터 데이터

Linux에서 비로컬 NUMA 액세스의 영향을 완화하기 위해 NUMA 밸런싱 스위치를 전환하고, 작업세트 기반의 파드를 CPU에 고정하는 것과 같은 기본적인 최적화를 시도했지만 이 중 어느 것도 성능에 크게 도움이 되지 않았다. 로컬 NUMA 할당을 강제하고 이러한 NUMA 도메인에 속하는 CPU에서 프로세스가 실행되도록 하는 numactl 기반의 컨테이너 피닝이 도움이 된 최적화 중 하나였다. 그러나, 조사를 돕기 위한 현시점에서의 일회적인 해결책일 뿐이다.

그림 5의 차트는 베어메탈 엔터프라이즈 리눅스 테스트베드에 있는 numactl 기반 고정(pin)을 사용하여 달성할 수 있는 개선을 보여준다.

베어메탈 엔터프라이즈 리눅스의 파드 고정으로 17% 향상된 성능

pp-fig05-1024x292.png

그림 5: 베어메탈 엔터프라이즈 Linux의 성능에 대한 NUMA 지역성 향상

이와 같은 고정 관행이 규모에 따라 컨테이너를 배치할 때는 실용적이지 않으며, 이질적인 하드웨어에 걸쳐 오류가 발생하기 쉽다. 이 실험을 위해 파드 내부의 워크로드의 메모리 사용량에 대한 적절한 구성을 선택했으며, 결과는 이러한 설정에만 한정된다. 워크로드가 메모리 강도가 높거나 낮을 경우 NUMA 지역성이 성능에 미치는 영향은 달라질 것으로 예상된다.

결론 및 향후 작업

이 테스트에서는 메모리 바인딩 워크로드를 실행하는 대형 파드가 Project Pacific 기반의 vSphere Supervisor Cluster에서 vSphere 네이티브 파드로 배포될 때 NUMA 동작과 우수한 성능을 보인다는 것을 보여 준다. 메모리 바인딩되지 않은 다른 워크로드에 미치는 영향을 탐색하지 않았으며, 다른 포드 크기를 테스트하지도 않았다. 향후 작업으로, 소형 포드를 포함한 다양한 포드 크기의 스펙트럼으로 테스트하고 I/O 및 네트워크 활동이 더 많은 다른 워크로드를 시도하고자 한다.

Disclaimer

여기에 제시된 결과는 현재 개발 중인 제품에 근거한 예비 결과물이다. 결과는 환경에 적용되지 않을 수 있으며 반드시 모범 사례를 나타내지는 않는다.

 

구강사의 간단 요약

  • NUMA 환경(실험에 사용한 워크로드)에서 Linux 보다 ESXi가 더 뛰어난 스케줄링 성능을 보인다.
  • 성능향상에서 Locality는 30년 전이나 지금이나 변함 없이 중요하다.
  • 칩렛(chiplet), COD(Cluster On Die)와 같은 CPU 아키텍처하에서 NUMA 스케줄링은 무엇 보다 중요한 요소다
  • 메모리(DRAM)은 CPU에 비하면 여전히 느린 존재다. 그래서 캐시 적중률이 성능에 미치는 영향이 크고, 이걸 끌어올리려면 NUMA 스케줄링을 잘해야하는 것이다.