퍼블릭 클라우드 EC2 오버커밋 Steal Time 측정 방법

mpstat로 EC2 Steal Time을 실측하여 오버커밋과 악성 이웃 식별

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

Steal TimeEC2 오버커밋성능 감사NitroFinOpsCloudWorthVPS 오버셀링VPS 점검

Steal Time이 높다고 해서 반드시 오버커밋은 아니며, Nitro와 크레딧 메커니즘을 결합하여 종합적으로 판단해야 합니다.

mpstat 실측 오버셀링

퍼블릭 클라우드 EC2에서 Steal Time을 측정할 때 가장 직접적인 방법은 mpstat -P ALL 1로 몇 라운드 %steal을 지켜보는 것이다. 하지만 숫자가 높다고 바로 오버셀링이라고 외치면 안 된다. 내가 밟았던 함정이 있다: T3 인스턴스의 CPU 크레딧이 소진되면 %steal도 30% 이상 치솟을 수 있다. 그런데 그것은 이웃이 CPU를 빼앗는 것이 아니라 크레딧 풀이 비어 있는 것이다. Nitro 가상화에서의 정상적인 스케줄링 오버헤드, Burstable 크레딧 소진, 그리고 악성 이웃(noisy neighbor)의 선점을 제대로 구분하려면 /proc/schedstat와 CloudWatch의 CPUCreditBalance 지표를 함께 봐야 한다.

실무에서는 먼저 sudo apt install sysstat && mpstat 1 5를 실행하고, %steal이 지속적으로 10%를 넘는지에 주목한다. 단순히 순간적으로 흔들리는 정도라면 호스트의 정상적인 CPU 리소스 경쟁일 가능성이 높다. 오랜 시간 높은 수준을 유지하고 cpustat에서 steal 시간 비율이 안정적으로 나타난다면 그때 오버셀링을 의심한다. 참고: Steal Time이 높다고 해서 반드시 오버셀링은 아니다. 스스로 인스턴스 크기를 너무 작게 선택했을 수도 있다. T3 인스턴스에서 Unlimited를 켜면 지속적인 고부하가 먼저 미래 크레딧을 앞당겨 사용하게 되고, 그 증상으로 steal이 올라간다.

여기서 끝이 아니다. 나는 보통 mpstat 출력을 CSV로 내보내고, CloudWatch 스크린샷과 함께 PDF로 묶는다. 나중에 권리 보호 티켓을 열어야 할 때 확실한 증거가 된다. AWS 공유 인스턴스의 가성비는 매력적으로 보이지만, FinOps로 비용을 계산할 때는 잠재적인 steal 리스크를 프리미엄 비율로 환산해야 한다. 같은 4 vCPU라면, 이웃과 운을 겨루기보다 Dedicated Host와 공유 인스턴스의 장기 비용 차이를 명확히 계산하는 편이 낫다.

전체 감사 절차는 EC2 StealTime 감사 가이드에서 볼 수 있고, 바로 운영 감사 대시보드에 들어가 자동으로 한 라운드 실행할 수도 있다.

Nitro 오버커밋과 T3 크레딧

AWS EC2의 Nitro 아키텍처는 일반적인 KVM 오버커밋과 다릅니다. Nitro의 CPU 스케줄링은 더 엄격한 격리를 제공하지만, 공유 호스트에서는 여전히 이웃 간 경쟁이 발생합니다. 실제로 혼동하기 쉬운 것은 T3/T3a/T4g와 같은 버스트 가능 인스턴스입니다. CPU 크레딧이 소진되고 Unlimited가 활성화되지 않으면 성능이 강제로 기준선으로 끌려가며, 이때 mpstat의 %steal이 반드시 급증하는 것은 아니고 오히려 자체적으로 '버벅임'처럼 보일 수 있습니다. Unlimited를 활성화하면 크레딧을 초과 사용할 수 있지만 추가 비용이 발생합니다.

따라서 문제 해결 시 먼저 mpstat 1로 연속 샘플링한 다음 CloudWatch의 CPUCreditBalance 지표와 대조하십시오. steal이 높은데 크레딧이 충분하다면 오버커밋의 증거입니다. 그렇지 않으면 Nitro 가상화의 정상적인 오버헤드일 수 있습니다. 실제 측정에서 지속적으로 높은 steal이 발생한다면 /proc/stat 타임스탬프 증거를 수집하여 티켓 제출이나 사양 축소 논거로 사용하는 것을 권장합니다. 결국 FinOps 관점에서 오버커밋에 비용을 지불하는 것은 프리미엄 비율이 비효율적이기 때문입니다.

포렌식 티켓과 FinOps 프리미엄

EC2에서 지속적으로 높은 steal time을 발견했을 때, AWS에 '오버세일'이라는 딱지를 붙이기 전에 먼저 확인할 것이 있습니다. 제 습관은 먼저 mpstat -P ALL 1로 15분간 연속 샘플링한 다음, CloudWatch의 CPUCreditBalance와 CPUCreditUsage를 대조하는 것입니다. T3/T4g의 크레딧 잔액이 0이 되면, steal time이 높은 것은 CPU 크레딧 고갈 때문이지 이웃이 CPU를 뺏는 것이 아닐 가능성이 높습니다. 진짜 '악성 이웃'을 입증하려면 Nitro 가상화에서 steal이 5%를 초과하고 irq 상승이 동반되는지 확인해야 합니다. 하지만 Nitro 자체에도 약간의 스케줄링 오버헤드가 있으므로 VPS에서 쓰던 0.5% 임계값을 그대로 적용하면 안 됩니다.

포렌식 단계에서는 CloudWatch의 CPUUtilization, StealTime 지표를 동시에 내보냅니다(EC2의 StealTime은 커스텀 네임스페이스라 GetMetricData로 가져와야 합니다). 그리고 /proc 스냅샷으로 cpu 행을 기록합니다. 이 세 가지를 타임스탬프 기준으로 묶어 PDF로 만든 뒤 티켓에 바로 첨부합니다. AWS Support는 타임라인과 스크린샷이 포함된 데이터를 보면 일반적으로 물리 호스트를 더 기꺼이 조사합니다. 오버세일을 인정하는 경우는 거의 없지만, 인스턴스를 교체하거나 placement group을 조정해 주곤 합니다.

마지막으로 FinOps 프리미엄 얘기를 하자면, 같은 사양의 c7i.large를 공유 호스트에서 배치 작업에 돌릴 때, steal time 3%와 8% 인스턴스의 실제 처리량은 12% 이상 차이 날 수 있습니다. 크레딧 고갈 후 추가 비용(T 시리즈 unlimited)까지 계산하면 종합 비용이 전용 호스트보다 더 비쌀 수 있습니다. steal time을 월간 비용 보고서에 포함시켜 5%를 초과하면 '성능 손실 프리미엄'으로 환산하고, Dedicated Host의 연간 약정 가격과 비교해 볼 것을 권장합니다. 실제로 중요한 작업은 호스트를 업그레이드하는 것이 더 저렴한 경우가 많습니다.