"배치"라는 단어는 상황에 따라 두 가지 의미를 가질 수 있습니다. 또한 Apache / Nginx의 역할과 다른 구성 요소의 역할을 혼동하고 있습니다.
역사적 참고 사항 :이 기사는 원래 Ruby 앱 서버 에코 시스템이 제한되었던 2010 년 11 월 6 일에 작성되었습니다. 이 기사는 2013 년 3 월 15 일에 생태계의 모든 최신 업데이트로 업데이트되었습니다.
면책 조항 : 저는 응용 프로그램 서버 중 하나 인 Phusion Passenger의 저자 중 하나입니다.
아파치 vs Nginx
둘 다 웹 서버입니다. 정적 파일은 제공 할 수 있지만 올바른 모듈을 사용하면 PHP로 작성된 동적 웹 앱도 제공 할 수 있습니다. 아파치는 더 대중적이고 더 많은 기능을 가지고 있으며, Nginx는 더 작고 빠르며 더 적은 기능을 가지고 있습니다.
Apache 나 Nginx는 즉시 루비 웹 앱을 제공 할 수 없으며, 나중에 설명 할 일종의 애드온과 함께 Apache / Nginx를 사용해야합니다.
Apache와 Nginx는 리버스 프록시 역할을 할 수 있습니다. 즉, 들어오는 HTTP 요청을 가져 와서 다른 서버 (HTTP를 사용하는 서버)로 전달할 수 있습니다. 해당 서버가 HTTP 응답으로 응답하면 Apache / Nginx는 응답을 클라이언트로 다시 전달합니다. 이것이 왜 중요한지 나중에 알게 될 것입니다.
잡종 및 기타 프로덕션 앱 서버 vs WEBrick
Mongrel은 Ruby "응용 프로그램 서버"입니다. 구체적으로 Mongrel은 다음과 같은 응용 프로그램입니다.
- 자체 프로세스 공간 내에 Ruby 앱을로드합니다.
- 외부 소켓 (예 : 인터넷)과 통신 할 수 있도록 TCP 소켓을 설정합니다. Mongrel은이 소켓에서 HTTP 요청을 수신하고 요청 데이터를 Ruby 웹 앱으로 전달합니다.
- 그런 다음 Ruby 웹 앱은 HTTP 응답의 모양을 설명하는 객체를 반환하고 Mongrel은 해당 객체를 실제 HTTP 응답 (실제 바이트)으로 변환하여 소켓을 통해 다시 보냅니다.
그러나 Mongrel은 상당히 오래된 것으로 요즘에는 더 이상 유지되지 않습니다. 최신 대체 응용 프로그램 서버는 다음과 같습니다.
- 퓨전 승객
- 일각수
- 얇은
- 퓨마
- 트리니다드 (JRuby 만 해당)
- TorqueBox (JRuby 만 해당)
나중에 그것들을 다루고 그것들이 Mongrel과 어떻게 다른지 설명 할 것입니다.
WEBrick은 Mongrel과 동일한 기능을 수행하지만 차이점은 다음과 같습니다.
- WEBrick은 이전에 언급 한 다른 모든 것과 달리 프로덕션에 적합하지 않습니다. WEBrick은 전적으로 Ruby로 작성되었습니다. Mongrel (및 대부분의 다른 Ruby 앱 서버)은 Ruby 및 C (대부분 Ruby)의 일부이지만 HTTP 구문 분석기는 성능을 위해 C로 작성됩니다.
- WEBrick은 느리고 강력하지 않습니다. 알려진 메모리 누수와 알려진 일부 HTTP 구문 분석 문제가 있습니다.
- WEBrick은 기본적으로 Ruby에 포함되어 있기 때문에 일반적으로 개발 중 기본 서버로만 사용됩니다. 잡종 및 기타 앱 서버는 별도로 설치해야합니다. Heroku는 프로덕션 환경에서 WEBrick을 사용하지 않는 것이 좋습니다. 어떤 이유로 Heroku는 WEBrick을 기본 서버로 선택했습니다. 그들은 전에 Thin을 사용하고 있었으므로 WEBrick으로 전환 한 이유를 모르겠습니다.
앱 서버와 세계
현재 모든 Ruby 앱 서버는 HTTP를 사용하지만 일부 앱 서버는 포트 80에서 인터넷에 직접 노출 될 수 있지만 다른 서버는 그렇지 않을 수 있습니다.
- 인터넷에 직접 노출 될 수있는 앱 서버 : Phusion Passenger, Rainbows
- 인터넷에 직접 노출되지 않을 수있는 앱 서버 : Mongrel, Unicorn, Thin, Puma 이러한 앱 서버는 Apache 및 Nginx와 같은 리버스 프록시 웹 서버 뒤에 배치해야합니다 .
- Trinidad와 TorqueBox에 대해 잘 모르므로 생략했습니다.
일부 앱 서버를 리버스 프록시 뒤에 배치해야하는 이유는 무엇입니까?
- 일부 앱 서버는 프로세스 당 하나의 요청 만 동시에 처리 할 수 있습니다. 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은 순전히 단일 스레드 다중 프로세스이므로 클러스터에서만 유용합니다. 프로세스 모니터링이 없습니다. 클러스터의 프로세스가 충돌하는 경우 (예 : 앱의 버그로 인해) 수동으로 다시 시작해야합니다. 사람들은 Monit 및 God와 같은 외부 프로세스 모니터링 도구를 사용하는 경향이 있습니다.
- 유니콘 은 잡종의 포크입니다. 제한된 프로세스 모니터링을 지원합니다. 프로세스가 충돌하면 마스터 프로세스가 자동으로 다시 시작합니다. 각 프로세스마다 별도의 소켓 대신 모든 프로세스가 단일 공유 소켓에서 수신 대기 할 수 있습니다. 이는 리버스 프록시 구성을 단순화합니다. Mongrel과 마찬가지로 순전히 단일 스레드 다중 프로세스입니다.
- Thin 은 EventMachine 라이브러리를 사용하여 이벤트 I / O 모델을 사용합니다. Mongrel HTTP 구문 분석기를 사용하는 것 외에는 Mongrel을 기반으로하지 않습니다. 클러스터 모드에는 프로세스 모니터링이 없으므로 충돌 등을 모니터링해야합니다. 유니콘과 같은 공유 소켓이 없으므로 각 프로세스는 자체 소켓에서 수신합니다. 이론적으로 Thin의 I / O 모델은 높은 동시성을 허용하지만 Thin이 사용되는 대부분의 실제 상황에서 하나의 Thin 프로세스는 하나의 동시 요청 만 처리 할 수 있으므로 여전히 클러스터가 필요합니다. "I / O 동시성 모델"섹션에서이 고유 한 특성에 대해 자세히 알아보십시오.
- Puma 는 Mongrel에서도 포크되었지만 Unicorn과 달리 Puma는 순전히 멀티 스레드로 설계되었습니다. 따라서 현재 내장 클러스터 지원이 없습니다. 여러 코어를 활용할 수 있도록 특별한주의를 기울여야합니다 ( "I / O 동시성 모델"섹션에서 이에 대한 자세한 내용 참조).
- Rainbows 는 서로 다른 라이브러리를 사용하여 여러 동시성 모델을 지원합니다.
퓨전 승객
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를 구성하는 대신 다음 작업 만하면됩니다.
- 웹 서버 설정 파일을 편집하고 Ruby 앱의 'public'디렉토리의 위치를 지정하십시오.
- 2 단계가 없습니다.
모든 구성은 웹 서버 구성 파일 내에서 수행됩니다. Phusion Passenger은 거의 모든 것을 자동화합니다. 클러스터를 시작하고 프로세스를 관리 할 필요가 없습니다. 프로세스 시작 / 중지, 충돌시 다시 시작 등-모두 자동화되었습니다. Phusion Passenger는 다른 앱 서버에 비해 움직이는 부품 수가 훨씬 적습니다. 이러한 사용 편의성은 사람들이 Phusion Passenger를 사용하는 주요 이유 중 하나입니다.
또한 다른 앱 서버와 달리 Phusion Passenger은 주로 C ++로 작성되어 매우 빠릅니다.
자동 롤링 재시작, 멀티 스레딩 지원, 배포 오류 방지 등과 같은 더 많은 기능을 갖춘 Phusion Passenger 의 엔터프라이즈 변형 도 있습니다.
위와 같은 이유로 Phusion Passenger는 현재 뉴욕 타임즈, 픽사, 에어 비앤비 등과 같은 대규모 웹 사이트를 포함하여 150,000 개가 넘는 웹 사이트를 지원하는 가장 인기있는 루비 앱 서버입니다.
Phusion Passenger 및 다른 앱 서버
Phusion Passenger은 다음과 같은 다른 앱 서버에 비해 훨씬 더 많은 기능을 제공하고 많은 이점을 제공합니다.
- 트래픽을 기반으로 프로세스 수를 동적으로 조정합니다. 우리는 대중을 대상으로하지 않는 리소스가 제한된 서버에서 수많은 Rails 앱을 실행하고 있으며 조직의 직원은 하루에 몇 번만 사용합니다. Gitlab, Redmine 등과 같은 것들 Phusion Passenger는 사용하지 않을 때 이러한 프로세스를 중단하고 사용 중일 때 프로세스를 회전시켜보다 중요한 앱에 더 많은 리소스를 사용할 수 있습니다. 다른 앱 서버에서는 모든 프로세스가 항상 켜져 있습니다.
- 일부 앱 서버는 설계 상 특정 워크로드에 적합하지 않습니다. 예를 들어 Unicorn은 빠르게 실행되는 요청을 위해서만 설계되었습니다 . Unicorn 웹 사이트 섹션 "일부 상황 만 악화"를 참조하십시오 .
유니콘이 좋지 않은 작업량은 다음과 같습니다.
- 스트리밍 워크로드 (예 : Rails 4 라이브 스트리밍 또는 Rails 4 템플릿 스트리밍).
- 앱이 HTTP API 호출을 수행하는 작업
Phusion Passenger Enterprise 4 이상의 하이브리드 I / O 모델은 이러한 종류의 워크로드에 탁월한 선택입니다.
- 다른 앱 서버에서는 사용자가 애플리케이션 당 하나 이상의 인스턴스를 실행해야합니다. 반대로 Phusion Passenger는 단일 인스턴스에서 여러 응용 프로그램을 지원합니다. 이는 관리 오버 헤드를 크게 줄입니다.
- 자동 사용자 전환, 편리한 보안 기능.
- Phusion Passenger는 많은 MRI Ruby, JRuby 및 Rubinius를 지원합니다. 잡종, 유니콘 및 Thin은 MRI 만 지원합니다. 푸마는 또한 3을 모두 지원합니다.
- Phusion Passenger는 실제로 Ruby 이상을 지원합니다! 또한 Python WSGI를 지원하므로 Django 및 Flask 앱을 실행할 수도 있습니다. 실제로 Phusion Passenger는 폴리 글롯 서버가되는 방향으로 나아가고 있습니다. 할 일 목록에서 Node.js 지원.
- 대역 외 가비지 수집. Phusion Passenger은 일반적인 요청 / 응답주기 외부에서 Ruby 가비지 수집기를 실행하여 요청 시간을 수백 밀리 초 줄일 수 있습니다. 유니콘도 비슷한 기능을 가지고 있지만 Phusion Passenger 버전은 1) GC에 국한되지 않고 임의의 작업에 사용될 수 있기 때문에 더 유연합니다. 2) Phusion Passenger 버전은 멀티 스레드 앱과 잘 작동하지만 Unicorn은 그렇지 않습니다.
- 자동 롤링이 다시 시작됩니다. Unicorn 및 기타 서버에서 롤링을 다시 시작하려면 스크립팅 작업이 필요합니다. Phusion Passenger Enterprise는 이러한 방식으로 완전히 자동화합니다.
더 많은 기능과 장점이 있지만 목록이 너무 깁니다. 자세한 내용은 종합 Phusion Passenger 설명서 ( Apache 버전 , Nginx 버전 ) 또는 Phusion Passenger 웹 사이트 를 참조하십시오.
I / O 동시성 모델
- 단일 스레드 다중 프로세스. Ruby 에코 시스템의 멀티 스레딩 지원이 매우 나빴 기 때문에 이는 전통적으로 Ruby 앱 서버에 가장 인기있는 I / O 모델입니다. 각 프로세스는 한 번에 정확히 1 개의 요청을 처리 할 수 있습니다. 웹 서버는 프로세스 간로드 밸런스를 수행합니다. 이 모델은 매우 강력하며 프로그래머가 동시성 버그를 도입 할 가능성이 거의 없습니다. 그러나 I / O 동시성은 매우 제한적입니다 (프로세스 수에 의해 제한됨). 이 모델은 빠른 단기 실행 워크로드에 매우 적합합니다. HTTP API 호출과 관련된 워크로드와 같이 느리고 오래 실행되는 블로킹 I / O 워크로드에는 매우 적합하지 않습니다.
- 순수한 멀티 스레드. 오늘날 루비 에코 시스템은 뛰어난 멀티 스레딩 지원을 제공하므로이 I / O 모델은 매우 실용적입니다. 멀티 스레딩은 높은 I / O 동시성을 허용하여 단기 실행 및 장기 실행 차단 I / O 워크로드에 적합합니다. 프로그래머는 동시성 버그를 도입 할 가능성이 높지만 다행히도 대부분의 웹 프레임 워크는 여전히 가능성이 거의없는 방식으로 설계되었습니다. 그러나 GRI (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 승객의 동시성 설정 조정을 참조하십시오 .
카피 스트라 노
Capistrano는 완전히 다른 것입니다. 이전의 모든 섹션에서 "배포"는 응용 프로그램 서버에서 Ruby 앱을 시작하여 방문자가 액세스 할 수 있도록하기 위해 수행되는 작업을 말하지만 일반적으로 다음과 같은 준비 작업을 수행해야합니다.
- Ruby 앱의 코드 및 파일을 서버 시스템에 업로드
- 앱이 의존하는 라이브러리 설치
- 데이터베이스 설정 또는 마이그레이션
- Sidekiq / Resque 워커 또는 기타와 같이 앱이 의존 할 수있는 데몬 시작 및 중지
- 응용 프로그램을 설정할 때 수행해야 할 기타 사항
Capistrano와 관련하여 "배포"는이 모든 준비 작업을 수행하는 것을 말합니다. Capistrano는 응용 프로그램 서버가 아닙니다. 대신, 모든 준비 작업을 자동화하는 도구입니다. Capistrano에게 서버의 위치와 새로운 버전의 앱을 배포 할 때마다 어떤 명령을 실행해야하는지 알려 주면 Capistrano는 Rails 앱을 서버에 업로드하고 지정한 명령을 실행합니다.
Capistrano는 항상 응용 프로그램 서버와 함께 사용됩니다. 애플리케이션 서버를 대체하지 않습니다. 반대로 응용 프로그램 서버는 Capistrano를 대체하지 않으며 Capistrano와 함께 사용할 수 있습니다.
물론 당신은하지 않습니다 이 카피 스트라 노를 사용 할 수 있습니다. FTP를 사용하여 Ruby 앱을 업로드하고 매번 동일한 단계의 명령을 수동으로 실행하려는 경우 그렇게 할 수 있습니다. 다른 사람들은 그것에 질려서 Capistrano에서 그 단계를 자동화했습니다.