때는 Vi.NO 런칭까지 1주일도 안남을때였습니다.. 필자는 휴대폰만 울리면 항상 두려운 맘을 가지고 알림을 확인했습니다.. 그럼 가장 무서운 메시지가 와있었습니다.
💬 프론트: 서버가 죽었어요..ㅠㅠㅠㅠ
원인
바로 필자는 컴퓨터에 앉아서 로그를 뜯어보고 원인을 파악했습니다. 저희가 사용하는 서버는 aws의 Elastic beanstalk을 사용하고 였습니다. 팀원들과 원인을 찾아본 결과 다음과 같은 가설들이 나왔습니다.
로직 상 부하를 주는 로직이 있다.
- 오토 스케일링이 자주 작동이 되어서 502가 나는거다
- 서버 용량이 부족하다
- 메모리가 부족하다.
먼저 1번 가설에 따라 부하를 주는 기능들을 살펴 본 결과, GPT 요약 과 유튜브 스크립트 추출은 각각 GPT와 클로바 노트를 쓰기 때문에, 서버에 부하를 주지 않으며, 가장 유력한 가능성이 있는건, FFMPEG를 이용해 mp3를 생성하고, 네이버 스토리지에 올리는 기능이었습니다. 실제로 서버에 파일을 저장했다가 올리면서 삭제하기 때문이죠. 그렇게 되면서 2번 가설로 이어졌습니다.
2번 가설에 따라 서버에 부하가 되면서 그 순간, 스케일업이 진행되었고, 그 동안은 502를 응답으로 줬다고 판단했습니다. 그럼 서버가 왜 아파하는가 파악하기 위해 3번 가설과 2번 가설을 검증했습니다.
Q1) 서버용량 부족?
저희가 사용하는 elastic beanstalk의 인스턴스는 t3.micro로 가장 용량과 메모리가 적은 인스턴스입니다. 8GB의 스토리지와 1GB의 메모리를 가지고 있죠. 먼저 서버 캐시들이 쌓였기때문에 점차 무리를 주는것이 아닌가 싶어 서버의 스토리지를 8GB => 16GB로 업그레이드 했습니다.
하지만 업그레이드 한 뒤 10분도 안되서 서버가 터졌다는 메시지를 받음으로써, 서버 용량 부족은 아닌것 같다라는 판단이 들어서, 다음은 메모리를 조사했습니다.
Q2) 메모리 부족?
메모리를 보기 위해서 SSH를 이용해 해당 인스턴스에 접속해서 로그를 뜯어봤습니다.
free 명령어를 통해 메모리를 보니, 스왑 메모리 설정을 제외하고, 가능한 메모리가 222mb밖에 되지 않았습니다. 사용을 하지 않을때가 222mb밖에 남지 않았으므로, FFMPEG를 사용하게 된다면 메모리 부족이 될 가능성이 크다. 가 확실해진 것 같았습니다.
메모리 부족!
그러다가 elastic beanstalk에서 제공하는 로그파일을 뜯어보던중 한 로그를 발견하게 됩니다.
"System has too much memory"
역시나 메모리 부족 문제였습니다!
이제 원인을 알았으니 해결을 해봅시다.
해결
가장 첫번째 방법은 Swap Memory를 사용하는 것이었습니다. swap Memory를 활용해 메모리가 부족할 시, 배정된 보조메모리의 용량을 가져와 주 메모리에 할당해서 쓰는 방식이죠.
window의 가상 메모리 설정을 생각해주시면 됩니다. 하지만 큰 효과를 보지 못했습니다.
최후의 방법으로는 인스턴스를 업그레이드 하는 방법이었습니다.
단지 이 방법이 최후의 방법인 이유는 바로, 온디멘드 인스턴스를 한단계 업그레이드 할때 마다 , 시간당 요금이 2배가 된다는 점이었습니다.
그렇기에, 고민하면서 다른 방법들을 찾아보았지만 적합한 해결책이 없었기에 t3.micro에서t3.small로 업그레이드 했습니다. 따라서, 서버에 할당된 메모리는 2g로 늘어났고, 502 또한 발생하지 않게 되었습니다.
결론
서버를 최적화하는것은 굉장히 중요한 일입니다. 아무리 좋은 기능이 있어도, 서버가 터지면 아무 소용도 없기 때문이죠. 실제로 이번 경우는 인스턴스 메모리가 워낙 적었기 때문에 생긴 문제였지만, 실제 업무에서 메모리가 4gib, 8gib인데 메모리 부족이 뜬다면, 서버 로직상 문제가 있는 지 확인해보는 것이 좋을 것 같습니다.
