Apache2 vs. Nginx

deepblue — Thu, 19 Jul 2007 18:02:32 -0700

특이하게도 레일스 배포 환경에 대한 이야기가 나올 때마다 ‘어떤 웹 서버가 가장 적합한가?’라는 이야기가 빠지지 않는다. 왜일까? 개인적인 생각으로는 아직도 완벽한 레일스 배포 스택이라는 것이 정해지지 않았기 때문인 것 같다. 하지만 전부 제각각인 애플리케이션들을 모두 수용할 수 있는 최적의 솔루션, 마치 은빛 총알 같은 것이 가당키나 한 이야기일까? 그렇다면 방법은 초기에 한가지 선택을 하고 계속 튜닝을 해가는 것 뿐이다. 전에 어떤 블로그에서 이런 내용을 본 적이 있다.

Q: 내 레일스 애플리케이션 앞단에서는 도대체 어떤 웹 서버를 사용해야 합니까?

A: 당신이 가장 편안함을 느끼고, 운영하기 쉽고, 어떤 경우에는 확장도 할 수 있는 그 웹 서버를 사용하세요. 그것이 정답입니다.

백번 동감하는 말이다. 그래서 스프링노트에서는 가장 많이 사용해본 웹서버이기도 하고, 지난 글(레일스 최적의 배포환경)에서 추천한 적도 있는 Apache 2.2.x + mod_proxy_balancer 조합을 사용하고 있고 지금까지도 큰 탈 없이 잘 운영되고 있다. 아파치 설정을 꽤 오래동안 반복하고 있지만, 매번 느끼지만 쉽지 않다. 그런데, 최근 커뮤니티를 보면 Nginx(엔진엑스라고 읽는다)라는 묘한 이름의 웹서버를 많이들 추천하고 있다. 그 이유는 아마도 레일스에서 필요한 기능이란 것이 빠른 정적 파일 서빙과 똑똑한 로드 밸런서가 전부이기 때문이다. 한마디로 아파치는 너무 범용적인(모든 기능이 다 있는) 웹 서버라서 무겁고, nginx는 딱 필요한 기능만 있은 우리가 원하는 그 웹 서버라는 것이다. 기능이 많기 때문에 무겁다 또는 느리다라는 것은 이유없는 미신일까? 그래서 몇 가지 벤치마크를 해보기로 했다.

