장고 프로젝트 배포하기 (pythonanywhere 과 AWS EC2)

챗봇 프로젝트에서 만든 스킬을 배포하면서 알게된 내용들을 정리해 보려고 한다.

 

챗봇 프로젝트의 일환으로, 나이, 성별, 증상을 받아와 그에 맞는 비타민 제품을 아이허브 사이트에서 긁어와 결과를 보여주려고 했다.

 

사용한 기술스택은 

파이썬 3.7, 장고 프레임워크 2.2.7 버전, Beautifulsoup4 4.8.1 버전 이다.

 

1. pythonanywhere 에 배포하기

pythonanywhere 무료버전은 한정된 CPU 할당량과 파일 용량 내에서 파이썬 프로젝트의 배포가 가능하다.

 

 

**만약 나처럼 urllib 또는 requests 모듈을 사용하여 특정 사이트를 크롤링하는 코드가 포함되어 있을 경우에는 

반드시 pythonanywhere whitelist 에 내가 크롤링하고자 하는 사이트가 있는지 확인하여야 한다. 보안상의 문제로 pythonanywhere 서버 측에서 특정 사이트들의 접근만 허용시켜놓았다. 무론 무료계정일 경우에만 해당되고, 유료결제시 이런 접근제한은 풀어진다. 무료 계정으로 한다면, whitelist 에 없는 사이트에 접근을 시도하면, 403 Forbidden error 가 뜰것이다. 따라서, whitelist 에 없는 사이트를 크롤링하는 프로젝트라면 pythonanywhere 엔 배포가 불가능하다.

 

만약, whitelist 에 있는 사이트를 urllib 모듈을 이용해 크롤링하고자 한다면, proxy.server:3128  에 HTTP 프록시 서버 설정이 필요하다. requests 모듈 사용시 별도의 프록시 서버 설정은 필요가 없다. 

 

이와 같은 에러는 여기 에서 더 자세한 설명을 하고있으니 참고하길 바란다.

 

그럼, 장고 프로젝트를 pythonanywhere 에 배포하는 과정을 정리해보겠다.

 

우선 회원가입을 하고, 콘솔창 하나를 띄운다.

 

장고 프로젝트를 git 에 올려놓고, git clone <<project-name>> 을 이용해 프로젝트 디렉토리를 가져온다.

 

프로젝트를 만들고 나서 pip freeze > requirements.txt 를 이용해 dependency 가 있는 모듈을 파일에 저장해놓는 것이 편리하다.

 

cd <<project-name>> 을 하고 가상환경을 설정한다.

 

virtualenv --python=python3. myvenv 

source myvenv/bin/activate

 

가상환경이 실행되었을 것이다.

 

그리고 의존성있는 패키지들을 pip 을 이용해 설치해준다.

나같은 경우에는 django 2.2.7 , beautifulsoup4 4.8.1, requests 를 따로따로 설치했다. -> pip install <<package-name>>

requirements.txt 파일에 있는 패키지들을 한꺼번에 설치할 때는 -> pip install -r requirements.txt

 

그리고 데이터베이스를 생성해준다. 로컬서버에서 했던 것과 같이, pythonanywhere 에서도 데이터베이스를 초기화해주어야 한다.

 

python manage.py migrate

python manage.py createsuperuser

 

이제 콘솔창에서 할 것은 끝났다.

 

Web 탭으로 간다. 

 

Code 쪽에, 소스코드와 워킹디렉토리의 경로를 잘 설정해준다.

 

그리고, WSGI 환경설정 파일에 들어간다.

코드를 다음과 같이 수정한다. << >> 안의 내용을 자신에게 맞게 바꿔야 한다.

# This file contains the WSGI configuration required to serve up your
# web application at http://smartshk98.pythonanywhere.com/
# It works by setting the variable 'application' to a WSGI handler of some
# description.
#
# The below has been auto-generated for your Django project

import os
import sys

# add your project directory to the sys.path
path = '/home/<<your ID>>/<<your-project-path>>'
if path not in sys.path:
    sys.path.append(path)

# set environment variable to tell django where your settings.py is
os.environ['DJANGO_SETTINGS_MODULE'] = '<<directory name that your settings.py file is in>>.settings'


# serve django via WSGI
from django.core.wsgi import get_wsgi_application
from django.contrib.staticfiles.handlers import StaticFilesHandler

application = StaticFilesHandler(get_wsgi_application())

 

참고로, WSGI(Web Server Gateway Interface) 는 파이썬 스크립트(파이썬으로 작성된 웹앱) 가 웹서버와 통신하기 위한 인터페이스다. 

 

(출처 : thesoftjaguar.com )

 

