주로 uwsgi를 보통 이용하는데 gunicorn을 한 번 공부할겸 정리하게 되었습니다.

Gunicorn 설정

wsgi app 설정

gunicorn을 실행하기 위해서는 wsgi 모듈과 매핑할 필요가 있습니다.

$(MODULE_NAME):$(VARIABLE_NAME) 와 같이 설정할 수 있습니다. django의 경우에는 wsgi 모듈 경로를 첫 번째 인자에 입력하고 두 번째 인자에 wsgi 애플리케이션 객체 변수 이름을 입력해주면 됩니다.

gunicorn <모듈 이름>:<변수 이름>

bind

바인드될 주소와 포트 또한 설정할 수 있습니다.
default는 로컬 ip의 8000 포트입니다.

--bind 0.0.0.0:443
or 
--b 0.0.0.0:80

Process, Thread 설정

gunicorn은 Master Process가 Worker Process를 Fork하여 관리하고, Worker Process가 실제 요청을 받아 로직을 수행하는 역할을 담당합니다.
Worker Process의 개수와 클래스를 목적에 맞춰 설정하는 것이 중요합니다.

공식 사이트를 참고하면 2 * number of cpu core + 1 만큼 프로세스를 설정하는 것을 추천하고 있습니다.

thread worker를 사용할 thread 의 개수는 num_core * (2~4)의 값을 권장하고 있습니다.

로그

Gunicorn은 access, error 두 가지 로그를 제공하고 있습니다.
로그 파일 경로 설정은 아래와 같이 설정할 수 있습니다.

--access-logfile /home/ubuntu/logs/gunicorn-access.log
--error-logfile /home/ubuntu/logs/gunicorn-error.log

최대 요청 (메모리) 관리

api 요청을 처리할 때마다 요청을 처리한 worker 프로세스에서 메모리 누수 현상이 발견되었습니다.
gunicorn을 이용할 때 꽤나 빈번하게 발생하는 문제라고 합니다.

이럴 때에는 max-requests 설정을 통해 최대 요청 개수를 설정하고 최대 요청 개수에 도달했을 때 도달한 프로세스만을 재시작하여 메모리를 리프레시하는 방식으로 해결이 가능합니다. 만약 여러 프로세스가 동시에 max-request 한계치에 도달하여 재시작하게 되는 경우에는 요청을 처리하는 시간이 늦어지는 것을 방지하기 위해 max-requests-jitter 설정으로 프로세스 별로 max-requests 설정 값에 난수를 더하여 max-request를 설정하도록 도와줄 수 있습니다.
근본적으로 문제가 발생하는 원인을 해결하는 방안은 아니지만 메모리 누수 문제로 인해 더 커질 수 있는 문제가 생기는 것을 방지할 수 있는 좋은 선택입니다. 설정 값은 운영 상황에서 평균적으로 몇 번의 요청에 얼만큼의 누수가 일어나는 지를 잘 고려하여 설정하면 됩니다.

명령어는 다음과 같습니다.

--max-requests [최대 요청 수]
--max-requests-jitter [난수 최대값]

번외로 max-request를 사용하는 것 이외에도 특정 api에서 메모리에 잔여 데이터가 계속 쌓이는 것이 발견된다면 python의 가비지 컬렉터 모듈을 사용하여 수동으로 메모리를 비워주는 것도 하나의 방법이 될 수 있습니다.

reload

reload 설정을 하게 되면 Directory의 소스 코드가 변경되었을 시에 자동으로 gunicorn 서비스가 reload 됩니다.

로컬에서 개발할때 유용한 옵션이므로 가장 많이 사용하게 되는 옵션입니다.

--reload