Dragonkun in Tistory

공개 SW 공모대전에 참가합니다.

별 일이 없으면 공개 SW 챌린지 Linux System Monitoring Tool 쪽으로 제출하려고 합니다.
Flex 공부도 할 겸, UI 는 레일스 + Flex 쪽으로 생각하고 있습니다.
사실 그래프 컴포넌트 등이 있는 Flex 로 하는 게 마감까지 맞출 수 있을 같더군요.
현재 확정 인원은 3명이고, 가능하기는 최대 5명까지 가능하니 주변에 떡밥 좀 뿌리고 다니고 있습니다;;

다들 학생이고 주중에는 회사 다니기에 주말밖에 시간이 안 나긴 하지만;;
되는 데까진 열심히 해봐야 겠습니다.

이번 주말 쯤엔 서점가서 Flex 책 좀 뒤져봐야 겠군요.

Ps. 이번 기회에 Redmine 좀 써보면 되겠군요. :)

설치
우선 Phusion Passenger (A.K.A mod_rails)를 설치합니다.

우분투에서는 설치 후 패스가 제대로 걸려 있지 않습니다.
/var/lib/gems/1.8 아래에 설치가 되더군요.
아래와 같이 아파치 모듈을 설치하는 명령어를 실행합니다.
(apache2-prefork-dev 같은 아파치 개발 패키지가 필요할지도 모릅니다.)

엔터 몇 번을 치면 자동으로 모듈을 빌드하고 설치를 끝마칩니다.
그리고 아래와 같은 설정을 /etc/apache2/mods-availabe/mod_rails.load 라는 파일을 만들어 놓습니다.

쉘에서 아래와 같은 명령으로 mod_rails 모듈을 활성화 시킵니다.

그리고 아래와 같이 아파치 설정을 합니다.
전 포스팅에서 다뤘던 redmine 을 예제로 합니다.

우선 /etc/apache2/sites-enable/default 파일을 아래에 아래와 같이 수정합니다.

아파치를 설정을 다시 불러들입니다.

이걸로 설정이 끝났습니다.
다른 어떤 배포 환경보다도 간단하게 설치/설정이 가능합니다.
nginx+몽그렐 클러스터, 아파치+프록시 밸런서+몽그렐 클러스터 등등의 설정에 비하면 정말 간단해진 것을 알 수 있습니다.

우아한 재시작
레일스 어플리케이션을 구동하다 보면 새로운 모델을 추가한다던가 새로운 플러그인을 설치한다던가, 웹 서버를 재시작해야 할 일이 종종 생깁니다.
기존에는 우아하게 재시작하기 위해서 seesaw 와 같은 gem으로 몽그렐 클러스터를 관리했었는 데, mod_rails 는 한 술 더 뜹니다.  그저 어플리케이션 디렉토리에서 아래와 같은 명령어면 됩니다.

이렇게 restart.txt 파일만 만들어 놓으면 접속이 있을 때, 새로 레일스 설정을 불러들입니다.

어느 정도 mod_rails 를 이용하여 어플리케이션을 돌려봤는 데, 성능도 좋고 정말 안정적으로 돌아갑니다.
예전 초창기에 FCGI 썼을 때의 악몽(정말 이유를 알 수 없는 500에러...) 따위는 이제 생각하지 않아도 됩니다.
게다가 서버 재시작을 위해서 루트 권한도 필요없으니 한 번 설정만 해 놓으면 사용자 계정에서 무리없이 쓸 수도 있구요.
루비의 배포환경도 나날이 발전하고 있습니다.  아직 완벽해졌다고는 할 수 없지만, 이 정도만 되고 꽤나 편리해 진 셈이지요.

redmine의 홈페이지

오늘 아침 출근해서 이것 저것 웹 서핑하다가 우연히 redmine 의 존재를 알게 되었습니다.
Python 의 trac 처럼 위키, scm, 이슈 트래킹 시스템 등등이 포함되어 있는 통합 프로젝트 관리 어플리케이션이죠.
동아리 홈페이지에 프로젝트를 공유할 수 있는 시스템을 마련하려고 하는 차에 이 놈이 딱 눈에 들어오게 됐네요.
레일스로 만들어진 어플리케이션이라 조금 수정을 하면 다른 레일스 어플리케이션이랑 잘 붙을 것 같더군요.

