이 글은 AVA Hosting에 대한 부정적인 리뷰를 쓰기 위한 것이 아닙니다.
개발자로 일하다 보면 흔히 겪는 하루 중 하나였습니다. 서버는 이상하게 느려졌고, 흔한 원인들은 맞지 않았으며, 결국 Linux가 무슨 일이 벌어지고 있는지 보여줬습니다.
제가 사용한 것은 AVA Hosting의 소형 KVM VPS였습니다.
1 vCPU
2 GB RAM
25 GB NVMe평범한 프로덕션 workload가 돌고 있었습니다. Nginx도 실행 중이었고 backend도 살아 있었습니다. 사용 가능한 메모리가 있었고 디스크도 가득 차지 않았습니다.
그런데 서버가 요청을 따라가지 못했습니다.
그래서 정상적인 프로덕션 트래픽 상태에서 60초 동안 수동적인 관찰을 진행했습니다. stress test, 인위적인 HTTP flood, disk benchmark는 실행하지 않았습니다.
결과는 다음과 같았습니다.
vCPU count: 1
Average CPU user: 52.52%
Average CPU system: 8.07%
Average CPU softirq: 6.69%
Average CPU steal: 32.73%
Average CPU iowait: 0.00%
Average CPU idle: 0.00%
Maximum runnable queue: 11핵심 숫자는 CPU steal 32.73%였습니다. 이 값을 본 뒤 진단 방향이 완전히 달라졌습니다.
왜 이 결과가 놀라웠나
AVA Hosting은 현재 VPS 상품을 “Guaranteed resources — no sharing”이라고 설명합니다. VPS 페이지에서는 fixed 또는 dedicated vCPU allocation을 언급하고, 다른 고객 때문에 성능이 영향을 받지 않아야 한다고 말합니다. Linux VPS 설명에서는 더 나아가 같은 호스트의 다른 tenant가 CPU-intensive workload를 실행하더라도 자신의 instance에 steal time을 발생시킬 수 없다고 합니다. 다른 페이지에서는 CPU steal이 hypervisor 수준에서 제거된다고 설명합니다.
상당히 구체적인 주장입니다. 단순히 1 vCPU라고만 적고 CPU 할당 방식은 설명하지 않는 VPS가 아닙니다. AVA는 Linux가 제 VM 내부에서 보고한 바로 그 종류의 CPU contention으로부터 보호된다고 명시적으로 광고하고 있었습니다.
CPU steal이 의미하는 것
steal은 가상화 환경에서 Linux가 제공하는 일반적인 CPU 지표입니다. guest에 실행 가능한 작업이 있었지만 virtual CPU가 실제로 실행되지 않았던 시간을 나타냅니다.
애플리케이션이 할당된 CPU를 모두 사용한 것과는 다릅니다. user/system이 약 100%, steal 0%, idle 0%였다면 단순히 workload에 더 많은 연산 성능이 필요하다고 판단했을 것입니다.
하지만 이번에는 CPU 시간의 약 3분의 1이 steal로 기록됐습니다.
guest 내부에서는 AVA의 hypervisor를 볼 수 없습니다. physical node 부하, 인접 VM 수, CPU pinning 정책, overcommit ratio도 알 수 없습니다. 확인할 수 있는 것은 Linux가 VM에 보고한 내용입니다. 실행할 작업이 기다리고 있는데도 vCPU가 반복해서 실행되지 않았습니다.
1초짜리 순간 스파이크가 아니었다
나쁜 CPU 샘플 하나만으로 결론을 내리지는 않았습니다. 그래서 60초 동안 연속으로 측정했습니다. stress test, 인위적인 HTTP flood, disk benchmark는 의도적으로 실행하지 않았습니다.
초당 샘플은 반복해서 다음과 같이 나타났습니다.
%usr %sys %soft %steal %idle
53.54 10.10 5.05 31.31 0.00
56.44 6.93 5.94 30.69 0.00
51.52 7.07 6.06 35.35 0.00
55.45 6.93 5.94 31.68 0.00
51.49 8.91 5.94 33.66 0.00
52.53 7.07 7.07 33.33 0.00
52.48 6.93 7.92 32.67 0.00관찰이 끝날 무렵에도 같은 패턴이 유지됐습니다.
50.98 10.78 6.86 31.37 0.00
48.48 8.08 9.09 34.34 0.00
55.00 5.00 7.00 33.00 0.00전체 평균은 다음과 같았습니다.
user: 52.52%
system: 8.07%
softirq: 6.69%
steal: 32.73%
iowait: 0.00%
idle: 0.00%즉, 짧은 scheduling anomaly가 아니었습니다. 측정한 1분 대부분에서 steal은 약 30% 이상을 유지했고 CPU idle은 계속 0%였습니다.
감각적으로 보면 1분의 32.73%는 약 19.64초입니다. VPS가 19.64초 동안 연속으로 멈췄다는 뜻은 아닙니다. vCPU가 schedule되지 않았던 짧은 구간들이 누적되어 그 정도가 됐다는 뜻입니다.
backend가 밀린 요청을 처리하지 못했다
CPU 문제는 애플리케이션 수준에서도 보였습니다. 측정 전 backend listen queue는:
Recv-Q: 168
Send-Q: 51160초 후:
Recv-Q: 166
Send-Q: 511168과 166이라는 정확한 숫자 자체가 중요한 것은 아닙니다. 중요한 점은 queue가 사실상 줄지 않았다는 것입니다. 애플리케이션은 1분 동안 따라잡을 기회가 있었지만 여전히 뒤처져 있었습니다.
CLOSE-WAIT 연결도 많았습니다. 다만 이 상태만으로 호스트를 탓하지는 않겠습니다. 애플리케이션 측 connection handling에서도 발생할 수 있기 때문입니다. 하지만 전체적인 그림은 일관됐습니다.
1 vCPU
32.73% steal
0% idle
~99% CPU pressure
elevated runnable queue
backend queue not draining서버는 살아 있었지만 정상적인 상태는 아니었습니다.
RAM과 디스크가 명확한 병목은 아니었다
일반적인 원인도 확인했습니다. 메모리 상태:
RAM total: ~1.9 GiB
RAM available: ~959 MiB
Swap total: 2 GiB
Swap used: ~33 MiB여전히 상당한 메모리가 사용 가능했고 이 현상을 설명할 명확한 OOM 이벤트도 없었습니다.
파일시스템:
24 GB total
14 GB used
9.4 GB available
60% used평균 CPU I/O wait는 0.00%였습니다. 반면 CPU pressure는 약 99%에 머물렀고 1-vCPU VM의 load average는 약 3.5~4, runnable queue는 최대 11이었습니다.
여러 측정값이 모두 같은 방향을 가리켰습니다. RAM이나 storage에 막힌 것이 아니라 CPU 실행 시간을 충분히 받지 못하고 있었습니다.
AVA의 설명과 실제 측정값의 모순
저는 이 부분이 가장 흥미롭습니다.
AVA는 “Guaranteed resources — no sharing”이라고 말합니다. 다른 고객 때문에 성능이 영향을 받지 않아야 한다고 합니다. Linux VPS 자료에서는 다른 tenant가 steal time을 발생시킬 수 없다고 하며, 다른 페이지에서는 CPU steal이 hypervisor 수준에서 제거된다고 설명합니다.
하지만 제가 받은 AVA VPS는 다음과 같았습니다.
Average CPU steal: 32.73%VM 내부에서 정확한 원인을 증명할 수는 없습니다. 의도적인 overselling을 입증할 수도 없고, 특정 인접 workload를 지목할 수도 없으며, AVA 호스트의 CPU 구성을 재구성할 수도 없습니다.
모든 AVA Hosting VPS가 이렇게 동작한다고 주장하는 것도 아닙니다. 제가 테스트한 것은 한 대입니다.
다만 제가 측정한 동작이 위와 같은 구체적인 CPU isolation 주장과 매우 맞추기 어렵다는 점은 말할 수 있습니다. 이 글에서는 그 정도면 충분합니다.
왜 업그레이드하지 않았나
가장 쉬운 대응은 vCPU를 더 구매하는 것이었을 겁니다.
steal이 거의 0%이고 애플리케이션이 단순히 한 core를 모두 사용하고 있었다면 업그레이드가 합리적이었을 것입니다. 하지만 관찰한 CPU 시간의 약 3분의 1이 steal이었습니다.
첫 번째 vCPU의 실행 시간 중 이렇게 큰 비율이 이미 unavailable로 기록되는 이유를 이해하지 못한 상태에서 추가 virtual CPU에 비용을 지불하고 싶지 않았습니다. 그래서 VPS를 취소하고 환불을 요청했습니다.
AVA는 전액을 빠르게 환불했다
이 부분은 좋은 경험이었습니다.
AVA Hosting은 전액을 환불했습니다. 처리도 빨랐고 CPU 측정값을 두고 며칠씩 논쟁하지 않았습니다. 문제를 설명하고 환불을 요청하자 그대로 돈을 돌려줬습니다.
이 점은 고맙게 생각합니다.
따라서 제 경험에서는 두 가지 결론을 분리해서 볼 수 있습니다. 제가 받은 VPS에는 심각한 CPU availability 문제가 있었다. 그리고 AVA의 환불 처리는 적절했다. 두 가지 모두 사실입니다.
이 경험에서 얻은 것
이제 저는 1 vCPU / 2 GB RAM / NVMe / KVM 같은 사양표만 보고 VPS를 평가하지 않습니다. 그런 숫자는 무엇이 provision되었는지 말해줄 뿐, 실제 workload에서 CPU를 얼마나 예측 가능하게 사용할 수 있는지는 알려주지 않습니다.
새 VM을 받으면 초기에 다음을 확인합니다.
mpstat 1 60
vmstat 1 60
cat /proc/pressure/cpu
ss -ltnp
free -h
df -h
iostat -xz 1 60AVA Hosting 경험에서 얻은 가장 중요한 교훈은 1 vCPU가 무조건 부족하다는 것이 아닙니다. 프로세스가 실행 중이고 RAM이 남아 있으며 디스크가 정상처럼 보여도, 그 아래 전혀 다른 문제가 숨어 있을 수 있다는 점입니다.
제 경우 Linux는 그것을 매우 분명하게 보여줬습니다.
CPU steal: 32.73%
CPU idle: 0.00%
CPU pressure: ~99%AVA Hosting은 CPU 리소스를 공유하지 않는다고 광고하며 인접 workload 때문에 steal이 발생해서는 안 된다고 설명합니다. 하지만 제 VPS가 보고한 값은 달랐습니다.
저는 VPS를 취소했습니다. AVA는 전액을 빠르게, 별다른 논쟁 없이 돌려줬습니다.
그렇게 이 디버깅 하루가 끝났습니다.