aws 호스팅2

https://wikidocs.net/75556

4-09 WSGI

 

WSGI

장고 서버를 구동하기 위해 지금까지는 python manager.py runserver 처럼 장고의 내장 서버를 구동하는 방식을 사용했다.

 

장고의 내장서버

장고의 내장 서버는 웹 서버와 WSGI 서버의 기능을 모두 포함하고 있다. 다만 내장 서버는 기능이 단순하고 '대량 요청'이나 '동시 요청'을 효율적으로 처리하지 못하므로 운영 환경에는 적합하지 않다.

 

개발 환경이 아닌 운영 환경에서 어떻게 웹 서버와 WSGI 서버를 구성해야 하는지 알아보자.

 

웹 브라우저

사용자는 파이보 시스템에 접속하기 위해 웹 브라우저를 이용하여 파이보 홈페이지에 접속한다. 이 때 웹 브라우저는 파이보의 웹 서버에 페이지를 요청한다.

웹 브라우저가 파이보 웹서버에 요청하는 페이지는 크게 두 가지로 분류된다.

1. 정적 페이지
2. 동적 페이지

 

정적(static) 페이지

웹 브라우저로 다음 URL을 요청해 보자. (여러분의 고정IP를 사용하자.)

http://3.37.58.70:8000/static/bootstrap.min.css

그러면 웹 브라우저 화면에 내용이 그대로 출력될 것이다.

파이보 서버는 위와 같은 웹 브라우저의 요청을 받으면 서버의 /static/bootstrap.min.css 파일을 읽어서 리턴한다. bootstrap.min.css는 파일이므로 항상 변하지 않는 동일한 값을 리턴할 것이다. 확장자명이 js인 자바스크립트나 jpg, png와 같은 이미지 파일도 마찬가지이다. 이런 파일들을 정적 파일(static file)이라고 한다.

이렇게 웹 브라우저에서 css, js, jpg, png와 같은 정적 파일을 요청하는 것을 정적 페이지 요청이라고 한다.

 

동적(dynamic) 페이지

