티스토리 툴바


nginx 만세!

사용자 삽입 이미지







"엔진엑스"라고 읽는 nginx는 고성능의 가벼운 웹서버이다. 처리 성능도 매우 뛰어나지만, 설정파일을 건드리기 매우 쉽고 간단하다는 점이 더 매력적이다. 실서비스에 운영중인 웹서버의 설정파일이 100줄로도 충분한 설정이 가능한데다, mongrel과의 연동에 필수인 모듈들도 기본 포함돼있어서 별도의 옵션 없이도 간단히 빌드해서 사용할 수 있다.

다음 캘린더 서비스는 최신 안정판이었던 nginx-0.5.33으로 운영중이었는데, 며칠전 0.5.44버전이 공개된 사실을 오늘 알게 되었다. 언제 업그레이드해야지 생각했다가, 문득 전에 스쳐읽었던 문서가 떠올랐다. 문서의 제목으로 보아하니 서비스 운영중에도, 전혀 중단없이 새 바이너리로 업그레이드 할 수 있다는 얘기인거 같았다. '가만, 그러면, 지금 당장할 수 있는거잖아.'

Upgrading To a New Binary On The Fly

경험과 성격상, 이런 업그레이드는 부지런히 하지 않으면, 부담도 커지고 하기도 더 귀찮아진다고 생각한다. 그때그때 바로바로 처리해야지, 오랫동안 업데이트 없이 방치 상태로 가는 것을 막을 수 있다고 생각한다.

문서의 내용을 요약해보면,

nginx프로세스가 돌고 있는 시스템에서 다음의 과정을 거치면 실행중에 업데이트가 완료된다.

  1. nginx 바이너리를 최신버전으로 update
  2. 실행중인 nginx 프로세스에게 USR2 시그널을 보낸다.
    -> 새로운 nginx master프로세스가 추가로 실행된다. 즉, nginx 프로세스가 master와 worker 프로세스를 포함해서 두세트가 실행된다.
  3. 먼저 실행중인 nginx 프로세스에 WINCH 시그널을 보내면, 자신이 관리중인 worker 프로세스를 모두 부드럽게 제거한다 (gracefully shut down).
    -> 이제 새 버전의 nginx만이 운영에 들어간다.
  4. 옛버전의 nginx의 worker 프로세스가 모두 안전하게 종료되면 master프로세스도 쉬게 해줄 수 있다.
  5. 옛버전의 nginx 프로세스에게 QUIT시그널을 보낸다.

이 과정을 진행하면, 새로운 바이너리로 운영중에 교체가 가능하다. 문서를 보면, 중간과정에서, 혹시나 문제를 발견했을 때, 옛버전으로 되돌리는 과정도 설명되어있다.

참고로, 위 과정을 내 로컬시스템에서 진행해 본 상황을 업로드!

사용자 삽입 이미지


같은 방법으로, 실 서비스도 모두 0.5.44로 안전하게 업데이트!

엔진엑스 만세!!!

다음 캘린더 서비스 소개

Daum 캘린더 서비스루비(ruby)라는 간결한 프로그래밍 언어를 써서 개발해 운영하고 있습니다. 국내에서도 루비에 관해서 '한국루비사용자모임'을 중심으로 모여 다양한 주제로 의견을 나누는 '루비세미나'가 비정기적으로 개최되고 있습니다. 지난 12월1일에 열린 다섯번째 루비세미나에서는, '캘린더 서비스 개발이야기'라는 주제로 발표할 수 있는 기회가 있었습니다.

캘린더팀의 완소 개발자 taskin님이 훌륭하게 발표해주셨는데, 아래는 해당 발표를 담은 동영상입니다.





그동안 루비세미나에서 많은 것을 배우고, 프로젝트에도 많이 활용할 수 있었는데, 다시 저희의 경험을 공유할 수 있는 뜻깊은 자리였습니다. 캘린더 서비스도 잘 자라나서, 개발적인 측면에서도 좋은 정보를 공유할 수 있는 기회가 지속되었으면 좋겠습니다.

