사내 서비스를 올릴 때 물리 서버를 한 대씩 사는 대신, 장비 한 대에 가상 머신을 여러 개 띄워 나눠 쓰는 경우가 많습니다. 가상 머신마다 CPU 코어 몇 개와 메모리 몇 GB를 할당해 두고, 그 안에서는 평범한 리눅스 서버처럼 씁니다.
가상 머신 한 대가 느려지면 확인할 곳이 두 군데입니다. 가상 머신 안에서 동작하는 운영체제와, 그 가상 머신을 실행하는 물리 장비입니다. 그런데 가상 머신이 계산하는 사용률은 할당받은 몫만 기준으로 삼습니다. 물리 코어를 기다린 시간은 그 숫자만으로는 알 수 없습니다.
VMware 모니터링은 가상 머신 안에서 보는 지표와 그 가상 머신을 올려둔 호스트에서 보는 지표를 함께 모아, 성능 저하의 원인이 어느 쪽에 있는지 구분하는 일입니다.
가상화 환경에는 두 개의 관찰 지점이 있습니다. 가상 머신 안에서 동작하는 운영체제를 게스트라고 하고, 그 가상 머신들을 실제로 실행하는 물리 장비와 그 위의 소프트웨어를 호스트 또는 하이퍼바이저라고 합니다.

VMware 가상화 환경을 이루는 구성 요소의 이름은 다음과 같습니다.
게스트는 자기에게 할당된 자원만 봅니다. CPU 코어 네 개를 할당받았으면 그 네 개를 기준으로 사용률을 계산합니다. 그런데 그 네 개는 물리 코어를 독점한 것이 아닙니다. 같은 호스트에 올라간 다른 가상 머신들과 번갈아 쓰는 몫입니다.
그래서 게스트 지표에 "CPU 30%"로 찍힐 때도, 실제로는 물리 코어 차례를 기다리느라 일을 못 하고 있을 수 있습니다. 기다린 시간은 게스트 지표에서 대기로 따로 드러나지 않습니다. 메모리와 디스크도 마찬가지입니다. 할당량을 기준으로 본 숫자와 실제로 쓴 물리 자원은 다릅니다.

