2012년 7월 5일 목요일

using rebar


Richard Jones 님이 정리한, rebar 사용법.
http://www.metabrew.com/article/erlang-rebar-tutorial-generating-releases-upgrades

이건 2010년도에 Belo Horizonte님이 정리한 사용법
http://alancastro.org/2010/05/01/erlang-application-management-with-rebar.html

그런데, outdated된 내용도 있고, 그대로 딱 되지는 않는다.

당장 필요한 것만 정리하면 다음과 같다.

1. rebar를 다운로드 받는다.
https://github.com/basho/rebar

2. 프로젝트 루트 디렉토리를 만든다. 그리고 rebar를 copy한다.
#> mkdir proj_home
#> cd proj_home

3.  proj_home/apps/mysample/src 로 프로젝트를 만든다.
디렉토리 구조는, https://github.com/RJ/erlang_rebar_example_project/tree/v1 이것을 참조하면 된다.

src 폴더에서,
#> rebar create-app appid=mysample
로 소스를 생성한다.

mysample_app.erl 을 mysample.erl로 mv하고, start/0 함수를 추가한다.

다음을 rebar.config에 추가한다.


{sub_dirs, [
            "apps/mysample",
            "rel"
           ]}.


그리고, 추가 소스를 넣고, 동작이 되게 하고, 컴파일한다.
#> ./rebar compile

4. release버젼을 만들어 본다.

#> mkdir rel
#> cd rel
#> ../rebar create-node nodeid=mysample

=> rel.config를 수정한다.
https://github.com/RJ/erlang_rebar_example_project/blob/v1/rel/reltool.config
{lib_dirs, ["../apps"]},

{rel, "dummy", "1",
        [
         kernel,
         stdlib,
         sasl,
         dummy_app
        ]},

이 부분을 수정하면 된다.

#> cd ..
#> ./rebar generate

5. 확인한다.
#> bin/mysample 치면 console,start,stop,attach,ping 등을 해 볼 수 있다.





2012년 7월 2일 월요일

distributed read/write cache for type value store


riak을 ram(memory) backend로 설정도 해보고,
redis/memcached도 고려해 보고,
couchBase도 고려해보고,
RabbitMQ를 이용한 방식도 생각해봤다.
scalaris도 설치해봤다.

riak은 내부적으로 erlang의 ets를 사용하는데, stress test시 garbage collection을 제대로 처리 못해서, swap memory를 사용한다. 그래서, 갑자기 퍼포먼스가 떨어진다.

redis/memcached는 memory flush out에 callback을 붙이는 것이 단기간에는 쉽지 않았다.

couchBase는 license비용 때문에, 엄두가 나질 않았다.

scalaris는 설정하다가 실패. 아직 찾아볼 자료도 별로 없다. 소스 리뷰는 도움이 된다.

결국, cache에 대해서는, mnesia를 사용해서 자체적인 분산처리 agent를 만들기로 결정했다.

결론적으로, 현재의 best practice는 memory cache 를 read only로 redis를 사용하고,(그것이 싫다면 자체제작) persistence에 대해서는 riak의 bitcask를 사용하는 것인 듯.

mongoDB와 riak은 근본적으로 분산처리 알고리즘이 다르다.
어떻게 다른지, 잘 알고 써야 한다. mongoDB는 controller를 통해서, hash key를 통제하는 방식이고, riak은 vnode를 사용하여, peer끼리 gossip하며 balance시키며 교환하는 방식이다. mongoDB는 자체적으로 memory cache를 갖고 있기 때문에, 성능이 더 좋다. 하지만, 잘 쓰기 나름이다. 개인적으로 riak이 더 마음에 든다.
Riak의로 AP를 확보하고, Memory Cache로 C(Consistency)와 성능을 확보하면 완벽할 듯.



mongoDB value size


type-value store를 넘어서 document store라고 알려져 있는데...
실제로는 그렇지 않다.
최대 value size를 10k 이하로 유지할 것.
그러기 위해서 key를 잘 선정하고, 잘 쪼갤 것.

그리고, nested 구조를 쓰지 말 것.


