[aws] 드디어 때가 되었다, 반쯤 죽어 눈을 반만 뜬 나의 인스턴스를 살릴 시간이..(ec2 인스턴스 상태검사 1/2통과, 인스턴스 연결성 검사 실패)

0. 상황

    - Docker compose로 java 어플리케이션을 3개 올려놓은 내 ec2 인스턴스는, docker compose를 up 한 뒤 24시간 이내로 CPU가 튀면서 인스턴스 상태검사에 실패하고, 배포 사이트 접속은 물론 ssh 접속마저 불가능해지는 이슈가 있었다.

인스턴스 연결성 검사에 실패

    - 모니터링을 확인해보니, compose up을 실행한 후 하루가 되지 않아 실제로 cpu 사용율과 cpu크레딧 사용량이 튀면서 더이상 네트워크 패킷이 정상적으로 오가지 않는 것을 확인할 수 있었다.

cpu 사용율이 100%까지 올라갔다. 오 멋져. 처음으로 인스턴스를 full로 쓰네요?

cpu 크레딧 사용량도 8개 이상으로 튀었다. 이야 cpu 8개까지 될수있는 멋쟁이 내 인스턴스

cpu가 튄 이후로 네트워크 입력이 들어오지 않는 것을 확인 할 수 있었다. 흑흑 울지말고 말해봐

1. 에러코드 전문

    - 일단...로그를 뺄 수 있을까? 시도해 보자

---

2. 원인

    - Amazon ec2는 아래 세 가지 상태 확인을 통해 각 ec2 인스턴스 상태를 모니터링한다.

        1. 시스템 상태 확인

           - 시스템 상태 확인이 실패한 경우, AWS에서 문제를 해결할 때까지 기다리거나 문제를 직접 해결할 수 있습니다.

- 네트워크 연결 끊김
- 시스템 전원 중단
- 물리적 호스트의 소프트웨어 문제
- 네트워크 연결성에 영향을 주는 물리적 호스트의 하드웨어 문제

 

        2. 인스턴스 상태 확인

           - 인스턴스 상태 확인이 실패할 경우에는 일반적으로 사용자가 인스턴스를 재부팅하거나 인스턴스 구성을 변경하는 등의 방법으로 문제를 직접 해결해야 합니다.

- 시스템 상태 확인 실패
- 잘못된 네트워킹 또는 스타트업 구성
- 메모리가 모두 사용됨
- 파일 시스템 손상
- 호환되지 않는 커널

 

        3. 연결 된 EBS 상태 확인

          - 연결된 EBS 상태 확인 지표가 실패하면 AWS에서 문제가 해결될 때까지 기다리거나 영향을 받는 볼륨의 교체 또는 인스턴스 중지 후 재시작 등의 조치를 취할 수 있습니다.

- EBS 볼륨의 기반이 되는 스토리지 하위 시스템의 하드웨어 또는 소프트웨어 문제
- EBS 볼륨의 연결성에 영향을 주는 물리적 호스트의 하드웨어 문제
- 인스턴스와 EBS 볼륨 간의 연결 문제

 

 

내 경우에는 2번 인스턴스 상태 확인이 실패한 경우였으며, 그중에서도 '메모리가 모두 사용됨'이 의심되었다.

메모리가 100% 사용된 이후에는, 인스턴스 상태검사의 fail이 계속해서 유지되는 건지 한번 확인해봐야 할 것 같다.

---

3. 해결방안

    - AWS문서에서 말하듯이 우선 인스턴스를 재시작 한 뒤, log를 확인해보고자 했다.

 

1. 인스턴스 재부팅

2. 시스템 로그 가져오기

 

---

4. 결과

    - system log를 빼서 어떤 문제가 있었는지 추론할 수 있었다.

      로그를 통해, 시스템 메모리가 부족하여 OOM Killer가 Java 프로세스를 종료시킨 것을 확인했다.

      하지만... ssh 접속이 안 되는 이유는 뭘까? oom killer가 종료시킨 프로세스 중에 sshd는 포함되지 않은 것 같은데,, 이 부분은 추가로 확인이 필요할 것 같다.

 

관련해서 AWS의 System log Error별 대응 방법 문서를 참고하였다.

잠재적인 원인 : 메모리 소진(부족)

 

권장 대응

    - 1) 인스턴스를 중지한 후, 더 크거나 메모리 최적화된 인스턴스로 변경하여 새로 인스턴스를 시작합니다.

    - 2) 인스턴스를 재시작 합니다.(인스턴스를 변경하지 않으면 문제가 다시 발생 할 수 있습니다.)

 

내 경우에는 인스턴스 크기를 키워서 운영하기에는 트래픽이 거의 없는 개인 포트폴리오용 사이트들이기에 비용적 측면에서 낭비라고 생각했으며, 더불어 메모리 부족 현상이 docker compose로 동시에 띄워진 3개 server들의  Full GC로 인한 이슈로 생각됨으로, 우선은 GC log를 확인해보고, Full GC로 인한 이슈가 맞다면 JVM 메모리를 제한하는 설정을 추가하고 인스턴스에 swap 메모리를 지정하는 방법으로 해결을 시도해볼 예정이다.

 

5. 추후 학습

메모리 관련 이슈는 EC2 t4g.micro 인스턴스에 java application을 3개 올림 + nginx + docker compose를 통한 구동이 원인이 되지 않았을까 추측된다. 이와 관련된 [Java] GC log 확인하기(내 가녀린 EC2인스턴스는 정말 GC때문에 죽는게 맞을까?,  [JVM] JVM Heap Memory size, JVM 힙(heap) 크기 조정 과 [aws, memory] Ubuntu swap memory 설정하기(feat. aws ec2) 는 각각 해당 글에서 자세하게 다뤄보고자 한다..!