CloudWatch와 top이 다른 이유

개요

컴퓨터 비전 및 AI 모델과 같이
CPU & Memory 집약적인 워크로드를 개발 및 운영한 적이 있습니다.
이 과정에서 CloudWatch Metric과 Linux top의 오차를 알게되 었습니다. 이 문서는 “왜 오차가 발생할까? 그리고 어떤 지표를 신뢰해야 할까?”를 다루고 있습니다.

결론

CloudWatch Metric은 하이퍼바이저 레벨의 매트릭이며
Linux top 명령어는 에이전트 레벨의 매트릭이기 때문에
매트릭을 수집하는 기준이 다르며, 최종 지표 또한 다릅니다.

CPU에 대한 지표로는
CloudMatch Metric의 CPUUtilization 지표로 시스템 부하 및 장애 경보를 활성화하고
Linux top 명령어로 각 프로세스들의 부하량을 세밀하게 관찰할 수 있습니다.

기본적으로 Linux top 명령어가 실시간성 정보를 제공합니다.
단 top 명령어 자체가 점유하는 CPU도 있으므로 다소간의 오차가 있을 수 있습니다.

해당 결론을 내리는 데에는 CS 지식과 실제 지식으로 구분하여 정리하였습니다.

CS 지식

CloudWatch Metric과 Linux top 명령어에 대한 비교 이전에 CPU에 대한 CS 지식이 필요하다고 생각합니다. 전체적인 내용은 pCPU, vCPU 등의 이론과 이로 인해 발생하는 CPU Overcommitment, Scheduling 이슈를 다루고 있습니다.

1. pCPU와 vCPU에 대한 내용

2. AWS에서 pCPU, vCPU에 대한 내용

3. CPU Overcommitment란?

4. CPU Scheduling과 CPU Ready란?

pCPU와 vCPU에 대한 내용

컴퓨터는 마더 보드*를 가지며 여러 대의 pCPU*를 가집니다.
최근에 나온 중앙 처리 장치는 물리적인 프로세스인 Core를 여러개 가지고 있습니다.
개별 코어는 명령을 실행하고 출력을 제공하는 논리적인 코어인 Thread를 가집니다.
이때 하이퍼스레딩 모델을 사용하게 되면 vCPU*가 별도로 생성됩니다.

마더보드(Motherboard), 중앙 처리 장치(CPU), 가상 중앙 처리 장치(vCPU)

마더 보드의 pCPU 자원의 수와, vCPU 자원의 수는 다음과 같이 계산됩니다.

- 2 CPU socket * 6 Core / process = 12 pCPU
- 12 pCPU * 2 thread/pCPU = 24 vCPU

AWS에서 pCPU, vCPU에 대한 내용

AWS EC2 인스턴스 타입 문서의 일부를 보면
AWS EC2의 다양한 타입이 대체적으로 pCPU보다 vCPU가 많아보입니다.

기본적으로 하이퍼스레딩 모델 일종인 멀티스레딩(SMT)을 기본적으로 사용합니다.
이를 선택적으로 비활성화하여 pCPU와 vCPU의 숫자를 일치시킬 수 있습니다.

다만 하이퍼스레딩을 사용하여 vCPU가 pCPU 대비 2배 늘어날 경우
그렇지 않은 경우에 비하여 최대 30%의 성능 향상(고점)이 일어납니다.
따라서 멀티스레딩(SMT)을 비활성화 하는 것은 특수 목적이 없는 이상 권장되지 않습니다.

CPU Overcommitment란?

앞서 pCPU는 하이퍼스레딩 모델을 통해 더 많은 수의 vCPU를 할당할 수 있음을 배웠습니다.
실제로 AWS EC2는 가상 머신(VM)에 멀티 스레딩(SMT)을 적용하여 2배수 정도의 vCPU를 가지고 있었습니다.

