Module2 Flow 정리 - vvonha/NaverAPI GitHub Wiki

[Module2 Flow]

  1. Client
  • Web Server로 HTTP 요청
  1. Web Server (NginX)
  • 웹 서버(Web Server)는 HTTP를 통해 웹 브라우저에서 요청하는 HTML 문서나 오브젝트(이미지 파일 등)을 전송해주는 서비스 프로그램을 말한다. - Wikipedia
  • Client로부터의 HTTP요청을 받아 정적인 페이지/파일을 돌려줌. (동적인 부분은 uWSGI가 담당)
  • 가벼움과 높은 성능이 목표.
  • 웹 서버, 리버스 프록시 및 메일 프록시 기능을 가짐.
  • Web Server 종류: Apache, Nginx
  1. WSGI (uWSGI)
  • 웹 서버 게이트웨이 인터페이스(WSGI, Web Server Gateway Interface)는 웹 서버와 웹 애플리케이션의 인터페이스를 위한 파이썬 프레임워크다. - Wikipedia
  • Web server와 WAS간의 연결을 중계
  • Nginx는 Python을 모르기 때문에 uWSGI는 HTTP 요청을 python으로, Flask로 부터 받은 응답을 Nginx가 알 수 있도록 변환해줌.
  • WSGI 종류: Bjoern, uWSGI, mod_wsgi, CherryPy, Gunicorn
  1. WAS (Flask)
  • 웹 애플리케이션 서버(Web Application Server, WAS)는 웹 애플리케이션과 서버 환경을 만들어 동작시키는 기능을 제공하는 소프트웨어 프레임워크이다. - Wikipedia
  • 웹 요청에 대해 동적데이터를 돌려줌.
  • WAS 종류: 톰캣, PHP, Django, Node.js

[Web Server와 WAS를 구분하는 이유 - WAS가 Web Server의 기능도 모두 사용하면 되지 않을까?]

  1. 기능을 분리하여 서버 부하 방지
  • WAS는 DB 조회나 다양한 로직을 처리하느라 바쁘기 때문에 단순한 정적 컨텐츠는 Web Server에서 빠르게 클라이언트에 제공하는 것이 좋다.
  • WAS는 기본적으로 동적 컨텐츠를 제공하기 위해 존재하는 서버이다.
  • 만약 정적 컨텐츠 요청까지 WAS가 처리한다면 정적 데이터 처리로 인해 부하가 커지게 되고, 동적 컨텐츠의 처리가 지연됨에 따라 수행 속도가 느려진다.
  • 즉, 이로 인해 페이지 노출 시간이 늘어나게 될 것이다.
  1. 물리적으로 분리하여 보안 강화
  • SSL에 대한 암복호화 처리에 Web Server를 사용
  1. 여러 대의 WAS를 연결 가능
  • Load Balancing을 위해서 Web Server를 사용
  • fail over(장애 극복), fail back 처리에 유리
  • 특히 대용량 웹 어플리케이션의 경우(여러 개의 서버 사용) Web Server와 WAS를 분리하여 무중단 운영을 위한 장애 극복에 쉽게 대응할 수 있다.
  • 예를 들어, 앞 단의 Web Server에서 오류가 발생한 WAS를 이용하지 못하도록 한 후 WAS를 재시작함으로써 사용자는 오류를 느끼지 못하고 이용할 수 있다.
  1. 여러 웹 어플리케이션 서비스 가능
  • 예를 들어, 하나의 서버에서 PHP Application과 Java Application을 함께 사용하는 경우
  1. 기타
  • 접근 허용 IP 관리, 2대 이상의 서버에서의 세션 관리 등도 Web Server에서 처리하면 효율적이다.

[forward proxy vs reverse proxy -> NginX 사용 이유]

  1. forward proxy
  • 포워드 프록시는 클라이언트 측에서 origin 서버로 요청을 보낸다.
  • 포워드 프록시는 origin 서버가 특정한 클라이언트와 통신하는걸 막는 것
  1. reverse proxy
  • 리버스 프록시는 네트워크의 끝자락에서 요청을 가로채서 origin 서버로 요청을 보낸다.
  • 리버스 프록시는 클라이언트가 origin서버와 직접 통신하는걸 막는 것
  1. Web Server reverse proxy 사용 이유 (Nginx 사용 이유)
  • 웹서버 리버스프록시를 쓰면 origin 서버가 노출되지 않는다. 보안적으로 좋다는 것
  • 또 외부에서 요청이 많아지면 웹서버쪽에서 로드 밸런싱을 자동으로 처리해준다. 성능적으로 좋다는 것

