Archive for May, 2007

둘째날 저녁 시간에는 여러명의 키노트 발표가 있었고, 그중에 Avi Bryant가 어떤 내용의 발표를 할지 매우 기대되었습니다. 저녁시간의 발표를 한꺼번에 정리해봅니다.

“Enterprise” is not a Four Letter-word

FiveRuns사의 CEO인 Steven Smith의 키노트였습니다.

상업용 서비스에 레일스를 쓰고 있는 사람을 손들어보라고 합니다. 깜짝 놀랬습니다. 1,600여명의 절반 이상이 손을 듭니다. 사람들은 레일스가 엔터프라이즈 환경에 사용될 준비가 되었냐고 묻는다지만, 그는 이렇게 반문합니다.

엔터프라이즈가 레일스를 맞이할 준비가 되었나요?

간디가 한말을 인용하며 말을 이어갑니다.

First they ignore you,
then they laugh at you,
then they fight to you,
then you win.

전체적으로, 이미 이 곳에서의 분위기는 레일스를 엔터프라이즈 환경에 적극적으로 활용하는 분위기인거 같습니다. 긴가민가하는 망설임의 단계는 이미 지난 것처럼 보입니다. 방법과 해결책의 문제이지 선택의 문제는 이미 끝난 것처럼 말이죠.

앞으로 어떻게 펼쳐질지 너무도 궁금하군요. 제목에서 말한 네 글자 단어는 무엇이고, 이기고 지는 무시, 비웃음, 싸움은 무멋일까 한참 고민했는데, 뒤늦게 눈치챘습니다. J로 시작하는 프로그래밍 언어명 아니겠습니까? 꼭 이기고 지는 싸움을 해야할까 싶지만 말입니다.

Avi Bryant

웹 데이터베이스라는 조금은 생소한 서비스를 제공하는 Dabble DB사의 co-CEO이자, 스몰토크(Smalltalk)기반의 웹애플리케이션 프레임워크 Seaside의 개발자인 Avi Bryant의 키노트가 이어졌습니다.

단상에 가볍게 뛰어 올라와서 아무런 소개 없이 발표를 시작한 그는, 자신이 미래에서 왔다고 말합니다. 2030년대까지 루비와 레일스는 어마어마한 발전을 거듭했으며, 여러가지 훌륭한 기능과 툴이 있다면서 소개합니다. 있으면 좋을 법한, 아니 어쩌면 당연이 있어야할 법한 항목들의 슬라이드를 보여주며 얘기합니다. “이런 기능들이 있으면 좋겠다고 생각하죠?”

화면이 있던 슬라이드가 교묘히 몇군데 교체됩니다. 2000년대부터 2030년대이라는 기간이 1970년대부터 2000년대 기간으로 바뀌고, 루비의 자리는 스몰토크로 바뀝니다. 지난 30년간 스몰토크가 이루어 놓은 일들을 앞으로 루비도 이루어야한다고 얘기합니다.

무언가 통통튀는 느낌으로 활달한 발표를 이어간 그는, 루비와 스몰토크는 같은 동적언어(Dynamic Language)로 똑같은 언어이며, 스몰토크가 한 일을 루비도 할 수 있다고, 그리고 해야한다고 주장합니다.

부디 배타적인 반응을 보이지 말고, 좋은 점을 적극적으로 받아들이려는 긍정적인 태도를 보여야겠습니다만, 질문과 답변 시간에 다소 공격적인 질문이 나와서 조금 아쉬웠습니다. 어디가나 어쩔 수 없는 현상이구나 하는 생각도 들었습니다.

레일스 축제 분위기의 컨퍼런스에 당당히 초대돼서, 일침을 가한 내공이 꽤 존경스럽습니다. 배워야 할 점은 배우고 활용해야겠죠.

Ze Frank

