[AWS] CloudWatch가 EC2 Memory 모니터링을 제공하지 않는 이유는? (Hypervisor & OS)

 

 

 

 

 

왜 CloudWatch가 EC2 Memory 모니터링을 제공하지 않을까?

 

 

EC2에서 CloudWatch는 CPU와 네트워크 정보는 기본적으로 수집을 제공한다.

반면에 Memory와 Disk 정보에 대해서는 CloudWatch Agent를 OS에 추가로 설치해야만 수집할 수 있다.

 

CPU까지는 기본적으로 수집할 수 있는데, 왜 Memory는 추가적인 소프트웨어를 설치해야만 수집할 수 있는 것일까?

핵심적인 원인은 Hypervisor Level과 OS Level에서 수집할 수 있는 정보의 차이다.

 

 

 

 

 

 

CPU는 Hypervisor Level  

 

하이퍼바이저는 기본적으로 물리적 Host의 CPU 사용을 VM마다 적절히 분배해야 한다.

Guest OS는 하이퍼바이저에게 제공받는 시간만큼의 CPU를 사용하기 때문에, OS level보단 Hypervisor Level에서의 CPU 모니터링이 정확하고 더 적절할 수밖에 없다. (당연히  OS에서도 가능하다.)

 

 

기본적으로 AWS는 자신들의 하이퍼바이저에 Cloud Watch 모니터링을 세팅해둘 수 있으므로, 기본적으로 CPU 모니터링이 가능하다. (Cloud watch가 하이퍼 바이저에게 주기적으로 질의하는지, 하이퍼바이저가 주기적으로 메트릭을 전송하는지는 확실하지 않다.)

 

 

하이퍼바이저에 대한 질의는 각 VM의 성능에도 영향을 주지 않으므로, 고객 입장에서도 좋다고 생각한다. (전체적인 물리적 Host의 부하가 심하다면 다를 수 있겠지만)

 

 

 

 

 

 

Memory는 OS Level 

 

반면 메모리는 하이퍼바이저가 모니터링하기 적절하지 않다.

 

그 이유는 OS는 기본적으로 가상 메모리를 사용하기 때문이다.

OS에서 동작하는 각 프로세스는 자신이 모든 메모리를 사용하는 것처럼 동작한다.

이를 위해 OS가 각 프로세스의 정보를 적절히 메모리에 적재하거나 디스크의 Swap 영역에 배치하는 등의 복잡한 메모리 관리를 진행해야 한다.

 

이를 Hypervisor가 일일이 추적하는 것은 오버헤드가 많이 발생한다.

반면 이미 VM의 메모리를 관리하고 있는 Geust OS 입장에서는 메모리 사용량 추적은 오버헤드가 거의 없는 쉬운 일이다.

따라서 VM의 OS에 CloudWatch Agent를 설치하여 메트릭 값을 CloudWatch로 주기적으로 보내야 메모리 모니터링이 가능하다.

 

 

 

 

정리하면 아래의 그림과 같다.

 

 

 

 

 

그리고 실제 Hypervisor들은 물리 호스트의 자원보다 더 큰 양의 자원을 VM들에게 배치하고는 한다.

이를 OverCommit 이라고 하는데 다음 글에서는 이에 대해서 알아보자

 

 

 

 

 

참조

https://stackoverflow.com/questions/44507609/why-aws-cloudwatch-does-not-have-memory-usage-metric-for-autoscaling-group

Why AWS CloudWatch does not have Memory usage metric for Autoscaling group