변하지 않는 것은 없다. 이제 대세는 Passenger(aka. mod_rails)
출근길에 문득 Rails Deployment의 글을 빨리 수정해야겠다고 생각했다. 6개월 정도 글을 업데이트하지 않았을 뿐인데, 그 사이에 바뀐 내용이 반영되지 않아, 어쩌면 틀린 글이 되어버렸는지도 모르겠다는 위기감이 들었기 때문이다. 관련해서 올초에 책도 한권 출판되었는데, 내가 이 책의 저자라면 이런 속도가 무척이나 당혹스러울 것 같다(책을 쓰는 중간에도 대대적인 업데이트가 있었다고 한다).
세상은 빠르게 변하고, IT 업계는 더 빨리 변하고 있지만, 정말 내 주변에서 레일스 배포 환경만큼 빠르게 변하는 것도 없는 것 같다. 먼저 지금까지의 역사를 한번 돌아보면 좋겠다. 지난 5회 루비 세미나에서 ikspres님이 잘 정리해주신 내용이 있으니 이 내용을 한번 읽어보자. 참 파란만장했다.
마지막으로 깔끔한 정리버전도 있다. 역시 출처는 ikspres님 발표 자료다.
레일스 오늘 처음이에요 Webrick 이제 조금 알 것 같네요. Mongrel ( evented Mongrel) 좀 더 빠른거요. 쉬우면서. Pen/Balance + Mongrel_cluster 좀 더 빠르거요. SSL 되면서요 Pound + Mongrel_cluster 아파치 아니면 안되요. 좀 복잡해도 참을께요 Apache + mod_proxy_balance + Mongrel_cluster 무지 빠르고. 간지나는 NginX + Mongrel_cluster
이제 그 이후 어떤 변화가 있었는지 돌아보자.
Thin의 등장
한동안 몽그렐 천하였던 루비 웹서버 판에 새로운 도전자가 나타났다. 바로 Thin이다. Thin은 현재 루비가 가진 것을 잘 활용해, 조금 더 나은 것을 만들었다. 몽그렐의 파서와 루비 프로젝트를 슈퍼카로 만들어즌 EventMachine, 그리고 Rack이 Thin을 있게한 요소들이다. 물론 Thin의 판매 전략은 성능이다.
그림: Evented Mongrel보다 나은 성능을 보여주는 Thin(출처 - Thin 홈페이지)
몽그렐이 훌륭하게 자기 몫을 하고 있기는 하지만, 약간의 잡음(그 유명한 Rant)으로 살짝 위기감이 들었는데, Thin이라는 좋은 경쟁자 또는 대체제가 생겨서 다행이라는 생각이다. 그치만, 현재 Mongrel에 큰 문제가 없다면 꼭 Thin으로 바꿔야할 이유는 없어보이기도 한다. 이 부분은 좀 더 지켜보자.
Merb, 누구냐 넌!
몽그렐 클러스터가 필요한 이유에서 설명했던 그 이유, 레일스가 쓰레드 안전성(Thread-Safety)를 갖추고 있지 않다는데 대부분의 사람들은 개의치 않지만, 어떤 사람들은 매우 민감하다. 가장 민감한 곳은 자원의 효율성이 돈과 직결되는 호스팅 업체들이다. 그래서 나타난 것이 쓰레드 안전성을 전면에 내세운 Merb다.
Merb는 EngineYard에서 일하며, 레일스 배포환경에 큰 공헌을 한 Ezra Zygmuntowicz이 주도적으로 개발하고 있다. 더 빠르고 가벼운 레일스를 추구한다. ORM을 선택해서 사용할 수 있는 것도 큰 차이점이다.
Merb가 레일스보다 느릴 이유가 없기에, 여러 벤치마크에서도 Merb의 성능이 더 나은 것으로 나온다(그렇지 않으면 Merb의 존재 이유 No.1이 사라진다).
출처: Performance Comparison For Rails and Merb
최근 Merb가 조금이나 새력을 확장해가고 있다. 곧 1.0이 나올텐데, 그 때는 레일스의 대안으로 자리매김할 수도 있을 것 같다.
2008년 상반기 히트작 Phusion Passenger(aka. mod_rails)
마지막으로 소개할 것은 최근 큰 인기를 얻고 있는 Phusion Passenger다. 왜 레일스 애플리케이션은 PHP 처럼 배포가 간단하지 않은 것인가?라는 문제에서 시작한 프로젝트로, 이 문제를 훌륭하게 풀어냈다. 이제 복잡한 클러스터 세팅 없이 mod_rails를 설치하고 Virtual Host를 설정해주는 것만으로 레일스 애플리케이션이 돌아간다. 정말 쉽고 편해졌다! 레일스 배포 환경이 너무 꼬졌다고 불편하던 Dreamhost도 최근 Passenger를 도입했다는 소식이 들린다. 클러스터의 관리를 요청에 따라 아파치가 관리하도록 위임하는 것이기때문에, 항상 N개의 인스턴스가 떠 있었던 기존 방식에 비해 더 많은 리소스를 확보할 수 있다는 큰 장점이 있는 것이다.
Passenger의 존재 이유는 쉬운 설정, 적은 관리 비용이지만, 성능도 괜찮은 편이라니 이보다 좋을 수 없다(이 부분은 약간의 이견이 있기도 하다).
출처: Benchmark: Passenger (mod_rails) vs Mongrel vs Thin
설치 및 사용법은 먼저 잘 설명해주신 분들이 많으니 이 글을 참고하자.
국내에서도 이미 몇개의 서비스가 Passenger를 사용하고 있다.
Passenger와 함께 등장한 Ruby Enterprise Edition도 GC를 패치해서 메모리 사용량을 줄요준다고 하니 참고하자.
결론
또 6개월이 지나면 얼마나 바뀔지 모르겠지만, 현 시점에서 추천하는 배포 스택은 선호하는 웹서버에 따라 아래 두가지다.
- Apache 2.2 + Phusion Passenger
- Nginx + EventedMongrel + Monit
경쟁과 변화는 항상 좋은 일이다. 나도 뒤쳐지지 않으르면 오늘도 내 루비를 닦아야겠다. 항상 반짝거릴 수 있게..
참고
comments
No comments yet.
You must be logged in to add your own comment.