호스트 쪽에서 확인하면 게스트에 안 드러나는 원인이 보입니다. 여기서는 다섯 가지를 봅니다.
CPU 준비 시간(CPU Ready)은 가상 머신을 많이 올릴수록 늘어납니다. 물리 코어 수보다 할당한 가상 CPU 수가 많은 상태에서 여러 가상 머신의 부하가 겹치면 서로 순서를 기다립니다. 게스트 커널과 하이퍼바이저가 지원하면 게스트 안에서도 CPU Steal Time으로 이 대기를 일부 짐작할 수 있습니다. 지원하지 않는 환경에서는 0으로만 찍히므로 호스트의 CPU 준비 시간을 직접 봐야 합니다. Steal Time이 무엇이고 어떻게 읽는지는 CPU Steal Time이란? 클라우드 서버 지연 원인과 해결 방법에서 따로 다뤘습니다.
Co-Stop은 가상 CPU를 여럿 가진 가상 머신에서만 생깁니다. 가상 CPU들이 서로 너무 앞서거나 뒤처지지 않도록 하이퍼바이저가 진도를 맞추는데, 앞서 간 가상 CPU를 잠시 멈춰 세우는 그 시간이 Co-Stop입니다. 가상 CPU가 많을수록 맞출 대상이 늘어 이 대기도 함께 늘어납니다.
그래서 가상 CPU를 많이 할당한다고 항상 빨라지지는 않습니다. 실제로는 네 개면 충분한 작업에 여덟 개를 할당하면, 호스트가 바쁠 때 오히려 스케줄링 대기가 길어집니다.
메모리 벌루닝(Memory Ballooning)은 이름이 낯설지만 동작은 단순합니다. 호스트에 메모리가 모자라면 게스트 안에 설치된 드라이버가 풍선처럼 부풀어 메모리를 차지하고, 그만큼을 호스트가 회수해 갑니다. 게스트 입장에서는 갑자기 쓸 메모리가 줄어든 것처럼 보입니다. 게스트만 보면 "메모리가 부족하다"로 읽히지만, 원인은 호스트의 자원 배분입니다. vSphere 성능 지표에서는 vmmemctl이라는 카운터로 확인합니다.
디스크 지연은 게스트가 보낸 입출력 요청이 저장소에서 응답을 받기까지 걸린 시간입니다. 같은 데이터스토어를 쓰는 가상 머신이 많거나 저장소 경로 하나에 요청이 몰리면 길어집니다. 게스트에서는 디스크가 느리다는 것만 보이고, 어느 가상 머신 때문인지는 알 수 없습니다.
다섯 번째는 호스트 하드웨어 상태입니다. 전원 장치나 냉각 팬에 이상이 생기면 프로세서 동작 속도가 자동으로 낮아지기도 합니다(스로틀링). 이 경우 게스트에서는 아무 이유 없이 느려진 것으로 보입니다.
지금 겪는 증상에 따라 먼저 볼 지표가 달라집니다.
CPU 준비 시간과 Co-Stop은 같이 읽어야 원인이 좁혀집니다. 준비 시간만 높고 Co-Stop이 낮으면 호스트에 가상 머신이 몰렸거나 CPU Limit 같은 자원 제한이 걸린 쪽을, 둘 다 높으면 그 가상 머신에 할당한 가상 CPU 수까지 함께 의심합니다.
표에 정리한 지표는 모두 호스트에서 가져오는 값이라, 게스트에 설치한 에이전트로는 모이지 않습니다.
호스트 지표는 vSphere API로 가져옵니다. vCenter에 연결하면 그 vCenter가 관리하는 ESXi 호스트와 가상 머신을 한 번에 수집하고, vCenter 없이 ESXi 호스트에 직접 연결하면 그 호스트만 수집합니다. 다만 관리 중인 개체 수, 활성 알람 수, 인증서와 라이선스 만료일처럼 vCenter 자체의 구성 정보는 vCenter에 연결해야 얻을 수 있습니다.
여기까지 본 지표는 vCenter 화면에서도 확인할 수 있습니다. 까다로운 쪽은 비교입니다. 원인을 좁히려면 가상 머신 안의 프로세스와 메모리 지표, 호스트의 CPU 준비 시간과 Co-Stop, 벌루닝을 같은 시각에 놓고 읽어야 합니다. 호스트와 가상 머신이 늘어날수록 게스트 지표와 호스트 지표를 한 시간 축에서 볼 수 있는지가 원인을 찾는 속도를 좌우합니다.
흔히 쓰는 기준은 가상 CPU 하나 기준으로 5%를 넘으면 확인, 10%를 넘으면 성능 영향을 의심하는 것입니다. 다만 보고 있는 값의 단위를 먼저 확인해야 합니다. vSphere 화면에서는 이 값이 퍼센트가 아니라 수집 간격 동안 누적된 밀리초로 표시되기도 해서, 화면 숫자에 퍼센트 기준을 그대로 대면 어긋납니다. 가상 CPU가 여럿인 가상 머신은 가상 CPU 수만큼 값이 커지므로 하나 기준으로 환산해 보는 편이 정확합니다. 단일 기준에 기대기보다 같은 호스트의 다른 가상 머신과 견주는 편이 낫습니다. 한 가상 머신만 값이 크면 그 가상 머신의 구성을, 호스트 전체가 크면 가상 머신을 너무 많이 올린 것을 의심합니다. 값이 평소보다 눈에 띄게 늘었는지가 절댓값보다 중요합니다.
게스트에 에이전트를 설치하는 것만으로는 게스트가 보는 값까지만 모입니다. 호스트 지표는 vSphere API로 따로 가져와야 하고, 접속할 vCenter나 ESXi 주소와 계정을 등록하는 과정이 필요합니다. 대상 가상 머신마다 무언가를 설치해야 하는 것은 아닙니다. API를 호출할 수집 지점 한 곳과 읽기 권한을 가진 계정이면 됩니다.
반대일 때가 있습니다. 게스트 CPU 사용률이 늘 낮은데 Co-Stop이 꾸준히 잡힌다면 가상 CPU 수를 줄여 보고, 줄이기 전과 후의 응답시간과 Co-Stop을 같은 길이의 기간끼리 비교합니다. 처음에는 적게 할당하고 모자랄 때 늘리는 쪽이 되돌리기도 쉽습니다.
가상 머신 안에서 본 사용률로는 CPU와 메모리, 디스크 같은 물리 자원을 호스트에서 얼마나 기다리고 나눠 썼는지 알 수 없습니다. 그 값은 호스트 지표에서만 확인할 수 있습니다. 증상이 보이면 게스트 지표와 호스트 지표를 같은 시간 축에 놓고, CPU 준비 시간과 Co-Stop, 벌루닝 값이 같은 시각에 어떻게 움직였는지 비교합니다.
와탭 서버 모니터링에서는 가상 환경 메뉴의 VMware 모니터링으로 vCenter나 ESXi 호스트를 연동해 호스트 지표와 가상 머신 지표를 함께 수집할 수 있습니다. 어떤 값을 모으는지는 VMware 수집 항목 문서에서 확인해 보세요.