그렇다고, couchDB(couchBase)는 잘 될까?


2012년 6월 28일 목요일

erlang node


riak에서 riak-admin join을 하다가
unreachable이 나와서, 알아보다가 실수를 하였다. -.-;

node().
를 쉘에서 넣으면, 현재 node의 이름이 나온다.
erlang:get_cookie()
를 넣으면, 현재 세팅된 cookie가 나온다.
net_adm:ping('some@remote.ip').
하면, 리모트 노드와 연결 가능한 상태인지 알 수 있다.
이때  cookie가 다르면, pang이 뜬다.
command shell에서 ping이 되더라도,
cookie값이 다른지 스펠링부터 확인하자.


2012년 6월 27일 수요일

list_to_atom and apply


외부에서 callback 으로 설정할 모듈:함수 이름을 전달했다고 치자.

M=list_to_atom(ConfigModuleName).
F=list_to_atom(ConfigFuncName).
Args=[1,2,3].
apply(M,F,Args).

이렇게 하면, 원하는 함수를 실행시킬 수 있다.
다만, DoS를 피하려면, list_to_existing_atom 을 쓰면 안전하다.



mongoDB to riak + postgres


http://vimeo.com/42744689

mongoDB로 고생하다가
riak + postgres로 바꾼 스토리다.

덤덤하게 이야기하지만, 많이 고생했을 것 같다.


2012년 6월 15일 금요일

using riakpool_client in erlang

https://github.com/dweldon/riakpool

