RailsConf2007 첫째날: Scaling Rails Application …
May 20th, 2007 by danteScaling Rails Application from the Bottom Up
RailsConf2007 첫째날에는 오전과 오후로 나누어 여러가지 튜토리얼이 준비되어 있었는데, 오전에는 “Scaling Rails Application from the Bottom Up”을 들었습니다. Joyent사의 CTO인 Jason Hoffman의 레일스 애플리케이션의 성능과 확장성에 대한 강의식 세션이었구요, 튜토리얼이라고 보기는 어려운 형식으로 꽤 흥미로운 내용을 발표했습니다.
전체적으로,
레일스로 실서비스에 적용할 만큼 안정적이고 충분한 성능을 보일 수 있나요?
라는 질문에 대한 답변과 보충 설명이었고, 답변 대신에
그것이 정말 레일스의 문제인가?
라는 반문으로 얘기를 풀어나갔습니다. 시스템관리자의 관점으로 전체를 바라볼 때, 성능과 확장성에 관련한 구성요소가 어떤 것들이 있는지 슬라이드 한장에 작은글씨로 가득 채워 놓고, 그 중에 레일스가 차지하는 부분을 표시해서 그 비율이 얼마나 적은지를 보여주었습니다. 개발자 관점으로만 좁게 바라보다보니, 마치 레일스로 바뀌는 것이 대단한 차이가 있을 것처럼 생각되는데, 사실 전체적으로 중요한 부분은 한 두가지가 아니라는 점을 얘기합니다.
확장성의 의미에 대해서는 레고블럭처럼 한 개에 블럭 한 개를 더 꽂으면 딱 2배 길이가 되고, 하나 더 꽂으면 3배 길이가 되고, 다시 한개 줄이면 2개 길이가 되는등, 늘이고 줄이는 만큼의 결과차이를 그대로 보인는 시스템이 확장성이 뛰어난 것이라고 비유했고, 막연히 여러대의 서버로 늘여서 성능 높이는게 확장성이 아니다라는 점을 강조했습니다.
확장의 걸림돌
성능과 확정성의 기본적인 제약사항으로 자금, 시간, 인력, 경험, 전력, 네트워크 bandwidth를 꼽았습니다. 전력의 경우, 3년정도의 기간으로 보면, 전체 서버비용의 30%정도의 큰 금액이 전력비용으로 소비되고, 전력이 사용할 수 있는 CPU와 메모리를 제한하기 때문에, 전체 성능과 확장성에 큰 제약사항일 수 있다고 했습니다.
레일스의 강점
하루 아침에 완성되는 최고 수준의 웹사이트는 없으며, 여러 단계를 반복해 계속 완성도를 높이고 기능을 추가하는 과정이 필요한데, 레일스는 이 반복과정(iteration)을 빠르게 진행할 수 있다.
인프라(infrastructure) 구성
확장성을 위한 목표는 컴퓨팅 파워를 높이고, 작은 공간을 차지하고, 전력소비를 줄여야한다고 얘기합니다. 전력, 서버, 네트워크 등의 애플리케이션 인프라(infrastructure) 비용에 대해,
The 10% Rule: (인력 비용을 제외한) 인프라비용이 수익의 10%이하여야 한다.
고 합니다. 수익의 10%이하로 인프라비용을 낮추든지, 아니면 인프라비용에 맞추어 수익을 그만큼 늘이든지해야 사업성이 있다는 얘기였습니다. 구글의 경우는 8%~10%선으로 발표되었다고 하더군요. 덧붙여, 인프라비용을 줄이기 위해 자체 데이터센터를 구축해 운영한다거나하는 것은 인프라자체 비용은 줄일 수 있을지 몰라도, 값비싼 고급인력을 보유해 연봉을 지급해야한다라는 점에서 전체비용 절감효과가 크지 않을 수도 있다고 언급했습니다. 무엇을 보더라도 단편적으로만 바라보고 문제를 해결할 수는 없겠습니다.
선택
이제까지 발표한 고려사항과 필요한 선택에 대해 결론으로 Joyent사에서 선택한 솔루션을 언급하며, 레일스 애플리케이션의 성능을 높이고, 확장성을 좋게 할 수 있는지 제안했습니다. 실제 사용하는 제품명까지 언급했는데, S사의 AMDs서버에 Solaris Nevada를 설치해서 사용한다고 합니다. 처음에는 D사의 서버로 시작해서 S사 제품으로 바꾸었다면서 운영상의 장점을 강조 했습니다. S사에서도 인텔아키텍쳐(IA)의 CPU로 돌아가는 서버를 팔고 있는지조차 몰랐습니다. ㅠ.ㅠ
Solaris OS를 선택한 이유로는 오픈소스임을 강조하면서, 상업용 제품이었던 믿을만한 운영체제(OS)가 오픈소스화 되었으니(음, OS가 OS화되었군요) 상업용의 장점과 오픈소스의 장점을 함께 갖추어서 좋다고 얘기했습니다. 우선 하드웨어벤더가 적극적으로 지원하는 운영체제를 설치하는게 기본이겠고, 특별히 Solaris OS를 선택한 이유로는 ZFS 파일시스템의 매력, 가벼운 가상화(virtualization)가 가능한 점, 무료라는 점, 그리고 대규모 시스템(512GB RAM, 1TB swap)에서 검증됐다는 점을 꼽았습니다 (가상화에 대해서는 다른 발표자의 추가 세션이 있어서, 따로 정리해서 올리도록 하겠습니다). S사에서 스폰서라도 받았는지, SAN장비도 S사 제품의 운영편의성을 강조하며 극찬했습니다.
레일스 프로세스
레일스 프로세스를 띄우는 방법으로
- FCGI
- 몽그렐(mongrel, 자바의 톰캣과 비슷한 역할)
- JRuby in Glassfish
를 나열했습니다. 지금의 상황은 몽그렐이 좋은 선택이지만, JRuby in Glassfish의 높은 가능성을 암시했습니다. JRuby를 사용하면 JDBC연결이나 Sequoia 사용등, 자바환경의 강점을 그대로 흡수할 수 있겠습니다.
지금까지의 상황으로는 몽그렐이 가장좋은 선택이겠지요.
몽그렐(mongrel) 구성
몽그렐은 멀티쓰레딩 HTTP서버이지만, 레일스가 thread-safe하지 않기 때문에, 디스패치(dispatch) 메소드에 뮤텍스(mutex)를 걸어 실행합니다. 그래서, 몽그렐을 레일스 컨테이너로 사용려면 프로세스를 여려개 띄워서 사용합니다. Joyent사에서 사용하는 몽그렐 클러스터의 구성은, 16GB RAM의 4 AMD CPU 시스템을 4개의 버추얼 컨테이너로 나누어(물리적으로 서버 한대가, 논리적으로 4대의 서버로 분할) 각각의 컨테이너(논리적으로 4GB RAM, 1 AMD CPU 서버)가 각각 몽그렐 프로세스를 10개씩 띄워서 사용한다고 합니다.
로드밸런서(load balancer)
로드밸런서(load balancer)로는 f5사의 BIG-IP를 쓰는데, 안정적이고 확장성 뛰어난점은 물론이고 Layer7 수준이라는 강점을 내세웠습니다. 다음에서 주로 쓰는 LVS같은 L4수준에서 할 수 없는 기능을 보여주었는데, 꽤 샘이 나더군요.
일반적으로 몽그렐 클러스터는 Apache의 프록시 밸랜서 모듈(mod_proxy_balancer)을 사용할텐데요, Joyent에서는 BIG-IP 로드밸런서에 곧바로 몽그렐 클러스터를 그룹별로 연결해서 사용한다고 합니다. 아파치 모듈의 어떤 부분이 블러킹콜(blocking call)을 사용해서 확장성의 한계가 크다라는 점을 애기했습니다.
L7수준이라서 같은 호스트명의 /svn이나 /trac 에 따라 서버를 나누어 처리 하는것이 가능하고, 레일스 애플리케이션의 경우에는 컨트롤러별로 몽그렐 클러스터를 구분지어서 처리한다는 점이 인상적이었습니다. 레일스 컨트롤러별로 몽그렐 클러스터 그룹을 나누어 놓으면, 어떤 컨트롤러에서 문제가 발생하는지 찾아내기 쉽고, 서비스 전체의 장애는 줄일 수 있겠습니다.
L7수준의 로드밸런싱을 위해 무료로 사용가능한 대안으로는 HA-Proxy와 Varnish를 제안했는데, LVS대신에 써볼 수 있는 기회가 생기면 좋겠습니다.
데이타저장소(datastore)
그리고, 이 부분이 전체 세시간의 핵심일 수 있는 내용일텐데요, 꼭 레일스 애플리케이션에 한정되는 얘기는 아니지만, 데이타저장소로 RDBMS만을 고집하지 말라고 합니다. memcached, LDAP, J-EAI, 파일시스템을 잘 활용해서 확장성을 높일 수 있는 점을 잊지 말라고 합니다. J-EAI는 메모리DB를 사용하는 메시지버스로, 커넥터도 다양하고 클러스터링해서 사용가능한 확장성 좋은 솔루션이라고 합니다.
파일시스템의 경우, 한 디렉토리에 10,000개 이상의 파일을 저장하지 말라는 기본적인 얘기가 있었구요, 이를 위해 다단계 해쉬를 써서 디렉토리를 몇단계 나눌 때, 보기에도 깔끔하고 예측가능한 방법으로 해쉬처리하자는 내용을 언급했습니다. Jamis의 ID파티셔닝에 대한 간단한 루비코드를 예제로 보여주었습니다.
DNS
간과하기 쉬운 DNS에 대해서도 언급했는데요. PowerDNS에 데이타베이스를 백엔드로 붙여서 간단히 분리가능한 그룹별로 서버군을 분리하는 내용을 언급했습니다. Master DB 하나만 공유하고, 분리가능한 대부분의 데이터는 분리된 서버군이 나누어 처리하는 방식이었습니다.
- http://channy.cool.daum.net/
- http://likejazz.cool.daum.net/
예를들어, cool.daum.net에 대해 PowerDNS서버 + PostgreSQL를 설치해 channy나 likejazz가 어떤 서버군으로 분리되는지 DB로 관리하며 나누어 처리할 수 있겠습니다.
마무리
이 시간에 언급한 내용만 보더라도, 성능이나 확장성을 위해서는 레일스뿐만이 아니라 다양한 소프트웨어, 하드웨어가 영향을 미치고, 무엇보다 중요한 것은 경험과 역량일거 같다는 생각으로 정리되네요. 결론적으로, ‘안정적이고 확장성 좋은 웹서비스에 레일스를 사용할 수 있는가?’라는 질문에 대해서는 우문현답이 되어 마무리된걸까요?