인스턴스 정상 실행 중 갑자기 나타나는 네트워크 에러

정말 큰일이 났었다. 사실 AWS의 EC2를 Elastic IP에 연결해서 웹을 배포하고 쓰고 있었는데 잘 작동을 했었다.

그래도 혹시나 버그나 찾아보려고 켜두고 이것저것 만지던 중 갑자기 나타난 에러…

Network error: Software caused connection abort

처음에는 뭐가 문젠지 몰랐다. 어디서 메모리 누수가 발생하는 건가? 아니면 학교 기숙사 와이파이가 불안정해서 그런가 하고 아무렇지도 않게 넘겼다. 문제는 이렇게 putty가 꺼지고 다시 접속하면 timeout 에러가 발생하면서 다시 들어가지지 않았다. 다시 들어가려면 aws의 ec2 인스턴스를 껐다가 켜야 됐었다. 인스턴스를 껐다가 다시 키는데도 몇분의 시간이 걸린다..

일단 인스턴스를 끄고 다시 키는 중에 에러의 원인을 구글링 해봤다. 여러 해결책이 있었지만 그중에 공통적으로 말하는 해결책은 바로 putty에 들어가서 Connection를 누르고 거기서 keepalives를 5~60으로 설정하고 enable tcp keepalives 또한 체크하는 것이다. 그리고 다시 스크립트를 실행시키고 한동안 지켜봤다.

But…

다시 나오는 Network 에러…

“대체 왜그러지?…“

stackoverflow에다가 질문을 올려보기도하고 stackexchange에 나오는 해결책도 참고를 했지만 소용이 없었다.

원인을 찾기 위해서는 어떤 작업을 한 다음에 다시 인스턴스를 껐다가 켜야하는데 그러기까지 시간이 너무 오래 걸려서 문제였다. 그러다가 aws 인스턴스의 문제인가 하고 상태 창을 봤더니 문제가 생기는 것을 볼 수 있었다.

Status Check을 보면 상태 체크가 실패한 것을 볼 수 있었다. 더 자세히 보기 위해서 클릭해서 들어갔지만 그렇게 도움이 되는 문구는 아니였다…

“Instance reachability check failed”

이게 대체 무슨 에러일까… 일단 일종의 인스턴스 연결성 문제인거 같은데 정확한 원인을 알 수 없었다. 그렇게 새로운 문구를 발견하고 다시 해결책을 찾으려고 구글링 했다.

마음에 드는 해결책은 전혀 찾을 수 없었다. 도저히 안되겠다 싶어서 AWS에 직접 문의를 해보려 하자..

돈을 내라고 한다…

돈도 많으면서 무슨 질문 하나 하는데 돈을 내래 ㅡㅡ..

하지만 이 상태로 갔다간 데모 때 큰일 날 수도 있어서 돈을 낼 것을 각오하고 질문을 했다. 한국어 질문을 지원하지 않을 것 같아서 애써서 영어로 질문했것만 ㅋㅋ 답변은 한국어로 왔다.

그래도 돈이 좋긴 좋다.. 돈 주고 질문하니까 답변이 엄청 자세하고 친절했다. 그렇게 쭉 읽어보다가 현타가 왔다. 문제는 내 프로그램이나 putty가 아니였다 ㅠㅠ

바로 인스턴스 타입이 문제였다. 분명히 내가 쓰는 인스턴스의 기본 스펙을 확인했는데 문제는 내가 확인한 것은 메모리이고 cpu 사용량을 간과했다는 것이였다.

내가 쓰는 t.micro 타입은 cpu가 1개에다가 base 사용량이 20%를 넘어가면 안되는데 사용량이 20%를 넘었던 모양이다.

“이 바보…“

나는 이 문제로 소중한 2~3일을 날렸다. 이럴 줄 알았으면 진작에 물어볼 걸 후회가 된다.

CloudWatch로 계속 확인을 했는데 cpu를 간과하다니..

다음에는 이런 실수를 하지 말아야겠다. 요즘들어 실수가 많아졌는데 반성을 해야겠다.