Q&A

질문과 답변 내용을 가감및 보충해서 짤막히 다시 적습니다.

1. 레일스(rails)캠핑(camping)을 혼용해 썼다고 했는데, 그 비율은?
대부분의 주요 서비스는 레일스가 담당하고 있고, 주요서비스와는 조금 구분되는 간단하고 작은 별도의 업무에 대해, 별도 서버에 캠핑을 쓰고 있다. 캠핑의 비율은 매우 적다.
2. 캠핑 디플로이(deploy)는 어떻게 해서 쓰고 있는지?
엔진엑스(nginx) -> 몽그렐(mongrel) -> 캠핑으로 구성되어있다. 앞단에 엔진엑스가 요청을 받아주며, 캠핑은 몽그렐 프로세스안에서 실행된다.  
3. 캠핑의 앞단에 몽그렐이 있다는건, 몽그렐이 로드된 다음에 캠핑이 실행되는 것인가? 리퀘스트 하나에 대해서 몽그렐이 하나씩 뜨는 것인가?
몽그렐은 자바 서블릿 엔진처럼, 프로세스가 하나 떠있는 상태에서 매 리퀘스트마다 처리 쓰레드가 실행된다. 즉, 몽그렐 프로세스는 하나만이 실행된다.
4. 캠핑과 mod_ruby를 비교해서 어떤지?
캠핑은 가벼운 웹프레임웍이고, mod_ruby는 웹서버에서 루비로 처리할 수 있는 하나의 수단이라 비교 대상은 아닐 수 있지만, mod_ruby는 아파치(apache) 프로세스 안에서 돌아가기 때문에 단점이 될 수 있다고 생각한다. 캠핑자체는 단순한 업무를 구조적으로 해결하기에 꽤 재밌는 해결책이다.

5. 앞단에 L4 로드밸런서가 있는데, 왜 nginx를 써야하는가? L4에서 몽그렐로 바로 연결해도 되지 않는지?
첫번째로, Layer 4 로드밸런서로는 사용자 요청을 여러대로 나누어 처리하는 것은 가능하지만 Layer 7수준의 처리를 할 수 없다는 문제가 있다. http access log를 남기는 작업을 비롯해 http 프로토콜 수준의 url_rewrite등의 작업이나, 정적(static) 파일을 신속히 서비스하기 위해서는 중간에 L7수준의 작업을 간편하고 쉽게 처리할 수 있는 레이어나 웹서버가 하나 더 필요하다.

두번째는, 정책적인 사항인데, L4스위치를 관리운영해주는 본부가 따로 있기때문에, 개발자가 직접 제어하는 것이 바람직하지 않다는 이유이다. 중간에 개발자가 운영상황에 따라 손쉽게 제어할 수 있는 레이어가 하나 더 있는 것이 좋다는 판단이다. 
6. 개발인원은 몇명인가?
레일스개발자는 세 명이 자바스크립트 개발도 함께 하고 있으며, UI개발자분이 한분 더 있다.
7. 서비스를 살펴보니 RESTful하게 개발했는데, 오픈API에대한 고려가 있는것인가?
꼭 오픈API를 위해서가 아니더라도, RESTful 서비스 방식은 꽤 매력적인 개념이라고 생각한다. 내부적으로 RESTful 방식으로 개발되어있고, 캘린더 미니 역시 같은 방식으로 접근해 xml 데이터를 가져가서 사용한다. 우선은 다음내의 플랫폼 연동에 주력하고, 추후에 오픈API를 고려하고있다.

8. 자바개발자로써 루비를 써보니 어떤가?
코딩하는 재미가 있고, 코드 분량이 상당히 줄어든다. 처음엔 낯설고, 자바에 비해 참고문서가 적다는 점이 불편하기도 하지만, 그외에는 꽤 만족하고 쓰고 있다.

