웹서버 성능과 유지보수

 

3.5년전 DDOS 공격을 잘 방어할 수 있는 방법을 찾고자 redirection 기능만 넣고 테스트한 적이 있다.

Nginx라는 녀석이 좋은 대안이 될 수도 있다는 생각이 들었다.

	TC1	TC2	TC3	TC4	TC4(nolog)	Nginx
Base	Apache 2.2	Apache 2.2	Apache 2.2	Tux	Tux	Nginx
1분 부하값 (load avg)	220	22	220	0.3	0.3	0.5
테스트	Java script redirect	Apache redirect(302)	Java script redirect	Java script redirect	Java script redirect	Redirect (302)
MAX TPS	4358.56	5120.5	4523.25	10838.5	10903.1	10790.2

 

테스트 결과는 kernel 기반의 Tux 웹 서버와 Nginx의 성능은 비슷했다.

Tux의 장점은 Static content serving(DMA directly from page cache) 와 user/kernel간의 context switching도 적고  system call이 적어 cpu를 더 효율적으로 쓸 수 있다. 그러나 단점으로는 kernel기반이다 보니 쉽게 운영하기 어려운 단점이 있다.

Ingo Molnár(http://en.wikipedia.org/wiki/Ingo_Moln%C3%A1r ) 라는 사람이 버려졌던 Tux를 리눅스 커널 2.6.0에 올렸다. 

 

Tux는 왜 점점 버려지고 있었을까?

1. 운영 측면에서 불편하다.

운영이 편리한(디버깅, 개발, 플러그인 추가) 어플을 사용하는 것이 편하다.

커널단을 건드려서 복잡한 단계를 진행하는 것보다 어플단에서 진행하는 게 백 번 낫다. 안정성 측면에서도 커널영역이 아닌 유저레벨에서 처리가 가능하다.  데몬 실행 할때만 root 권한이 필요하니. apache httpd나 nginx가 편리하다.

 

2. 메모리 사용 (sendfile)

어쩌면, sendfile이 대중화되면서 Tux의 장점이 사라졌던 것 같다. Apache http 서버는 sendfile directive가 추가되고 sendfile을 통해서 user space buffer copy 부분이 사라졌다. (zerocopy) Apache http 서버는 sendfile 기능을 넣어서 약 10%정도의 성능 효과를 발휘할 수 있다. (물론 nginx도.. ) 웬만한 웹서버는 sendfile 기능은 off이다.

f = open(file)

sendfile (socket, f, 0, fiesize)

굳이 커널레벨을 쓸 필요가 없다.

 

3. 성능

커널 단이라서 빠를 수 있지만, 오히려 처리 아키텍쳐가 더 큰 영향을 미친다.

 

4. 플러그인 개발

커널 모듈을 올렸나 내리는 작업이 결코 개발자에게는 좋지 않다.  바로 dynamic linking 하는 아파치 모듈이 더 편리하다. (현재까지는 nginx는 아직 dynamic linking을 지원하지 않는다. )

 

마치며..

과거에 Tux를 이용해서 먼가 해보려는 나의 시도는 굉장히 위험했던 것 같다. 언제나 생각해봐도 어플단에서 할 수 있는 것들을 최대한 살려서 쓰는 게 좋을 것 같다.

참고로. Tux 와 비슷하지만 성공했던 모델은 MS의 IIS (kernel + user) 이다. IIS 업데이트할 때마다 리스타트하는 상황을 보면. 참 거시기 하다. 여전히 어떻게 생존해 나갈지도 매우 궁금하기도 하구..