riakpool_client는 riak pb client에 connection pooling 기능을 넣어서 쓸 수 있게 해준다.
간단하게 쓸 수 있다. 하지만, 실전에 쓰기에는 아직 부족함이 많다.
riak http client ( https://github.com/basho/riak-erlang-http-client )을 쓰는 것이 맞을지도 모르겠다. 어떤 것을 쓰는게 빠를지 테스트 해 볼 예정이다.

riak은 key-value store다. value에 attribute들을 여러개 넣으려면,  record를 저장해야 할텐데, binary로 변환해서 저장한다. 즉, record를 꽉 채워서 넣어야 한다. 일부 field만 저장하는 것은 지원하지 않는다. 그렇게 하려면, record를 읽어와서, 바뀐 field만 다시 record에 넣고, put해야 한다. 이 부분은, 좀 아쉽다! 근데, 다른 key-value store도 내부적으로 그렇게 할 듯 하다. 확인이 필요한 부분이다. 현재까지 내가 확인 한 것은 그렇다. -.-;;
다음은 간단히 record를 put하는 예제를 구현해 봤다.

1> rd(item, {id,name} ).
item
2> It=#item{ id= <<"aaa">> , name = <<"bbb">> }.
#item{id = <<"aaa">>,name = <<"bbb">>}

3> riakpool_client:put( <<"aaa">> , <<"bbb">> , term_to_binary(It) ).
ok
4> { ok , R } =  riakpool_client:get( <<"aaa">> , <<"bbb">> ).

5> binary_to_term(R).
#item{id = <<"aaa">>,name = <<"bbb">>}
6> R2 = binary_to_term(R).
#item{id = <<"aaa">>,name = <<"bbb">>}
7> R2#item.id.
<<"aaa">>


2012년 6월 14일 목요일

erlang in production leads to haskell


Erlang으로 프로젝트를 시작한지 3주.
아주 만족스럽다.
deployment와 management,scale 이슈만 커버하면 거의 다 마스터 될 듯.

Erlang을 입문하는데, 어려움을 겪고 있다면,
webmachine,mochiweb을 써서 간단한 것이라도 만들어 보길 권한다.
금새 익숙해 질 것이다. ^^

최근에 다시 haskell을 보기 시작했는데,
Erlang에 익숙해지니, 전에 어렵게 느껴지던 haskell도 훨씬 쉬워 보인다.

Haskell에 OTP의 기능들이 들어오면 좋을텐데...
Haskell/OTP 프로젝트 없을까? ^^

DB는 mnesia와 riak을 프로젝트에 쓸 것이다.
두개의 성능 테스트의 결과가 흥미진진하다.


2012년 6월 10일 일요일

10 year project


* Erlang/Haskell으로 web/game을 위한 서버사이드의 모든 미들웨어와 서비스를 구현
-> 2~3년내에 가능

* GPGPU를 활용하는 언어 디자인
그에 따른 게임엔진 구현
그에 따른 게임 구현

10년을 투자할만하지 않을까? ^^


erlang in production

erlang으로 드디어 실제 서비스에 들어갈 작업을 한다.
2주 정도만에, 프로토타입을 완성했다.

mochiweb,webmachine,mnesia을 이용하여, 서버를 구현하고,
html/javascript/jquery로 웹 클라이언트,
iOS에선 Obj-c로 앱 클라이언트를 구현했다.

이곳저곳에서 웹서핑을 하며, 예제를 구하고, 테스트 하고, 코딩하면서
즐겁게 코딩했다.

erlang의 위대함을 느낄 수 있었다.

데이터베이스는 mnesia를 쓰고 있지만,
riak이나 couchBase등을 쓸 계획도 있다. 물론 모두 테스트 해서 어플리케이션에 맞는 DB를 고를 것이다.

erlang으로 작업하고 있자니, 내버려둔 haskell이 생각나서, haskell도 다시 보려고 한다.
haskell로 production에 써야 할텐데...

앱 클라이언트로는 native하게 obj-c로 쓰긴 했지만,
cross platform용으로 mosync를 쓸 생각이다.


2012년 4월 17일 화요일

150 spells


5개 대륙,
25개의 영웅,
100개 남짓의 유닛,
150여개의 아이템.

스마트폰 게임에서 이 정도 스케일의 작품이 있었나?

덕분에 용량은 200메가를 육박한다.
압축하자;;;

2~3개월안에 출시 꼭 한다.
세상을 놀라게 하는거다.

2012년 1월 24일 화요일

playframework for google app engine


play!framework 홈페이지에 오랜만에 들어가봤다.
그들은 2.0을 만들고 있었다.

요즘은 웹프레임워크가 모두 Cloud환경에 맞춰서 개발한다.
그에 맞게 대대적인 공사중인 듯 하다.

실망스럽지만, google app engine을 사용하고, smart phone game에서 쉽게 가져다가 쓸 수 있는 framework는 아직 없는 듯 하다.
play!framework를 일단 쓰기로 했다.
google app engine을 data store로 사용하면 전세계 배포에 문제가 없기 때문이다.


pain on me :(


몸도 마음도 한달째 좋지 않다. 원인을 찾고 있다.
부정적인 임팩트에 쉽게 지쳐버리는 체질이 된 것 아닐까 의심하고 있다.
더 강해져야 한다.
기도하자.

no pain, no gain. T_T

2012년 1월 20일 금요일

Time to package


출시 3~4개월을 앞두고 있다.

기본적인 게임의 완성도 이외에도 챙겨야 할 일들이 많다.
지금 일단 생각하고 있는 것들은 다음과 같다.

1순위 : 게임의 재미 확보, 안정성
2순위 : UI 완성도 , 튜토리얼(학습곡선)
3순위 : 컨텐츠 량 ( 캐릭터,아이템,스테이지 )
4순위 : 그래픽 퀄러티
5순위 : 사운드 퀄러티
6순위 : 아웃게임 및 게임센터 ( Achievement ), 아이템샵
7순위 : 소셜 ( 랭킹, 페이스북, 트위터 )
8순위 : 패키징 퀄러티 ( 소개글, 스샷, 용량 , 로고, 이름 )
9순위 : 멀티플랫폼 테스트 ( 안드로이드, 아이폰, 아이패드, 태블릿 )
10순위 : 가격정책, 유료화 ( 포인트샵, 광고 )
11순위 : 반복적인 재미를 위한 스테이지, 업데이트 확장성
12순위 : PvP, Online (옵션;;;)
13순위 : 홍보, 마케팅 ( 웹페이지 , 포지셔닝 키워드 , 앱스토어 등록 )