Django에 uWSGI랑 Nginx 결합하기

Django가 제공하는 manage.py runserver 커맨드로도 간단한 웹 서버를 구동할 수 있다. 공식 홈페이지 튜토리얼에 따르면 "Pure" Python으로 작성된 웹 서버라고 한다. 하지만 실서비스를 배포할때 쓰기에는 부적절하다고 한다. 간단한만큼 기능이 부족할 수도 있겠고, 성능 문제도 있을 것이다.

그래서 실서비스를 배포할때는 기존에 개발되어서 많은 사람들이 사용하고 있는 웹 서버와 웹 어플리케이션 서버를 Django와 결합시켜서 쓴다. 그렇다면 어떤 웹 서버와 어떤 웹 어플리케이션 서버를 사용할 것인가?

박영록님이 쓴 "스타트업을 위한 기술 스택" 이라는 글을 참고서로 삼았다. 웹 서버에는 Apache 보다 Nginx를 더 추천하였기에 이를 골랐다. 웹 어플리케이션 서버는 사용하는 언어와 웹 서버에 따라 결정되는 부분이 있나보다. Python을 사용하고 Nginx를 사용한다면 uWSGI를 추천한다고 하여 선택했다.

---

이제 선택을 했으니 직접 결합해볼 차례이다. 이미 웹 상에 Django와 uWSGI, Nginx를 결합하는 방법에 대한 좋은 자료들이 많이 있다(그럼에도 포스트를 남기는 것은, 개인적인 기록을 위해서....). 여러 자료들을 살펴봤는데, 아래 자료가 필요한 최소한의 내용을 가장 담백하게 담고 있는 듯 하다.

How To Serve Django Applications with uWSGI and Nginx on Ubuntu 14.04

서버 컴퓨터로 사용할 머신을 구한 뒤, Ubuntu Server OS를 설치하고, 위 링크 본문을 따라서 진행하면 Django가 기본으로 제공하는 웹 사이트를 클라이언트 PC의 브라우저에서 확인할 수 있다.

본문을 따라하면서 맞닿뜨린 몇가지 이슈:

1) AWS EC2 Instance를 사용할 경우, ./manage.py runserver 0.0.0.0:8000 같이 Django 커맨드만으로 특정 포트 번호를 모든 IP에게 개방하는 것이 불가능하다. EC2 Instance의 security group으로 접속을 제한하기 때문. 그러니 브라우저로 서버에 접속하기 위해서는 security group에서 새로운 rule을 추가해줘야한다.

2) 본문에서는 Domain name을 구매했음을 가정했다. 도메인을 구매하지 않았으므로 AWS EC2 Instance의 Public IP 주소를 가지고 브라우저에서 접속한다. 그 경우에는 Nginx configuration 파일을 작성할때 server 디렉티브의 server_name parameter를 적지않으면 된다.

3) 본문에서는 8000번 포트로 접속하게끔 Nginx를 설정했다. Nginx에 기본적으로 default server의 디렉티브가 기술되어있는데 여기서 HTTP 프로토콜 고유의 80번 포트를 담당하기 때문인듯하다. 그러므로 Domain_Name:8000으로는 접속이 되지만, Domain_Name 자체로 접속할 경우 Nginx의 default HTML 페이지를 만나게 된다. 이를 해결하기 위해서는 sites-enabled 디렉토리에서 default를 삭제해주면 된다(sudo rm default). sites-available 디렉토리에 configuration file을 작성하고, sites-enabled에 link 시키는 구조이므로 sites-enabled에서 삭제해도 configuration file 본문은 sites-available에 남아있다. 

본문을 읽으면서 접하게 된 개념 간단 정리:

• uWSGI

application container server(application server)의 일종이다. application으로 향하는 길목의 (WSGI 형식의) interface 역할을 맡는다. 클라이언트의 HTTP 요청을 (우리의 경우 Python Web Framework인 Django로 application을 개발했으므로) application이 처리할 수 있는 Python 호출로 번역하는 역할을 맡는다.

• Nginx

web server의 일종이다. 클라이언트와 uWSGI 사이에 위치하여 클라이언트의 요청을 uWSGI에게 Reverse Proxy 해주는 역할을 맡는다. Reverse Proxy에 대해서 자세히 모르지만, 위상적으로 생각해보면 앞단에 들어오는 여러 다발(클라이언트는 여러명)의 요청을 한다발(Nginx와 uWSGI를 사이의 연결은 하나)로 묶어서 뒷단에 전달해준다고 생각해볼 수 있겠다. 또한 정적 컨텐츠를 처리할때는 Nginx의 performance가 더 뛰어나고, security feature 면에서도 뛰어나기 때문에 Nginx가 잘하는 부분은 Nginx에게 맡기는 것이다.