클라우드 서버 메모리 대역폭을 어떻게 측정하나요? 초과 판매와 허위 표기 간파하기

교차 감사 방법으로 메모리 대역폭 허위 표기를 간파하세요

업데이트됨 2026-08-12 · CloudWorth

메모리 대역폭벤치마크 테스트오버셀링 감지FinOpsCloudWorthSteal TimeVPS 오버셀링VPS 점검

메모리 대역폭 테스트는 Steal Time 및 Cache 절벽과 결합하고, FinOps 프리미엄 비율로 실제 가격 대비 성능을 확정해야 합니다.

벤치마크 방법: STREAM과 mbw

클라우드 서버 메모리 대역폭을 측정할 때 가장 자주 사용하는 도구는 STREAM과 mbw입니다. STREAM은 이론적 최대치에 가깝고 하드웨어 세대를 확인하는 데 적합하며, mbw는 실제 읽기/쓰기 부하에 더 가깝고 특히 Docker/K8s 컨테이너 환경에 적합합니다. 명령은 간단합니다:

# STREAM（需编译）
gcc -O3 -fopenmp stream.c -o stream
./stream

# mbw（apt/yum均可装）
mbw -n 8 512

하지만 숫자만 보고 성급히 결론을 내리지 마세요. 클라우드 서버 메모리 대역폭 측정의 함정은 바로 가상화 계층에 있습니다. 측정 전에 /proc/stat의 steal time을 먼저 확인하세요. 연속 샘플링이 2%를 초과하면 물리 CPU가 이웃에게 빼앗긴 것이며, 이때 측정된 대역폭은 확실히 낮아집니다. 또한 cache 급락도 확인하세요. 테스트 배열을 점점 늘려가면서 대역폭이 특정 지점에서 갑자기 1/3 이하로 떨어진다면 L3 캐시가 제한되거나 경합 중일 가능성이 높습니다.

핵심을 말하자면, 공칭 값과 실측 값이 얼마나 차이가 나야 '허위 표기'라고 할까요? 저는 메모리 대역폭을 'GiB당 가격'으로 환산한 뒤, 동일 구성의 베어메탈 참조 값과 비교하여 FinOps 프리미엄 비율을 계산합니다. 프리미엄 비율이 30%를 초과하는데 대역폭이 이론 값의 절반에 불과하다면 기본적으로 과판매 또는 세대 축소로 판단할 수 있습니다. 이것이 CloudWorth 교차 감사의 접근 방식입니다 — 실제 시나리오 벤치마크로 가성비를 확정. 전체 비교 템플릿은 뒤의 작은 북마크에 넣어 두었습니다. 먼저 한 가지 원칙을 기억하세요. 벤치마크가 목적이 아니라 '가성비의 변곡점'을 파악하는 것이 목적입니다.

허위 스펙 식별: Steal Time 및 Cache

STREAM이나 mbw의 예쁜 숫자를 보고 먼저 기뻐하지 마세요. 클라우드 서버에서 가장 치명적인 것은 단일 대역폭이 낮은 것이 아니라 "겉으로는 높아 보이지만 압력을 가하면 무너지는" 것입니다. 저는 세 가지를 교차 테스트하는 습관이 있습니다: 메모리 대역폭, Steal Time, Cache 히트율. 특히 mbw 실행 후 /proc/stat의 steal 값을 확인하세요. 지속적으로 10%를 초과하면 호스트 CPU가 심각하게 오버커밋된 것이며, 구매한 "vCPU"가 이웃과 코어를 다투고 있을 수 있습니다. 메모리 대역폭 테스트 결과가 거짓으로 높아지거나 변동에 가려질 수 있습니다.

진짜 킬러는 Cache 단절입니다. stream으로 다양한 배열 크기를 테스트할 때, 8MB에서 16MB로 넘어갈 때 대역폭이 60% 이상 급락한다면, L3가 분할되었거나 인스턴스가 구형 CPU 세대로 강등되었음을 사실상 단정할 수 있습니다. 예를 들어, 어떤 IPO 회사가 "고주파 메모리"를 주장하지만 실제 테스트 결과는 자사 보급형보다도 못한 경우, CloudWorth의 프리미엄율 공식으로 계산해야 합니다: (실제 성능/명목 성능) ÷ (가격/동급 평균 가격), 0.7 미만이면 과감히 반품하세요.

