다음 질문에 대한 단순화 된 답변을 찾고 있습니다. Nginx가 Gunicorn과 함께 작동하는 방식에 대한 기초적인 이해를 구축하려고합니다.
Nginx에 Django 앱을 배포하려면 Nginx와 Gunicorn이 필요합니까?
그렇다면 실제로 HTTP 요청을 처리하는 것은 무엇입니까?
추신. Apache와 mod_wsgi를 사용하고 싶지 않습니다!
답변:
지나치게 단순화 : Python을 실행하는 것이 필요하지만 모든 유형의 요청을 처리하는 데 Python이 최고는 아닙니다.
[면책 조항 : 저는 Gunicorn 개발자입니다]
덜 단순화 : 사용하는 응용 프로그램 서버 (Gunicorn, mod_wsgi, mod_uwsgi, cherrypy)에 관계없이 모든 종류의 사소한 배포에는 Django 앱이 처리해서는 안되는 요청을 처리하는 업스트림이 있습니다. 이러한 요청의 간단한 예는 정적 자산 (images / css / js)을 제공하는 것입니다.
그 결과 클래식 "3 계층 아키텍처"의 첫 번째 2 계층이 생성됩니다. 즉, 웹 서버 (귀하의 경우 Nginx)는 이미지 및 정적 리소스에 대한 많은 요청을 처리합니다. 그런 다음 동적으로 생성해야하는 요청은 응용 프로그램 서버 (예 : Gunicorn)로 전달됩니다. (제외, 세 계층 중 세 번째는 데이터베이스입니다)
역사적으로 말해서, 이러한 계층 각각은 별도의 머신에서 호스팅 될 것입니다. 처음 두 계층에는 여러 개의 머신이있을 것입니다.
현대 시대에는 이제 모든 모양과 크기의 응용 프로그램이 있습니다. 모든 주말 프로젝트 나 소규모 비즈니스 사이트가 실제로 여러 기계의 성능을 필요로하는 것은 아니며 단일 상자에서 매우 행복하게 실행될 것입니다. 이것은 호스팅 솔루션 배열에 새로운 항목을 생성했습니다. 일부 솔루션은 앱 서버를 웹 서버와 연결합니다 (Apache httpd + mod_wsgi, Nginx + mod_uwsgi 등). 그리고 이러한 웹 / 앱 서버 조합 중 하나와 동일한 머신에서 데이터베이스를 호스트하는 것은 드문 일이 아닙니다.
이제 Gunicorn의 경우 Nginx의 프록 싱 동작에 의존하면서 Nginx와 분리되도록 특정 결정 (루비의 유니콘에서 복사)을 결정했습니다. 특히, Gunicorn이 인터넷에서 직접 연결을 읽지 않는다고 가정 할 수 있다면 느린 클라이언트에 대해 걱정할 필요가 없습니다. 이것은 Gunicorn의 처리 모델이 매우 간단하다는 것을 의미합니다.
또한 분리를 통해 Gunicorn을 순수 Python으로 작성하여 개발 비용을 최소화하면서 성능에 큰 영향을 미치지 않습니다. 또한 사용자는 다른 프록시를 사용할 수 있습니다 (제대로 버퍼링한다고 가정).
실제로 HTTP 요청을 처리하는 것에 대한 두 번째 질문에 대한 간단한 대답은 Gunicorn입니다. 완전한 대답은 Nginx와 Gunicorn이 요청을 처리한다는 것입니다. 기본적으로 Nginx는 요청을 수신하고 (일반적으로 URL 패턴을 기반으로 한) 동적 요청 인 경우 해당 요청을 Gunicorn에 제공하여 처리 한 다음 Nginx에 응답을 반환하여 응답을 원래로 다시 전달합니다. 고객.
닫을 때 예. 적절한 장고 배포를 위해서는 Nginx와 Gunicorn (또는 이와 유사한 것)이 필요합니다. Nginx로 Django를 호스팅하려는 경우 Gjang, mod_uwsgi 및 CherryPy를 Django 쪽의 후보로 조사 할 것입니다.
나는이 설명을 간단하게 좋아했습니다.
Nginx는 외부 세계에 직면 할 것입니다. 파일 시스템에서 직접 미디어 파일 (이미지, CSS 등)을 제공합니다. 그러나 Django 애플리케이션과 직접 대화 할 수는 없습니다. 응용 프로그램을 실행하고 웹에서 요청을 제공하며 응답을 반환하는 무언가가 필요합니다.
Gunicorn의 일입니다. Gunicorn은 Unix 소켓을 생성하고 wsgi 프로토콜을 통해 nginx에 대한 응답을 제공합니다. 소켓은 양방향으로 데이터를 전달합니다.
The outside world <-> Nginx <-> The socket <-> Gunicorn
지나치게 단순화 된 답변을 찾고 있습니다 ...
Nginx에 Django 앱을 배포하려면 Nginx와 Gunicorn이 필요합니까?
그렇다면 실제로 HTTP 요청을 처리하는 것은 무엇입니까?
지나치게 단순화 된 답변 :
예.
Nginx와 Gunicorn 둘 다
Nginx에 배포하기 때문에 물론 Nginx가 필요합니다.
웹 프레임 워크 인 장고를 배포하기 때문에 웹 서버 (Nginx)와 웹 프레임 워크 (Django) 간의 대화를 연결하는 것이 필요합니다. 파이썬 세계에서는 그러한 것을 WSGI 서버라고하지만 (미들웨어처럼 생각) Gunicorn과 uWSGI를 예로들 수 있습니다. 요청을 처리 할 때 Nginx는 요청을 Gunicorn 또는 uWSGI로 프록시하여 Django 코드를 호출하고 응답을 반환합니다.
이 문서 와 바울의 대답은 더 잘 배우는 데 도움이 될 것입니다.
Gunicorn은 자원 낭비입니다. 단순히 django에서 gunicorn을 실행하고 다시 nginx를 실행하는 대신 포트에서 django 수신 대기 프록시를 프록시 할 수 있습니다. 벤치 마크에서 속도가 크게 눈에 띄었습니다. Nginx는 장고에 대한 직접 요청을 쉽게 처리 할 수 있습니다. Gunicorn은 일반 도로 위의 비행 (실제로 느린 비행)입니다. 그냥 앉아서 리소스를 먹고 웹 사이트에 힘을 실어주고 있다고 주장합니다.
nginx는 기본적으로 모든 요청을 버퍼링하고 정적 파일 요청을 자체적으로 처리합니다 (그렇게 구성한 경우). 그리고 모든 동적 컨텐츠를 다른 서버로 프록시합니다 (gunicorn / django).
Gunicorn은 요청을 응용 프로그램에 전달하는 것 외에 다른 용도는 없습니다. 유리에서 직접 마실 수 있거나 빨대에서 제한된 속도로 마실 수있는 빨대와 같습니다 (여기서 마시는 사람은 장고). nginx는 주스 한 잔을 가져다 준 웨이터입니다.
나는 벤치마킹하고 이것을 발견했다-gunicorn : 22k req / s with gunicorn : 34k req / s
귀하의 사이트에는 과부하가 걸리는 추가 요구 사항이 필요합니다.