Django 구성에 대한 이해

본 내용 중 틀린 부분이 있다면 피드백 부탁드리겠습니다.

출처: https://itmining.tistory.com/135 [IT 마이닝]해당 블로그의 내용이 주를 이루며

Two Scoops of Django에서 내용을 보강하였습니다.

Django

• Django는 Django만의 웹 서버를 사용한다.
• 개발 목적으로 python으로 짜여진 가벼운 wsgi(Web Server Gateway Interface)를 사용한다.
• Django는 runserver를 통해 웹 서버와 웹 애플리케이션 서버 역할을 한다. 프로덕션 레벨에서는 하면 안된다고 문서에 써있습니다.

WAS (Web Application Server)

웹 서버 위에 서버 애플리케이션을 얹은 것이다. 동적 리소스 처리를 위해 사용한다. (물론, 정적 처리도 가능하다.)

웹 서버와(Nginx) 웹 애플리케이션(Django)간의 연결을 중계 (Nginx에서 받은 요청을 Django에서 처리하기 위한 중계인 역할을 한다. )

Nginx는 python을 모르기 때문에, uWSGI는 HTTP request를 python으로, Django로 부터 받은 response를 Nginx가 알 수 있도록 변환해준다.

WSGI Server

웹 서버와 파이썬을 사용한 웹 애플리케이션 개발 환경간의 인터페이스에 대한 표준 규칙이며 파이썬의 웹 애플리케이션 서버이다

Django에서는 일반적으로 uWSGI나 Gunicorn을 Nginx에 연동한다.

WSGI는 웹서버와 웹 애플리케이션(또는 프레임워크) 간에 호환성있는 웹 애플리케이션 개발환경을 만들기 위해 로우-레벨 인터페이스로 만들어졌다.

WSGI는 보통 서버 사이드와 게이트웨이 사이드(Nginx, Apache 등)을 가진다. 그리고 애플리케이션 또는 프레임워크 사이드와 통신한다.

WSGI 요청을 처리하기 위해서 서버 사이드는 애플리케이션을 실행하고, 환경정보를 제공하며 콜백 함수를 애플리케이션 사이드에 전달한다.

그러면 애플리케이션은 요청을 실행하고, 전달받은 콜백 함수를 통하여 응답을 서버 사이드에 넘겨준다.

서버와 애플리케이션은 요청을 실행하고 전달받은 콜백 함수를 통하여 응답을 서버사이드에 넘겨준다.

서버와 애플리케이션 사이에서, 양방향의 API를 실행할 수 있는 WSGI 미들웨어가 사용되기도 한다. 서버는 클라이언트의 요청을 받아, 미들웨어에 넘겨준다. 미들웨어가 요청을 처리한 후에는 요청을 애플리케이션에 보낸다. 애플리케이션에서 나온 응답은 다시 미들웨어를 통해 서버와 궁극적으로 클라이언트 측에 전달된다. WSGI 친화적인 애플리케이션에서는 이러한 미들웨어 여러 개가 스택을 이루어 사용된다.

Web Server, Web Application Server

그렇다면 WAS만 쓰면 되지 어째서 웹서버를 따로 쓰느냐는 의문이 생길 수 있다. 그 이유는 목적이 다르기 때문이다. 웹 서버는 정적인 데이터만 처리하는 서버이다. 이미지나 단순 html파일과 같은 리소스를 제공하는 서버는 웹 서버를 통하면 WAS를 이용하는 것보다 빠르고 안정적이다. WAS는 동적인 데이터를 처리하는 서버이다. DB와 연결되어 데이터를 주고 받거나 프로그램으로 데이터 조작이 필요한 경우에는 WAS를 활용 해야 한다. 실무에서는 둘 다를 연동해서 사용한다. 정적 처리는 웹서버에서, 동적 처리는 WAS에서 처리한다.

이것에 대한 의문이 생기었다. 톰캣은 5.5부터 스태틱 파일의 처리를 지원한다. uwsgi, gunicorn 도 한번 찾아보도록 하겠다.