[Django] 장고 웹서비스의-이해
django 프로젝트 구성
장고를 이용해 웹서비스를 구성할 때 보통 다음과 같은 구조를 가진다고 합니다. 기본적으로 WSGI Web Application Server 하단 부분을 구현하게 되는데, 상단의 웹 서버와 웹 애플리케이션 서버에 대한 궁금증으로 조사해본 결과를 공유합니다.
Web Server가 뭔데?
웹서버는 다른 말로 HTTP Server라고도 부른다. 웹브라우저의 카운터 파트너로서 서버 쪽에서 정보를 제공하는 소프트웨어를 의미한다. 클라이언트로부터의 HTTP요청을 받아 정적인 페이지/파일을 돌려준다. (동적인 부분은 WSGI가 담당. 아래에서 다룹니다.) 가벼움과 높은 성능을 목표로 한다. 웹 서버, 리버스 프록시 및 메일 프록시 기능을 가진다. 대표적인 웹서버는 Apache, Nginx가 있다.
Nginx가 뭐지?
NGINX는 차세대 웹서버로 불린다. 위의 그래프를 통해서 알 수 있듯이 Apache의 독주에 제동을 걸고 있다. NGINX의 특징은 한마디로 정의하면 아래와 같다.
더 적은 자원으로 더 빠르게 데이터를 서비스 할 수 있다.
NGINX와 Apache의 관계
Apache는 웹의 산증인이라고 해도 과언이 아니다. 위의 그래프에 따르면 1996년 이래로 한번도 1등의 자리를 놓친적이 없다. 오픈소스이고, 무료로 사용할 수 있는 소프트웨어인 아파치가 웹을 지탱하고 있다고해도 과언이 아니다. 하지만, 아파치는 오래전에 만들어진 소프트웨어다. 아파치가 만들어진 시대의 요구사항이 이제는 유효하지 않은 것도 있고, 새로운 요구사항과 충돌하는 것도 있을 것이다. 그렇다고 과거의 유산을 청산하고 마냥 새로운 시대의 요구사항만 쫒아갈수는 없는 것이다.
NGINX는 새로운 시대의 요청에 부응해서 만들어진 웹서버이다. 개발의 모든 목적이 높은 성능에 맞춰져 있다. 그리고 잘 사용하지 않는 기능은 과감하게 제외했다. 덕분에 폭발적인 증가세에 있는 인터넷 서비스를 지탱하는데 적합하다.
Django는 웹 서버야?
장고는 장고만의 웹서버를 사용한다. 개발 목적으로 python으로 짜여진 가벼운 wsgi(web server gateway interface)를 사용한다. 그렇다. 장고도 웹서버인 것이다. (정확하게 얘기하자면, 장고 자체는 웹 프레임워크이고 runserver를 통해 웹 서버와 웹 애플리케이션 서버 역할을 하는 것.) 하지만 프로덕션 과정에서는 사용하지 않는 것을 추천한다.
DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through security audits or performance tests. (We’re in the business of making Web frameworks, not Web servers, so improving this server to be able to handle a production environment is outside the scope of Django.) 이 서버를 프로덕션 세팅에서 사용하지마라. 이것은 보안 검수나 퍼포먼스 테스트를 통과하지 않았다. (우리는 웹 서버를 만드려는게 아니고 웹 프레임워크를 만들었고, 그렇기 때문에 프로덕션 환경에서 서버를 향상시키고 싶다면 장고 외의 서버를 사용하라. )
WAS(Web Application Server)는 뭔데?
간단하게 말해 웹 서버 위에 서버 어플리케이션을 얹은 것. 동적 리소스 처리를 위해 사용. (정적 처리도 가능하긴 함) 웹 서버(Nginx)와 웹 애플리케이션(Django)간의 연결을 중계 (Nginx에서 받은 요청을 Django에서 처리하기 위한 중계인 역할을 해준다.) Nginx는 Python을 모르기 때문에 uWSGI는 HTTP 요청을 python으로, Django로 부터 받은 응답을 Nginx가 알 수 있도록 변환해준다.
WSGI 서버는 뭔데?
웹서버와 파이썬을 사용한 웹 어플리케이션 개발환경 간의 인터페이스에 대한 표준 규칙. 파이썬의 웹 어플리케이션 서버! 파이썬으로 선택할 수 있는 웹 프레임워크에서 사용할 수 있는 기존 웹서버는 CGI, FastCGI, mod_python, 또는 커스텀으로 만들어진 API 등으로 상당히 제한되어 있었다. 또 반대로 웹서버를 선택하는 것이 파이썬 웹개발환경을 제한하기도 하였다. 이를 위해 표준으로 나온 것이 WSGI이다.
WSGI는 웹서버와 웹 어플리케이션(또는 프레임워크) 간에 호환성있는 웹 어플리케이션 개발환경을 만들기 위해 로우-레벨 인터페이스로 만들어졌다.
WSGI는 보통 서버 사이드와 게이트웨이 사이드(Nginx, Apache 등)를 가진다. 그리고 어플리케이션 또는 프레임워크 사이드와 통신한다. WSGI 요청을 처리하기 위해서 서버사이드는 어플리케이션을 실행하고 환경정보를 제공하며, 콜백 함수를 어플리케이션 사이드에 전달한다. 그러면 어플리케이션은 요청을 실행하고 전달받은 콜백 함수를 통하여 응답을 서버사이드에 넘겨준다.
서버와 어플리케이션 사이에서, 양방향의 API를 실행할 수 있는 WSGI 미들웨어 (이하 미들웨어, middleware)가 사용되기도 한다. 서버는 클라이언트의 요청을 받아 미들웨어에 넘겨준다. 미들웨어가 요청을 처리한 후에는 요청을 어플리케이션에 보낸다. 어플리케이션에서 나온 응답은 다시 미들웨어를 통해 서버와 궁극적으로 클라이언트 측에 전달된다. WSGI 친화적인 어플리케이션에서는 이러한 미들웨어 여러 개가 스택을 이루어 사용될 수 있다.
Web Server와 Web Application Server
그렇다면 WAS만 쓰면 되지 어째서 웹서버를 따로 쓰느냐는 의문이 생길 수 있다. 그 이유는 목적이 다르기 때문이다. 웹 서버는 정적인 데이터만 처리하는 서버이다. 이미지나 단순 html파일과 같은 리소스를 제공하는 서버는 웹 서버를 통하면 WAS를 이용하는 것보다 빠르고 안정적이다. WAS는 동적인 데이터를 처리하는 서버이다. DB와 연결되어 데이터를 주고 받거나 프로그램으로 데이터 조작이 필요한 경우에는 WAS를 활용 해야 한다. 실무에서는 둘 다를 연동해서 사용한다. 정적 처리는 웹서버에서, 동적 처리는 WAS에서 처리한다.