Red Hat Blog를 보다가 관심 가는 글이 보여서 AI번역+약간 교정해 보았습니다.
출처: https://www.redhat.com/en/blog/performance-and-energy-consumption-comparing-cpu-virtualization-and-emulation-efficiency
최근, 직장용 노트북의 하드웨어를 새로 교체해야 했고 Linux가 설치된 ARM 기반 노트북(MacBook)으로 교체하려고 했습니다. 이때 CPU 가상화 와 에뮬레이션의 효율성을 비교하는 작업을 맡게 되었습니다.
이 글에서는 가상화와 에뮬레이션에서 실행되는 작업 부하의 성능과 전력 소비를 비교한 연구와 벤치마크 데이터를 소개합니다.
우리는 흥미로운 시대에 살고 있습니다. x86 아키텍처가 수년간 시장을 장악했지만, 새로운 경쟁자들이 등장했습니다. Amazon은 몇 년 전부터 ARM 기반 CPU 설계를 사용하는 Graviton 인스턴스를 제공해 왔습니다. 이 인스턴스는 x86 인스턴스에 비해 가격 경쟁력이 있습니다. CPU는 2000년대부터 하드웨어 가상화를 지원하는 가상 머신(VM)을 널리 지원해 왔지만, 이는 동일한 CPU 아키텍처의 VM으로 제한되었습니다. 다른 CPU 아키텍처의 VM을 실행하려면 에뮬레이션이라는 프로세스를 통해 더 많은 소프트웨어 개입이 필요합니다.
에뮬레이션 대신 가상화를 사용하는 가장 널리 알려진 이유는 성능 때문입니다. 하지만 성능과 전력 소비에 정확히 어떤 영향을 미칠까요? “aarch64 시스템에서 x86 문제를 재현하고 싶습니다” 또는 “이 오래된 애플리케이션을 실행해야 합니다”와 같은 사용 사례에서는 성능이 그다지 중요하지 않습니다. 네이티브(베어 메탈 또는 가상화된) 리소스에 액세스할 수 없는 경우, 에뮬레이션이 적절한 대안이 될 수 있습니다.
지원 엔지니어들은 수년간 가상화를 활용하여 작업을 더욱 편리하게 만들어 왔습니다. 중첩된 커널 기반 가상 머신(KVM)을 사용하면 “게스트 온 게스트”를 실행할 수 있습니다. 이를 통해 테스트를 위해 OpenStack 및 OpenShift 환경을 복제할 수 있습니다.
오늘날의 기술
Red Hat Enterprise Linux(RHEL) 8, 9, 10부터 고객은 KVM과 함께 QEMU를 사용하여 가상화된 게스트를 실행할 수 있습니다. 이를 통해 고객은 CPU 명령어가 호스트 시스템의 CPU에서 직접 실행되는 게스트 운영 체제를 실행할 수 있습니다. 이러한 설정에서는 네트워크 인터페이스 카드(NIC)와 같은 추가 하드웨어를 에뮬레이션할 수 있습니다.
Fedora에서는 일반 저장소를 통해 다른 아키텍처의 에뮬레이션을 사용할 수 있습니다. 예를 들어, aarch64 Fedora 저장소에는 qemu-system-x86_64가 있어 x86_64 아키텍처의 게스트를 에뮬레이션할 수 있습니다.
측정 설정
QEMU 에뮬레이션 패키지는 일반 저장소에서 편리하게 설치할 수 있으므로, 측정을 위해 Fedora를 호스트로 사용할 수 있습니다. 패키지 구성 요소는 다음과 같습니다.
- Performance Co-Pilot (PCP): PCP는 전력 소비량 지표를 제공합니다. 이 지표는 보관 파일에 저장되어 사용자가 직접 평가할 수 있습니다.
- Python 3 래퍼 스크립트: 이 스크립트는 프레임워크를 제공하여 하나의 스크립트를 실행하여 전력 소비 모니터링을 제어하고 가상화/에뮬레이션 게스트에서 작업 부하를 실행할 수 있도록 합니다.
- Ansible 플레이북: 게스트에 테스트 스크립트를 배포하고 필요한 패키지를 설치하는 데 사용됩니다.
- ‘bzip2’: ‘bzcat’은 데이터를 압축 해제하고 이를 CPU 기반 작업 부하로 사용하는 데 사용됩니다.
가장 흥미로운 리소스 세 가지는 CPU 컴퓨팅, I/O, 그리고 네트워크 처리량입니다. 대부분의 워크로드에 가장 큰 영향을 미치는 CPU 컴퓨팅 리소스는 ‘bzip2’를 사용하여 처리했습니다. 성능 외에도 소비 전력도 중요합니다.
이 기사 에서는 기본적인 전력 측정 설정에 대해 읽어보세요 .
에뮬레이션된 CPU 성능을 비교해 보자
이제 CPU 성능에 대해 살펴보겠습니다. 실제 작업 부하의 예로, 압축 파일 추출을 살펴보겠습니다.
루프에서는 httpd-2.4.57.tar.bz2 파일을 최대한 여러 번 추출합니다. 루프를 한 번 실행하면 CPU 하나만 사용하므로 여러 개의 병렬 루프를 사용하여 테스트할 수도 있습니다.
프로그램 워크플로를 보여주는 통합 모델링 언어(UML) 다이어그램:
에뮬레이션된 게스트에서 이러한 테스트를 실행한 후 결과를 시각화할 수 있습니다.
다양한 에뮬레이션 시스템에서 추출 성능을 보여주는 그래프
이러한 시스템 대부분은 에뮬레이션된 x86_64 시스템과 에뮬레이션된 aarch64 시스템 하나와 함께 실행됩니다. 모든 시스템에는 4개의 가상 CPU가 있으며, 모두 Fedora를 실행하는 aarch64 호스트 시스템에서 에뮬레이션됩니다. y축은 httpd-2.4.57.tar.bz2 파일이 5분 동안 압축 해제된 횟수를 나타냅니다. 이러한 모든 시스템에서 병렬 실행 중인 추출 루프 수와 완료된 추출 작업 수가 증가하여 최대 4개의 병렬 루프가 생성됩니다. 루프가 8개로 늘어나면 CPU당 루프가 1개만 존재하게 되고, 완료된 전체 작업 수가 감소합니다.
위의 빨간색과 검은색 선은 RHEL 7.9에서 “-cpu qemu64″와 “-cpu max” 옵션을 사용하여 에뮬레이션한 결과를 보여줍니다. 이 두 가지 옵션은 그래프에서 에뮬레이션된 모든 시스템 중 가장 높은 성능을 보여줍니다.
y 축척은 더 나은 가시성을 위해 로그로 표현됩니다. 다른 에뮬레이션된 아키텍처는 거의 비슷한 성능을 보입니다. 이들은 Haswell, Icelake 또는 Broadwell과 같은 최신 칩셋을 에뮬레이션합니다. 이러한 에뮬레이션된 CPU는 x86_64-v2 또는 -v3 ABI 사양을 지원합니다. RHEL 9는 x86_64-v2를, RHEL 10은 x86_64-v3를 요구합니다. 최신 RHEL을 v2/v3 ABI에 최적화하면 Linux 배포판에서 최신 CPU를 더 잘 활용할 수 있습니다. 에뮬레이션된 CPU에서 최신 RHEL 버전을 실행할 때 QEMU는 이러한 CPU 기능을 에뮬레이션해야 하므로 성능 차이가 발생합니다.
CPU를 에뮬레이션할 때 QEMU 매개변수(“-cpu max”)를 사용하여 에뮬레이션된 CPU에서 사용 가능한 모든 기능을 활성화할 수 있습니다. 이를 통해 최상의 호환성(RH EL7과 RHEL 10 모두 실행 가능)을 확보하고 에뮬레이션된 시스템의 성능을 극대화할 수 있습니다. QEMU 및 CPU 구성에 대해 자세히 알아보세요.
최상의 CPU 플래그 및 성능 호환성을 위해 “-cpu max”를 사용하는 것이 좋습니다.
가상화와 베어메탈은 어떤가요?
가상화 결과는 다음과 같습니다.
aarch64 호스트에서 에뮬레이트된 시스템에서 완료된 추출 작업을 보여주는 그래프
이 워크로드에 대한 가상화와 베어 메탈 성능은 상당히 유사하며 에뮬레이션보다 훨씬 뛰어납니다. 가장 빠르게 에뮬레이션된 게스트보다 4배 더 많은 추출 작업을 완료합니다. 이는 가상화가 기업에서 널리 사용되고 절대적으로 필요한 경우에만 게스트를 에뮬레이션하는 이유를 보여줍니다.
그래프 오른쪽의 8개 스레드는 가상 게스트(녹색)가 4개의 코어로 총 추출 수를 더 이상 증가시키지 않음을 보여줍니다. 베어 메탈 시스템(연한 파란색)은 10개의 코어를 가지고 있으므로 4개 스레드 이상으로 확장 가능합니다.
x86_64 호스트 시스템을 사용하면 동일한 패턴이 나타납니다. 베어 메탈에서 가장 좋은 성능을 내고, 가상화된 x86_64 게스트에서는 성능이 약간 떨어지고, 모든 아키텍처의 에뮬레이트된 게스트에서는 성능이 훨씬 낮아집니다.
x86_64 호스트에서 에뮬레이트된 시스템에서 완료된 추출 작업을 보여주는 그래프
추출 작업당 얼마나 많은 에너지가 사용됩니까?
Performance Co-Pilot을 사용하면 작업 실행 중 전체 시스템의 에너지 소비량을 측정할 수 있습니다. 전체 소비량을 완료된 작업 수로 나누면 단일 추출 작업당 소비량을 구할 수 있습니다.
단일 비압축 작업에 사용되는 에너지를 보여주는 그래프
가상화를 사용하면 더 많은 에너지를 소모하지 않고도 더 많은 비압축 작업을 수행할 수 있으므로, 단일 비압축 작업당 소비량이 줄어듭니다.
마지막 생각
컴퓨팅과 시스템은 오랜 역사를 가지고 있습니다. 기존 시스템의 에뮬레이션은 앞으로도 중요한 주제이며, 앞으로도 그럴 것입니다.
고려해야 할 또 다른 세부 사항은 에뮬레이션된 CPU의 정확성입니다. 에뮬레이션 코드는 CPU 아키텍처 사양 준수 여부에 대한 공식적인 검증을 거치지 않기 때문에 사용자는 미묘한 버그에 직면할 수밖에 없습니다. 특히 다중 vCPU 사용 환경에서는 동시 실행이 물리적 CPU 특성과 일치하지 않아 문제가 가려지거나 잘못된 문제가 노출될 수 있어 문제가 심각해질 수 있습니다. 논리 회로가 알려진 구형 CPU의 경우, 일부 FPGA(Field Programmable Gate Array)를 사용하여 기존 CPU와 유사한 기능을 구현하고 있습니다.
에뮬레이션 대비 가상화의 또 다른 이점은 보안입니다. QEMU는 에뮬레이션 사용 시 호스트와 게스트 간에 보안 경계를 설정하지 않습니다 . 에뮬레이션 시나리오에만 관련된 기능의 버그는 CVE 발급 대상으로 간주되지 않습니다.
CPU 기반 워크로드에 대해 에뮬레이션된 시스템과 가상화된 시스템의 성능을 비교했습니다. 가상화된 시스템은 성능이 훨씬 우수했고 작업당 에너지 소비도 훨씬 적었습니다. 하지만 에뮬레이션이 합리적이고 성능 저하가 크지 않거나, 기존 하드웨어를 더 이상 사용할 수 없는 경우에도 에뮬레이션이 효과적일 수 있습니다. 여러 아키텍처의 하이퍼바이저를 사용하는 Red Hat OpenShift 및 Red Hat OpenStack 환경을 활용하여 적합한 유형의 시스템에서 가상화를 구현할 수 있습니다.
