Django Lifecycle
WSGI
WSGI는 Web Server Gateway Inteface이다.
WSGI는 프로토콜로 웹 서버와 웹 애플리케이션 간의 통신 표준이다.
웰 서버는 웹 애플리케이션과 대화(요청)하는 방법을 알아야 하며,
웹 애플리케이션은 웹 서버에 대화(응답)하는 방법을 알아야 한다.
즉, 둘 다 이해할 수 있는 표준을 사용해야 하는 것이다.
예를 들면 쿠키, 세션, 인증, 라우팅과 같은 웹 환경에서 공통으로 사용하는 것들이 있다!
WSGI는 웹 서버와 웹 애플리케이션 간 통신, 웹 서버가 웹 애플리케이션과 상호작용하는 방법에 대한 간단하고 보편적인 Protocol이다.
Nodejs, Java는?
Nodejs는 내장된 HTTP 서버가 직접적으로 요청을 처리한다.
Java는 서블릿 컨테이너를 활용하여 웹 서버 통신할 수 있게 도와준다.
서블릿 컨테이너가 소켓을 만들고 웹 서버와 손 쉽게 통신할 수 있게 해준다!
pep3333
pep3333 Abstract의 요약은 아래와 같다.
Abstract
This document specifies a proposed standard interface between web servers and Python web applications or frameworks, to promote web application portability across a variety of web servers.
다양한 웹 서버에서 파이썬 웹 애플리케이션, 프레임워크 간의 이식성을 위해 표준 인터페이스 지정을 위해 제안된 문서라고 한다.
✅ 즉, 파이썬을 이용하는 곳이 많아지면서 다양한 웹 서버와 소통하는 표준을 정립하기 위해 제안된 것이다!
Django runserver
runserver는 로컬 환경에서 가벼운 개발 전용 웹 서버를 시작해주는 명령어이다.
runserver는 WSGI_APPLICATION 설정으로 지정된 WSGI 애플리케이션 Object를 사용한다.
Django Docs를 보면 아래와 같은 주의점이 나온다.
DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through security audits or performance tests. (And that’s how it’s gonna stay. 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.)
⚠️ 해당 웹 서버를 프로덕션 환경에서 사용하지 마라
보안 감사나 성능 테스트를 거치지 않았다!(Django는 웹 서버가 아닌 웹 프레임 워크를 만드는 사업을 하는 팀이다. Django에서 제공하는 웹 서버를 프로덕션 환경에서 처리할 수 있또록 개발하는 것은 우리 팀의 영역이 아니다.)
Original Rationale and Goals (from PEP 333)의 중간에 아래와 같은 이야기가 나온다.
😤 이를 참고하면 Django팀이 위와 같이 Docs에 작성해 놓은 것이 이해가 된다!
This PEP, therefore, proposes a simple and universal interface between web servers and web applications or frameworks: the Python Web Server Gateway Interface (WSGI).
But the mere existence of a WSGI spec does nothing to address the existing state of servers and frameworks for Python web applications. Server and framework authors and maintainers must actually implement WSGI for there to be any effect.
However, since no existing servers or frameworks support WSGI, there is little immediate reward for an author who implements WSGI support. Thus, WSGI must be easy to implement, so that an author’s initial investment in the interface can be reasonably low.
...
기존 서버에 존재하는 서버나 프레임워크가 WSGI를 지원하고 있지 않기에 WSGI를 구현하는 개발자에게는 보상이 거의 없다. 그렇기에 WSGI 구현은 쉬워야 인터페이스를 구현하는 사람에 대한 투자 비용이 낮아지게 될 것이다.
...
인터페이스의 단순성이 가장 중요하며 WSGI 설계의 주요한 기준이 된다.
Gunicorn, uWSGI
Gunicorn은 Gunicorn은 UNIX용 Python WSGI HTTP server로 Green Unicorn의 약자이다.
uWSGI는 universal Web Server Gateway Interface의 약자이다.
Gunicorn과 uWSGI는 Python 웹 어플리케이션 프로덕트 환경을 지원해주기 나온 호스팅 서버이다.
즉, Web Server와 Python Application 서버 사이에 위치하며 두 서버의 상호 운용을 도와주는 역할을 하는 것이다.
정리
Python이 다양한 부문으로 진출하고 사용되면서 Web Server와 통신하기 위한 일관성 있는 규율이 필요해 졌다.
그러한 Gateway Interface pep333 -> pep3333로 제안되었고 이런 서비스를 제공하는 것들 중 Gunicorn uWSGI runserver 등이 있다.
Django Lifecycle 중 진입점이 wsgi.py인데 아래와 같은 코드로 되어 있다.
import django
from django.core.handlers.wsgi import WSGIHandler
def get_wsgi_application():
"""
The public interface to Django's WSGI support. Return a WSGI callable.
Avoids making django.core.handlers.WSGIHandler a public API, in case the
internal WSGI implementation changes or moves in the future.
"""
django.setup(set_prefix=False)
return WSGIHandler()파이썬 인터프리터가 해당 코드를 실행하면서 wsgi application을 얻게 되는 것 같다 :)
참고자료
