해피 코딩!

WebServer , WSGI , Docker 의 개념 정리 본문

Deploy

WebServer , WSGI , Docker 의 개념 정리

지속가능한 성장을 2020. 11. 23. 19:10

틀리다고 생각하시는 부분을 지적해주세요! 피드백을 환영합니다!

용어정리

  • Nginx

    웹이란 World Wide Web 의 약자로, 네트워크 체계 위에서 동작하는 통신 규약의 하나이다.
    웹은 사람과 컴퓨터간의 상호작용
    인터넷과 웹은 엄연히 구분하자면 다르다. 같은 의미로 사용되는 이유로서는 웹이 가장 성공한 인터넷 서비스이기 때문이다.

    웹 서비스는 컴퓨터와 컴퓨터 간의 상호작용을 위한 시스템
    인터넷이란 전 세계적 규모의 시스템과 시스템을 연결해주는 네트워크 체계
    네트워크 위에서 동작하는 서비스가 Web , ftp , email 등이 있다.
    차세대 웹 서버로 불린다. 더 적은 자원으로 더 빠르게 데이터를 서비스 할 수 있다 ( 이전에 등장했던 아파치보다 )

  • WSGI

    웹서버(Nginx)에서 받은 요청이 서버측에서 처리가 필요한 경우에, wsgi가 서버사이드 애플리케이션을 실행하여 담당 우린 ubuntu에서 사용이 가능한 uWSGI를 사용하였다.
    wsgi 통신은 기본적으로 socket 방식을 사용한다. http 방식을 사용할 수 있지만 , 통신에서 loss가 발생하는 단점이 있다, 그에 비하여 wsgi app은 서버 안쪽에서 서버의 요청을 django 어플리케이션에 중계하는 역할을 하기 때문에 무거운 http 요청 보다는 socket이라는 전송방식을 사용한다 ( HTTP에 비해서 훨씬 가볍게 설정이 가능 )

  • http server

    http 라는 웹 서비스를 사용할 수 있도록 도와주는 공통된 규약을 사용하는 서버

    http란 웹 서버와 웹 클라이언트가 서로 정보를 주고 받기 위한 프로토콜.

  • HTTP 통신 vs SOCKET 통신

    가장 큰 차이점은 접속의 유지 여부
    http는 클라이언트의 요청이 있을 때 , 서버가 해당 페이지에 대한 자료를 전송하고 곧바로 전송을 끊는다 전송을 끊는 이유는 서버의 부하를 줄이기 위함. 서버에 많은 request를 유지시켜 서버를 공격하는 개념이 DDOS
    SOCKET 클라이언트가 서버와 접속이 되면 서버나 클라이언트 둘 중 하나가 접속을 끊을때 까지 유지가 된다. 서버가 대응할 수 있는 클라이언트는 제한적. 실시간 데이터 교류가 필요한 서비스에 사용

  • manage.py 의 runserver를 쓰지 않는 이유는?

    Nginx + uWSGI + Django
    Django에는 기본적으로 주어지는 웹서버가 있어서 manage.py runserver를 이용하여 웹서버를 구동할 수 있다. 하지만, Django 내에서 제공하는 서버는 개발할 때 쓰이는 조그마한 디버깅용 웹서버이기 때문에 실제 서비스를 배포할 때에는 다른 웹서버(Nginx or Apache)를 통해 배포하는 것이 좋다.

  • EC2

    24시간 제공 되는 서버를 amazon 측에서 제공한다.
    서버실을 운영하기 제약적이다면 가상 서버를 구동시킬 수 있다는 장점이 있다.
    효율적으로 프로그램 개발을 하기에 용이하다.

  • S3

    웹 서비스를 배포하는데에 있어서 필요한 정적 파일들(css,js, static 파일 등) 과 서비스를 하는데에 필요한 이미지 등등을
    Django 외에 다른 저장소에 두어 정적 파일에 대한 처리를 대신한다.
    이는 Django를 통해 전달하지 않아서 Django에 부담을 덜여준다는 장점이 있다.
    이는 WebServer에서 static이나 media를 처리해주도록 해야햔다.

WebServer , WSGI , Docker 의 개념!

EC2
클라이언트로부터 접속을 설정
Django application이 실행되고 있는 서버 컴퓨터

requset -> EC2 -> (runserver:8000) -> Django
런서버는 develop 서버이기 때문에 성능이 떨어진다
이 과정에서 우리는 장고로 가기전에 웹서버를 추가한다.

Cloud Server 물리서버 또는 가상서버 ( EC2 위에 docker를 쓴다는 가정으로 )

Webserver Application (사용자의 requset를 받고 응답을 보내주는데 특화 정적인 처리를 해주는것에 특화가 되어있다. 외부의 요청의 처리에 좋다 )

WSGI application ( 웹서버랑 python web application을 중개 )

Python Web application (동적으로 response를 보내주는 기능)

웹서버는 사용자의 request를 받고, web application에 전달을 해주며 전달을 받은 application은 그 요청을 가공하고 response돌려준다.

WSGI 등장 이전에 server와 application간의 어떤식으로 데이터를 주고 받을지에 대한 문제가 있었다.
이에 WSGI는 Web server가 application에 주고 싶은 데이터를 WSGI형태에 맞는 형식으로 전달하고
application 도 WSGI와 데이터 전달을 위한 표준적인 방법으로 보내주면서
server와 application의 정보 전달을 도운다.

장점은
WSGI의 규격에 맞게 application을 짜면 webserver를 무엇을 쓰던간에 WSGI가 알아서 번역을 해준다.

좋은 예시로 Django의 ORM이 있다. ORM에만 맞게 작성을 하면 다양한 DB 에 대한 SQL 문법은 조금씩 차이가 있지만 ORM을 통해 디비에 커넥션이 이루어져 신경을 쓸 필요가 없다.(oracle , mysql , postgresql , sqlite 를 ORM을 통하여 쓸 수 있는 이유)
이걸 ORM을 통해 어떻게 DB와의 중개가 이루어지냐면

Django - ORM - python - psycopg2 - PostgreSQL

이런식으로 중간과정에 중개역할이 이루어진다. psycopg2는 PostgreSQL 에 존재하는 데이터베이스에 접근할 수 있도록 중개 역할을 한다. 파이썬에서 DB와의 커넥션을 이루어지게 해주는것이다. 단점은 포팅이 이루어져야 하므로 좀 느리지만 ORM을 이용하면 Django와 PostgreSQL의 연결에 대해서 신경을 쓰지 않아도 된다는 장점이 있다.

이처럼 uWSGI도 같은 역할을 해준다.
Webserver에 어떤 요청이 오던 간에 wsgi에만 맞추어 준다면 Web application과의 통신을 이루어준다.

이렇게 이어주는것이
requset -> EC2 -> Nginx(Webserver) -> uWSGI(WSGI) -> Django

requset -> EC2 -> (runserver:8000) -> Django 와의 차이점이 이제 잘 이해가 가는 것 같다.

Docker [운영체제 가상화를 통한 버전관리]

우분투 자체를 매핑해서 가지게 됨. 도커에 설정된 도커파일을 통해
우분투 차원의 운영체제를 재구성이 가능하다.
정해진 리눅스 버전을
도커는 리눅스 위에서만 돌아간다. 리눅스의 가상화 기술을 사용하였기 때문에 리눅스 운영체제 위에서만 돌아간다.

EC2에 올려서 사용을 한다면 로컬에서 도커를 이용해서 세팅을 완료하고 다 한 내용을 EC2에 올리는게 가장 보기 편하다.

Comments