우선 기능을 몇 개 살펴보면, 위에 언급한 위키, scm, 이슈 트래킹 시스템 등은 모두 사용할 수 있습니다.
더욱이 기본적으로 멀티 프로젝트가 가능하고 trac 에는 존재하지 않았었던 프로젝트 별 포럼과 파일 저장소를 지원합니다.
단순히 프로젝트 관리 기능에만 충실했던 trac 과는 달리 뉴스, 문서 관리 시스템 등 일종의 커뮤니티 및 배포 사이트로서의 기능이 포함되어 있습니다.

일단 한 번 설치를 해 봅시다.
우분투 8.10 데스크탑 버젼을 기준으로 설명합니다.

우선 subversion 클라이언트가 설치되어 있지 않으신 분은
으로 subversion 클라이언트를 준비합시다.

다음은 최신 stable 버젼을 저장소에서 export 합니다.

디렉토리로 이동 후 webrick을 실행합니다.

제 경우는 레일스를 2.1.0 버젼으로 업데이트 했는 데 config/boot.rb 가 버젼이 맞지 않는다고 하더군요.
redmine 은 레일스 2.0.2 버젼을 필요로 합니다.

명령으로 boot.rb 를 최신 버젼으로 업데이트 시킬 수 있습니다.
레일스가 설치되지 않으신 분은
로 2.0.2의 버젼을 설치하시던가, 최신 버젼의 레일스를 설치하시고 저처럼 아래와 같은 작업을 하시면 됩니다.

config/environment.rb 를 열어서, 아래와 같은 부분에서 RAILS_GEM_VERSION을 현재 자신이 사용하고 있는 레일스의 버젼과 맞추어 줍시다.

다음은 데이터 베이스 설정입니다.
저는 mysql을 이용하므로 mysql 서버에 접속해 데이터 베이스를 만들어 줍니다.

사실 production 환경으로 돌리는 것이 가장 나을 거고 그러면 redmne_production 만 만들어 주면 됩니다.
기본으로는 development 환경으로 서버가 돌아가게 되는 데, config/environment.rb 등에서 RAILS_ENV 를 'production'으로 변경하면 production 환경으로 돌아가게 됩니다. 저는 다른 프로그램들과 연동시킬 생각이라 development 로 돌리기로 했습니다.

다음은 config/database.yml을 수정합니다.

로 샘플 설정을 복사하시고,  db 이름, db user 이름, db user 패스워드 등을 잘 설정하시면 됩니다.
우분투의 경우 mysql 소켓의 위치가 rails 기본값과는 달라서 아래와 같이 해 주거나 혹은 mysql gem 을 설치하면 된다고 합니다.




웹 서버를 돌려보려 하면, rfpdf 플러그인이 에러를 냅니다.(레일스 2.1 기준)

/home/alice/redmine/redmine-0.7/vendor/plugins/rfpdf/init.rb 의 소스 중

을 아래와 같이 수정합니다.


그래도 아직 에러를 내는군요.;;
app/controllers/application.rb 에 제일 첫째 줄에
이라고 적어줍시다.

그리고 rake!

rake 중에도 또 에러가 나는데..
db/migrate/072_add_enumerations_position.rb
db/migrate/078_add_custom_fields_position.rb
파일의 each_value 라는 메소드를 그냥 each로 바꿔 줍니다.

rake가 끝나면 마지막으로 webrick을 실행시켜 보기위해
로 서버를 실행시킵니다.

그리고 localhost:3000 으로 확인해보면 끝!

심플하다 못해 썰렁한 디자인의 redmine 첫 페이지가 나오네요.
이거 삽질하다 보니 그냥 레일스 2.0.2에다 설치하거나 redmine 개발 버젼을 설치할 걸 하는 후회도 좀 드네요. :)
그래도 굳이 난 레일스 2.1에 stable 버젼을 쓰겠다고 고집하시는 분이 계시면 이 글이 도움이 되었으면 하네요.
좀 사용해보고 trac과 비교도 해보고 하려고 했는데, 설치까지만 하도록 하고 다음 포스팅거리로 남겨둬야겠습니다.
사용기 전에 설치편 번외편;; 정도로 mod_rails, svn 연동을 다룰까합니다. mod_rails 설정이야 별 다를 것 없겠지만 이왕 하는 김에 같이 다룰까 합니다.