발표자료도 첨부합니다.


RailsConf2007 관련 글모음

올해 5월에 다녀온 RailsConf2007에 대한 관련글 링크를 적습니다.

이곳에 따로 정리하려다가, 결국 별도 정리는 하지 않았습니다. 대신 "다음 개발자 블로그"에 남겼던 블로그 포스트에 링크를 걸어둡니다.

RailsConf2007: DHH 키노트

키노트중

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

오프닝: Chad Fowler

Chad Fowler

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

키노트: David Heinemeier Hansson

DHH

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버전으로 해보자고 팀원들과 얘기해봐야겠습니다. ^^

RailsConf2007: Scaling Rails Application from the Bottom Up

RailsConf2007 첫째날입니다. 내일부터가 본격적인 시작이고, 오늘은 가벼운 튜토리얼세션으로 워밍업하는 날인데도, 열기는 대단했습니다. 내일부터는 정말 붐비겠네요.

오늘은 본격적인 시작에 앞서, 오전/오후로 나누어 튜토리얼 몇개가 준비되어 있었는데요, 저는 오전에는 Scaling Rails Application from the Bottom Up을 듣고, 오후에는 Rails Routing Round Up을 들었습니다.

먼저 오전의 Scaling Rails Application from the Bottom Up 튜토리얼은, Joyent사의 CTO인 Jason Hoffman의 레일스 애플리케이션의 성능과 확장성에 대한 강의식 세션이었구요, 튜토리얼이라고 보기는 어려운 형식으로 꽤 흥미로운 내용을 심도 깊게 얘기해 주었습니다.

James Hoffman


50분씩 3시간으로 나누어 진행했으며, 처음 두시간은 일반적인 성능과 확장성에 대한 접근방법을 넓은 시각으로 비추어 주었고, 마지막 한시간만이 레일스 관련한 확장성에 대한 설명시간이었습니다.
 
전체적으로는
루비/레일스로 실서비스에 적용할 만큼 안정적이고 충분한 성능을 낼 수 있나요?

라는 질문에 대한 답변과 보충 설명의 시간이었다고 볼 수 있습니다. 그 답변에 대해 우선은
그것이 정말 레일스의 이슈인가?

라는 반문으로 문제를 풀어나갔는데요, 전체 시스템관리자의 관점으로 바라볼 때, 성능과 확장성에 관련한 구성요소가 어떤 것들이 있는지 슬라이드 한장에 작은글씨로 가득 채워 놓고는 그 중에 레일스가 차지하는 부분을 표시해서 그 비율이 얼마나 적은지를 보여주었습니다. 개발자 관점으로만 좁게 바라보다보니, 마치 레일스로 바뀌는 것이 대단한 차이가 있는 것처럼 생각되지만, 사실 전체적으로 중요한 부분은 한 두개가 아니구나하는 것을 일깨워준 슬라이드였습니다.

확장성의 의미에 대해서는 레고블럭에 비유하며, 어떤 시스템이 확장성 좋은 시스템인지를 설명했습니다. 레고블럭의 경우 하나에 한블럭 더 꽂으면 딱 2배 길이가 되고, 하나 더 꽂으면 3배 길이가 되고, 다시 한개 줄이면 2개 길이가 되는등, 늘이고 줄이는 만큼의 결과차이를 그대로 보인다는 점에서 확장성이 뛰어나다라고 하는 비유였는데요, 막연히 여러대의 서버로 늘여서 성능 높이는게 확장성이 아니다라는 점을 강조했습니다.

