5. (개념) 해당 프로젝트를 하며 궁금한 것들 (AWS + Flask + 계산기 서버 구축해보기)
우리가 최종적으로 만들어야 하는 구조는 아래와 같다.
해당 구조와 앞선 (AWS + Flask + 계산기 서버 구축해보기) 1~4를 따라왔다면 여러 가지 의문을 품을 수 있다.
ㆍApache2(Web Server)에 WSGI와 Flask가 필요한 이유?
우선 Apache2 등 웹서버(Web Server)는 정적인 파일밖에 처리하지 못한다. HTML , 이미지, JS 등이 포함된다. 즉, DB에서 데이터를 가져와 HTML에 삽입하는 등의 기능을 하지 못한다.
실제 우리가 보는 웹 서비스의 형태가 되려면 웹 서버와 같은 정적인 소프트웨어만으로는 구현이 불가하다. 그래서 웹서버와 함께 애플리케이션(Web Application)을 추가로 적용하는 것이고, 이에는 Flask 등의 프레임워크가 만드는 역할을 한다.
Apache2는 Python언어를 읽을 수 없기 때문에 Apache2와 Flask는 직접적으로 연동하지 못한다.(다른 WebServer도 마찬가지이다.) 그래서 미들웨어인 WSGI를 통해 데이터를 주고받는다.
웹서버에 동적 페이지 요청이 발생하면 웹 서버는 WSGI 서버를 호출하고 WSGI 서버는 다시 WSGI 애플리케이션을 호출한다. 여기서 알 수 있는 중요한 사실은 실제 동적 페이지 요청은 결국 WSGI 애플리케이션(FLASK, Djnago)이 처리한다는 점이다. WSGI 애플리케이션에는 장고(Django), 플라스크(Flask) 등이 있다. 파이보 시스템이 사용할 WSGI 애플리케이션은 우리가 지금껏 공부해온 장고이다.
WSGI 서버는 웹 서버와 WSGI 애플리케이션 중간에 위치한다. 그래서 WSGI 서버는 WSGI 미들웨어(middleware) 또는 WSGI 컨테이너(container)라고도 한다.
4-09 WSGI
장고 서버를 구동하기 위해 지금까지는 `python manager.py runserver` 처럼 장고의 내장 서버를 구동하는 방식을 사용했다. [[TIP(점프 투 장 ...
wikidocs.net
ㆍ그렇다면 WSGI와 Flask만 있으면 되지 않나?
우리는 Flask만으로 사용자가 접속 가능함을 보였다. 그럼 Apache라는 웹 서버는 왜 필요한가? 왜 다들 웹 서버가 앞에 있는 구조인가? 이는 프레임워크마다 이유가 있겠지만 우선 Flask입장에서는 다음과 같다.
Flask를 실행했을 때 다들 아래와 같은 메시지를 보았을 것이다. 여기서 WARNING: This is a development server. Do not user it in a production deployment. Use a production WSGI server intead ( 개발 서버입니다. 프로덕션 배포에서는 사용하지 마십시오. 대신 WSGI 서버 사용 )
이는 개발서버로 실행된다. 그렇기에 효율적, 안정적 또는 보안을 위해 설계되지 않았다. 또한 Flask만으로는 하나의 요청밖에 처리하지 못한다. 그래서 WSGI 서버를 필요로 한다.(사실 필수는 아닌데 필수다.) (아래의 Flask 공식 문서 참조)
그리고 Apache의 SSL, VirtualHost 같은 편리한 기능을 추가적으로 사용할 수 있는 것도 Apache와 Flask를 연동하는 이유이다.
Deploying to Production — Flask Documentation (2.2.x)
Deploying to Production After developing your application, you’ll want to make it available publicly to other users. When you’re developing locally, you’re probably using the built-in development server, debugger, and reloader. These should not be us
flask.palletsprojects.com
ㆍWSGI는 무엇이고, WSGI는 WAS인가?
WSGI는 CGI(Common Gateway Interface)의 일종이다. CGI는 Web Server에서 애플리케이션을 작동시키기 위한 '인터페이스'이다. 들어오는 요청을 연결해주는 역할만 한다. 고로 Web Server가 Flask를 실행시키는 것이다. 요청이 들어올 때마다 fork를 통해 프로그램을 계속해서 복제한다. 이는 단점이기도 한데, 요청이 들어올 때마다 DB Connection을 매번 열어줘야 한다. 이는 메모리를 많이 잡아먹는다.
WAS는 Web Server + CGI의 형식이다. 여기에는 Tomcat 등이 있는데, WAS는 스레드를 실행시켜 동적 콘텐츠를 만드므로. WAS는 CGI보다 메모리를 덜 잡아먹게 되고, 속도도 더 빠르다. 또한 웹앱 서버인 WAS가 애플리케이션을 직접 실행한다는 점이 있다.
결론적으로 CGI와 WAS의 차이점은 아래와 같다.
CGI는 요청이 올 때마다 프로세스를 실행시켜 동적 콘텐츠를 만든다. WAS는 스레드를 실행시켜 동적 콘텐츠를 만든다. 그래서 WAS는 CGI보다 메모리를 덜 잡아먹게 되고, 속도도 더 빠르다.
Flask나 Django는 WSGI를 지원하고, Spring boot 등은 TomCat을 지원한다. 참고로 둘 다 미들웨어라는 큰 범주안에서 부르기도 한다.
아래 블로그를 많이 참조하여 작성하였다.
WSGI, CGI, ASGI란?
이번 프로젝트를 진행하면서 처음 들어본 WSGI에 대해 알아보다가 공부한 것들
velog.io