Chad Fowler가 그를 초청하게된 경유를 설명하면서, “정말 그를 초대해도 될까?”라고 망설였다고 합니다. 온라인 엔터테이너라는 그는, 올라와서 레일스와는 전혀 상관없는 서너가지 에피소드의 재밌는 이야기를 정신없이 펼쳤는데, 관중들은 너무도 재밌어하는 나머지 정신없이 웃으며 눈물을 흘렸지만, 음, 전 알아 들을 수가 없어서 눈물이 났습니다. 간혹 못 알아들어도 웃음이 터져나올만큼 재밌는 사람인거 같더군요. 그의 키노트 덕분에 분위기는 더 밝아지고 사람들의 얼굴에는 웃음이 가득했습니다.

Ze Frank의 사이트

둘째날의 일정은 여기까지해서 10시가 넘어서야 끝났지만, 사람들은 자리에서 일어날 줄 모르고 계속 이야기를 나누었습니다.

Chad Fowler의 오프닝과 DHH의 키노트로 시작된 하루였습니다. 키노트 발표가 끝나고 쉬는 시간에는 많은 사람들이 넓은 홀에 군데군데 옹기종기 몇몇씩 모여서 이런 저런 얘기를 나누는데, 그 분위기가 무슨 축제장에 와 있는 것처럼 활기찹니다.

“Clean Code” by Robert C. Martin

밥아저씨(UncleBob)로 불리우는 오브젝트멘터(ObjectMentor)사의 Robert C. Martin이 코드를 깨끗히 하라는 주제로 발표했습니다. 이제까지 읽어 본 밥아저씨 문서(article)의 이미지로는 상당히 점잖고 권위적인 느낌일 것이라고 생각했는데, 의외의 이미지로 무대(!)에 나섰습니다. 재밌지만 사뭇 “딱딱한” 문서와는 아주 다른 분위기였습니다.

시작하자마자, 압도적으로 전체 관중을 휘어잡는 강렬한 기운을 마구 뿜어내면서 열정으로 발표하더군요. 특이한 유머로 분위기를 띄우고 청중의 집중도를 높인 다음 던진 질문이 이번 세션의 시작이었습니다.

How many of you ever been significantly impeded by bad code?

“지저분한 코드에 심각하게 고생해본적 있는 사람?”쯤의 의역이 괜찮을 지 모르겠습니다. impeded라는 단어에 강렬한 액센트를 넣으며 표정을 찡그리자, 사람들 마구 웃으며, 대부분의 사람들이 손을 번쩍 듭니다. 개발자라면 누구나 손을 드는게 정상이겠지요.

이어서 거침 없이 날아오는 하이킥에 청중들 쓰러집니다.

Why did you write that?

그러게요, 왜들 그런 코드를 작성하셨습니까? (저는 안그런척 )

이미 지저분해진 코드에 대해서 유일한 해결책은 조금씩 개선하는 방법이라고 합니다. 기존 시스템을 놔두고 별도로 새롭게 재구성하는 팀을 만들어 접근하는 전략은 절대 성공할 수 없다고 말합니다. 오로지 조금씩 꾸준히 기존시스템을 개선해 나가는 것만이 유일한 해결책이랍니다.

Args 파서(Parser)

어떻게 깨끗히 코드를 관리하는지, 커맨드라인 파서를 루비코드로 만든 슬라이드 한장의 코드를 보여주며 시작했습니다. 원래는 자바코드로 설명한 Clean Code: Args의 루비 버전입니다. 루비의 경우 메타프로그래밍 코드가 조금 들어갔다는 점을 제외하고는 거의 같습니다.

자라나는 코드

작성한 코드는 그렇게 심각히 나빠보이지 않습니다. 나름대로 괜찮은 코드에 테스트도 문제 없이 통과했습니다. 그러나 문제는, 중복된 코드가 많고, 새로운 기능 확장에 대해 닫혀있다는 점에서 아쉽습니다. 즉, 프로그램은 확장에 열려있고, 변경에 닫혀있어야한다는 The Open Closed Principle에 어긋나는게 가장 큰 문제입니다.

이런 안좋은 냄새(bad smells)가 날 때, 가능한한 빨리 리팩토링(refactoring)을 해야합니다.