이렇게 pCPU 보다 많은 vCPU를 가지는 것을 CPU Overcommitment라고 합니다.
CPU Overcommitment 상한선은 다양한 요소들로 측정되며 1:3 이하를 권장합니다.

CPU Scheduling과 CPU Ready란?

만약 pCPU가 4인 호스트에
vCPU 4, vCPU 2인 가상 머신을 2개 실행하면 어떻게 될까요?
일반적으로 vCPU가 모두 준비되어야 작업이 진행되므로 CPU Ready가 발생합니다.

하지만 vCPU 2로 통일시킨 가상머신을 2개를 실행한다면
전체적으로 CPU Ready 수치가 내려가고 성능은 개선될 것입니다.

과거 K8s 스터디를 할 때,
컨테이너에 request & limit 항목에 cpu를 명시하는 부분이 있었습니다.
이 부분을 단순히 최소 요청, 최대 제한으로 이해했는데 다시 공부해야 할 것 같습니다.

CPU Ready 수치는 esctop 커맨드로 확인할 수 있습니다.
이 커맨드로는 가상 머신이 준비되었으나 pCPU에서 실행되도록 예약할 수 없는 시간을 볼 수 있으며 이런 수치가 5% 미만이 되도록 작업해야 합니다.

실제 지식

근본적인 질문인 “왜 오차가 발생할까?” 와 “어떤 지표를 신뢰해야 할까"?”의 답을 위해
CloudWatch Metric과 Linux top 명령어가 무엇인지를 명확히 알아야 합니다.

1. CloudWatch Metric 중 CPUUtilization이란?

2. Linux top 명령어와 %CPU이란?

CloudWatch Metric 중 CPUUtilization이란?

CloudWatch Metric

CloudWatch Metric은 하이퍼바이저 레벨에서 발생하는 매트릭을 표시합니다.
AWS EC2는 일정 간격마다 CloudWatch Metric으로 지표를 전송합니다.

그 중에서도 핵심 지표 중 하나인 CPUUtilization을 일정 시간 사용한 pCPU 비율입니다.

The percentage of physical CPU time that Amazon EC2 uses to run the EC2 instance, which includes time spent to run both the user code and the Amaon EC2 code.

아래의 2가지 이유로 일부 오차가 발생할 수 있습니다.

1. 하이퍼바이저 레벨의 매트릭이기 때문에 세부적인 수준의 오차가 있을 수 있다.

2. 일정 시간 사용량이기 때문에 지표 증감이 늦게 표기된다.

하지만 대다수 오차 범위를 고려하더라도
실제 호스트의 전체 부하량을 판단하는 기준으로는 적합합니다.

Linux top 명령어와 %Cpu(s), %CPU이란?

Linux top 명령어는 에이전트 레벨에서 발생하는 매트릭을 실시간*으로 표시합니다.
현재 시스템에 대한 요약 정보, Linux kernel의 process, thread 정보를 포함합니다.

여기서 실시간*은 마지막 화면 업데이트 이후의 CPU 사용량을 의미합니다.

The task’s share of the elapsed CPU time since the last screen update, expressed as a percentage of total CPU time. - top(1) - Linux manual page

Linux top 명령어에서는 크게 2종류의 CPU 지표를 확인할 수 있습니다.

• %Cpu(s) : 시스템 전체의 CPU 지표

• %CPU : 프로세스 별 CPU 지표

실제로 각 항목에 대한 확인을 위해서 AWS EC2를 아래 설정으로 생성하였습니다.
여기서 Thread Model은 기본적으로 활성화 되어 있으니 신경 쓰지 않아도 됩니다.

- OS : Amazon Linux 2023
- Instance Type : t3.medium
- Spec : 1 pCPU, 2 vCPU, 2 Thread/Core
- Thread Model : 멀티스레딩(SMT)

이후 생성한 AWS EC2에서 top 명령어를 실행해보겠습니다.

top

