ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [Github Actions] self-hosted runner 사용 중 CICD 오류 및 EC2 ssh 접속 안 됨 해결 (원인: EC2 인스턴스 CPU사용량 100%) [AWS EC2]
    웹 개발/소소한 팁, 버그 해결 2024. 11. 21. 21:52

    이번에 회사에서 웹 수정하면서 서버가 다운되는 일이 발생하여 어째저째 해결했는데,

    나중에 같은 일을 겪을 분들을 위해 정리해보기로 했다.

     

    문제는 이제 클라이언트 쪽에서 새로 추가될 api를 사용하기 위해 서버 코드를 github에 업로드하면서 발생했다.

    지금 서버랑 클라이언트 모두 github actions을 이용해 CICD를 수행하고 있는데, 서버 쪽 CICD 과정이 덜컥 실패한 것이다.

    The self-hosted runner: {{name-of-runner}} lost communication with the server.
    Verify the machine is running and has a healthy network connection.
    Anything in your workflow that terminates the runner process, starves it for CPU/Memory,
    or blocks its network access can cause this error.

     

    확인해보니 서버가 갑자기 꺼져서 재부팅을 했지만, 여전히 작동하지 않았다.

    workflow를 재실행해보았지만, 이번에는 아예 runner가 작업을 실행하지 못하고 아래의 상태에서 머물렀다,.. Endless...

    Requested labels: self-hosted Job defined at: {{name-of-runner}}/.github/workflows/node.js.yml@refs/heads/main
    Waiting for a runner to pick up this job...

     

     

    그런데 이제 문제는, 우리가 지금 서비스하고 있는 어플리케이션이 사용하는 서버가 터졌다는 것...

    서버가 터진 순간부터 복구 전까지는 앱 및 웹 로그인 / 결제 등이 다 막혀 버려서 이 문제를 최대한 빠르게 해결해야 했다.

    프론트를 주로 맡긴 했지만 AWS 설정에 지분이 있었기에, 옆에 멘탈 터진 백엔드 개발자 복돋아서 함께 해결책을 찾아 나섰다.

     

    일단 복구가 우선이라 백엔드 개발자분이 재부팅했으나 여전히 안 됐고,

    터미널에서 ssh로 ec2 instance에 바로 접근해서 빌드하려 했으나 아예 접속이 안 됐다.

    그래서 2차 멘붕...이 왔지만,

    ssh가 접근이 안 된다는 말은 github actions 문제가 아니라 aws ec2 문제라는 뜻이라 AWS 쪽 디버깅을 시작했다.

     

     

    앞의 에러 메세지를 보았을 때, 네트워크 문제보다는 CPU/Memory 문제가 있을거라 판단해서

    AWS EC2 서비스에 들어가서 실행 중인 인스턴스를 모니터링 해보니, CPU 사용률이 100%를 찍고 있었다.

    (사진은 사태가 마무리된 후 캡쳐함)

    사진을 보면 백엔드 개발자분이 푸시한 시점에 갑자기 CPU 사용률이 100%를 찍은 것을 확인할 수 있다.

    오류가 해결된 뒤에 다시 푸시를 했을 땐 아무런 문제가 없었어서, 진짜 왜 발생한지 원인을 아직 모르겠다.

    (아시는 분은 댓글 부탁드려요...)

     

     

    암튼 이젠 저 CPU 사용률을 낮출 방법을 찾아야 했다.

    열심히 구글링해서 발견한 글...

     

    Why sometimes AWS EC2 works really slow?

    I do only one thing one this server - encoding videos by ffmpeg. And sometimes it does work ok, sometimes it's really slow. I run the same command just for a test: $ sudo time ffmpeg -i test.mp4 ...

    serverfault.com

     

    아무리 봐도 크레딧 문제는 아닌 것 같아 서버를 껐다 켜보았다.

    사실 앞서 살짝 언급했듯이 서버 문제라는 것을 알고 난 직후에 바로 서버를 재부팅 했으나 해결이 안 됐었는데,

    해당 글에는 재부팅이 아니라 서버를 아예 껐다가 켜보라고 적혀 있어 시도해볼만하고 판단했다.

     

    그런데, 살짝 걱정되는 부분은 서버를 중지했다가 다시 시작하면 퍼블릭 IPv4 주소가 바뀌는 것이었다.

    이전에 AWS 설정할 때 로드밸런서를 설정한 기억이 있어서 - 실제로 확인해보니까 잘 해놨음 깔깔,

    클라이언트 쪽은 문제가 없을 거라 판단해 고! 했음

     

    결과는 (반쯤) 성공적이었다...!

    CPU 사용률이 떨어지고 서버도 정상 작동했다.

    클라이언트 쪽도 문제가 없었음 (https://api.{{domain.com}} 으로 접근하도록 처리해둬서 괜찮았음)

     

    다만, 여전히 api를 사용하는 데는 문제가 있었는데

    이 부분은 mongoDB에서 사용하는 서버 IPv4 주소를 변경해주니까 해결되었다ㅏ.

     

    이렇게... 다사다난했던 한 시간이 지났다. 해결.. 완료..

     

     

    끝으로 정리를 하자면

     

    server repository의 github actions(CICD)가 동작하지 않는다면

    1. AWS EC2에서 연결된 인스턴스의 모니터링 탭에서 CPU 사용량을 확인한다.

    2. CPU 사용량이 100%(또는 그 근처)라면 서버 인스턴스를 중지한 후 다시 인스턴스 시작을 눌러 서버를 재시작한다.

    3. 클라이언트 및 데이터베이스에서 사용 중인 서버 IP 주소를 새로 바뀐 IP 주소로 변경한다.

     

    끗~