이번에는 웹 브라우저가 파이보 메인페이지(http://3.37.58.70:8000/)를 요청하는 경우를 생각해 보자. 파이보 서버는 이런 요청이 들어오면 질문 목록을 조회하여 리턴한다. 이때 응답 데이터인 질문 목록은 데이터베이스의 내용에 따라 수시로 변한다.

이렇게 응답이 수시로 변하는 요청을 동적 페이지 요청이라고 한다.

 

웹 서버(Web Server)

웹 서버는 웹 브라우저의 정적 요청과 동적 요청을 처리하는 서버이다.

대표 적인 웹 서버에는 아파치(Apache), 엔진엑스(Nginx) 등이 있다. 파이보는 장고와 가장 잘 어울리는 엔진엑스(Nginx)를 웹 서버로 사용할 것이다.

웹 서버에 정적 페이지 요청이 들어오면 정적 파일을 읽어 응답하면 되므로 간단하다.

하지만 동적 페이지 요청은 조금 복잡하다.

웹 서버에 동적 페이지 요청이 들어오면 웹 서버는 파이썬 프로그램을 호출해야 한다. 예를 들어 질문 목록 페이지 요청이 들어오면 질문 목록을 조회하여 리턴하는 파이썬 프로그램을 호출해야 한다. 하지만 대부분의 웹 서버는 파이썬 프로그램을 호출할 수 있는 기능이 없다. 어떻게 파이썬 프로그램을 호출해야 하는지 모르기 때문이다.

이러한 이유로 파이썬 프로그램을 호출하는 WSGI(web server gateway interface) 서버가 반드시 필요하다. 웹 서버에 동적 요청이 발생하면 웹 서버가 WSGI 서버를 호출하고, WSGI 서버는 파이썬 프로그램을 호출하여 동적 페이지 요청을 대신 처리하는 것이다.

 

WSGI 서버

WSGI 서버는 웹서버가 동적 페이지 요청을 처리하기 위해 호출하는 서버이다. WSGI 서버에는 여러 종류가 있지만 Gunicorn과 uwsgi를 가장 많이 사용한다. 파이보는 Gunicorn을 사용할 것이다.

웹서버에 동적 페이지 요청이 발생하면 웹 서버는 WSGI 서버를 호출하고 WSGI 서버는 다시 WSGI 애플리케이션을 호출한다. 여기서 알수 있는 중요한 사실은 실제 동적 페이지 요청은 결국 WSGI 애플리케이션이 처리한다는 점이다. WSGI 애플리케이션에는 장고(Django), 플라스크(Flask) 등이 있다. 파이보 시스템이 사용할 WSGI 애플리케이션은 우리가 지금껏 공부해온 장고이다.

WSGI 서버는 웹 서버와 WSGI 애플리케이션 중간에 위치한다. 그래서 WSGI 서버는 WSGI 미들웨어(middleware) 또는 WSGI 컨테이너(container)라고도 한다.

 

WSGI 애플리케이션

WSGI 서버는 항상 다음 파일을 경유하여 장고(django) 프로그램을 호출한다.

[파일명: projects\mysite\config\wsgi.py]

이 파일에 선언된 application이 바로 장고의 애플리케이션이다.

 

WSGI 순서도

다음은 지금까지 설명한 내용을 그림으로 나타낸 것이다.

웹 브라우저의 정적 페이지 요청은 웹 서버가 처리하고, 동적 페이지 요청은 [WSGI 서버 → WSGI 애플리케이션]으로 처리한다. 위 그림의 과정은 이어지는 챕터들을 통해 더 자세히 알아볼 것이다.

 

Gunicorn

이전 장에서 웹 서버에서 파이썬 장고 애플리케이션을 호출하려면 WSGI 서버가 필요하다고 했다. 이번 장에서는 파이보에서 사용할 WSGI 서버인 Gunicorn을 설치하고 사용해 보자.

 

1. Gunicorn 설치 : 서버 환경에 설치

(mysite) ubuntu@jumpto:~/projects/mysite$ pip install gunicorn

 

Gunicorn이 정상으로 실행되는지 확인 : config/wsgi.py 파일의 application

(mysite) ubuntu@jumpto:~/projects/mysite$ gunicorn --bind 0:8000 config.wsgi:application
http://3.37.58.70:8000

config.wsgi:application 명령에서 config.wsgi 와 application을 구분하는 구분자는 '.'이 아니라 ':'임을 주의하자.

 

Gunicorn 소켓 이용

Gunicorn은 앞에서 본 것처럼 포트(8000)를 이용하여 서버를 띄울수 있다. 하지만 Unix 계열 시스템에서는 포트로 서비스하기보다는 유닉스 소켓(Unix socket)을 사용하는 것이 빠르고 효율적이다.

 

현재 여러분의 AWS 서버가 Unix 계열 시스템인 우분투이다

다음과 같이 Gunicorn을 실행하자.

(mysite) ubuntu@jumpto:~/projects/mysite$ gunicorn --bind unix:/tmp/gunicorn.sock config.wsgi:application

 

유닉스 소켓 방식으로 Gunicorn 서버를 실행하면 단독으로 Gunicorn 서버에 접속하여 실행할 수 없다. 유닉스 소켓 방식으로 실행한 Gunicorn 서버는 Nginx와 같은 웹 서버가 반드시 필요하다.

 

2. Gunicorn 서비스

이번에는 AWS 서버에 Gunicorn을 서비스로 등록해 보자. 그 이유는 Gunicorn의 시작, 중지를 쉽게 하고, 또 AWS 서버를 다시 시작할 때 Gunicorn을 자동으로 실행하기 위해서이다. Gunicorn을 서비스로 등록하려면 환경 변수 파일과 서비스 파일을 작성해야 한다.

 

1) 환경 변수 파일 - nano 편집기를 이용 / 관리자 권한

 

[파일명: /home/ubuntu/venvs/mysite.env]

