Ruby on Rails 서버 옵션

질문 : Ruby on Rails 서버 옵션

---

Ruby on Rails 애플리케이션을위한 개발 서버를 설정하는 전체 문제가 혼란 스럽습니다. WEBrick, Mongrel, Passenger, Apache, Nginx 등이 있습니다. 저는 그들이 수행하는 다른 역할을 실제로 이해하지 못합니다.

저는 WEBrick을 사용하기 시작했고 지금은 개발을 위해 Mongrel을 사용합니다. 이러한 서버는 독립형입니까, 아니면 Apache 앞에 있습니까?

Passenger에 대해 읽었는데 이것이 무엇인지 잘 모르겠습니다. 사이트에서 "Ruby 웹 애플리케이션을 쉽게 배포 할 수 있습니다."라고 나와 있습니다. Mongrel을 대체합니까? 웹 애플리케이션도 배포하는 Capistrano와 비슷합니까?

SSL을 테스트하고 싶은데 이것이 mongrel에서 지원하지 않는다는 점을 염두에두고 가장 좋은 개발 서버 설정은 무엇입니까?

감사

답변

---

"배포"라는 단어는 문맥에 따라 두 가지 의미를 가질 수 있습니다. 또한 Apache / Nginx의 역할과 다른 구성 요소의 역할을 혼동하고 있습니다.

역사적인 메모 :이 기사는 원래 Ruby 앱 서버 생태계가 제한되었던 2010 년 11 월 6 일에 작성되었습니다. 이 문서는 2013 년 3 월 15 일에 생태계의 모든 최신 업데이트로 업데이트되었습니다.

면책 조항 : 저는 앱 서버 중 하나 인 Phusion Passenger의 저자 중 한 명입니다.

Apache vs Nginx

둘 다 웹 서버입니다. 정적 파일을 제공 할 수 있지만 올바른 모듈을 사용하면 PHP로 작성된 동적 웹 앱도 제공 할 수 있습니다. Apache는 더 인기 있고 더 많은 기능을 가지고 있으며 Nginx는 더 작고 빠르며 기능이 적습니다.

Apache와 Nginx 모두 Ruby 웹 앱을 기본적으로 제공 할 수 없으므로 나중에 설명 할 추가 기능과 함께 Apache / Nginx를 사용해야합니다.

Apache와 Nginx는 또한 역방향 프록시로 작동 할 수 있습니다. 즉, 들어오는 HTTP 요청을 받아 HTTP를 말하는 다른 서버로 전달할 수 있습니다. 해당 서버가 HTTP 응답으로 응답하면 Apache / Nginx는 응답을 클라이언트로 다시 전달합니다. 이것이 왜 관련이 있는지 나중에 알게 될 것입니다.

 

Mongrel 및 기타 프로덕션 앱 servers vs WEBrick

Mongrel은 Ruby "애플리케이션 서버"입니다. 구체적으로 말하자면 Mongrel은 다음과 같은 애플리케이션임을 의미합니다.

1. 자신의 프로세스 공간에 루비 앱을 로드합니다.
2. 외부(예: 인터넷)와 통신할 수 있는 TCP 소켓을 설정합니다. Mongrel은 이 소켓에서 HTTP 요청을 수신하고 요청 데이터를 Ruby 웹 앱에 전달합니다.
3. 그러면 루비 웹 앱은 HTTP 응답의 모양을 설명하는 객체를 반환하고, Mongrel은 이를 실제 HTTP 응답(실제 바이트)으로 변환하여 소켓을 통해 다시 전송한다.

그러나 Mongrel은 꽤 오래되어 현재는 더 이상 유지되지 않습니다. 최신 대체 애플리케이션 서버는 다음과 같습니다.

• Phusion Passenger
• Unicorn
• Thin
• Puma
• Trinidad (JRuby only)
• TorqueBox (JRuby only)

나는 그것들을 나중에 다루고 그들이 서로 그리고 Mongrel과 어떻게 다른지 설명 할 것입니다.

WEBrick은 Mongrel과 동일한 작업을 수행하지만 차이점은 다음과 같습니다.

