이 답변은 다른 답변을 보완하고 왜 Unicorn이 nginx를 필요로하는지 설명 합니다 .
TL; DR Unicorn이 일반적으로 nginx와 같은 리버스 프록시와 함께 배포되는 이유는 제작자가 의도적으로 그렇게 설계하여 단순 성과의 균형을 맞추기 때문입니다.
우선 , 리버스 프록시 없이 Unicorn을 배포 할 수있는 것은 없습니다 . 그러나 이것은 좋은 생각이 아닙니다. 이유를 보자.
Unicorn은 Unix 철학을 따르고 있는데, 이는 한 가지 일을 잘 수행하는 것입니다 . 즉 , 대기 시간이 짧은 빠른 고객 에게 서비스를 제공하는 것입니다. 유니콘 위해 설계되어 있다는 사실 고속은 대기 시간이 낮은 클라이언트는 또한 매우 좋지 않다 것을 의미 천천히, 대기 시간이 클라이언트 실제로 사실이다. 이 유니콘의 약점 중 하나이며 리버스 프록시가 활동하기 시작하는 곳이있다 : 그것은 유니콘의 앞에 앉아 그 처리 소요 느린 클라이언트를 (우리가 나타납니다 어떻게 나중에).
다행히도 이러한 리버스 프록시는 이미 존재하며 nginx 라고 합니다.
빠른 클라이언트 만 처리하기로 결정하면 배포 부서에 약간의 추가 복잡성으로 인해 Unicorn의 디자인이 크게 단순화되고 훨씬 더 간단하고 작은 코드베이스가 가능해집니다 (즉, Unicorn 외에 nginx도 배포해야 함).
다른 결정은 리버스 프록시가 필요없는 방식으로 Unicorn을 설계하는 것일 수 있습니다. 그러나 이는 현재 nginx가 수행하는 모든 작업을 수행하기 위해 추가 기능을 구현해야하므로 더 복잡한 코드베이스와 더 많은 엔지니어링 노력이 필요합니다.
대신 제작자들은 전투 테스트를 거쳐 잘 설계된 기존 소프트웨어를 활용하고 다른 소프트웨어로 이미 해결 된 문제에 시간과 에너지를 낭비하지 않기로 결정했습니다.
그러나 기술을 얻고 질문에 대답합시다.
왜 Unicorn을 nginx와 함께 배포해야합니까?
주요 이유는 다음과 같습니다.
유니콘은 클라이언트에 대한 차단 I / O를 사용합니다.
리버스 프록시에 의존한다는 것은 유니콘이 비 차단 I / O를 사용할 필요 가 없음을 의미합니다 . 대신 프로그래머가 추적하기에 더 간단하고 쉬운 블로킹 I / O를 사용할 수 있습니다.
또한 DESIGN 문서에는 다음 과 같이 명시되어 있습니다.
[블로킹 I / O 사용]을 사용하면 Ruby 인터프리터 내에서 더 간단한 코드 경로를 따르고 더 적은 수의 syscall을 수행 할 수 있습니다.
그러나 이것은 또한 몇 가지 결과를 초래합니다.
요점 # 1 : 느린 클라이언트에서는 유니콘이 효율적이지 않습니다
(간단하게하기 위해 유니콘 작업자 1 명과 설정을 가정합니다)
I / O 차단이 사용되므로 Unicorn 작업자는 한 번에 하나의 클라이언트에만 서비스를 제공 할 수 있으므로 느린 클라이언트 (예 : 연결이 느린 클라이언트)는 작업자를보다 빠르게 바쁘게 유지합니다 (빠른 클라이언트보다) ). 그 동안 다른 클라이언트는 작업자가 다시 해제 될 때까지 기다립니다 (즉, 요청이 대기열에 쌓이게 됨).
이 문제를 해결하기 위해 리버스 프록시가 Unicorn 앞에 배치되어 수신 요청 및 애플리케이션 응답 을 완전히 버퍼링 한 다음 각각 한 번에 (스푼 피드) Unicorn 및 클라이언트에 각각 보냅니다 . 이와 관련하여 리버스 프록시가 느린 네트워크 클라이언트로부터 유니콘을 "차폐"한다고 말할 수 있습니다.
다행스럽게도 Nginx는 수천 명의 동시 클라이언트를 효율적으로 처리하도록 설계 되었기 때문에이 역할의 훌륭한 후보입니다.
리버스 프록시가 Unicorn과 동일한 로컬 네트워크 내에 있어야하며 (일반적으로 Unix 도메인 소켓을 통해 Unicorn과 통신하는 동일한 물리적 시스템에 있어야 함) 네트워크 대기 시간이 최소로 유지되어야합니다.
그래서 이러한 프록시 효과적으로의 역할을 담당 신속한 클라이언트 는 유니콘 요청 프록시를하기 때문에 유니콘은 처음에 역할을하도록 설계되어 빨리 바쁜 노동자 유지 시간의 짧은 금액을 (얼마나 많은 시간을 클라이언트에 비해 연결이 느릴 경우).
요점 # 2 : 유니콘은 HTTP / 1.1 연결 유지 기능을 지원하지 않습니다
Unicorn은 블로킹 I / O를 사용하기 때문에 느린 클라이언트의 지속적인 연결이 사용 가능한 모든 Unicorn 작업자를 빠르게 점유 할 수 있기 때문에 HTTP / 1.1 연결 유지 기능을 지원할 수 없습니다.
따라서 HTTP 연결 유지를 활용하려면 리버스 프록시가 사용되는 것을 추측하십시오.
반면에 nginx는 몇 개의 스레드 만 사용하여 수천 개의 동시 연결을 처리 할 수 있습니다. 따라서 Unicorn과 같은 서버 (기본적으로 작업자 프로세스 수로 제한 됨)와 같은 동시성 제한이 없으므로 지속적인 연결을 잘 처리 할 수 있습니다. 이것이 실제로 작동하는 방법에 대한 자세한 내용은 여기를 참조하십시오 .
그렇기 때문에 nginx는 클라이언트로부터 연결 유지 연결을 허용하고 일반적으로 Unix 소켓을 통해 일반 연결을 통해 Unicorn에 프록시를 제공합니다.
포인트 # 3 : 유니콘은 정적 파일을 잘 제공하지 못합니다
다시 한 번, 정적 파일 제공은 Unicorn이 할 수있는 일이지만 효율적으로 수행하도록 설계되지 않았습니다.
반면에 nginx와 같은 리버스 프록시는 훨씬 뛰어납니다 (예 : sendfile(2)캐싱).
더
PHILOSOPHY 문서에 요약 된 다른 사항이 있습니다 ( "역 프록시 사용을 통한 성능 향상" 참조 ).
nginx의 기본 기능 중 일부를 참조하십시오 .
우리는 기존 소프트웨어 (예 : nginx)를 활용하고 "한 가지 일을 잘 수행"한다는 Unix 철학에 따라 Unicorn은 더 단순한 디자인과 구현을 따를 수 있으며 랙 앱을 효율적으로 제공 할 수 있습니다 (예 : Rails 앱).
자세한 내용은 유니콘의 참조 철학 및 디자인을 더 자세히 설명 문서 유니콘의 디자인 뒤에 선택과의 nginx는 좋은 유니콘에 대한 역 프록시로 간주되는 이유.