DJANGO_SETTINGS_MODULE=config.settings.prod

 

2) 서비스 파일 - 관리자 권한

 

[파일명: /etc/systemd/system/mysite.service]

 

[Unit]
Description=gunicorn daemon
After=network.target 

[Service]
User=ubuntu
Group=ubuntu
WorkingDirectory=/home/ubuntu/projects/mysite
EnvironmentFile=/home/ubuntu/venvs/mysite.env
ExecStart=/home/ubuntu/venvs/mysite/bin/gunicorn \
        --workers 2 \
        --bind unix:/tmp/gunicorn.sock \
        config.wsgi:application 

[Install]
WantedBy=multi-user.target

 

# 서비스 파일의 EnvironmentFile 항목이 우리가 작성한 환경 변수 파일을 사용하게 하는 설정

# --worker 2는 Gunicorn 프로세스를 2개 사용하라는 의미이다. (월 사용료 5달러 사양의 서버로 적당)

 

서비스 실행과 등록

실행

(mysite) ubuntu@jumpto:/etc/systemd/system$ sudo systemctl start mysite.service

 

# 만약 다음과 같은 메시지가 나타나지 않으면 /var/log/syslog 파일에서 오류 원인을 확인 가능

(mysite) ubuntu@jumpto:/etc/systemd/system$ sudo systemctl status mysite.service

 

마지막으로 AWS 서버가 다시 시작될 때 Gunicorn이 자동 실행되도록 등록 – enable 옵션

(mysite) ubuntu@jumpto:/etc/systemd/system$ sudo systemctl enable mysite.service

 

서비스 종료와 재시작

Gunicorn 서비스를 종료

$ sudo systemctl stop mysite.service

Gunicorn 서비스를 다시 시작

$ sudo systemctl restart mysite.service

 

 

Nginx

웹서버(Web Server)는 브라우저의 정적 페이지 요청을 처리하고 동적 페이지 요청인 경우 WSGI 서버를 호출하는 역할을 한다. 이번 장에서는 파이보가 사용할 웹 서버인 엔진엑스(Nginx)를 설치하고 적용해 보자.

 

Nginx 설치 - 관리자 권한

(mysite) ubuntu@jumpto:~/projects/mysite$ sudo apt install nginx

 

Nginx 설정

(mysite) ubuntu@jumpto:~/projects/mysite$ cd /etc/nginx/sites-available/

/etc/nginx/sites-available 디렉터리는 Nginx의 설정 파일들이 위치한 디렉터리이다.

최초 설치시에는 deafult라는 설정 파일만 존재한다.

 

그리고 파이보 서비스에 대한 Nginx의 설정파일을 다음과 같이 관리자 권한으로 작성한다.

(mysite) ubuntu@jumpto:/etc/nginx/sites-available$ sudo nano mysite

 

그리고 mysite 파일의 내용은 다음과 같이 작성하자.

 

[파일명: /etc/nginx/sites-available/mysite]

server {
        listen 80;
        server_name 3.37.58.70; 

        location = /favicon.ico { access_log off; log_not_found off; } 

        location /static {
                alias /home/ubuntu/projects/mysite/static;
        } 

        location / {
                include proxy_params;
                proxy_pass http://unix:/tmp/gunicorn.sock;
        }
}

# listen 80 은 웹 서버를 80 포트로 서비스 한다는 의미이다. HTTP 프로토콜의 기본포트는 80이다. 따라서 이제 http://3.37.58.70:8000/ 대신 포트를 생략하여 http://3.37.58.70 처럼 웹 브라우저에서 접속 할 수 있다.

# server_name 에는 여러분의 고정IP를 등록한다.

# location /static 은 정적 파일에 대한 설정으로 /static으로 시작되는 URL 요청은 Nginx가 /home/ubuntu/projects/mysite/static 디렉터리의 파일을 읽어서 처리한다는 설정이다.