• WEBrick은 이전에 언급 한 다른 모든 것과 달리 프로덕션에 적합하지 않습니다. WEBrick은 전적으로 Ruby로 작성되었습니다. Mongrel (및 대부분의 다른 Ruby 앱 서버)은 일부 Ruby와 일부 C (대부분 Ruby)이지만 성능을 위해 HTTP 구문 분석기가 C로 작성되었습니다.
• WEBrick은 느리고 덜 견고합니다. 알려진 메모리 누수와 알려진 HTTP 구문 분석 문제가 있습니다.
• WEBrick은 기본적으로 Ruby에 포함되어 있기 때문에 일반적으로 개발 중에 기본 서버로만 사용됩니다. Mongrel 및 기타 앱 서버는 별도로 설치해야합니다. 어떤 이유로 Heroku는 WEBrick을 기본 서버로 선택했지만 프로덕션 환경에서는 WEBrick을 사용하지 않는 것이 좋습니다. 그들은 이전에 Thin을 사용하고 있었기 때문에 왜 WEBrick으로 전환했는지 모르겠습니다.

앱 서버 및 월드

현재의 모든 Ruby 앱 서버는 HTTP를 사용하지만 일부 앱 서버는 포트 80에서 인터넷에 직접 노출 될 수 있지만 다른 서버는 그렇지 않을 수 있습니다.

• 인터넷에 직접 노출 될 수있는 앱 서버 : Phusion Passenger, Rainbows
• 인터넷에 직접 노출되지 않을 수있는 앱 서버 : Mongrel, Unicorn, Thin, Puma. 이러한 앱 서버는 Apache 및 Nginx와 같은 역방향 프록시 웹 서버 뒤에 배치되어야합니다.
• Trinidad와 TorqueBox에 대해 잘 모르기 때문에 생략했습니다.

일부 앱 서버를 역방향 프록시 뒤에 배치해야하는 이유는 무엇입니까?

• 일부 앱 서버는 프로세스 당 동시에 1 개의 요청 만 처리 할 수 있습니다. 2 개의 요청을 동시에 처리하려면 각각 동일한 Ruby 앱을 제공하는 여러 앱 서버 인스턴스를 실행해야합니다. 이 앱 서버 프로세스 세트를 앱 서버 클러스터 라고합니다 (따라서 Mongrel Cluster, Thin Cluster 등의 이름). 그런 다음이 클러스터에 대한 리버스 프록시를 사용하도록 Apache 또는 Nginx를 설정해야합니다. Apache / Nginx는 클러스터의 인스턴스 간 요청 분산을 처리합니다 (이에 대한 자세한 내용은 "I / O 동시성 모델"섹션 참조).
• 웹 서버는 요청과 응답을 버퍼링하여 데이터를 매우 빠르게 보내거나받지 않는 HTTP 클라이언트 인 "느린 클라이언트"로부터 앱 서버를 보호 할 수 있습니다. 클라이언트가 전체 요청을 보내거나 전체 응답을받을 때까지 기다리는 동안 앱 서버가 아무 작업도하지 않기를 원합니다. 그 시간 동안 앱 서버는 다른 작업을 수행 할 수 없기 때문입니다. Apache와 Nginx는 다중 스레드이거나 이벤트이기 때문에 동시에 많은 작업을 수행하는 데 매우 능숙합니다.
• 대부분의 앱 서버는 정적 파일을 제공 할 수 있지만 특히 잘하지는 않습니다. Apache와 Nginx는 더 빠르게 할 수 있습니다.
• 사람들은 일반적으로 정적 파일을 직접 제공하도록 Apache / Nginx를 설정하지만 정적 파일과 일치하지 않는 요청을 앱 서버에 전달하는 것이 좋은 보안 관행입니다. Apache와 Nginx는 매우 성숙하며 (아마도 악의적으로) 손상된 요청으로부터 앱 서버를 보호 할 수 있습니다.

일부 앱 서버가 인터넷에 직접 노출되는 이유는 무엇입니까?

• Phusion Passenger는 다른 모든 앱 서버와는 매우 다른 야수입니다. 고유 한 기능 중 하나는 웹 서버에 통합된다는 것입니다.
• Rainbows의 저자는 인터넷에 직접 노출하는 것이 안전하다고 공개적으로 밝혔습니다. 작성자는 HTTP 파서 (및 이와 유사한)에 취약점이 없다고 확신합니다. 그럼에도 불구하고 저자는 보증을 제공하지 않으며 사용에 따른 위험이 있다고 말합니다.

애플리케이션 서버 비교

이 섹션에서는 내가 언급 한 대부분의 애플리케이션 서버를 비교하지만 Phusion Passenger는 비교하지 않습니다. Phusion Passenger는 나머지 부분과는 매우 다른 짐승이므로 전용 섹션을 제공했습니다. Trinidad와 TorqueBox도 충분히 잘 모르기 때문에 생략했지만 어쨌든 JRuby를 사용하는 경우에만 관련이 있습니다.

