WSGI란?
Web Server GateWay interface : 웹 서버 소프트웨어와 파이썬으로 작성된 웹 응용 프로그램 간의 표준 인터페이스이다.
파이썬 애플리케이션이 웹 서버와 통신하기 위한 인터페이스이다.웹 서버에서의 요청을 해석하여 파이썬 애플리케이션 쪽으로 던지는 역할을 수행한다.
- 웹서버는 파이썬 프로그램을 호출할 수 있는 기능이 없어서 사용
- 파이썬의 대표적인 WSGI는 uWSGI, Gunicorn이 존재한다.
- 두 개중 Gunicorn의 포퍼먼스가 조금 더 좋고 가볍다는 의견이 다수이다.
WSGI는 멀티 쓰레드를 만들 수 있기 때문에 Request요청이 많아지더라도 효율적으로 처리할 수 있다. 즉 production 환경에 적합하다.
- 파이썬은 멀티 쓰레드가 안된다. 자바는 가능!
WSGI는 CGI(Common GateWay Interface)의 일종으로 여러 언어 사용자들의 다양한 요청을 이해할 수 있도록 이를 공통된 규칙으로 변환하는 관문 역할을 하는 것이다.
CGI의 기본 동작 과정
1. input으로 HttpRequest를 받음
2. 요청에 대한 정보를 환경번수 형식으로 만들어 파이썬 스크립트의 stdin형식의 input으로 받음
3. 스크립트가 print와 같은 stdout형식으로 응답하면 HTTP형식으로 변환
정리 :
server/gateway side(Nginx 쪽)와 application/framework side(Django, flask쪽)를 둘 다 구현하고 있는 하나의 프로그램입니다. 서버에 대해선 어플리케이션 역할을 수행하고, 어플리케이션에 대해선 서버의 역할을 수행하는 셈이죠.
Gunicorn이란?
파이썬의 WSGI를 구현하는 HTTP server
Gunicorn은 Python WSGI로 WEB Server(Nginx)로부터 서버사이드 요청을 받으면 WSGI를 통해 서버 애플리케이션(Django)로 전달해주는 역할을 수행한다.
- 다수의 web 프레임워크와 널리 호환됨
- 구현이 심플하다.
- 서버 리소스가 적다
- 빠른 속도로 동작한다.
결론 : 웹서버와 Django(flask)사이에서 Request를 처리해주는 역할을 한다.
Nginx(웹 서버 Web Server)
웹 서버 : 클라이언트가 (웹 사이트에서) 무언가 요청하면 그에 대한 적절한 반응을 해주는 존재
Web Server Vs WAS
- 웹서버 -> 단순히 정적파일(이미지, html, css등 변하지 않는 파일 그자체)을 응답하는 존재
기능
- 정적인 컨텐츠 제공
- WAS를 거치지 않고 바로 자원을 제공한다
- 동적인 컨텐츠 제공을 위한 요청 전달
- 클라이언트의 요청(Request)을 WAS에 보내고, WAS가 처리한 결과를 클라이언트에게 전달(응답, Response)한다.
- WAS -> 동적 사이트를 전문적으로 처리하는 존재
- 동적인 처리는 클라이언트가 아이디, 패스워드를 넘겼을 때 하는 로그인 처리 또는 클라이언트 쿼리 파라미터에 따라 달라지는 DB 값 표시 등을 말합니다.
기능
- 프로그램 실행 환경과 DB 접속 기능 제공
- 여러 개의 트랜잭션(논리적인 작업 단위) 관리 기능
- 업무를 처리하는 비즈니스 로직 수행
웹 서버를 별도로 운영하는 이유
WAS의 부담을 줄여주기 위함이다. 기본적으로 정적인 파일들을 굳이 동적인 처리를 하는 WAS에서 담당할 필요가 없기 떄문!!!
Ngnix를 사용하는 이유
- 빠른 속도
- 동시 요청이 많아도 메모리 사용량이 현저히 적음
- 리버스 프록시로 사용가능
리버스 프록시란 인터넷과 백엔드 사이에 있는 서버를 가라킴(정보를 대신 전달해주는 주체)
- 클라이언트는 reverse proxy 를 실제 서버라고 생각하고 요청한다.
- 실제 서버의 IP가 유출되지 않는다. ==> 서버의 정보를 클라이언트로부터 숨길 수 있다
-
여러 WAS가 존재하면 클라이언트 요청을 여러 서버로 분산시키는 역할 수행 --> 로드 밸런싱
- 동시 커넥션을 유지하여 기존 요청을 계속 처리하면서 뒷단에 서버를 추가할 수 있는 것이다.
- 즉, 해야할 작업 및 요청을 적절히 분배시켜서 서버의 부하를 분산
-
캐싱 기능(WAS까지 요청하지 않아도 클라이언트 요청에 빠르게 응답)
-
민감한 WAS정보를 숨기는 보안 역할 수행
- SSL 지원
- HTTPS의 인증서 제공
- 웹페이지 접근 인증
- 로그인 정보(관리자, 사용자)를 WAS에서 하지 않고 Nginx에서도 가능
- 압축
- gzip을 사용하면 클라이언트가 보낸 텍스트 파일을 압축
- 비동기 처리
- Event loop기반으로 상당히 많은 트래픽을 동시에 처리가능
프로젝트 응용
Nginx, Gunicorn 서버 연결
-
wsgi.py
-
nginx/Dockerfile
-
nginx/nginx.conf
-
docker-compose.yml
요약
요약하자면, 로드 밸런서는 서버의 부하를 분산시켜 성능과 가용성을 향상시키는 역할을 하고, 리버스 프록시는 클라이언트와 서버 사이에서 요청을 중재하여 추가 기능을 제공하고 서버의 응답을 가공하여 클라이언트에게 전달하는 역할을 합니다. Nginx는 이러한 기능을 효과적으로 제공하는 웹 서버 및 리버스 프록시 서버로 널리 사용됩니다.
추후 nginx.conf
upstream api { # origin 서버라고도 한다. 여기서는 WAS를 의미하고, nginx는 downstream에 해당한다고 할 수 있다. 여러 서버를 지정해두고, weight 을 정할 수 있다.
server backend:8000;
}
server { #하나의 웹사이트를 선언하는데 사용된다. server 블록이 여러개이면, 한대의 머신(호스트)에 여러 웹사이트를 서빙할 수 있다.
listen 8080; #웹 사이트 포트
server_name localhost; # 클라이언트가 접속하는서버(주로 도메인)
charset utf-8;
location /api/ { #server 블록안에 등장해서, 특정 웹사이트의 url 을 처리하는데 사용한다.
proxy_pass http://api; # 요청을 전달할 서버의 주소를 작성하면 됩니다.
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; #현재까지 거쳐온 서버의 IP에 대한 정보(클라이언트의 IP를 알 수 잇음)
proxy_set_header X-Forwarded-Proto $scheme; # 클라이언트 요청 프로토콜
proxy_set_header Host $http_host;
proxy_read_timeout 300;
proxy_connect_timeout 300;
proxy_send_timeout 300;
proxy_http_version 1.1; # 리버스 프록시 웹소켓일때 사용해줘야함(이 줄 포함 밑에 3줄은 빼도됨)
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_redirect off;
}
location ~* (service-worker\.js)$ {
add_header 'Cache-Control' 'no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0';
expires off;
proxy_no_cache 1;
}
location / {
root /var/www/buyself-frontend;
try_files $uri $uri/ /index.html?q=$uri&$args;
}
}- nginx가 /api/로 들어오는 요청은 백엔드:8000번 서버에서 응답을 해주고 /로 들어오는 요청은 nginx에 들어있는 리액트 더미에서 정적인 데이터를 응답해줌
nginx.conf 작성법//nginx.conf 작성법2//nginx proxy module
