그간 개인 및 팀 프로젝트를 진행하면서 두어번 정도 Azure 서비스를 이용해 배포를 진행해보았다. 하지만 데이터 흐름을 이해하지 못한 채로 일단 VM에서 돌아가게 하기가 목표였다 보니 배포해놓고도 모르는 점이 너무 많았다. 때문에 이번 주차 스터디 주제를 '배포 기반 지식 이해하기'로 잡고 관련 내용을 쭉 정리해본다.
우선 파이썬 백엔드와 관련된 용어를 살피며 웹 데이터의 전체적인 흐름부터 알아보자.
Web Server 와 Web Application Server
보통 Web server와 Web Application을 엄격히 구분할 수 있을 것처럼 말하지만, 사실 둘은 웹사이트가 사용자 요청을 받아 처리하게끔 동작한다는 점에서 동일한 목적을 갖는다. 게다가 웹 서버가 앱 서버의 기능을 수행한다거나 그 반대의 경우도 있어서 초심자(나다)들은 뭐가 뭔지 헷갈리기 쉬운데, 웹의 역사와 데이터 흐름을 들여다보면 의외로 이해가 쉽다.
웹의 동작 방식
- 웹 브라우저가 정적 페이지를 요청한다 > 웹 서버에서 처리
- 웹 브라우저가 동적 페이지를 요청한다 > WSGI 서버 호출 > WSGI 앱 서버(파이썬 프로그램) 호출
저 그림 그리느라 30분 걸렸다.
여튼, 초기 웹은 이미지처럼 변하지 않는 정적인(static) 페이지로 이루어진 경우가 대다수였다. 그러나 시간이 흐르면서 사용자 정보를 입력받거나 실시간으로 변하는 정보를 표현해야 할 필요성이 생겼고, 그에 따라 동적인(dynamic) 페이지를 제공하기 위해 앱 서버를 이용하게 된다. 이때 웹 서버와 앱 서버 사이에서 통역사 역할을 해주는 애들이 WSGI. 자세한 내용은 아래로.
-
웹 서버
인터넷을 통해 클라이언트가 요청한 웹 컨텐츠를 전달하는 하드웨어와 소프트웨어의 통칭. 정적인 콘텐츠(HTML pages, files, images, videos 등) 요청을 처리한다. Apach HTTP Server, Nginix 등이 있다. -
CGI(Common Gateway Interface) / WSGI(Web Server Gateway Interface)
CGI나 WSGI나 웹 서버와 웹 애플리케이션이 소통하기 위한 인터페이스로서의 역할을 한다. 다만 CGI는 매번 다시 스크립트를 수행해 메모리에 적재하는 과정에서 추가적인 시간 소용이 발생하는 등의 문제가 있었고, 이 단점을 해결한 방법이 2003년에 등장한 Python 표준(PEP333, Python Web Server Gateway Interface v1.0)인 WSGI다.
또, Authentication, Routing, Session, Cookie, Error Page 등의 기능을 웹앱 실행 전후로 추가해주는 것을 WSGI Middleware라고 하며, 라이브러리로 uWSGI, Gunicorn, Werkzeug 등이 있다. uWSGI, Gunicorn, Werkzeug은 자체적으로 Web server의 역할을 수행할 수도 있기 때문에 WSGI Server나 Stand alone WSGI Container라고도 불린다.
참고로 Flask는 기본적으로 Werkzeug 기반이라, 디버깅하다 보면 아래처럼 Werkzeug 화면이 뜬다.
Flask 공식문서 - Flask는 Werkzeug 와 Jinja2 라이브러리에 의존적이다. Werkzeug는 웹어플리케이션과 다양한 서버 사이의 개발과 배포를 위한 표준 파이썬 인터페이스인 WSGI를 구현한 툴킷이다.
- 웹 애플리케이션(WSGI 애플리케이션) 서버
동적인 콘텐츠 요청을 처리한다(비즈니스 로직을 수행한다고 표현) 우리가 아는 Flask가 바로 웹 애플리케이션 프레임워크.
그간 배포를 진행할 때마다 ngnix, gunicorn 관련 설정을 해야했던 이유가 위와 같다. 그럼 이제 실제로 배포를 진행해볼 텐데, 그건 다음 장에서 계속~!
[출처]
https://www.nginx.com/resources/glossary/application-server-vs-web-server/
https://wikidocs.net/81076
https://gmlwjd9405.github.io/2018/10/27/webserver-vs-was.html
