1️⃣ 문제 상황
올해 3,4월부터 문제없이 운영되던 node.js EC2 서버가 이번 달 10월에 갑자기 “인스턴스 상태 검사 실패” 상태가 되는 이슈가 생겼다. 지난주와 오늘까지 2번이나 서버 접속 불가 제보를 받았기에 급히 원인 파악에 나섰다.
확실히 실제 유저가 사용하는 서버를 운영해보니 이런저런 트러블 슈팅을 할 수 있는 것 같아서 참 좋다!
✔️AWS EC2 - 상태 검사 상태 확인
상태 검사 탭에 가면 시스템 상태 검사는 통과하고, 인스턴스 연결성 검사에 실패한 문구를 볼 수 있다.
[인스턴스 연결성 검사 실패] 2023/10/24 21:52 GMT+9 (about 4 hours)
- 인스턴스 상태 확인 실패의 원인은 아래와 같다.
- 운영 체제 부팅 실패
- 올바른 볼륨 탑재 실패
- CPU 및 메모리 소진
- 커널 패닉
- 네트워크가 작동하지 않음
✔️원인 분석
이와같은 문제를 만났다면 꼭 인스턴스 재부팅을 하기전에 시스템 로그를 백업해두어야한다.
재부팅을 해버리면 보통 문제가 해결되기 때문에 이전 에러 로그가 날아가버려서 원인 분석을 하지 못한다. (다른 방법이 있을 지도 모르지만 필자는 발견하지 못했음)
1) 인스턴스 상태-모니터링 및 문제해결 - 시스템 로그 가져오기 로 이동
2) 해당 시스템 로그에 EC2에 생긴 오류의 원인이 어딘가엔 써져있다.
아래 AWS 문서에 보면 어떤식으로 로그가 남겨지는지 자세히 적혀있다. 필자 같은경우엔 오류 예시를 하나하나 찾아가며 파악했다.
- 시스템 로그 관련 AWS DOCS : https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstances.html#InitialSteps
살펴보면 메모리, 장치, 커널, 파일 시스템, 운영체제 오류에 대한 로그가 어떤식으로 나타나고 어떻게 해결할 수 있는지 나와있다.
Troubleshoot instances with failed status checks - Amazon Elastic Compute Cloud
On some systems, you disable SELinux by setting SELINUX=disabled in the /mount_point/etc/sysconfig/selinux file, where mount_point is the location that you mounted the volume on your recovery instance.
docs.aws.amazon.com
3) 시스템 로그에서 아래와 같은 Out of memory: Killed process 메모리 부족 로그를 확인했다.
아래와 같이 [메모리 부족: 프로세스 종료] 로그를 발견하였다. 메모리 부족으로 인해 PM2 프로세스를 kill했다는 로그를 발견함.
4) 그렇다면 해결법은?
AWS 문서에 해당 부분에 대한 해결법이 아래와 같이 나와있다.
결론적으로는, 인스턴스 유형을 더 큰 메모리를 가진 것으로 업그레이드 하거나 아니면 그냥 재부팅해서 해결하라는 것 같다.
2️⃣해결 과정
1) 일단, 인스턴스 상태 검사 실패는 [인스턴스 재시작]을 하면 웬만하면 해결된다. 이렇게 해서 서버 복구를 시킨다.
- 대신 재시작 하기 전에 [시스템 로그 가져오기]로 원인을 파악을 확인해 보고 재시작해야한다.
2) 메모리 부족같은 경우에는, 우리 사이드 프로젝트에선 비용적인 부담을 줄여야하기 때문에 일단은 재부팅으로 해결했지만, 실무였다면((데브옵스를 안쓰는)) 인스턴스 유형 업그레이드를 고려해야할 것으로 보인다.
추가로, 실무에서는 대부분 Kubernetes를 사용하니까, 쿠버네티스에서 기본으로 제공하는 HPA(Horizontal Pod Autoscaler)로 해결될 수 있지 않을까?
- HPA는 CPU 사용률을 기반으로 디플로이먼트로 실행된 pod의 개수를 자동으로 늘리거나 줄이는 역할을 해준다.
- targetCPUUtilizationPercentage로 CPU 사용률이 몇 %가 됐을때 오토스케일링을 적용하라고 설정할 수 있다. 이때 최대와 최소 pod 개수까지 설정하는 식으로 오토스케일링을 관리할 수 있다.
ex) kubectl autoscale deployment kubernetes-simple-app --cpu-percent=30 --min=1 --max=20
3) 아무튼, 우리 프로젝트에선 EC2를 재부팅하면 문제가 없어지고, pm2로 node 서버를 시작하고나면 메모리 부족으로 이어지는 것이니까, 기존의 PM2에서 클러스터를 4개로 운영하던 방식에서 클러스터 개수를 조정하여 운영하는 방식을 시도했다. 존재하는 자원으로 최대한 해결해야하니까 이 방법부터 시도해본다.
이 방안으로 23/10/25 이후로 현 인스턴스 유형 t2.micro에서 메모리 부족 문제의 빈도가 줄어드는지 확인해볼 예정이다.
아직 풀리지 않은 궁금증...주절 주절(검증된 이야기가 아니니 무시)
3월에 릴리즈를 한 이후로 개발 서버에 추가된 내용은 없는데, memory가 10월에 갑자기 부족한 이유는 무엇일까?
- 메모리 부족으로 pm2 서버가 10월에 갑자기 2번정도 강제 종료되었음. 활동유저가 훨씬 많았던 초창기에는 이런적이 한번도 없었는데.
너무 오래쓰면 메모리가 닳나…..?……아닐거같은데…아니면 ec2 메모리랑 rds에 저장된 데이터 크기랑 연관이 되나…? 아닐거같은데….서버내에서 점점 불러와야하는 데이터의 크기가 커져서 그런가..?예를 들면 게시글 전체 개수가 늘어나면 조회할때 더 많이 가져와야해서..?일시적으로 메모리 확 늘어나는..?
Anyway,
AWS 서버에 대한 깊은 공부가 필요하다! 얼른 실무에서 쿠버네티스로 데브옵스 만져보고싶다! 끝