• Mongrel 은 예쁜 뼈였다. 앞서 언급했듯이 Mongrel은 순전히 단일 스레드 다중 프로세스이므로 클러스터에서만 유용합니다. 프로세스 모니터링이 없습니다. 클러스터의 프로세스가 충돌하면 (예 : 앱의 버그로 인해) 수동으로 다시 시작해야합니다. 사람들은 Monit 및 God과 같은 외부 프로세스 모니터링 도구를 사용하는 경향이 있습니다.
• Unicorn 은 Mongrel의 포크입니다. 제한된 프로세스 모니터링을 지원합니다. 프로세스가 충돌하면 마스터 프로세스에 의해 자동으로 다시 시작됩니다. 모든 프로세스가 각 프로세스에 대해 별도의 소켓 대신 단일 공유 소켓에서 수신하도록 할 수 있습니다. 이는 리버스 프록시 구성을 단순화합니다. Mongrel과 마찬가지로 순전히 단일 스레드 다중 프로세스입니다.
• Thin 은 EventMachine 라이브러리를 활용하여 이벤트 I / O 모델을 사용합니다. Mongrel HTTP 파서를 사용하는 것 외에는 어떤 식 으로든 Mongrel을 기반으로하지 않습니다. 클러스터 모드에는 프로세스 모니터링이 없으므로 충돌 등을 모니터링해야합니다. 유니콘과 같은 공유 소켓이 없으므로 각 프로세스는 자체 소켓에서 수신합니다. 이론적으로 Thin의 I / O 모델은 높은 동시성을 허용하지만 Thin이 사용되는 대부분의 실제 상황에서 하나의 Thin 프로세스는 1 개의 동시 요청 만 처리 할 수 있으므로 여전히 클러스터가 필요합니다. 이 특성에 대한 자세한 내용은 "I / O 동시성 모델"섹션을 참조하십시오.
• Puma 는 Mongrel에서도 분기되었지만 Unicorn과 달리 Puma는 순전히 다중 스레드로 설계되었습니다. 따라서 현재 기본 제공 클러스터 지원이 없습니다. 여러 코어를 사용할 수 있도록 특별히주의해야합니다 (이에 대한 자세한 내용은 "I / O 동시성 모델"섹션 참조).
• Rainbows 는 서로 다른 라이브러리를 사용하여 여러 동시성 모델을 지원합니다.

Phusion Passenger

Phusion Passenger 는 다른 모든 것과 매우 다르게 작동합니다. Phusion Passenger는 Apache 또는 Nginx에 직접 통합되므로 Apache 용 mod_php와 비교할 수 있습니다. mod_php를 사용하여 Apache가 PHP 앱을 제공하는 것처럼 Phusion Passenger는 Apache (및 Nginx!)가 거의 마법처럼 Ruby 앱을 제공 할 수 있습니다. Phusion Passenger의 목표는 가능한 한 번거 로움없이 모든 것을 Just Work (tm)로 만드는 것입니다.

앱의 프로세스 또는 클러스터를 시작하고 Phusion Passenger를 사용하여 프로세스 / 클러스터에 정적 파일 및 / 또는 리버스 프록시 요청을 제공하도록 Apache / Nginx를 구성하는 대신 다음 만 수행하면됩니다.

1. 웹 서버 구성 파일을 편집하고 루비 앱의 '공용' 디렉터리 위치를 지정합니다.
2. 2단계는 없습니다.

모든 구성은 웹 서버 구성 파일 내에서 수행됩니다. Phusion Passenger는 거의 모든 것을 자동화합니다. 클러스터를 시작하고 프로세스를 관리 할 필요가 없습니다. 프로세스 시작 / 중지, 충돌시 다시 시작 등-모두 자동화되었습니다. 다른 앱 서버에 비해 Phusion Passenger는 움직이는 부품이 훨씬 적습니다. 이러한 사용 편의성은 사람들이 Phusion Passenger를 사용하는 주된 이유 중 하나입니다.

또한 다른 앱 서버와 달리 Phusion Passenger는 주로 C ++로 작성되어 매우 빠릅니다.

자동화 된 롤링 재시작, 멀티 스레딩 지원, 배포 오류 방지 등과 같은 더 많은 기능을 갖춘 Phusion Passenger의 Enterprise 변형도 있습니다.

위의 이유로 Phusion Passenger는 현재 가장 인기있는 Ruby 앱 서버로, New York Times, Pixar, Airbnb 등과 같은 대규모 웹 사이트를 포함하여 150,000 개 이상의 웹 사이트를 지원합니다.