저는 루비를 제대로 공부해 본 적이 없습니다.
다만, 파이썬을 약간 다뤄본 지식으로 몇 개 레일스 프로젝트를 맡아 진행해 왔었고,
간단한 레일스 어플리케이션을 작성하기 위한 최소한의 루비 지식을 가지고 있습니다.
그렇기 때문에 아직도 익숙치 않는 루비 문법들이 많이 있고, 익숙치 않아서 자꾸 쓰기를 꺼려하는 문법들이 몇 개 있습니다.
그런 문법들의 개념을 익히고 잘 사용해 보기 위해서 한 번 정리해 보기로 했습니다.

코드 블록
루비 코드를 보게 되면서 처음으로 막히는 부분은 바로 코드 블록이었습니다.
코드 중간에 갑작스럽게 등장하는 중괄호나 do/end 키워드는 어떻게 해석해야할지 난해하기만 했습니다.
사실 지금도 루비는 초보 수준이라 코드 블록이 익숙하지는 않습니다. :)
코드 블록은 다음과 같이 쓰입니다.


혹은


메소드 뒤에는 당연히 인자들이 나열되어야 할 것인데.. 어째서 쌩뚱맞게 코드들이 나오는가?
하는 생각이 많이 들었죠.
이렇게 생각해도 되는 건지는 잘 모르겠지만..
코드 블록안의 코드들을 인자처럼 method 에 넘긴다고 생각하면 될 것 같네요.
실제로 메소드에서 인자로 요구하는 건 아니지만, 이해하기엔 그게 가장 쉽게 이해가 되더군요.

yield 키워드
위에서 인자처럼 넘긴다고 했는데, 그건 그냥 이해를 쉽게 하기 위해서 그렇게 생각하는 것이고..
실제로는 메소드안에서 yield 키워드 부분이 코드 블록으로 대체가 되는 것이더군요.
더 자세히 보면 메소드가 코드의 일부분을 코드 블록에게 양보(yield)한다는 느낌일까요.



의 결과는


이 되겠지요. yield 에서 인자를 넘길 수도 있고 코드 블록에서 리턴된 값을 받을 수도 있습니다.




yield 키워드가 함수처럼 10 이란 수를 코드 블록으로 넘겨줬고, 코드 블록은 10을 x라는 블록안의 지역 변수로 넘겨 받았습니다.
또 코드 블록에서 수행된 x*5의 결과를 yield_test 안으로 리턴하여 yield_test의 result가 넘겨받았음을 알 수 있습니다.

each 메소드
그 의미도 잘 모르고 계속 써 왔었던 Array 클래스의 each 메소드가 코드 블록을 보고 나니 다시 보이기 되더군요.
그냥 원래 그런 형태로 쓰는 거다 정도로만 생각하고 있었는데, yield 와 코드 블록을 이해할 수 있는 대표적인 예가 each 였네요.


each는 Array 에서 한 원소씩 돌아가면서 계속 그 원소의 값을 인자로 yield를 하는 형식이겠죠.
yield에서 넘긴 인자를 코드 블록이 받아서 반복하는 형태의 가장 자주 쓰이는 코드 블록/yield의 예라고 할 수 있겠네요.

--
사실 최근에 취업과 관련해 면접을 보면서, rails 프로젝트를 진행한 것을 보고 루비를 잘 아시는 면접관 분이
루비와 레일스에 관련한 질문을 몇 개 하셨는데, 코드 블록에 대한 질문을 제대로 답변하지 못한 적이 있었습니다.  그래서 제대로 공부도 할겸 책도 찾아보고 인터넷 사이트도 뒤져보면서 알아보고 개념을 익히게 됐네요.
다음번에도 비슷하게 개념이잘안 잡힌 루비의 문법 등이 있으면, 정리해서 포스팅할 계획입니다.
이번 기회에 루비 공부도 확실히 해 두는 것이 좋을 것 같아서요. :)

Rails 는 정말 훌륭한 웹 프레임워크입니다.
하지만 편하다고 아무렇게나 코딩을 하게 되면 골치아픈 상황들이 여럿 발생합니다.
프레임워크에서 어떤 SQL을 생성하는지, 각 쿼리들은 속도가 어떠한지 꾸준히 확인을 해 줘야합니다.

이 포스팅은 제가 정말 생각없이 코딩을 하게 되어서 겪은 여러가지 상황을 정리한 것입니다.

