CGI? WSGI? 무엇일까

우선 CGI에 대한 설명은 여기를 보자

http://snuet.com/CML/C05/C05.html

 

그리고 wsgi에 대한 설명은 퍼왔다.

An Introduction to Python WSGI Servers: Part 1(번역)

원문 https://blog.appdynamics.com/python/an-introduction-to-python-wsgi-servers-part-1/

(해당 번역은 번역 수준으로도 범위적으로도 완전하지 않습니다. 원문을 볼 것을 추천드립니다.)

Python WSGI의 역사

wsgi는 2000년대 초반 Phillip J. Eby라는 사람이 만들었는데,

wsgi가 존재하기 전, 기존에 존재하던 Apache 모듈의 일종인 mod_python이 공식적인 명세도 없을 뿐더러 불안정했기 때문에 개발자들은 다른 해결책을 찾아나서기 시작했다.

wsgi는 CGI(Common Gateway Interface)의 일종으로, web이 이제 막 걸음마 단계를 시작했을 적에 CGI는 수많은 언어에서 문제 없이 작동한다는 이유로(애초에 CGI 외에 다른 선택권이 없기도 했다) 기하급수적으로 사용량이 증가했다. 하지만 CGI는 너무 느리고 제한사항도 많았을 뿐더러, python app에서는 CGI, mod_python, Fast CGI 등등 만을 사용했다. wsgi는 이와중에 프레임워크의 웹서버로, route web에서는 표준 인터페이스로 개발되었다.

Server와 Web app

WSGI에는 두가지 부류가 있다.

• Nginx나 Apache 같은 server–often high-profile 웹 서버
• python script로 짜여진 web app

server는 web app과 그에 연관되있는 정보, callback 함수등을 실행한다. request는 app 단에서 실행되며, response는 callback함수를 이용해서 server로 되보내진다.

가끔 server와 web app사이에 한개 이상의 wsgi middleware가 존재할 때가 있는데, middleware는 app objects에 직접적으로 request를 보내거나, load balancing, 등등 수많은 역할을 위해 이용된다. 
python framework인 django, cheerypy, flask, web2py 들에서 WSGI를 지원하는 것이 그 예라고 할 수 있다.

왜 wsgi가 필요하지?

그래 넌 아마 "아니 그건 됬고, 왜 wsgi가 필요한 거야?"라고 다시 물어볼 수 있다.

• wsgi server는 많은 request들을 다룰 수 있도록 설계되었다. framework들은 스스로 수천개의 request들을 실행하고 최고의 방법으로 처리할 수 있도록 설계되어있지 않다.(django의 경우 manage.py runserver로 배포하면 안된다는 소리다.)
• wsgi는 python web 개발 속도를 올려준다, 그 이유인 즉슨 wsgi의 기초적인 것들만 알아도 사용하는데에 아무 문제가 없기 때문이다. 만약에 너가 TurboGears, Django, cherryPy를 사용한다면, 너의 framework가 wsgi 표준을 어떻게 사용하는지 굳이 알 필요는 없다. 하지만 확실히 wsgi에 대해 안다면 도움이 된다.
• wsgi는 너가 stack components를 유연하게 바꿀 수 있도록 도와준다.

WSGI는 그 종류에 따라 다양한 규모와 성격을 갖고있으며 아래에는 범용적으로 쓰이는 몇 가지의 wsgi 종류를 서술하고자 한다.

Bjoern

Bjoern은 비동기 CPython의 WSGI server이다. 이는 C로 작성되었고 매우 가벼우며 속도가 빠르다. Bjoern은 http_parser를 이용해 개발되었으며, Node.js의 제작자로도 알려진 Ryan Dahl가 제작하였다.

다운로드 용량은 불과 18KB에 불과하며 800줄도 안되는 코드로 작성되었다. 실행시 메모리 사용량이 1MB를 넘지 않고 WSGI server가 낼 수 있는 가장 좋은 퍼포먼스를 보인다.

단점으로는 HTTP/1.1과 호환이 되지않는다.

uWSGI

uWSGI는 Hosting server에서 full stack 개발이 가능하도록 하기 위해 개발되었다. API와 일관된 configuration setup은 다양한 언어와 프로토콜, 프로세스 매니저, 프록시 등을 다양하게 다룰 수 있도록 개발되었다.

uWSGI는 다른 언어들과도 호환이 가능한데 Objective-C, C, C++등과 호환된다.

• Loop engines that handle concurrency and events. Supported technologies include Greenlet, Gevent, and Tornado, among others.
• The Core, which handles socket creation, process management, cluster membership, logging, configuration, ipc, shared memory, and the uWSGI Subscription Server.
• Gateways which activate proxies, load balancers and routers.
• Request plugins to handle application server interfaces for many different platforms including PHP, CGI, and Rack.

그리고 끊임없이 발전되고 있다. 단점으로는 bloat 현상이 일어난다.

mod_wsgi

Graham Dumpleton이 개발한 Apache HTTP Server 모듈이다. mode_wsgi는 python web apps을 위한 WSGI 인터페이스를 지원하는데, 최신버전에서는 python 2.6 과 3.2버전을 다룰 수 있다.

CherryPy

가장작은 python framework로 더 잘 알려져있는 CherryPy는 thread-pooled와 HTTP/1.1을 다룰 수있는 web server가 되었다.

• 빠르고 설정이 쉽다.
• 확장성이 좋다.
• 작고 이용이 쉽다.
• SSL handling

CherryPy는 이용이 쉽고 개발자 친화적이라고 알려져있다. 설치와 실행까지 불과 몇분 걸리지 않으며 단순히 server.py라는 한개의 파일만으로 mulit-processes가 가능하다. Nginx와 궁합이 좋다.

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를 이용한다. Gunicorn은 의존성이 없으며, 아래와 같은 장점을 포함한다.

• Works with Paster, Django, and WSGI out of the box.
• Worker process management is automatic.
• python 설정이 쉽다.
• Many worker configurations can be used.
• A variety of server hooks.

Gunicorn은 python 2.x 와 2.6버전, 3.x에서 3.2버전을 지원한다. However, there is no “keep-alive."(뭔소린지 모르겠음) sync woker는 Nginx에서 돌아가며 Nginx upstream servers는 오로지 HTTP/1.0을 사용한다.

어떤 WSGI를 사용하는 것이 가장 현명할까? 답은 당신의 목적에 달려있다.

• Bjoern은 매우 빠르고 C로 작성되어있으며 가벼우나 아직 HTTP/1.1을 지원하지 않는다.
• uWSGI는 확장성이 뛰어나며 강력하고 다양한 언어 위에서 작동하지만 너무 무거울 수 있다.
• Mod_wsgi는 작동하지만 약간 오래된 느낌이있다.
• Gunicorn은 남부럽지 않은 속도와 가벼움 그리고 django에서 자동으로 돌아간다.

출처: http://paphopu.tistory.com/37?category=637009 [파포푸]

 

너무 기니까 핵심 부분 요약

1. wsgi server는 많은 request들을 다룰 수 있도록 설계되었다. framework들은 스스로 수천개의 request들을 실행하고 최고의 방법으로 처리할 수 있도록 설계되어있지 않다.(django의 경우 manage.py runserver로 배포하면 안된다는 소리다.)

굳!