조금씩 개선하기

프로그램을 가장 빨리 망가뜨리는 방법은, 한번에 많은 기능을 추가하는 것입니다. 한번에 아주 작은 기능을 조금만 추가해 작업해야하며, 당연히 그 순서는 테스트 먼저 작성하는 것이라고 강조합니다. 테스트 프레임워크로는 구문이 더 깔끔하다는 이유로 RSpec을 추천했습니다. (최근에는 spec문 대신에 it으로 바뀌어서 우리말로 쓰기에는 그다지 깔끔하지 않습니다만… ) 기존의 코드는 간단히 테스트코드가 모두 통과합니다.

추가할 기능에 대한 테스트 코드를 먼저 작성하고, 통과시키기 위해 조금씩 코드를 작성해 나갑니다.

프로페셔널의 자세

짤막하고 흥미로운 코드를 개선해나가는 데모를 보여주고, 결론적으로 다음의 사항을 권장합니다. 눈빛은 그렇게 하지 않으면 꽤나 혼낼 태세입니다.

• 프로는 테스트를 (먼저!) 작성한다.
• 프로는 자신의 코드를 깔끔히 정리한다.
• 프로는 빨리 할 수 있는 유일한 방법이 정석대로 하는 것임을 잊지 않는다.

코드를 정리하며 제대로(!) 작성하는 것을 저녁 식사에 비유했습니다. 밥만먹고 설거지나 뒷정리를 하지 않고 그냥 일어나는 것은 당장은 빨리 쉴 수 있겠지만, 그 다음 번 식사를 위해서는 전혀 좋을 것이 없음은 물론이요, 전체적으로 더 많은 시간과 노력이 필요하다고 말입니다.

마무리

마지막으로, DHH가 얘기하는, “소스코드 저장소에 체크인할 때마다 그전의 소스보다 조금씩 나은 코드를 커밋하자(little better check-in)”를 언급하고 마무리했습니다.

아주 열정적인 모습과 압도적인 분위기가 인상적인 발표였습니다.

RailsConf2007 둘째날입니다. 기대되는 키노트와 세션이 몰려있는 날이라서 흥분됩니다. 오프닝과 키노트를 들으러 일찌감치 식사를 마치고, 앞에서 3번째 줄에 앉았습니다. 맨 앞줄에 쟁쟁한 분들이 앉아 있고, DHH가 제 바로 앞의 앞자리에 앉아있습니다. 뒷모습마저 멋지군요.

오프닝: Chad Fowler

Chad Fowler는 레일스 커뮤니티의 성공을 자축하면서, 그 주된 성공의 요인으로 레일스 커뮤니티의 훌륭한 정신을 꼽았습니다. 레일스 커뮤니티는 뛰어난 생산성의 루비와 레일스로 실질적으로 세상을 바꾸어왔다고 말합니다. 초창기의 루비컨퍼런스에서도 필요하다고 생각한 기능을 그 자리에서 구현해내어 컨퍼런스 기간중에 완성해내는 실행력을 보여주었으며, 그런 실용적인 생산성을 바탕으로 계속해서 우리가 직접 세상에 변화를 보여주자고 말합니다.

키노트: David Heinemeier Hansson

Rich Kilmer의 소개로 DHH(David Heinemeier Hansson)의 키노트가 시작됩니다. 올해에는 어떤 내용으로 한 획을 그을까 기대하며 들었습니다. 먼저 레일스의 성공과 그 증거를 보이며 자축했습니다. (다른데서 보는 시각은 어떤지 모르겠지만, 레일스 컨퍼런스의 분위기는 이미 성공을 자축하는 분위기입니다)

우선 작년의 레일스 컨퍼런스에서 소개한 ActiveResource의 실험이 성공했다고 선언했으며, 더이상 ActiveResource를 쓰지 않을 이유가 없다고 말합니다. 조금더 개선한 모습의 ActiveResource 사용방법을 라이브코딩으로 보여주었습니다. 라이브코딩은 자칫하면 지루해지거나 중단될 수 있는데, 아주 부드럽고 재미있게 진행했습니다. 중간에 살짝 막히는 부분에서는 귀여운 모습의 재치를 발휘하기도 했습니다.

