Hatena::ブログ(Diary)

cooldaemonの備忘録 RSSフィード

2009-10-27

Erlang に興味ある方が増えている気がするので、Erlang-users.jp に記事を追加してみようかな

と言う事を、病の床*1で考えたので、整理のため、ここに内容を記載します。

熱のおかげでコードを書けず、本も読めずで、それくらいしかする事が無かったのです。

Erlang-users.jp 上で書きたい記事

Web サービス開発で利用すると便利な Erlang VM 上で動作するミドルウェアのコードリーディング記事を、少しづつゆっくり書き足して行きたいと考えています。

具体的には、KaiScalarisCouchDBRabbitMQYawsEjabberd などを対象としています。

個人的な優先順位で行くと、Kai、RabbitMQ、CouchDB、あと適当・・・でしょうか。

ありがたい事に Erlang-users.jp のコミット権を頂いているのですが、記事の誤りを指摘してもらいやすいよう、まずはこの日記に書いて行こうと思います。三日坊主*2になったらごめんなさい。

何故、それらの記事を書きたいのか

私が Erlang を学び始めたのは、Erlang が持つ利点*3が、現在勤める会社で提供するサービスに役立つだろうという実務目的があった為です。多分、Erlang に興味を持つ多くの方々も、私と似た理由で学び始めているのではないでしょうか?

そして、その利点の体現が Erlang VM 上で動作する各ミドルウェアであるならば、それらのコードリーディング記事が、Erlang の考え方を理解する助けになるのではないかと考えています。

個人的な理由

仕事で Kai、Yaws を運用する自信はあるのですが、RabbitMQ などは運用する自信がありません。でも使いたいのです。

ただ・・・正直な所、RabbitMQ なんて、どこからコード読めば良いのでしょうか?(w;

とは言いつつも、仕組みを調べ、実際に動かして試行錯誤し、監視項目などを考えないと怖いので、記事を書く過程で運用できるほど精通できたらと考えています。

蛇足

Web サービス開発の現場で、Kai を使うべき箇所に Memcached が選択されていたり、RabbitMQ を使うべき箇所に MySQL をベースとしたアレコレが選択されている現状があるのではないかと妄想*4しています。

例えば、似たような機能を提供する Kai と Memcached ですが、それぞれの利点から得意とする領域が異なるので、適材適所で使い分けできると良いだろうと考えています。

ただ、Kai や RabbitMQ を現場で運用するには、Erlang VM の理解が必要であるため、コードリーディング記事だけでは足りないのだろうなぁと認識しています。

*1:ただの、おたふく風邪

*2:RabbitMQ の前半で挫折予定

*3:分散、並列が得意、障害耐性があるなど

*4:少なくとも私が知る幾つかの現場では、この傾向が強い

2009-02-16

守破離

自戒も込めて記す。

守を疎かにして仕事を創造すると、本来得たい成果から逸れた方向に突き進む事になる。

今朝、娘が、まだ濡れている洗濯物を取り込んでいる姿を見て思いついた。

妻に言われる前に動いた事は偉いけれど、それは、誰にも望まれない行為だよ。

育児と育自は難しい。

2008-01-13

catalyst 本が届いた

170ページしかないので半日で読めた。

ほぼ、知っている内容ばかりだったけど、Chapter 8 の Testing がとても良かった。(今度、日記に書こうっと)

その他は、Catalyst::Controller::REST、Jemplate、PAR 辺りが面白かったかな?(現在、js は Mochikit を、deploy は capistrano を使ってるから、REST 以外は使わないだろうけど…)

ってか Catalyst::Controller::FormBuilder は、使い難い上に、HTML を書いてくれる人との連携がキツくて諦めたんだよなー…。

2007-11-04

KLab勉強会 #3 「Erlang による高可用システムの構築」の感想

まずは、有意義な時間を過ごせた事に感謝!

会社としての取り組み

既に社内で利用し始めているようで、とても羨ましい。現在、根回しに労力を割いている私とはエライ違いだ orz

もし、erlang ネタで次回があれば、プロダクション環境で運用する為のノウハウを聞いてみたいと思いました。

あー、懇談会に出席できたら良かったのに!!

net_kernel:get_net_ticktime/0

こんな関数がある事を始めて知りました。

調べてみると、net_kernel:set_net_ticktime/1 以外に kernel の configuration でも設定できるっぽい。

ブロックする処理

質疑応答で、ブロックする処理の扱いは?という質問が出た。回答としては、ノード上のプロセスがブロックされても問題ない…だったような?(ちょっと記憶が曖昧)

確かに、ノード上のプロセスがブロックされても、他のプロセスには影響が出ない。

しかし、ノードは OS から見ると一つのプロセスであって、そのプロセス自体がブロックされる事はありそうな気がする。

とりあえず、I/O に限って言えば、+K オプションを付けてノードを起動すると epoll が使われるので避けられるらしい。ただし、erlang を ./configure する際、--enable-kernel-poll を指定する必要がある。(昔、kqueue 使ってくれないかなぁと思い、手元の FreeBSD で試した所「kernel-poll not supported; "K" parameter ignored」と出たので、未検証で放置してます手元の mac で [kernel-poll:true] となったので検証開始ports から R12B-0 を入れて +K true でノードを立ち上げたら [kernel-poll:true] となった

後は、+A オプションで async-threads の数を増やすという手もあるかと。+A オプションに関しては みかログ: Erlangの+Aオプション こちらが詳しいです。

ememcached の性能について

質疑応答で、memcached と ememcached の速度比較の質問が出た。回答としては、少しだけ試した感じでは2倍くらい遅いとの事。

ん〜、erlang で書かれたサーバは、同時接続数が増えた際に、その素晴らしさを発揮し始めるので、そこを補足して欲しかったなぁと思いました。

ノードが "絶対" スケールしないよ!

帰りのエレベータの中で「ノード が "絶対" スケールしないよ!」と話し合ってる方々がいらっしゃった。

それを質疑応答の際に発言すれば良いのに(w;

えーっと、スケールってスケールアウトの略語だろうか?だとしたら、ノードは環境であって、その環境の上で動くアプリケーション(mnesia とか)がスケールアウトするように作られていれば、ノードがスケールアウトする・しないは関係ない話だと私は思う。

その他

id:Hamano さんはじめ、erlang を仕事で使っている方々と知り合えて嬉しかったです。

erlang もっと普及すると良いなぁ