Red Hat Blog를 보다가 관심 가는 글이 보여서 AI번역+약간 교정해 보았습니다.
출처: https://developers.redhat.com/articles/2025/04/28/boost-openshift-database-vm-density-memory-overcommit
가상화 플랫폼은 워크로드 통합에 사용되며, 가상화 플랫폼에서 리소스를 초과 구독하는 것은 흔한 일이 아니지만, 가상화 호스트가 호스트가 제공할 수 있는 것보다 더 많은 리소스를 필요로 하는 가상 머신을 갖게 되는 경우가 있습니다. 이러한 상황은 클러스터 내 일부 호스트의 계획된 다운타임이나 호스트의 계획되지 않은 중단 시 발생할 수 있으며, 이러한 호스트의 가상 머신은 정상 작동하는 호스트에 있을 가능성이 높습니다.
이러한 경우, 플랫폼이 장애 없이 성능에 미치는 영향을 최소화하면서 추가 가상 머신을 유지할 수 있어야 비즈니스 연속성을 유지하는 것이 매우 중요합니다. wasp-agent를 사용하면 작업자 노드에 스왑 리소스를 할당하여 메모리 오버커밋을 용이하게 할 수 있습니다. 또한 높은 스왑 I/O 트래픽이나 높은 사용률로 인해 노드의 위험이 높은 경우 파드 제거를 관리합니다. 높은 트래픽에 대한 임계값은 구성 가능합니다. 자세한 내용은 제품 설명서의 Configuring higher VM workload density을 참조하십시오.
Red Hat OpenShift Virtualization이 메모리 초과 구독을 처리하는 방식
이 글에서 다룰 연구는 Red Hat OpenShift Virtualization 플랫폼이 호스트가 과도하게 구독된 경우에도 별도의 튜닝 없이 워크로드 연속성을 유지할 수 있음을 보여줍니다. 성능에 미치는 영향은 워크로드에 따라 달라지는데, 이는 예상된 결과입니다.
본 연구에서는 네 가지 데이터베이스를 평가했습니다. MariaDB와 Postgres는 Red Hat Enterprise Linux 배포판에 포함된 오픈소스 데이터베이스입니다. 나머지 두 데이터베이스는 Microsoft SQL Server와 Oracle입니다.
이 연구는 메모리 초과 구독(oversubscription)에 초점을 맞추었는데, 이는 매우 심각한 시스템 중단을 초래하는 것으로 나타났습니다. 메모리 초과 구독은 성능에 막대한 영향을 미칠 뿐만 아니라, 경우에 따라 OOM 킬러 프로세스에 의해 가상 머신(VM)이 종료되는 결과를 초래합니다. 이는 일반적으로 메모리 사용률이 시스템 한도를 초과할 때 발생합니다. 호스트에 스왑을 프로비저닝하면 이러한 상황을 방지하고 워크로드를 계속 실행할 수 있지만, 성능에 어느 정도 영향을 미칠 수 있습니다. 성능에 미치는 영향의 정도는 워크로드의 특성에 따라 달라집니다.
테스트 환경
본 연구에 사용된 호스트는 각각 16코어, 2.10GHz Intel Xeon Gold 6130 CPU 2개가 장착된 Dell PowerEdge R740XD로, 총 64개의 CPU와 192GB 메모리를 사용했습니다. VM은 vCPU 6개와 각각 20GB 메모리를 사용했습니다. 테스트에서는 각 VM이 데이터베이스 워크로드를 포화 상태까지 실행해야 했으며, 성능 영향을 분석하는 데 분당 트랜잭션(TPM) 지표를 사용했습니다.
TPM은 성능 추적에 사용되었지만, 데이터베이스 간 비교를 위해 수치는 공개되지 않았습니다. 데이터베이스는 다양한 하위 시스템에 부하를 주기 위해 실행에 맞춰 조정되지 않았으며, 수치를 공개하면 테스트 중인 데이터베이스의 성능 특성에 대한 혼란만 야기할 것입니다.
호스트가 초과 구독될 때까지 각 실행 시 VM 수를 늘렸고, 각 실행에 대한 총 TPM을 측정하여 차트로 추적했습니다. 표 1은 각 실행의 VM 수와 총 메모리 및 CPU 사용량을 보여줍니다.
| VM 수 | 1 | 2 | 4 | 8 | 12 |
|---|---|---|---|---|---|
| 총 vCPU | 6 | 12 | 24 | 48 | 72 |
| 총 메모리(G) | 20 | 40 | 80 | 160 | 240 |
마지막 열은 실행에 사용된 총 메모리가 240G, 즉 25%의 초과 구독이고, 총 CPU는 72, 즉 12.5%의 초과 구독임을 보여줍니다.
테스트 대상 시스템은 OpenShift 4.17.5 클러스터 구성 요소 전체를 실행했습니다. 사용된 스토리지는 VM 디스크 이미지용으로 단일 LVMCluster로 스트라이프된 1.5TB NVMe 3개였습니다. 스왑은 별도의 NVMe 장치에 구성되었습니다.
작업량 개요
HammerDB 는 모든 데이터베이스에 대한 데이터베이스 부하 테스트를 구동하는 데 사용되는 벤치마킹 도구로, 총 “인스턴스” 수를 확장하여 달성할 수 있는 총 TPM(분당 트랜잭션) 처리량 값에 중점을 둡니다. 클라이언트-서버 쌍은 각 데이터베이스 부하를 구동하기 위해 동일한 VM에 포함되었습니다.
Linux VM은 20GiB 메모리와 6개의 vCPU로 구성되었으며, 그 외에는 기본 템플릿 설정을 사용했습니다.
스케일링 연구
확장성 연구를 위해 유의미한 작업 부하를 나타내기 위해 사용자 부하(즉, 스레드 수) 40을 선택했습니다. HammerDB는 합성 벤치마크 도구로, 각 사용자가 슬립 지연 없이 최대한 빠르게 트랜잭션을 입력하기 때문에 사용자 수가 최대 용량을 나타내는 것은 아닙니다. 각 데이터베이스에 대해 표 1과 같이 VM을 가동하고 각 실행에 대한 TPM을 수집했습니다. 각 데이터베이스의 동작 방식이 다르므로 각 데이터베이스의 데이터를 개별적으로 살펴보겠습니다.
MariaDB
MariaDB의 경우, 데이터베이스 버퍼 풀은 각 VM의 VM 메모리의 50%로 설정되었습니다. MariaDB는 directIO를 사용하므로 VM의 메모리 사용량은 용량보다 훨씬 낮습니다. 이 테스트에서는 VM의 활성 메모리가 스왑되지 않으므로 성능 저하가 크지 않을 것으로 예상했습니다. 데이터는 그림 1에 나와 있습니다.
호스트에 VM이 추가됨에 따라 총 TPM이 매우 원활하게 확장되는 것을 확인했습니다. 호스트는 VM 8개에서 포화 상태에 도달했습니다. VM 수가 12개로 증가했을 때 메모리는 25%, CPU는 12.5% 초과 할당되었지만 성능 저하가 발생하지 않았습니다.
Microsoft SQL Server
SQL Server의 경우, 데이터베이스에 대한 메모리 값을 명시적으로 설정하지 않습니다. 기본적으로 SQL Server는 VM 메모리의 80%를 사용합니다. 모든 VM의 활성 메모리 중 일부는 호스트의 스왑 디스크로 푸시되지만, 초과 구독 시나리오에서 상당한 성능 저하가 관찰되지 않았습니다. 그림 2를 참조하십시오.
Oracle
Oracle의 경우, 각 VM에서 총 시스템 글로벌 영역(SGA) 크기를 VM 메모리의 75%로 설정했습니다. Oracle은 directIO를 사용하므로 VM의 메모리가 완전히 사용되지는 않지만, SGA에 75%를 사용하므로 VM 메모리는 90% 범위 내에서 사용됩니다(그림 3). 따라서 메모리를 초과 구독하면 이 테스트에서 성능이 13% 저하됩니다.
Postgres
Postgres의 경우, 각 VM에서 데이터베이스 버퍼 풀이 VM 메모리의 50%로 설정되었습니다. 하지만 Postgres 데이터베이스에 익숙한 사람이라면 Postgres가 버퍼 풀 외에도 시스템 파일 캐시를 사용한다는 것을 알고 있을 것입니다. 이로 인해 VM의 전체 메모리가 소모됩니다. 이 메모리 소모는 매개변수 effective_cache_size를 사용하여 제어할 수 있습니다. 그러나 이 테스트에서는 의도적으로 모든 메모리를 소모하도록 설정하지 않았습니다. 이는 성능과 VM 수가 증가함에 따라 TPM이 확장되는 방식에 상당한 영향을 미칩니다. 그림 4를 참조하십시오.
요약
본 연구에서 관찰한 바와 같이, OpenShift Virtualization 플랫폼은 호스트 리소스의 범위 내에서 VM에서 실행되는 다양한 워크로드에 대해 놀라운 확장성을 보여줍니다. 또한 다양한 워크로드에서 최대 25%의 메모리 초과 구독(oversubscription)을 매우 효과적으로 처리합니다. 초과 구독 중 성능에 미치는 영향은 VM 내 워크로드와 메모리 사용률에 따라 달라진다는 점을 언급할 필요가 있습니다.
부록: 시스템 구성
- CPU: Intel(R) Xeon(R) Gold 6130 x 2
- 16개 코어 x 2개 스레드, 총 64개 CPU
- 메모리: 192GiB RAM
- 테스트에 사용된 스토리지: 3x KIOXIA Corporation NVMe(각 1.5TB)
Wasp 구성은 호스트가 메모리를 초과 할당할 수 있도록 하는 데 중요한 부분입니다. WASP 설정 및 구성 방법을 알아보려면 Evaluating memory overcommitment in OpenShift Virtualization 문서를 참조하세요.