성능과 확정성의 기본적인 제약사항으로는, 자금, 시간, 인력, 경험, 전력, 네트워크 bandwidth를 언급했습니다. 레일스가 그 확장성의 제약사항이 아니라는 점을 은연중에 강조했다고 볼 수 있는데, 전력의 경우는 저는 미처 생각치 못한 내용이었습니다. 실제로 1년에 전체 서버비용의 30%정도의 큰 금액이 전력비용으로 소비되고, 전력이 결국 사용할 수 있는 CPU와 메모리를 제한하기 때문에 큰 제약사항일 수 있다고 했습니다. 이 부분에서 각종 전원플러그들을 잔뜩 찍어놓은 사진을 보여주면서 어떤게 전력손실이 적고 좋다를 설명하는거 같았는데, 저런거까지 신경써야하는구나 싶더군요. 전력 문제는, 대규모IT기업이 IDC센터를 지을 때, 전력비가 몇 센트라도 싼 지역에 짓는다는 사례를 들며 강조했습니다.

서비스 성능과 확장성에 레일스가 제약사항이 아니라는 점을 강조하면서, 그렇다면 레일스의 강점은 무엇일까하는 궁금점에 대한 답변으로는,

하루 아침에 완성되는 최고 수준의 웹사이트는 없으며, 여러 단계를 반복해 계속적으로 완성도를 높이고 기능이 추가되는 과정이 필요한데, 이 반복과정(iteration)을 빠르게 진행할 수 있다.

라는 장점을 얘기했습니다. 저는 레일스로 개발하면 편하고 빠르고 재미있다(!)라는 장점을 크게 보는데, Jason씨의 강점 언급이 보다 프로다운 것이 될 수 있겠네요.

다시 확장성으로 돌아와서, 확장성의 목표는 컴퓨팅 파워를 높이고, 작은 공간을 차지하고, 전력소비를 줄여야한다고 얘기합니다. 공간에 대한 얘기를하면서 보여준 사진은, 모종의 데이터센터였는데, 서버비용을 줄이겠다는 생각으로 헐값의 데스크탑PC들을, 랙도 아닌, 짜맞춘 앵글에 쌓아놓고 운영했던 사진을 보여주었는데요, 보기만해도 재밌는 사진이더군요. 전력, 공간, 운영부담은 무시하고, 단순히 서버비용만을 편협하게 고려한 재밌는 발상이 물든 사진이라고 볼 수 있겠습니다.

전력, 서버, 네트워크 등의 애플리케이션 인프라(infrastructure) 비용에 대해
The 10% Rule: (인력 비용을 제외한) 인프라비용이 수익의 10%이하여야 한다.

고 말했습니다. 수익의 10%이하로 인프라비용을 낮추든지, 아니면 인프라비용에 맞추어 수익을 그만큼 늘이든지해야 사업성이 있다는 얘기였습니다. 구글의 경우는 7%~8%선으로 발표되었다고 하더군요. 덧붙여 언급한 사항으로, 인프라비용을 줄이기 위해 자체 데이터센터를 구축해 운영한다거나하는 것은 인프라자체 비용은 줄일 수 있을지 몰라도, 값비싼 고급인력을 보유해 연봉을 지급해야한다라는 점에서 전체비용 절감효과가 크지 않을 수도 있다고 언급했습니다. 무엇을 보더라도 단편적으로만 바라보고 문제를 해결할 수는 없겠죠.

인프라를 위해 무엇을 어떻게하든, 다음의 3가지를 지키라고 얘기합니다.

  • keep it simple
  • standardize, standardize, standardize
  • try and use open technologies

이 밖에도 많은 광범위한 내용을 다루며 두시간에 걸쳐 얘기해주었구요, 마지막 시간이 되서야  대망의 레일스관련 내용이 터졌습니다. 앞시간에 언급한 고려사항과 필요한 선택에 대해 결론적으로 Joyent사에서 선택한 솔루션을 언급하며, 어떤 솔루션을 사용하면 레일스 애플리케이션의 성능을 높이고, 확장성을 고려할 수 있는지에 대한 제안이었습니다.