# location /은 location /static 에서 설정한 것 이외의 모든 요청은 Gunicorn이 처리하도록 하는 설정이다. proxy_pass는 동적 요청이 발생하면 해당 요청을 Gunicorn의 유닉스 소켓으로 보내라는 설정이다.

이와 같은 설정을 통해 /static 으로 시작되는 URL은 Nginx가 처리하고 나머지 URL에 대해서는 Gunicorn이 처리하게 된다.

 

이제 작성한 mysite 파일을 Nginx가 환경 파일로 읽을 수 있도록 설정해야 한다.

다음처럼 /etc/nginx/sites-enabled 디렉터리로 이동하자.

(mysite) ubuntu@jumpto:/etc/nginx/sites-available$ cd /etc/nginx/sites-enabled/
(mysite) ubuntu@jumpto:/etc/nginx/sites-enabled$

sites-enabled 디렉터리는 site-available 디렉터리에 있는 설정 파일 중에서 활성화하고 싶은 것을 링크로 관리하는 디렉터리이다.

ls 명령을 수행하면 현재 default 설정 파일만 링크됨을 확인할 수 있다.

(mysite) ubuntu@jumpto:/etc/nginx/sites-enabled$ ls

 

이제 default 링크는 삭제하고 mysite 파일을 링크하도록 변경해야 한다.

먼저 다음처럼 default 링크를 삭제하자.

(mysite) ubuntu@jumpto:/etc/nginx/sites-enabled$ sudo rm default

 

그리고 다음처럼 mysite 파일을 링크하자.

(mysite) ubuntu@jumpto:/etc/nginx/sites-enabled$ sudo ln -s /etc/nginx/sites-available/mysite
(mysite) ubuntu@jumpto:/etc/nginx/sites-enabled$ ls

 

Nginx 실행

Nginx는 설치할 때 자동으로 실행되므로 앞에서 작성한 Nginx 설정을 적용하려면 Nginx를 다음처럼 다시 시작해야 한다.

(mysite) ubuntu@jumpto:/etc/nginx/sites-enabled$ sudo systemctl restart nginx

 

Nginx 설정 파일에 오류가 발생했다면?

Nginx의 설정 파일에 오류가 있는지 확인하는 방법은 다음과 같다.

(mysite) ubuntu@jumpto:/etc/nginx/sites-enabled$ sudo nginx -t

nginx -t 명령 수행 시 오류가 발생한다면 설정이 올바르지 않은 경우이므로 Nginx서버가 정상적으로 실행되지 않을 것이다.

 

Nginx를 중지

(mysite) ubuntu@jumpto:/etc/nginx/sites-enabled$ sudo systemctl stop nginx

Nginx를 시작

(mysite) ubuntu@jumpto:/etc/nginx/sites-enabled$ sudo systemctl start nginx

 

파이보 작동 확인하기

Gunicorn과 Nginx를 모두 적용했으니 웹 브라우저로 다음 URL에 접속해 보자.

http://3.37.58.70/

웹서버(Nginx)를 사용하기 때문에 이전과 달리 :8000과 같은 포트번호를 사용할 필요가 없어졌다.

Nginx를 사용하면 HTTP 기본 포트인 80 포트를 사용할 수 있기 때문이다. 80 포트를 사용할 경우에는 http://3.37.58.70:80 처럼 사용해도 되지만 :80 을 생략할 수 있다.

 

Nginx 실행시 static 디렉터리의 파일을 읽지 못한다면?

만약 Nginx 실행시 static 디렉터리 하위의 부트스트랩 파일을 읽지 못하여 화면이 깨져보이는 현상이 나타난다면 다음과 같이 조치해 보자.

 

[파일명: /etc/nginx/nginx.conf] – nano 편집기 이용

user ubuntu;
worker_processes auto;
pid /run/nginx.pid;
(... 생략 ...)

 

/etc/nginx/nginx.conf 파일의 가장 첫줄의 user www-data;를 user ubuntu;로 바꾼후에 nginx를 재시작하여 정상동작하는지 확인해 보자.