이어서 Rails 2.0의 아홉가지 새로운 주요기능을 발표했습니다. 현재 최신 안정버전인 Rails 1.2.3기준에서는 새롭지만, 이미 현재 Rails Edge버전 에서 95% 이상 돌고 있는 실질적인 기능입니다.

debugger

레일스는 개발서버에 “breakpoint”를 걸어놓고 “script/breakpointer” 스크립트로 연결해서 (내부적으로 drb사용) 디버깅할 수 있습니다. 2.0에서는 debugger가 도입되고, 이는 개발서버가 debugger문을 만나면, 서버 콘솔에 바로 rdb디버거가 열려서, 디버깅 세션을 시작할 수 있습니다. 기존의 디버깅 작업도 놀랍도록 유용하고 편리하다고 생각했는데, debugger는 한발 더 나아가는군요. 이 유용한 기능은 짧은 글로 설명할 수 없음이 아쉽습니다.

HTTP 성능개선

HTTP 성능개선 관련해 두가지 기능이 추가되었습니다.

첫번째로, js와 css파일 하나로 합치는 기능입니다.

개발시에는 자바스크립트나 스타일시트를 여러개의 파일로 나누어 관리하다가, 실서비스에 배포할 때에 하나의 파일로 합쳐서 배포하는등의 작업을 하는 경우가 많을텐데요, javascript_include_tag와 stylesheet_link_tag 헬퍼메소드에 하나로 합쳐서 캐싱처리해주는 기능이 추가되었습니다.

<%= javascript_include_tag :all, :cache => true %>
<%= stylesheet_link_tag :all, :cache => true %>