실제 사용 제품까지 언급하며 보여주었는데요, Sun사의 Sun Fire AMDs T1000s서버에 Solaris Nevada를 설치해서 사용한다고 했습니다. 처음에는 Dell사의 서버로 시작해서 Sun으로 바꾸었다고 하는데, 운영상의 장점을 극찬해서, 왠지 써보고 싶다는 생각이 들더군요. Sun에서도 인텔아키텍쳐(IA)의 CPU로 돌아가는 서버를 팔고 있는지조차 몰랐어요. ㅠ.ㅠ

Solaris OS를 선택한 이유로는 오픈소스임을 강조하면서, 상업용 제품이었던 믿을만한 운영체제(OS)가 오픈소스화 되었으니(음, OS가 OS화되었군요) 상업용의 장점과 오픈소스의 장점을 함께 갖추어서 좋다고 얘기했습니다. 우선 하드웨어벤더가 적극적으로 지원하는 운영체제를 설치하는게 기본이겠고, 특별히 Solaris OS를 선택한 이유로는 ZFS 파일시스템의 매력, 가벼운 가상화(virtualization), 무료, 그리고 대규모 시스템(512GB RAM, 1TB swap)에서 검증됐다는 점을 꼽았습니다.

오래 전에 Solaris x86버전은 사업 접는다고 들었던거 같은데, 다시 IA쪽도 지원하나보군요. 무관심하게 지냈었던 분야였는데, 이번 기회에 다시 귀를 열고 지내야겠습니다. Sun에서 스폰서라도 받았는지, SAN장비도 Sun Fire X4500의 운영편의성을 강조하면서 극찬했습니다.

루비의 강점으로는 쓰레드기반이 아닌 프로세스기반임을 언급했고, 그 외에도 당연한 루비강점언급이 잠시 있었구요, 레일스 프로세스를띄우는 방법으로방법으로 FCGI, 몽그렐(mongrel), JRuby in Glassfish를 나열했습니다. 지금의 상황은 몽그렐이 좋은 선택이지만, JRuby in Glassfish의 높은 가능성을 암시했습니다. JRuby 완성도가 높아지면 자바쪽의 강점을 그대로 흡수할 수 있겠죠. 예를들어 JDBC연결이라든지 Sequoia사용등이 그 일부가 될 수 있겟습니다.

Joyent사에서 사용하는 몽그렐 클러스터의 구성은, 16GB RAM의 4 AMD CPU 시스템을 4개의 버추얼컨테이너로 나누어(물리적으로 한개의 서버가, 논리적으로 4대의 서버로 분할) 각각의 컨테이너에 10개식의 몽그렐 프로세스를 띄워서 사용한다고 했습니다.

DB연결은 MySQL adapter를 수정해서 Sequoia의 C-API에 연결해 사용할 수 있다고 했는데, 실제로 Joyent사에서 사용 중인지는 잘 못들었습니다.

로드밸런서(load balancer)로는 BIG-IP f5를 쓴다고 했는데요, 안정적이고 확장성 뛰어난점은 물론이고 Layer7 수준이라는 강점을 내세웠습니다. 제가 다니는 회사에서 주로 쓰는 LVS같은 L4수준에서 할 수 없는 기능을 보여주었는데, 꽤 샘이 나더군요.

현재 일반적으로 몽그렐 클러스터는 Apache의 로드밸런싱 프록시 모듈을 사용할텐데요, Joyent에서는 BIG-IP 로드밸런서에 곧바로 몽그렐 클러스터를 그룹별로 연결해서 사용한다고 합니다. 아파치 모듈의 어떤 부분이 블러킹콜을 사용해서 확장성의 한계가 크다라는 점을 애기했습니다.

L7수준으로 로드밸런싱해서, [HTTP:uri]를 보고 실제 웹서비스클러스터를 나누어서 사용하는데, 이를 이용해 같은 호스트명에 대해 svn이나 trac 클러스터군을 나누어 구분했고, 레일스 애플리케이션의 경우, 컨트롤러별로 몽그렐 클러스터를 구분지어서 처리한다는 점이 인상적이었습니다.

무료로 사용가능한 L7대안으로 몇가지 제시했는데, 미처 메모하지 못했습니다. 제가 다니는 회사에서는 L4수준인 LVS를 주로 쓰는데, L7수준으로도 무료가 있다고하니, 잘 써볼 수 있는 기회가 생기면 좋겠습니다. 우선은 아파치 밸런싱프록시 모듈로 따라해봐야겠습니다.^^;

그리고, 이 부분이 전체 3시간의 핵심일 수 있는 내용일텐데요, 꼭 레일스 애플리케이션에 한정되는 얘기는 아니지만, RDBMS만 너무 고집하지 말라고 했습니다. memcached, LDAP, J-EAI, File System을 잘 활용해서 확장성을 높일 수 있는 점을 잊지 말라고 했습니다. J-EAI는 처음 들어봤는데, 메모리디비를 사용하는 메시지버스라고 했습니다. 커넥터도 다양하고, 클러스터링해서 사용가능한 확장성 좋은 솔루션이라고 하는군요.

파일시스템의 경우, 절대 한 디렉토리에 10,000개 이상의 파일을 저장하지 말라는 기본적인 얘기가 있었구요, 이를 위해 사용하는 디렉토리 해쉬의 경우, 너무 다단계를 사용하는 우를 범하지 말고, 보기에도 깔끔하고 예측가능한 방법으로 해쉬처리하자는 내용을 언급했습니다. Jamis의 ID파티셔닝에 대한 간단한 루비코드를 샘플로 보여주기도 했습니다.

간과하기 쉬운 DNS에 대해서도 언급했는데요. PowerDNS에 데이타베이스를 백엔드로 붙여서 간단히 사용자별로 서버군을 분리하는 내용을 언급했습니다. Master DB 하나만 공유하고, 분리가능한 대부분의 데이터는 분리된 서버군이 나누어 처리하는 방식이었습니다.

전체 내용을 요약한 다음의 슬라이드 한장이, 핵심이라고 할 수 있겠습니다.

 

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

   

RailsConf 첫째날

어제, 포틀랜드에 도착해서, 오늘 아침부터 튜터리얼 세션에 참석중입니다. 오전에는 Scaling에 관한 강의식 세션이었구요, 지금은 Rails Routing에 대한 기초적 튜터리얼중입니다.

오픈마루의 문식님을 만나서, 오전에는 같이 듣고, 오후에는 따로 듣는중. 저녁 같이 먹기로 했어요. 어제는 혼자서 저녁먹느라 어찌나 뻘쭘하던지...

불행히도, 호텔의 인터넷 사정이 매우 열악해서, 실시간 블로깅은 어려울 것 같군요.

차차, 정리해서 올리겠습니다.

RailsConf2007 참석합니다

사용자 삽입 이미지

미국 Portland의 Oregon Convention Center에서 열리는 RailsConf2007에 참석합니다. 5월 17일부터 5월20일까지의 3박4일 일정이구요. 저는 16일 오전에 포틀랜드 공항에 상륙합니다.

작년에 첫 레일스컨퍼런스에 참석하고 싶었는데, 망설이던 찰나 순식간에 마감되어서, 가지 못했던 아쉬움이 컸습니다. 올해 컨퍼런스 소식을 접하고, 등록 시작하자마자 서둘러 신청했습니다. 아니나 다를까, 금새 1000여명이 등록완료해서 마감되었다는 소식을 들었습니다.

회사의 개발자지원 프로그램으로 가는 것이구요, 바쁜 프로젝트 와중에 자리를 비우게 돼서 동료들에게 미안하지만, 다녀와서 우리 프로젝트에 도움이 될 수 있도록 좋은 내용 많이 배우고 오겠습니다.

참가예정세션