#1. N+1 문제
흔히 말하는 N+1 케이스입니다.
posts = Post.find :all posts.each do |post| puts "#{post.title} (#{post.comments.length})" end
멀쩡해 보이는 코드지만.. 날아가는 쿼리가.. 대략.. 이렇습니다...-_-
SELECT * from posts SELECT * from comments where post_id = 1 SELECT * from comments where post_id = 2 ..... SELECT * from comments where post_id = 100
Eager Loading 으로 해결가능 합니다만..
Eager Loading 으로 쿼리의 수는 1개로 확실히 적어지지만, 항상 성능이 좋아지는 것은 아닙니다.

자세한 건 이 글 을 참고하시면 좋겠습니다.

덧붙여서 윗글의 정보와는 달리 현재 Edgerails 에서는 :preload 옵션이 없고 :include 를 사용해도,
preload 가 가능한 경우는 Eager Loading이 아니라 Preload 를 하도록 패치되어 있습니다.


#2. Find conditions 에 시간을 사용할 경우는 한 번 더 생각을...
얼마전 테스트를 하다가 우연히 발견했습니다.
Post.find :all #1 Post.find :all, :conditions => ['created_at > ?', 1.days.ago], :limit => 20 #2
어느 쪽이 더 빠를까요? 당연히 테이블 전체를 가져오는 1번보다 2번이라고 생각하기 쉽습니다.
그런데 실제로 해보면 예상치 못한 결과가 나오더군요.

첫번째 호출할 때는 2번이 빠른데.. 두번째 이상 호출을 하게 될 경우, 1번이 훨씬 빠릅니다.
답은 각자 생성하는 쿼리에 있었습니다.

1의 경우는
SELECT * from posts
로 처음이나 두번째 호출 후나 일정한 반면에..
2의 경우는
SELECT * from posts where created_at > '2008-04-02 22:57:01' limit 20
처럼 초단위가 변해서 쿼리가 날아갑니다.

한마디로 쿼리 캐시가 안되고 계속 새로운 쿼리를 보내는 것이죠.
아마 1초단위 까지 정확히 하루 전이라고 하고 싶으면 어쩔 수 없겠지만..
초단위 혹은 분단위를 올림/내림 등을 하는 것만으로도 쿼리 캐시의 효과를 잘 이용할 수 있게 될 겁니다.


#3. Pagination 의 함정.
이번엔 페이지를 나누는 Pagination 에서 생기는 문제입니다.
레일스 2.0 에서는 Pagination이 레일스 코어에서 빠지고 플러그인 식으로 설치를 해야 하는데..
제가 설치해 본 대부분의 Pagination 플러그인이 같은 문제를 가지고 있었습니다.

Pagination의 동작은 크게 두 부분으로 나눌 수 있습니다.
페이지 표시를 위해 전체 레코드 수를 가져오는 것과 페이지 번호를 이용해 :offset 과 :limit 으로 특정 부분의 레코드를 가져오는 부분입니다.
Pagination 의 플러그인 중 하나인 will_paginate 같은 경우 다음과 같이 Paginate를 합니다.

@posts = Post.paginate :page => params[:page], :per_page => 10, :include => [:comments]
find 의 옵션들을 그대로 쓸 수 있으므로 아주 편하게 paginate를 할 수 있습니다.
그런데 문제는 include 옵션이 들어가게 되면 문제가 발생합니다.
우선은 paginate 는 #1 에서 언급한 preload 가 구현이 되어 있지 않고..
두번째 문제는 전체 레코드 수를 가져오는 부분에서 쓸 데없는 Join 이 일어납니다.
위의 경우는.
SELECT COUNT(distinct post_id) from posts LEFT JOIN comments ON comments.post_id = posts.id
와 같은 쿼리가 생성됩니다. 그런데, 위의 경우는 굳이 comments와 join 할 필요가 없고,
만약 join을 해아할 테이블이 훨씬 많아지면 오버헤드는 상상할 수 없을 정도로 커집니다.
단순히 레코드가 몇 개인지 세는 것 뿐인데 말이죠.

외국의 글입니다. 이 paginate 문제 의 해결책을 제시하고 있습니다만 count 를 하는 쿼리와 선택을 하는 쿼리를 직접 SQL 로 만들어서 하는 방식은 가장 유연한 방식이지만 그다지 깔끔해 보이진 않네요.

will_paginate 의 이슈 트래커에 정확히 같은 문제를 지적한 티켓이 올라왔군요.