“/javascripts/*.js” 와 “/stylsheets/*.css” 가 “/javascripts/all.js”와 “/stylesheets/all.css”로 합쳐져 캐싱처리됩니다.

즉, 배포 작업시 하나의 파일로 합치는 스크립트 처리등의 불편한 작업이 필요 없어집니다.

두번째로는, 자바스크립트나 스타일시트나 이미지파일등의 asset서버를 위한 편의기능입니다.

웹브라우저에서 같은 호스트명의 웹서버에게 최대 한번에 두개까지의 HTTP connection을 열어서 사용합니다. (이거 HTTP 스펙에 있는 내용인가요?). 한페이지를 로딩해는데 js, css파일이나 이미지 파일등 동시에 여러파일을 받아갈 수 있도록 하기 위해, 호스트명을 다르게 처리하는 경우가 있습니다.

예를들어, 물리적으로 하나의 서버라고 하더라도 (실제로 독립적인 서버일 수도 있겠습니다만)

http://fs0.cool.daum.net/stylesheets/cool.css
http://fs1.cool.daum.net/javascripts/fantastic.js
http://fs2.cool.daum.net/images/so_smart.png
http://fs3.cool.daum.net/images/happy_railing.jpg

위의 URL에서처럼 호스트명을 다르게 처리할 수 있는데, 이럴 때 편리하게 쓸 수 있도록

config.action_controller.asset_host = “http://fs%d.cool.daum.net”

처럼 선언해 놓으면, 뷰(view)에서 해당 리소스의 url을 만들 때, hash값을 4로 나눈 나머지로, fs0 ~ fs3까지 나누어 출력해주어서, 클라이언트가 골고루 요청할 수 있도록 해줍니다.

예를 들면, 아래의 헬퍼메소드(helper method)가

<%= image_tag “so_smart.png” %>
<%= image_tag “happy_railing.png” %>

아래의 결과를 보이는거죠.

<img src=”http://fs1.cool.daum.net/images/so_smart.png” />
<img src=”http://fs3.cool.daum.net/images/happy_railing.png” />

이 역시 별것 아니지만, 편리한 기능입니다.

쿼리 캐쉬 (Query Cache)

ActiveRecord에 쿼리캐쉬가 추가되었는데,

ActiveRecord::Base.cache do … end

위의 블럭에 묶어서 사용한다고 합니다. 어디에 캐시데이타를 관리하며 어떤 로직으로 캐싱데이타를 expire하는지는 자료가 나오는대로 자세히 봐야겠습니다.

action.mime_type.renderer

ActiveController의 respond_to 처리시, HTTP 클라이언트가 요청한 mime-type에 따라 결과의 content-type을 기본지정하고, 템플릿파일에 사용할 렌더러(renderer)를 명시적으로 표시하는 파일명을 사용합니다.

views/people/index.html.erb
views/peopel/index.xml.builder
views/people/index.rss.erb
views/people/index.atom.builder

ERb나, XML builder 렌더러를 명시적으로 지정해주는 것입니다. 참고로 기존에는 rhtml, rxml이라고 썼습니다.

간단한 초기화 설정환경

레일스 초기화시에 initializers 디렉토리의 모든 루비파일을 읽어들입니다. 별도로 초기화 코드를 넣는 불편함 없이 파일만 준비해 놓으면 됩니다. Convention over Configuration의 영역은 점점 넓어지고 있습니다.

섹시 마이그레이션 (Sexy Migration)

데이타베이스 스키마 생성/변경작업에 매력적인 액티브마이그레이션(ActiveMigration)의 DSL(Domain-Specific Languate)구문이 더 섹시(sexy)하게 바뀌었습니다.

person 모델을 위해 people 테이블을 만드는데 integer타입의 account_id 컬럼과 datetime타입의 created_at 컬럼을 추가한다고 하면,

기존의 마이그레이션 코드는 아래와 같고

create_table :people do |t|
   t.column :account_id, :integer
   t.column :created_at, :datetime
end

섹시 마이그레이션 코드는 아래처럼 바뀝니다.

create_table :people do |t|
   t.integer :acount_id
   t.datetime :created_at
end

어차피 create_table 블럭 안에서는 컬럼을 정의하는 일이 전부니까 보다 표현적인 DSL로 처리하겠다는 맘에드는 모양이긴 합니다만, 내용보다 이름이 더 거창하군요. ^^

HTTP 인증처리

액션컨트롤러(ActionController)에서 HTTP 인증(authentication)을 처리하기 편리한 기능이 들어갑니다. 사실 HTTP인증은 사용자 웹브라우저를 위해서는 거의 쓰이지 않지만, HTTP기반의 API를 위해서는 꽤 유용하게 사용할 수 있습니다. 추가된 기능해서는 클라이언트가 요청한 mime-type에 따라 다른 인증루틴을 태우기 편리한 기능도 있습니다.

그외에도 MIT 라이센스 기본 지정, Spring cleaning이라는 주제로 추가 기능을 설명하며 키노트 발표를 마치자, 열화와 같은 성원의 박수갈채를 받았습니다.

마무리

DHH가 발표중에 말했듯이, Rails 2.0은 완전히 새로운 환상(발표중에는 유니콘에 비유)이라기 보다는, 끊임 없이 빠르게 발전하는 레일스의 모습 그대로이자 현실인거 같습니다.

귀국하면, 지금 개발중인 프로젝트를 Edge버전으로 해보자고 팀원들과 얘기해봐야겠습니다. ^^

Scaling 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로 관리하며 나누어 처리할 수 있겠습니다.

마무리

이 시간에 언급한 내용만 보더라도, 성능이나 확장성을 위해서는 레일스뿐만이 아니라 다양한 소프트웨어, 하드웨어가 영향을 미치고, 무엇보다 중요한 것은 경험과 역량일거 같다는 생각으로 정리되네요. 결론적으로, ‘안정적이고 확장성 좋은 웹서비스에 레일스를 사용할 수 있는가?’라는 질문에 대해서는 우문현답이 되어 마무리된걸까요?