Nginx는 필자도 처음 설정을 해보는데, 어렵지 않게 레일스 애플리케이션을 올릴 수 있었다. Lighttpd를 테스할 때도 느꼈지만, 아파치 설정 파일은 너무 불친절하다. 특히 요즘 애플리케이션이 많이 필요한 Rewrite 설정의 경우 아파치보다 nginx 설정 문법이 훨씬 간결하고 만들기 쉬웠다. (설정 파일 참조: http://brainspl.at/nginx.conf.txt)

지난 번에도 밝혔지만, 이 결과는 특수한 환경일 수 있으므로 참고만 하기 바란다.

테스트 환경

CPU: AMD64 2CPU
MEMORY 8G
운영체제: RHEL4

벤치마크에 사용한 소프트웨는 몽그렐 1.0.1, Swiftiply 0.5.1, EventMachine 0.7.2이고, 레일스의 버전은 EdgeRails 리비전 7161이다. 그리고 테스트를 위해 간단하게 Hello World를 출력하는 애플리케이션을 작성했다.

class TestsController < ApplicationController
def show
@hello = “Hello, world!”
@time = Time.now
end
end

위 애플리케이션을 아파치와 Nginx에서 각각 스레드 모드와 이벤트 모드로 모두 테스트했다. 테스트는 간단한 루비 스크립트를 작성해서 httperf를 이용해 rate(접속 빈도)를 10에서 1000까지 늘리며 반복적으로 테스트했다.

테스트 스크립트는 다음과 같다.

def test(rate = 10, num = 1000)
restart_mongrels
# restart_apache
restart_nginx
filename = “bench6/#{rate}_#{num}.txt”
puts “writing #{filename}”
File.open(filename, ‘w’) do |f|
f.write `httperf –num-conns #{num} –rate #{rate} –server test.w3pad.com –uri /tests/1`
end
end
(10..100).step(30) {|n| test(n, 50*n)}
(200..500).step(100) {|n| test(n, 100*n)}
(600..1000).step(200) {|n| test(n, 100*n)}

Apache 2.2 with Threaded Mongrels

가장 일반적으로 사용하는 방법이다. 스프링노트도 한달 전까지는 이 설정을 사용했다. 가장 무난한 환경이므로, 큰 망설임없이 추천할 만하다.

접속 빈도가 높아짐에 따라 자연스레 에러가 증가하고 응답도 느려짐을 알 수 있다. 위 테스트가 이번 벤치마크의 베이스라인(baseline)이 될 것이다.

Apache 2.2 with Evented Mongrels

이벤트 기반 몽그렐의 성능이라는 글에서도 적었듯, 몇가지 이유로 이벤트 기반 몽그렐이 더 나은 성능을 보여주고 있다. 현재 스프링노트에서 사용하고 있는 설정이기도 하다. 전에 쓴 글이 맞다면, 아파치 위에서도 이벤트 기반 몽그렐이 더 나은 성능을 보여줘야 한다. 그 결과는 어땠을까?

이벤트 기반 몽그렐을 사용했을 때, 에러 빈도가 낮아지고 특히나, 트래픽이 많을 때 더 나은 성능을 보여줌을 알 수 있다. 역시, 이벤트 기반 몽그렐이 더 나은 선택이다. 다시 비교해보니 rate가 800, 1000일 때 스레드모드의 결과는 처참하기까지 하다. 그에 비해 이벤트기반 몽그렐은 그 상황에서도 어느 정도 버텨주는 모습을 볼 수 있다.

Nginx with Threaded Mongrels

이번에는 Nginx를 사용한 벤치마크를 해보았다. 결론부터 이야기하면, Nginx는 기대 이상(!)의 결과를 보여주었다. 놀라울 정도였다. 결과부터 보자.

아파치에서 이벤트 기반 몽그렐을 사용했을 때보다 약간 나은 성능을 보여줌을 알 수 있다. 같은 스레드 기반 몽그렐을 사용할 때의 아파치와 비교해보면 그 차이가 명확하다. 특히 로드가 높아져도 꾸준한 응답률을 보여주는 부분이 놀랍다.

Nginx with Evented Mongrels

이번에는 마지막으로 Nginx 위에 이벤트 기반 몽그렐을 올렸을 때이다.

예상대로 스레드를 사용할 때 보다 나은 모습을 보인다.

비교

먼저, 평균 응답률을 비교해보자.

위 결과만으로 해석한다면 Nginx와 이벤트 기반 몽그렐을 사용할 때 가장 좋은 성능을 보이고, 그 다음 Nginx와 일반적인 몽그렐, 그리고 아파치는 좀 떨어지는 모습을 보였다. 특히나 스레드기반 몽그렐와 아파치는 저 급히 떨어지는 곡선은 참 위험해 보인다.

다음으로 각각의 응답 시간을 비교해보자.

rate가 낮을 때는 큰 차이가 없다가, 높아질 수록 차이가 보인다. 여기서도 Nginx가 더 나은 모습을 보여주고 있다.

마지막으로 에러 발생 빈도를 살펴보자.

rate가 1000일 때 아파치는 거의 100% 실패율을 보이지만, Nginx는 60%선에 머물고 있다. 이 결과도 마찬가지로 Nginx가 더 나은 모습을 보인다.

결론

그래프들이 보여주듯이 Nginx가 소문처럼 무척 좋은 성능의 웹서버임을 알 수 있다. 적어도 아파치보다는 비슷하거나 더 나은 성능을 보여준다. 그리고 Nginx에 내장된 밸런서의 성능도 좋고, 레일스와도 궁합이 잘 맞는 모습을 볼 수 있었다.

Nginx는 추천할만하다. 특히나 php나 webdav나 이런 여타 다른 기능이 필요없고, 딱 정적 파일과 레일스 밸런서만이 필요하다면 Nginx가 최적일 수도 있겠다는 생각이다. 특히, 간결한 설정 파일과 활발하게 개발되고 있는 모습을 보니 더 믿음이 간다. 그리고 레일스를 위해 Proxy 모듈에 몇 가지 기능을 추가해주겠다는 메일링 리스트의 글도 보이고 말이다. 완소 Nginx!

에필로그

사실 이 벤치마크를 하기 전에는 별 차이없겠지 했다가, 결과를 보고 대단한 발견을 한 것처럼 방방뛰며 좋아했던 기억이 난다. 마치 끝없는 사막을 거닐다가 오아시스라도 찾은 사람처럼 말이다. 그리고 마음 속으로는 Nginx를 도입해서 스프링노트가 빨라질거라는 기대감으로 엄청나게 기뻐하고 있었다.

하지만 하루가 지나고 이틀이 지나고, 또 이 결과를 다시 곱씹어보면서 생각이 조금씩 바뀌고 있다. 정말 이 결과만으로 Nginx가 아파치보다 훨씬 뛰어난 성능을 보입니다라고 할 수 있을까? 스프링노트가 저런 차이를 보이는 정도의 높은 트래픽을 받고 있고, 지금 당장 아파치 웹서버로 버틸 수 없다고 판단되면 위 결과가 의미가 있겠지만, 현 시점(서비스가 잘 운영되고있는)에서 어떤 차이가 있을까 싶어진 것이다.

그리고 다시 첫번째 질문으로 돌아간다.