컨테이너에서 테스트할 때도 주의해야 합니다. Docker는 기본적으로 커널을 공유하며, mbw는 cgroup 제한의 영향을 받습니다. 가능하면 --cpuset-mems로 NUMA 노드를 바인딩한 후 테스트하는 것이 좋습니다. 그렇지 않으면 결과는 그저 재미로만 볼 수 있습니다. 실제 AI 추론 시나리오를 재현하려면, pytorch로 미니 배치 행렬 곱셈을 직접 실행하여 물리 머신 베이스라인과 비교하는 것이 어떤 벤치마크 도구보다 실질적입니다.

FinOps 프리미엄 비율: 진짜 가성비

클라우드 서버 메모리 대역폭 테스트에서 가장 두려운 것은 정확히 측정되지 않는 것이 아니라, 측정 후에 어떻게 계산해야 할지 모르는 것입니다. 앞의 두 섹션의 Steal Time과 Cache 절벽은 본질적으로 같은 질문에 답하고 있습니다: 당신이 지불한 돈으로 구매한 것이 '명목 구성'인지 '실제 컴퓨팅 성능'인지? 이제 이 두 지표와 대역폭 테스트 결과를 합쳐서, 각 인스턴스에 대해 'FinOps 프리미엄 비율'을 계산합니다. 공식은 간단합니다: 프리미엄 비율 = 실측 대역폭 ÷ 명목 이론 대역폭 ÷ 단가. 비율이 높을수록 단위 투자 대비 얻는 대역폭이 더 실질적임을 의미하고, 반대라면 전형적인 '사양 부풀리기'입니다.

방금 IPO 상장을 하고 주가가 하루 만에 42% 급등한 후 사과한 클라우드 업체의 인스턴스를 예로 들어보겠습니다: 명목 사양 8코어 16G, 이론 메모리 대역폭 약 40GB/s(DDR4 듀얼 채널 추정). mbw로 fixed 모드를 실측한 결과 17GB/s에 불과했고, 동시에 5%의 Steal Time이 동반되었으며, Cache 절벽은 4MB에서 나타났습니다(L3에 있어야 할 16MB가 아니라). 같은 시기에 다른 유명 클라우드 업체의 동일 사양 인스턴스는 가격이 18% 비싸지만, 실측 대역폭은 32GB/s에 달했고 Steal Time은 거의 0이었습니다. 계산하면 전자의 프리미엄 비율은 0.43에 불과하고, 후자는 0.81입니다. 싼 인스턴스가 오히려 '비싼' 것입니다.

이것으로 끝이 아닙니다. 테스트를 컨테이너 환경으로 내려서 Docker에서 STREAM을 실행할 때, cgroup의 CPU 할당량이 메모리 대역폭을 조용히 제한한다는 것을 발견했습니다. 특히 멀티코어 시나리오에서 mbw 결과가 실제보다 높게 나올 수 있습니다. 그래서 제 교차 감사 방법에서는 모든 대역폭 테스트가 컨테이너 내부 시간과 외부 시간을 동시에 기록하고, FinOps 프리미엄 비율로 정규화합니다. 이렇게 하면 KVM이든 Xen이든, 오버커밋 여부와 관계없이 비교 가능한 가격 차원으로 끌어올릴 수 있습니다.

마지막으로 한 가지 덧붙이자면, '실시간 과금'이나 '탄력적 확장'을 맹신하지 마세요. 그것들은 단지 청구서의 친절함일 뿐입니다. 진짜 가성비는 mbw -b 256을 실행하고 CloudWorth의 Cache 절벽 보고서와 대조하여 각각의 프리미엄 비율을 계산한 다음, 그 '싼' 머신을 끄는 것입니다. 메모리 대역폭은 거짓말을 하지 않습니다. 청구서가 거짓말을 합니다.