API 서버 배포 삽질기

새로운 프로젝트를 맡아서 api 서버개발을 했다.
회사에 서버개발하는 사람이 나밖에 없어서 서버구축 - api 설계 - 코드 작성 - 배포 다 나 혼자 한다....리뷰도 셀프^^ ...
아무튼 django restframework로 api 개발을 마치고, 이 블로그를 참조하여 docker-compose를 사용해서 nginx, gunicorn을 사용하는 컨테이너를 만들었다. 테스트해보니까 로컬에선 venv + runserver 혹은 docker-compose up로 서버 띄워서 테스트시 양쪽 다 내가 의도한대로 잘 돌아가길래 이제 배포만 하면 되겠구나! 하고 배포했다.
배포의 경우엔 AWS ec2에 저장소 코드를 올리고, 여기에 어플리케이션 로드밸런서를 붙인 후,  route53에서 이미 생성되어있는 호스팅 영역에 해당 로드밸런서를 가리키는 레코드를 생성했다.
그렇게 해서 해당 url을 입력했더니 첫 화면이 성공적으로 나와서 배포 끝! 이라고 생각하고 집에 갔는데.....
다음날 다시 와서 테스트해보니 GET 요청만 되고 POST 요청만 날리면 아래와 같은 메시지가 등장하는 것이다..!   

web_1    | [2021-03-03 07:45:40 +0000] [8] [CRITICAL] WORKER TIMEOUT (pid:12)
nginx_1  | 2021/03/03 07:45:41 [error] 30#30: *22 upstream prematurely closed connection while reading response header from upstream, client: {client_ip}, server: localhost, request: "POST /auth/api-token-auth/ HTTP/1.1", upstream: "http://{ip}:8000/auth/api-token-auth/", host: {domain}
[03/Mar/2021:09:13:45 +0000] "GET / HTTP/1.1" 400 154 "-" "ELB-HealthChecker/2.0"

아악!!!!
 아직 nginx, gunicorn, docker등에 두려움이 있는 나로선 암담했다. 위에서 말했듯이 회사에 서버개발자는 나뿐이라 다른 분한테 말한다 해도 도움을 줄 수 있는 사람은 없다^^
일단 처음에는 엔진엑스상에서 업스트림 설정을 잘못한건가 했는데 찾아보니 구니콘 이슈들이 쭉 나오길래 구니콘 이슈로 가정하고 관련해서 서칭을 해봤고 이와 관련해서 시도해봤다.

docker-compose.yml 상의 오리지널 구니콘 command

• gunicorn project.wsgi:application --bind 0.0.0.0:8000

1. 구니콘의 timeout 시간이 짧다고 해서 해당 시간을 늘려봤다 (효과없음)
   • 변경된 커맨드: gunicorn --timeout 300 project.wsgi:application --bind 0.0.0.0:8000
   • 의미 없다...좀 더 대기타주기는 하는듯...근데 어차피 빨리 실패하나 늦게 실패하나 무슨 의미가 있지..?
2. 구니콘의 워커 수를 늘려봤다.(효과없음)
   • 변경된 커맨드: gunicorn --timeout 300 --workers 5 project.wsgi:application --bind 0.0.0.0:8000
   • 난리났다. 워커수가 늘어나면서 위 에러 메세지의 마지막에 있는 로드밸런서의 헬스체크 에러메세지가 더 빠르게 증식하기 시작했다. 흑흑....
3. 구니콘의 워커 종류를 바꿔봤다. (효과 없음)
   • 구니콘의 디폴트 워커는 sync라는 녀석인데 이 디폴트를 사용하면 비동기 처리가 안 되서 요청 처리가 어렵다나 뭐라나. 그래서 비동기 워커인 gevent 등을 사용한다고 한다. 솔직히 이게 해결책은 아니란걸 알았지만 일단 세팅해봤다.
   • 변경된 커맨드: gunicorn -k gevent --timeout 300 workers 5  --access-logfile gunicorn.log seocho.wsgi:application --bind 0.0.0.0:8000
   • 정말 놀라울 정도로 아무 일도 일어나지 않았다. 이럴줄 알았지만 기적이 일어나길 바랬어..

흠....구니콘 문제는 아닌 것 같다. 그 다음 뇌피셜로 자꾸 헬스체크하고 실패하는게 뜨는데 혹시 이 요청이 너무 자주 떠서 정작 필요한 내 요청에 쓰일 자원을 먹는게 아닐까? 하는 가설을 세워보았다.

그래서 찾아본 헬스체크 세팅 관련 스택 오버플로우 링크! 결과는 역시 아무 일이 없었다고 한다.

 결국엔 개발 오픈 톡방에 질문을 했는데 감사하게도 다른 분들이 도와주셔서 일단 첫 페이지나 GET요청이 잘 먹는거봐선 엔진엑스나 구니콘 관련 문제보다는 어플리케이션 단에서 발생하는 에러를 확인해보는 것이 좋겠다는 실마리를 얻었다!

 그래서 docker-compose up -d 대신 runserver로 띄워봤는데 웬걸, 데이터베이스를 못 찾고 있었다.

 AWS RDS에서 잘 돌고있고, 로컬에선 잘만 연결되던 postgresql이 왜 이런가, 하고 검색해보니 알고보니 RDS의 VPC-보안그룹의 설정 문제였다. 여기의 인바운드 규칙을 어디에서나 접근 가능하도록 해줘야했는데, 안 한 바람에 EC2에서 접근이 불가능했던 것이다.

 그래서 이걸 아래와 같이 수정해줬다.

 

그리고 다시 서버를 실행시켜보니까 잘 돌아간다!!

이로써 이번의 배포 삽질기는 끝. 

 

사실 해결하고 나서야 드는 생각이지만 GET요청은 되는데 POST요청이 안 되는 시점에서 웹서버 관련 세팅이 문제라기 보단 데이터베이스 연결쪽에 문제가 있다는걸 파악했어야만 했다. 애초에 서버 세팅이 문제였으면 첫 페이지가 뜨지도 않았을텐데...혼자서 해야한다는 생각에 너무 허둥대버린 듯.

 

- 이번엔 쓸모 없었지만 언젠간 도움이 될지도 몰라서... : NGINX 502 Bad Gateway: Gunicorn