502 Bad Gateway
by HOON
Last updated on Oct. 9, 2024, 12:36 p.m.
오랜만에 docker-compose down 으로 서버를 내린 후 다시 올렸더니 502 에러가 발생했다.
드디어 올 것이 온 것인가 생각이 들었다. 그야 서버의 성능도 제일 값싼 걸로 했고, 현재 구조가 chatbot이 서버가 올라올때마다 훈련을 시작하기때문에 비효율적인 구조이기 때문이다.
당장은 시간이 없기때문에 서버를 만질 시간이 없어, 우선 서버라도 접속되도록 에러를 찾아보자.
nginx에서 에러가 발생했다는거 보니 nginx쪽에 문제가 있는 것 같아, logs와 config 파일을 살펴보았다.
Nginx Logs
로그를 분석해보니 이상하게도 Nginx에는 이상이 없었다.
이상하다. 분명히 서버에서는 Nginx에서 에러가 발생했다했는데 로그를 보니 이상이없다??
docker-compose logs로 전체 로그를 보자. (현재 스크린샷이 이슈가있어서 보이지 않습니다 ㅜㅜ)
이상하게 web 컨테이너에서 에러가 발생했다. [CRITICAL] WORKER TIMEOUT (pid:10)
시나리오 예상
간단하게 생각해보면 아래와 같다.
1. 클라이언트가 www.hongjunghoon.com 으로 접속 요청을 한다.
2. 먼저 Nginx에서 요청을 받고, 정적파일이 아닌경우 Gunicorn에 요청을 보낸다.
3. 요청받은 데이터가 뭔지 분석하고, 적절한 응답값을 보낸다.
근데 이 과정에서 nginx에는 문제가 없고 web 컨테이너에 문제가 생겼으니, 이 과정에서 문제가 생긴것같다.
현재 Nginx의 config 파일엔 적절한 타임아웃이 설정되어있다.
location / {
proxy_pass http://do_it_django;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
proxy_redirect off;
proxy_read_timeout 600s;
proxy_connect_timeout 600s;
proxy_send_timeout 600s;
send_timeout 600s;
}
nginx의 요청을 600초 동안 여유를 두겠다는 뜻이다.
그럼 600초면 10분인데 왜 중간에 처리가 끊겼을까??
바로 Gunicorn 때문이다.
Gunicorn 설정
구글링을 좀 해보니, 사실 Nginx에서만 600초까지 기다리고, Gunicorn은 디폴트 시간인 30s만 대기한다.
따라서 Gunicorn에 대한 설정값을 변경해주자. 여기도 최대 600s를 기다리도록 설정하자.
현재 나는 docker-compose 를 사용중이기때문에 docker-compose.yml 파일을 수정해야한다.
web:
build: .
command: gunicorn --workers 4 --timeout 600 do_it_django_prj.wsgi:application --bind 0.0.0.0:8000
gunicorn이 존재하는 web 컨테이너에서, 실행 명령어를 --timeout 600으로 줬다.
이렇게 해주면 Nginx <-> Gunicorn 에서 최대 600s의 timeout 이 걸려있게 된다. 따라서 엄청나게 느린 서버가 아닌이상 정상적으로 통신이 가능한걸 확인 할 수 있었다.
Leave a Comment: