📌 Intro
Django EC2에서 django 배포하기
글에서 저는 ec2 ubuntu 환경에서 django를 배포할 때 wsgi를 위해 gunicorn을 썼습니다. wsgi가 뭔데 이걸 써서 배포를 했을까요?
WSGI를 알기 전에 우리는 먼저 Web Server와 WAS에 대해 알고 있어야 합니다. 이 부분에 대해선 다음번에 보다 심도 깊게 정리할 예정입니다. 지금은 간단하게 두개가 무엇인 지 뭐가 다른지 알아봐요.
Web Server
하드웨어 : Web 서버가 설치되어 있는 컴퓨터
💥 소프트웨어 : 웹 브라우저 클라이언트로부터 HTTP 요청을 받고, 정적인 컨텐츠(html,css 등)를 제공하는 컴퓨터 프로그램
여기서 저희는 소프트웨어의 개념으로 이해하시면 됩니다. 중요한 것은 정적인 컨텐츠를 제공한다는 점입니다. 그리고 동적 컨텐츠 제공을 위한 요청 전달을 한다는 것입니다.
종류 : Apache, Nginx 등
WAS
Web Application Server의 약자로서, DB조회 및 다양한 로직 처리 요구사 동적인 컨텐츠를 제공하기 위해 만들어진 애플리케이션 서버
HTTP를 통해 애플리케이션을 수행해주는 미들웨어입니다.WAS = 웹서버 + 웹컨테이너
웹 서버의 기능들을 구조적으로 분리하여 처리하는 역할을 합니다.
- 주요기능
- 프로그램 실행 환경 및 DB 접속 기능 제공
- 여러 트랜잭션 관리 기능
- 업무 처리하는 비즈니스 로직 수행
그래서?
user ⬅➡ Web Server ⬅➡ Web Application ⬅➡ DB
이게 일반적인 구조라고 할 수 있습니다. 그런데 Python으로 코드를 짜는 Django의 경우는 Web Server와 Web Application 간에 또다른 미들웨어가 존재해야 합니다.
그게 바로 WSGI 입니다.
📌 WSGI?
Web Server Gateway InterFace의 약자로써 파이썬 스크립트(웹 어플리케이션)가 웹 서버와 통신하기 위한 인터페이스입니다.
WSGI는 서버와 앱 양단으로 나뉘어져 있습니다. SWGI 리퀘스트를 처리하려면 서버에서 환경정보와 콜백함수를 앱에 제공해야합니다. 앱은 그 요청을 처리하고 콜백함수를 통해 서버에 응답합니다.
➡
Web Service 를 개발하다 보면 공통적으로 필요한 기능들이 있는데, Authentication, Routing, Session, Cookie, Error Page 보여주기, ... 와 같은 기능들이다.
WSGI Middleware 는 Middleware 라는 이름처럼 Web Application 의 실행 전과 후에 이러한 기능들을 추가해주는 녀석이며, 그 자체로도 WSGI Application 이다.
주요기능
- 환경변수가 바뀌면 타겟 URL에 따라서 리퀘스트의 경로를 지정해줍니다.
- 같은 프로세스에서 여러 애플리케이션과 프레임워크가 실행됩니다.
- XSLT 스타일시트를 적용하는 것과 같이 전처리합니다.
종류
uwsgi, gunicorn 등이 있습니다.
-
uwsgi
.... 추가적으로 공부가 더 필요하네요.. -
gunicorn
Nginx 는 주로 Buffering, Reverse Proxying, Load Balancing 등의 기능을 위해 Gunicorn 앞단에 배치하고,Gunicorn 은 Django 로 작성한 Web Application 에 HTTP 요청을 전달해주는 역할의 WSGI HTTP Server 로서 사용하는 것이다.Gunicorn 을 사용할 땐 worker process 의 개수와 worker class(async 방식인 Gevent, Tornado, ...)를 설정하여 요청 처리 성능을 높일 수 있다.
추가
참고로 gunicorn, uwsgi 모두 Web Server의 역할을 하지만 그럼에도 불구하고 앞단에 nginx를 쓰는 이유는 DDos 공격방지, static file전송 효율성 등이 있습니다. 그리고 gunicorn document에서도 말하고 있는 nginx buffering기능때문입니다.
nginx에도 설명이 잘나와있지만 nginx buffering에 대해 좀더 설명하자면,
client - nginx - app servers
이 구조에서 client에 response를 전송하는데 nginx buffer가 없고 클라이언트가 response 패킷을 천천히 받으면 그 영향이 app server한테까지 끼쳐서 그 process는 블락이되어 다른 패킷을 처리 못하게 됩니다.
하지만 nginx buffer가 있다면 nginx는 app server에게 response패킷을 모두 받을때까지 client에게 응답하지 않고 app server에게 다 받은후 client에게 응답을 보냅니다. 따라서 slow client를 만나더라도 app server는 블락이 되지않을 수 있는것이죠.
➡
이 부분 이해를 다 못했네요. 추가적으로 더 공부를 해야겠습니다.
📌 참고
