한 4일 전 쯤에, AWS에서 ACM 인증서를 발급 받고 웹 사이트에 https 접속을 받을 수 있게 되어서 굉장히 뿌듯해 하고 있었습니다. 그리고 이 뿌듯한 마음을 가지고 백 엔드 작업을 룰루랄라 신나게(?)하고 있었는데 갑자기 웹 사이트가 nginx 502: Bad Gateway 에러를 꽥 뱉으면서 접속이 되지 않았습니다.
처음 nginx 설정을 하기 전에도 출력되었던 화면이어서 하루 정도면 해결할 수 있는 문제라고 생각하고 pm2, nginx의 에러로그를 하나하나 편-안한 마음으로 살펴보았습니다. 하지만 하루종일 노트북을 두들겨 봐도 에러는 결국 해결되지 않았습니다. 다음 날에도 에러를 수정하려고 로그에 대해 구글링을 해봤지만 적당한 해결책을 찾을 수 없었고, 하나의 에러를 해결하면 또 다른 에러로그가 발견되는 상황이 반복되었습니다.
[추측1] MySQL DB서버의 연결에 문제가 생겼을 것이다.
제일 처음에 확인한 건 pm2의 에러로그입니다. pm2 log 명령어를 통해 로그를 확인해 보았더니 "Connection lost: The server closed the connection"라는 로그를 발견할 수 있었습니다. 그래서 MySQL DB서버가 종료되었거나 연결이 끊겨서 생기는 에러라는 생각을 하게되었고, 이 방법을 이용해서 DB서버와 연결이 끊어져 있으면 다시 연결을 시도하는 코드를 프로젝트 내에 추가했습니다.
그런데도 502: Bad Gateway 오류는 계속 발생하였고 조금 더 찾아보니 이는 DB서버와 연결문제와 관련된 것이 아니라는 걸 알게 되어서 다른 원인을 추측하기 시작했습니다.
[추측2] 얼마 전 발급받은 SSL인증과 관련해서 nginx 설정을 잘못했을 것이다.
에러가 발생하기 직전에 제가 프로젝트에 추가한 내용이 SSL- HTTPS 인증이었기 때문에 그 다음으로 의심해 본 것이 nginx 설정이었습니다. 원래 SSL 인증을 받고 https접속을 받기 위해서는 nginx에 설정을 추가하는 작업이 필요한데 저는 그 작업을 하지 않았습니다. 까먹어서 안 한건 아니고, ACM으로 인증서를 발급받고 ELB로 https접속을 받는 경우에는 nginx에 설정을 추가 할 필요가 없다고 들었기 때문입니다.
tail -f /var/log/nginx/error.log
위 명령어를 통해 nginx의 에러로그를 확인하니 "connect() failed (111: Connection refused) while connecting to upstream..." 라는 로그가 출력되었습니다. 이와 관련해서는 원인도 매우 다양하기 때문에 Stackoverflow를 참고해서 거의 할 수 있는 방법은 모두 따라해보았습니다. 하지만 그래도 502:Bad Gateway 문제는 해결되지 않았고 이번에는 AWS ELB를 의심해보기 시작했습니다.
아 그리고 이 과정을 통해서, 'ACM으로 인증서를 발급받고 ELB로 https접속을 받는 경우에는 nginx에 설정을 추가 할 필요가 없다'는 게 맞는 말이라는 걸 알게 되었습니다!
[추측3] EC2 ELB에서 오류가 발생하였을 것이다.
nginx 에러로그를 살펴보다가 이번에는 'GET / HTTP / 1.1..' 이 부분에 집중해서 '어떤 HTTP 요청을 제대로 못받는 건가?'라고 생각하게 되었습니다. 마침 AWS에서는 Classic Load Balancer(ELB) 를 사용하는 도중에 발생하는 HTTP 502에러에 대해 에러의 원인과 해결방법을 이 링크에서 알려주고 있었고, 저 또한 이 중에 제 에러를 해결 할 방법이 있을 것이라고 생각하기 시작했습니다.
하지만 저는 AWS의 로드 밸런서를 그저 https연결을 위한 도구로만 사용하였고 진짜 로드밸런서의 역할로는 사용해 본 적이 없기 때문에 생각보다 내용을 이해하기가 너무 어려웠습니다. 그래서 그냥 서버 컴퓨터 내 파일과 ELB를 모두 지우고 처음부터 다시 생성해 보자는 결론에 도달합니다,,
[추측4] Git과 관련하여, 서버의 원격저장소 내 파일에 오류가 생겼을 것이다.
서버 컴퓨터 내 파일을 모두 지우는 도중에 문득 한 가지 의심이 더 생겨났습니다. 거의 서버 컴퓨터를 처음 생성할 때 부터 Git 과 관련하여 발생하던 오류가 있었는데 이게 문제의 원인일 수도 있게다는 생각이었습니다. 사실 이전에도 매일같이 출력되던 에러였지만 웹 사이트가 이상하게 작동하던 적은 단 한번도 없었기 때문에 신경을 안 쓰고 있었습니다. 그래도 혹시나 하는 마음에 서버 컴퓨터 내 git repository 를 깔끔하게 삭제하고 git clone을 통해 디렉토리를 다시 생성하였습니다.
오우.. 그랬더니 nginx, git, DB와 관련된 모든 에러들이 깔끔하게 사라지고 웹 사이트가 너무나 정상적으로 작동했습니다. 알고보니 제가 Git의 동작 원리를 대충 알고있는 상태에서 서버 컴퓨터 내에서 명령어를 작성하다가 repository 내 파일 일부가 변경되서 발생한 문제였습니다.
[결론] 에러를 해결하면서 느낀 점
이렇게 포스팅을 하게 된 이유는, 이번에 겪은 일을 글로 적어두지 않으면 다음번에 또 이런 비슷한 오류를 만나게 될 것 같다는 생각 때문입니다. 그리고 이번 일을 계기로 작은 에러가 나더라도 일단 그 에러를 해결한 뒤에 다음 단계로 넘어가야 겠다는 생각이 많이 들었습니다. 처음에는 아무것도 아닌 것 같았던 Git 에러가 나비효과처럼 커져서 nginx, 그리고 또 다른 곳의 에러로 이어질 수 있으니까요 :(
또, 서버 컴퓨터 내 파일들을 함부로 수정하거나 추가하지 말자는 생각도 들었습니다. 제가 현재 진행하고 있는 프로젝트가 아직은 아주 복잡한 단계는 아니기 때문에 서버 컴퓨터 내 수정할 내용이 생기면 서버 컴퓨터 내에서 직접 작업을 진행하곤 했습니다. 근데 이러면 에러가 발생했을 때 뒤로 되돌리기도 힘들고 어디서, 언제 에러가 났는지도 찾기 힘들기 때문에 이번에도 더 고생을 한 것 같습니다. 이제는 로컬에서 작업을 모두 끝내고, 서버 컴퓨터는 이렇게 작업한 결과를 pull만 하는 형태로 좀 더 서버 컴퓨터를 조심히 다뤄야 겠다고 느꼈습니다.