아래를 보면 위에서 3번째 줄에 %Cpu(s)가 6번째 줄에 %CPU가 있는 것을 알 수 있습니다.

%Cpu(s)는 시스템 전체 CPU 사용율을 의미하며
%CPU는 프로세스 별 CPU 사용율을 나타내는 지표입니다.

따라서 시스템 전체 부하량을 파악하기 위해서는 %Cpu(s)를
프로세스 별 부하량을 파악하기 위해서는 %CPU를 확인하는 것이 좋습니다.

세부적으로 %Cpu(s), %CPU를 확인하는 방법에 대해서는 바로 아래에서 다루겠습니다.

1. Linux top %Cpu(s)에 대해서 알아보기

2. Linux top %Cpu(s)에 가설과 테스트하기

3. Linux top %CPU에 대해서 알아보기

4. Linux top %CPU에 대해서 가설과 테스트하기

Linux top %Cpu(s)에 대해서 알아보기

Linux top 명령어에서 3번째 줄은 SUMMARY Display로 시스템 정보 요약을 의미합니다.
그 중에서 %Cpu(s)는 마지막 화면 업데이트 이후의 CPU 사용율을 의미합니다.
pCPU, vCPU의 숫자와 무관하게 전체의 총합 대비 사용율을 표기해줍니다.

총 옵션은 8가지이지만, st는 커널 버전에 따라 보이지 않을 수 있습니다.

Depending on your kernel version, the st field may not be shown.
- 2. SUMMARY Display- top(1) - Linux manual page

%Cpu(s) 지표는 8가지로 구분되어 총합은 정확히 100.0이 됩니다.
이 중에서 전체 CPU 대비 실제 CPU 사용량은 다음과 같이 계산할 수 있습니다.

Total Percent = 100.0 - id
# Total Percent = 100.0 - 97.8 = 2.2

또한 성능 벤치마킹에서 유의미한 지표로서 3가지를 확인할 수 있습니다.

일정 기간 Steal Time이 5%가 넘어가지 않는 것이 좋으며,
추가적으로 User Percent, System Percent의 지표를 확인하는 것이 좋습니다.
해당 지표의 합이 너무 큰 값으로 치솟으면 시스템이 다운될 수 있습니다.
다만, 이 값은 위에서 알려준 …실제 사용량(Total Percent)으로 축약해도 됩니다.

User Percent   = us + ni
System Percent = sy + hi + si + quests
Steal Time     = st

실제로 위에서 말씀드린 User Percent, System Percent를 시각화할 수도 있습니다.
top 명령어 입력 이후, t를 한번더 입력하여 Display Mode를 사용할 수 있습니다.

공식 문서에서는 크게 4가지 부분으로 나누어 설명하고 있습니다.

            a   b     c  d
%Cpu(s):  22.8/9.1    32[||||||||||||                   ]

• a : User Percent : us + ni

• b : System Percent : sy + hi + si + geusts

• c : Total Percent

• d : Visual Grpahs for Total Percent(== c )

Where: a) is the ‘user’ (us + ni) percentage; b) is the ‘system’ (sy + hi + si + guests) percentage; c) is the total percentage; and d) is one of two visual graphs of those representations. Such graphs also reflect separate ‘user’ and ‘system’ portions. - 2. SUMMARY Display- top(1) - Linux manual page

Linux top %Cpu(s)에 가설과 테스트하기

실제 비즈니스 상황에서는 %Cpu(s)가 어떻게 변화할까요?
테스트를 위해서 아래 설정으로 AWS EC2를 설정하였습니다.

- OS : Amazon Linux 2023
- Instance Type : t3.medium
- Spec : 1 pCPU, 2 vCPU, 2 Thread/Core
- Thread Model : 멀티스레딩(SMT)

그리고 SteamPipe, PowerPipe를 실행하였습니다.

SteamPipe : Postgre 엔진으로 AWS CLI 등을 호출할 수 있음
PowerPipe : 대시보드 구성