Phusion Passenger vs other app servers

Phusion Passenger는 훨씬 더 많은 기능을 제공하며 다음과 같은 다른 앱 서버에 비해 많은 이점을 제공합니다.

• 트래픽을 기반으로 프로세스 수를 동적으로 조정합니다. 우리는 리소스가 제한된 서버에서 공용이 아닌 수많은 Rails 앱을 실행하고 있으며, 조직의 사람들은 하루에 최대 몇 번만 사용합니다. Gitlab, Redmine 등과 같은 것. Phusion Passenger는 이러한 프로세스를 사용하지 않을 때 스핀 다운하고 사용할 때 스핀 업하여 더 중요한 앱에 더 많은 리소스를 사용할 수 있습니다. 다른 앱 서버에서는 모든 프로세스가 항상 켜져 있습니다.
• 일부 앱 서버는 설계 상 특정 워크로드에 적합하지 않습니다. 예를 들어, Unicorn은 빠르게 실행되는 요청 전용으로 설계되었습니다 . Unicorn 웹 사이트 섹션 "일부 사례에서 더 나쁨"을 참조하십시오.

Unicorn이 잘하지 못하는 워크로드는 다음과 같습니다.

• 스트리밍 워크로드 (예 : Rails 4 라이브 스트리밍 또는 Rails 4 템플릿 스트리밍).
• 앱이 HTTP API 호출을 수행하는 워크로드입니다.

Phusion Passenger Enterprise 4 이상의 하이브리드 I / O 모델은 이러한 종류의 워크로드에 탁월한 선택입니다.

• 다른 앱 서버에서는 사용자가 애플리케이션 당 하나 이상의 인스턴스를 실행해야합니다. 반대로 Phusion Passenger는 단일 인스턴스에서 여러 애플리케이션을 지원합니다. 이렇게하면 관리 오버 헤드가 크게 줄어 듭니다.
• 편리한 보안 기능인 자동 사용자 전환.
• Phusion Passenger는 많은 MRI Ruby, JRuby 및 Rubinius를 지원합니다. Mongrel, Unicorn 및 Thin은 MRI 만 지원합니다. Puma는 또한 3 개를 모두 지원합니다.
• Phusion Passenger는 실제로 Ruby 이상을 지원합니다! 또한 Python WSGI를 지원하므로 예를 들어 Django 및 Flask 앱도 실행할 수 있습니다. 사실 Phusion Passenger는 다국어 서버가되는 방향으로 나아가고 있습니다. 할 일 목록에서 Node.js 지원.
• 대역 외 가비지 수집. Phusion Passenger는 정상적인 요청 / 응답주기 밖에서 Ruby 가비지 수집기를 실행하여 잠재적으로 요청 시간을 수백 밀리 초까지 줄일 수 있습니다. Unicorn도 비슷한 기능을 가지고 있지만 Phusion Passenger 버전은 1) GC에 국한되지 않고 임의의 작업에 사용할 수 있기 때문에 더 유연합니다. 2) Phusion Passenger 버전은 멀티 스레드 앱과 잘 작동하지만 Unicorn은 그렇지 않습니다.
• 자동 롤링 재시작. Unicorn 및 기타 서버에서 롤링을 다시 시작하려면 스크립팅 작업이 필요합니다. Phusion Passenger Enterprise는 이러한 방식으로 완전히 자동화됩니다.

더 많은 기능과 장점이 있지만 목록은 정말 깁니다. 자세한 내용은 Phusion Passenger 설명서 ( Apache 버전 , Nginx 버전 ) 또는 Phusion Passenger 웹 사이트 를 참조해야합니다.

I/O concurrency models