웹 서버는 기본적으로 정적인 컨텐츠의 전달을 하는 하드웨어와 소프트웨어다. 클라이언트가 요청하면 서버에 있는 리소스를 그대로 보내준다. CGI 란 웹 서버에서 어플리케이션을 동작시키기 위한 인터페이스다. 정적인 웹 서버를 동적으로 기능하게 하기위해서 등장했다. 서버 프로그램과 외부 프로그램간의 인터페이스다. 웹 서버의 프로세스로서 인터프리터를 상주시켜 CGI 로부터 프로그램을 호출해 부하를 줄임으로서 성능을 개선한 것이 java servlet 이다. 다시 말하면, 기존에는 클라이언트에서 외부 프로그램이 필요한 리퀘스트를 보내면 CGI 를 통해 그 외부 프로그램을 시켜 응답하도록 했지만, 지금은 웹서버에 인터프리터를 내장하여 따로 프로세스를 fork 하여 외부프로그램을 실행시키지 않고 내부에서 직접 처리한다. 즉, CGI 는 웹서버와 프로그램 사이의 정보를 주고받는 규칙을 의미하고, CGI 프로그래밍이란 Perl, C/C++ 등을 사용해 웹서버가 실행할 수 있는 프로그램을 작성하는 것을 의미한다. 

 

WAS 는 웹서버가 동적으로 기능하면 WAS다. 웹서버 + CGI = WAS ! 웹서버와 WAS 를 굳이 분리할 필요가 없으며, 웹서버 위에 어플리케이션 서버( 톰캣 등 ) 를 얹은 것이 WAS 다. 어플리케이션 서버가 프로그램 실행결과를 웹서버에 전달해주면, 웹서버가 브라우저에 결과를 전송한다. ( JSP 등 ) 

 

CGI 와 어플리케이션 서버 방식의 차이는, 접속자가 많은 서비스의 경우 CGI 방식보다 어플리케이션 서버 방식의 Throuhgput (처리량) 이 더 좋다고 한다. 

 

따라서, WSGI 는 CGI 로부터 파생된 거라고 볼 수 있다. 

 

둘의 차이는, 아파치는 80번 포트를 듣고있다가 요청이 오면 이를 해석해서 응답한다. 응답 방법은 CGI 를 통해 스크립트를 실행시키거나, 아니면 단순한 파일을 제공한다. CGI 의 경우 아파치는 환경을 준비하고 CGI 프로토콜에 따라 스크립트를 실행시킨다. CGI 서브프로세스는 소켓과 stdout 을 포함해 OS 환경을 상속한다. CGI 서브프로세스가 응답을 작성하고 아파치로 보내면 아파치는 응답을 브라우저로 보낸다. CGI 는 모든 리퀘스트마다 서브프로세스를 fork 하는 원시적인 프로토콜이다. 

 

WSGI 는 CGI 디자인 패턴에 기반한 인터페이스다. 하지만 WSGI 는 모든 요청에 대해 서브프로세스를 fork 하지 않는다. 따라서 속도가 더 빠르다. 

 

 

다시 배포과정으로 돌아가서, 

 

가상환경 경로도, 아까만든 가상환경 폴더가 있는 곳으로 잘 설정해준다.

static 파일이 있다면, 그 밑에 static files 부분 경로에 설정해준다. 그리고 마지막으로, 

 

settings.py 에서 ALLOWED HOST 리스트에 pythonanywhere 을 추가해주고, Debug 는 False 로 고쳐준다.

 

# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = Flase

ALLOWED_HOSTS = [ '.pythonanywhere.com' ]

 

그리고 reload 하면 끝이다. 

 

2. AWS EC2 인스턴스 만들고 배포하기.

 

EC2 인스턴스가 있다고 가정한다.

 

ssh 를 통해 인스턴스에 접근한다. 인바운드는 8000 포트를 허용하는 것으로 설정하자.

 

git clone, 가상환경 설정, 의존 패키지 설치는 앞에서 pythonanywhere 에서 배포하는 과정과 똑같다. 단, wsgi.py 파일을 프로젝트 안에 있는 wsgi.py 을 변경시켜야 한다. (/var/www/ 밑에있는건 여기서 존재하지 않음)

 

그리고 python manage.py runserver 0.0.0.0:8000 을 입력해 서버를 실행하면 끝! 

 

postman 을 통해 결과를 확인하면? 코드 500. 정상적으로 응답을 받아오는것을 확인할 수 있다.

 

확실히 AWS EC2 에서 배포하는게 훨씬 편하다.

 

 

장고 크롤링 코드는 깃허브에서 참고할 수 있다.

https://github.com/smartshk/VitaminBot_Django

smartshk/VitaminBot_Django

* result 결과는 카카오 아이 오픈빌더의 말풍선 응답별 JSON 포맷을 따른것이다. 

 

 

 

카카오톡 오픈빌더에 서버에 배포한 api 를 스킬로 등록하고 배포하였다.

 

확인해보니 결과를 잘 불러오는것을 확인하였다:)

 

 

카카오 아이 오픈빌더는 머신러닝 발화관리로 사용자의 증상과 연령, 성별을 파라미터로 받아올 수 있다. 스킬을 이용하면, 원하는 결과를 사용자에게 다양한 응답형식으로서 보여줄 수 있다.

 

덕분에 편리하고 빠르게 챗봇을 만들 수 있었다.

 

다음 프로젝트는 단순한 크롤링을 넘어, 자연어처리 모델을 직접 짜서 telegram 에 적용하는 것을 해볼 예정이다.