EC2 CPU Usage 이상 동작 이슈 해결하기
Amazon Web Service
Amazon Web Service
이번 글에서는 EC2에서 발생한 CPU Usage의 이상 동작 이슈의 해결 과정에 대해 이야기해 보겠습니다. 문제를 해결하기 위해서 고민했던 과정들과 AWS와의 협업 과정들을 담고 있습니다. CPU 이슈가 아니라도 다른 이슈로 EC2 문제를 겪고 있는 분들에게 도움이 되었으면 좋겠습니다.
문제의 발단
어느 날부터인가 아래와 같은 모니터링 메시지가 날아오기 시작했습니다.
CPU Usage 알럿 메시지API 서버에서 CPU 사용률이 80%를 넘었다는 메시지였습니다. 여러 대의 API 서버 중 유독 한 대에서만 발생하는 메시지였습니다. 트래픽의 증가로 인해 CPU 사용률이 올라간 게 아닌 상황이었기 때문에 서버에 접속해서 원인을 살펴보게 되었습니다.
첫 번째 조치
서버에 접속해서 보니 JAVA 프로세스의 CPU 사용률이 모든 코어에서 80% 이상을 기록하고 있었습니다. 당연히 JAVA 프로세스의 오작동으로 판단하고 원인을 파악하기 시작했습니다. 이상 동작하는 EC2에서 JAVA 스레드 덤프까지 만들어서 분석했지만 크게 문제가 될 만한 내용은 찾지 못했습니다. 그렇게 여러 가지 방안으로 원인 파악에 애쓰던 찰나, 아래와 같은 내용을 접할 수 있었습니다.
https://lng1982.tistory.com/261
정확히 이게 원인이라고 볼 수는 없었으나 CPU 사용률이 높아졌다는 것에서 공통점이 있었고, 일단 무엇이라도 조치를 취해봐야 하는 상황이었기 때문에 적용을 해 봤습니다. 또한 CPU Usage 이슈가 발생하기 시작한 즈음에 무작위 수를 생성하는 로직이 들어가기 시작한 것도 해당 이슈일 것이라고 생각하는데 영향을 주었습니다.
효과가.. 있었을까요..?
두 번째 조치
하지만 모두의 기대에도 불구하고 효과는 없었습니다. /dev/random 블로킹 이슈가 비정상적인 CPU Usage의 원인이 아니었기 때문이었습니다.
나도 울고 개발자들도 울었다. 아침 7시 41분부터..자포자기하는 마음으로 원인 파악에 오랜 시간이 걸릴 것으로 예상하며 해당 EC2에 삭제 방지 기능을 활성화한 후 서비스에서 제외하기 위해 (자동으로 제외되긴 하지만 완전히 제외하기 위해) JAVA 프로세스를 내린 순간, 뭔가 이상한 현상이 발견되었습니다.
바로 커널 스레드 및 모니터링용 프로세스들도 비정상적으로 높은 CPU 사용률을 보이는 것이었습니다.
인프라 모니터링을 위한 프로세스들의 이상 동작평상 시라면 있는지도 모를 정도의 CPU 사용률을 보이던 모니터링 프로세스들이 갑자기 CPU 사용률이 100% 이상을 보이고 있는 것이었습니다. 뭔가 EC2 자체가 이상한 것 같다는 낌새를 느낀 건 이때부터 였습니다. 그 전에도 느낄 수 있었겠지만 워낙 JAVA 프로세스의 CPU Usage가 높았기 때문에 미처 발견하지 못한 부분이었습니다.
AWS와의 협업
EC2 인스턴스가 비정상적이라는 것을 감지한 후 AWS 서포트 센터를 통해 서포트 티켓을 작성했습니다. 모니터링 프로세스들의 CPU 사용률이 비정상적으로 높다는 내용의 서포트 티켓을 작성해서 엔지니어와 문제 해결을 위한 자료들을 모으기 시작했습니다.
자료를 모으던 중 한 가지 매우 이상한 것을 감지했습니다. 바로 EC2에서 보이는 CPU MHz가 정상이 아니었던 것이었습니다.
실제 서포트 티켓의 내용 중 일부원래대로라면 3.0 GHz 이상으로 나와야 하는 MHz 값이 131이라는 매우 작은 값으로, 심지어 16개의 코어 모두에서 작은 값으로 보였습니다.
이 값은 /proc/cpuinfo 혹은 lscpu 명령을 통해서 확인할 수 있습니다.
이에 하드웨어 상의 문제를 의심하게 되었습니다. 하드웨어 상의 문제는 AWS를 사용하는 고객의 입장에서는 처리할 수 없었기 때문에 위 데이터를 바탕으로 하드웨어에 대한 점검을 요청했습니다.
AWS에는 위와 같이 CPU MHz 정보가 제대로 나오지 않은 경우 아래와 같이 시도해 보길 가이드하고 있습니다.
https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/processor_state_control.html#turbo-perf
turbostat이라는 명령을 통해서 CPU에 최대 부하를 주고 CPU MHz가 정상으로 회복되기를 요청하는 작업인데요, 위 작업이 CPU MHz에 영향을 주는 이유를 알기 위해서는 CPU의 C-State와 P-State에 대해 이해해야 합니다. 간단히 이야기하면 C-State는 CPU의 잠자기 단계를, P-State는 잠에서 깬 후 얼마나 열심히 일하게 하느냐의 단계를 의미합니다. 이를 이해하기 위한 가장 좋은 그림은 아래와 같습니다.
C-State와 P-State의 관계 (이미지 출처 : http://lunatine.net/2015/01/06/rhel6-intel_idle-and-c-states/)해당 이슈에 대해 조금 더 깊이 있게 이해하고 싶으신 분들은 제가 너무나 존경하는 루나틴님의 블로그를 참고하시기 바랍니다.
http://lunatine.net/2015/01/06/rhel6-intel_idle-and-c-states/
문제 해결
잘못된 CPU MHz에 대한 정보를 주고, turbostat 명령 실행 후에도 회복되지 않는 CPU MHz 정보를 전달한 후 AWS 측으로부터 답변이 왔습니다.
서포트 티켓 메시지최종적으로 EC2가 사용하던 하드웨어에 문제가 있음이 확인되었고, 그로 인해 발생한 문제였습니다. AWS에서 이슈 확인 후 즉각적인 조치를 취해주어서 이후로는 같은 문제가 발생하지 않았습니다.
마치며
아마 첫 번째 이슈가 발생했을 때 다른 프로세스들의 CPU 사용률을 꼼꼼하게 지켜보았다면 더 빨리 해결할 수 있었을 것입니다. 급한 마음에 JAVA 프로세스의 이슈로만 보았고, 그로 인해 빨리 해결할 수도 있었을 문제를 실제로는 한 달 정도 걸려서 해결했습니다. 이렇게 이상 동작하는 EC2가 발생한다면 삭제하고 다시 만들어서 해결할 수도 있지만, 문제의 원인을 파악하고 해결하기 위해 노력하는 것도 좋은 경험이 될 수 있습니다.
CPU와 관련된 문제가 있을 경우 프로세스들의 오동작을 확인하고 CPU 자체에 대해서도 확인할 것.
저희가 이번 일을 통해 얻게 된 교훈입니다.