• 단일 스레드 다중 프로세스. Ruby 생태계의 멀티 스레딩 지원이 매우 나빴 기 때문에 전통적으로 Ruby 앱 서버에서 가장 인기있는 I / O 모델입니다. 각 프로세스는 한 번에 정확히 1 개의 요청을 처리 할 수 있습니다. 웹 서버는 프로세스간에 부하를 분산합니다. 이 모델은 매우 견고하며 프로그래머가 동시성 버그를 도입 할 기회가 거의 없습니다. 그러나 I / O 동시성은 매우 제한적입니다 (프로세스 수에 의해 제한됨). 이 모델은 빠르고 단기 실행 워크로드에 매우 적합합니다. 느리고 오래 실행되는 차단 I / O 워크로드 (예 : HTTP API 호출과 관련된 워크로드)에는 매우 적합하지 않습니다.
• 순전히 다중 스레드입니다. 요즘 Ruby 생태계는 뛰어난 멀티 스레딩 지원을 제공하므로이 I / O 모델은 매우 실용적이되었습니다. 멀티 스레딩은 높은 I / O 동시성을 허용하므로 단기 실행 및 장기 실행 차단 I / O 워크로드 모두에 적합합니다. 프로그래머는 동시성 버그를 도입 할 가능성이 더 높지만 운 좋게도 대부분의 웹 프레임 워크는 이것이 가능성이 거의없는 방식으로 설계되었습니다. 그러나 한 가지 주목할 점은 GIL (Global Interpreter Lock) 사용으로 인해 MRI Ruby 인터프리터가 여러 스레드가있는 경우에도 여러 CPU 코어를 활용할 수 없다는 것입니다. 각 프로세스가 CPU 코어를 활용할 수 있기 때문에 다중 스레드 프로세스를 사용하여이 문제를 해결할 수 있습니다. JRuby 및 Rubinius에는 GIL이 없으므로 단일 프로세스에서 여러 코어를 완전히 활용할 수 있습니다.
• 하이브리드 다중 스레드 다중 프로세스. 주로 Phusion Passenger Enterprise 4 이상에서 구현됩니다. 단일 스레드 다중 프로세스, 순수 다중 스레드 또는 여러 스레드가있는 여러 프로세스간에 쉽게 전환 할 수 있습니다. 이 모델은 두 가지 장점을 모두 제공합니다.
• 이벤트. 이 모델은 앞서 언급 한 모델과 완전히 다릅니다. 매우 높은 I / O 동시성을 허용하므로 장기 실행 차단 I / O 워크로드에 탁월합니다. 이를 활용하려면 애플리케이션과 프레임 워크의 명시적인 지원이 필요합니다. 그러나 Rails 및 Sinatra와 같은 모든 주요 프레임 워크는 이벤트 코드를 지원하지 않습니다. 이것이 실제로 Thin 프로세스가 여전히 한 번에 하나 이상의 요청을 처리 할 수없는 이유이며, 이는 단일 스레드 다중 프로세스 모델과 효과적으로 동일하게 작동합니다. Cramp와 같이 이벤트 I / O를 활용할 수있는 특수 프레임 워크가 있습니다.

작업 부하에 따라 프로세스 및 스레드 수를 최적화하는 방법에 대한 기사가 최근 Phusion 블로그에 게시되었습니다. Phusion Passenger의 동시성 설정 조정을 참조하십시오.

Capistrano

카피 스트라 노는 완전히 다른 것입니다. 이전의 모든 섹션에서 "배포"는 방문자가 액세스 할 수 있도록 애플리케이션 서버에서 Ruby 앱을 시작하는 작업을 의미합니다. 그러나 그 전에 일반적으로 다음과 같은 몇 가지 준비 작업을 수행해야합니다.

• Ruby 앱의 코드와 파일을 서버 시스템에 업로드합니다.
• 앱이 의존하는 라이브러리 설치.
• 데이터베이스 설정 또는 마이그레이션.
• Sidekiq / Resque 작업자 등과 같이 앱이 의존 할 수있는 모든 데몬을 시작하고 중지합니다.
• 응용 프로그램을 설정할 때 수행해야하는 기타 작업.

Capistrano의 맥락에서 "배포"는이 모든 준비 작업을 수행하는 것을 의미합니다. Capistrano는 애플리케이션 서버가 아닙니다. 대신 모든 준비 작업을 자동화하는 도구입니다. 새 버전의 앱을 배포 할 때마다 Capistrano에 서버 위치와 실행해야하는 명령을 알려 주면 Capistrano가 Rails 앱을 서버에 업로드하고 지정한 명령을 실행합니다.

Capistrano는 항상 애플리케이션 서버와 함께 사용됩니다. 애플리케이션 서버를 대체하지 않습니다. 반대로 애플리케이션 서버는 Capistrano를 대체하지 않으며 Capistrano와 함께 사용할 수 있습니다.

물론 당신은 카피 스트라 노를 사용할 필요가 없습니다. FTP로 Ruby 앱을 업로드하고 매번 동일한 단계의 명령을 수동으로 실행하는 것을 선호한다면 그렇게 할 수 있습니다. 다른 사람들은 그것에 질려서 Capistrano에서 이러한 단계를 자동화합니다.

출처 : https://stackoverflow.com/questions/4113299/ruby-on-rails-server-options