[CGI vs WSGI -> WSGI 사용 이유]

  • Web Server 가 Web Application 과 대화할 수 있는 인터페이스가 필요
  • 특히, 다양한 종류의 Web Server 와 Web Application을 Interchangable하게 사용하기 위해서는 잘 정의된 인터페이스가 필수
  1. CGI(Common Gateway Interface)
  • 먼저 Web Server 가 Client로부터 HTTP Request 를 받는다.
  • Web Server 는 Request 에 대한 정보(Method, Url, Parameters, ...)를 Environment Variable 과 Standard Input을 통해 전달하면서 Script를 실행한다.
  • Script는 비즈니스 로직을 수행하고 Standard Output으로 결과를 Web Server 에게 전달한다.
  • Web Server 는 이를 다시 Client 에게 전달한다.
  • 문제는 매번 다시 스크립트를 실행하여 메모리에 적재하는 과정에서 발생하는 추가적인 시간 소요 등이었다.
  1. WSGI(Web Server Gateway Interface)
  • Callable Object라는 녀석을 통해 Web Server 가 요청에 대한 정보를 Application 에 전달한다.
  • Callable Object 는 Function 이나 Object 의 형태가 될 수 있다.
  • Web Server 는 Callable Object를 통해 2가지 정보를 전해주어야 한다.
  • 2가지 정보: HTTP Request 에 대한 정보(Method, URL, Data, ...) 및 Callback 함수
  • Web Application 는 HTTP Request 에 대한 정보를 가지고 Business Logic을 수행한 뒤에 Callback Function을 통해 결과를 웹서버에 반환한다.
  1. WSGI 사용 이유
  • wsgi server는 많은 request들을 다룰 수 있도록 설계되었다. framework들은 스스로 수천개의 request들을 실행하고 최고의 방법으로 처리할 수 있도록 설계되어있지 않다.
  • wsgi는 python web 개발 속도를 올려준다, 그 이유인 즉슨 wsgi의 기초적인 것들만 알아도 사용하는데에 아무 문제가 없기 때문이다.
  • wsgi는 사용자가 stack components를 유연하게 바꿀 수 있도록 도와준다.

[WSGI 종류 -> uWSGI 사용 이유]

  1. Bjoern
  • Bjoern은 비동기 CPython의 WSGI server이다. 이는 C로 작성되었고 매우 가벼우며 속도가 빠르다. Bjoern은 http_parser를 이용해 개발되었으며, Node.js의 제작자로도 알려진 Ryan Dahl가 제작하였다.
  • 다운로드 용량은 불과 18KB에 불과하며 800줄도 안되는 코드로 작성되었다. 실행시 메모리 사용량이 1MB를 넘지 않고 WSGI server가 낼 수 있는 가장 좋은 퍼포먼스를 보인다.
  • 단점으로는 HTTP/1.1과 호환이 되지않는다.
  1. uWSGI
  • uWSGI는 Hosting server에서 full stack 개발이 가능하도록 하기 위해 개발되었다. API와 일관된 configuration setup은 다양한 언어와 프로토콜, 프로세스 매니저, 프록시 등을 다양하게 다룰 수 있도록 개발되었다.
  • uWSGI는 다른 언어들과도 호환이 가능한데 Objective-C, C, C++등과 호환된다.
  • 그리고 끊임없이 발전되고 있다. 단점으로는 bloat 현상이 일어난다.
  1. mod_wsgi
  • Graham Dumpleton이 개발한 Apache HTTP Server 모듈이다. mode_wsgi는 python web apps을 위한 WSGI 인터페이스를 지원하는데, 최신버전에서는 python 2.6 과 3.2버전을 다룰 수 있다.
  1. CherryPy
  • 가장 작은 python framework로 더 잘 알려져있는 CherryPy는 thread-pooled와 HTTP/1.1을 다룰 수있는 web server가 되었다.
  • CherryPy는 이용이 쉽고 개발자 친화적이라고 알려져있다. 설치와 실행까지 불과 몇분 걸리지 않으며 단순히 server.py라는 한개의 파일만으로 mulit-processes가 가능하다. Nginx와 궁합이 좋다.
  1. Gunicorn
  • UNIX에서 사용하기 위해 만들어졌다. Gunicorn은 Python WSGI HTTP Server이다.(Gunicorn은 Green Unicorn의 줄인말이라고 한다.) Gunicorn은 Rupy의 Unicorn Project에서 영향을 받았다고 한다. 상대적으로 빠르고 가볍고 사용이 용이하다.
  • Gunicorn팀은 HTTP proxy server로 Nginx를 쓰길 권장한다. Gunicorn은 localhost 8000번을 사용하는데 Nginx는 전형적으로 reverse proxy server를 이용한다.
  1. uWSGI 사용 이유
  • uWSGI는 확장성이 뛰어나며 강력하고 다양한 언어(Flask) 위에서 작동하지만 너무 무거울 수 있다.

[참고] https://ahzick.tistory.com/entry/Web-Server-WAS-WSGI-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0 [참고] https://joft.site/86 [참고] https://gmlwjd9405.github.io/2018/10/27/webserver-vs-was.html [참고] https://velog.io/@shortdary/nginx-uwsgi [참고] https://sgc109.github.io/2020/08/15/python-wsgi/ [참고] https://paphopu.tistory.com/entry/WSGI%EC%97%90-%EB%8C%80%ED%95%9C-%EC%84%A4%EB%AA%85-WSGI%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80 [참고] nginx(proxy), uWSGI 설명