위 내용을 기반으로 아래와 같이 3가지 가설을 세웠습니다.

• Postgres 엔진 호출을 하지 않는 API 요청에서는 us 지표만 소폭(e.g. 10 Pts) 증가

• Postgres 엔진 호출을 하는 API 요청에서는 us 지표만 대폭(e.g. 70 Pts) 증가

• Postgres 엔진을 동시다발적으로 호출하는 API 요청에서는 us 지표만 대폭 증가

하지만 실제로는 아래와 같이 3가지 결과를 얻었습니다.

• Postgres 엔진 호출을 하지 않는 API 요청에서는 us 1.0, st 0.3 Pts 증가

• Postgres 엔진 호출을 하는 API 요청에서는 us 66.8, st 16.0 Pts 증가

• Postgres 엔진 동시 다발적으로 호출을 하는 API 요청에서는 us 65.4, st 20.3 Pts 증가
  추가적으로 sy 20.3 Pts, si 11.0 Pts 증가

테스트 결과 단순 페이지만 보여주는 경우 postgres 엔진을 실행하지 않습니다.
이 경우에는 기대치와 결과가 크게 다르지 않았습니다.

하지만 실제 postgres 엔진이 실행된 경우에는 기대치와 크게 다른 결과가 나왔습니다.
결정적인 지표는 st(steal time)이 급증한 것을 볼 수 있습니다.

해당 테스트로 알 수 있는 점은
CPU가 100% us 에 쓰이는 것이 아니며
st, sy, si 등에서 손실되는 부분이 존재한다.

따라서 SpringBoot, Nest.js 등의 웹 서버의 기능을 잘못 구현할 시에
wa, st, sy, si 등을 과도하게 사용하게 되면서 실제 연산에 필요한 us 가 부족해질 수 있다.

Linux top %CPU

다만 이 수치는 CloudWatch Metric의 수치와 다릅니다.
실제로 Linux top이 적합한 용도는 작업 처리에 따른 %CPU(s)의 증감입니다.
아래 예시를 보면, 단일 가상 머신 환경에서 다수의 프로세스의 실행으로 인해
User Space, Steam Time이 가파르게 치솟아 전체 사용량이 위험한 수치가 되는 것을 확인할 수 있습니다.

아래는 steampipe, flowpipe, powpiper라는 오픈소스가 배포된 호스트입니다.
위에서 학습한 사전 지식을 기반으로 생각해보면 us 지표만 증가할 것이라 예상했습니다.

하지만 반복적인 요청을 보내 top 명령어로 확인하면 us, st 지표가 모두 올라갑니다.

요청을 처리하는 주체인 steampipe가 호출한 postgres가 대규모로 실행이 되면서
후순위로 호출된 postgres들이 대기 상태에 빠지거나 상호 간에 vCPU를 뺏음으로 인해
st 지표가 증가된 것으로 추측하고 있습니다.

중요한 부분은 단일 호스트의 복수의 가상 머신 외의 상황에서도
단순히 하이퍼바이저 위에서 멀티 스레딩(SMT)과 vCPU를 쓰는 것만으로도
St(steal time)이 허용 한계선 5%를 아득히 넘어가는 20.6%가 될 수 있습니다.

• 씨솔트의 밑 빠진 독에 물 붓기 - 왜 Cloudwatch의 CPU 사용량과 top 결과가 다를까?

• Stackoverflow - Why does top report a different cpu usage than CloudWatch?

• CPU Utilization metrics not matching

• Why are results from ‘top’ in batch mode different than from interactive ‘top’?

• Youtube (CloudNow) - HOST 당 vCPU 몇 개를 할당하면 가장 좋을까요?

• Geeks or Geeks - How to Monitor System Activity in Linux | top Command

• Stackoverflow - Why linux "top" command shows different CPU utilizations values with only one CPU?