WebSocketサーバライブラリ rev-websocket リリース - Blog by Sadayuki Furuhashi
いま WebSocket がにわかに注目を集めているようです。 ブラウザとサーバの間でリアルタイムな双方向通信を実現する機能で、HTML5に追加された（される予定の）新しい仕様です。 このWebSocketを使うには、ブラウザ側のJavaScriptの記述だけでなく、サーバ側の実装も必要になります。 そこで、Rubyで使えるWebSocketのサーバライブラリ rev-websocket をリリースしました。 gemでインストールできます：gem install rev-websocket 早速、デモアプリケーションを作ってみました：シャウッたー *1 WebSocket を使ったチャットシステムに、ちょっとした演出を加えたシンプルなアプリケーションです。速くタイプするほど大きく表示されるという趣向です^^; WebSocket に対応しているブラウザは今のところ Safari と Chr
ニコニコ動画、分散Key-valueストア「kumofs」を導入 - Blog by Sadayuki Furuhashi
つい先日、ニコニコ動画モバイルの一部でkumofsを導入した というお話を伺いました。 まだまだ利用は一部でしか始まっていないようですが、これからデータを取りながら運用実績を作っていきたいとのことでした。 kumofsは、バージョン0.3.3でflagsの保存に対応し、バージョン0.3.5でexpireに対応しています。バージョン0.3.4では、Javaクライアントとの互換性を改善しています。 これらの機能の改善に加えて、運用実績やノウハウの蓄積も、オープンソースソフトウェアとして重要な要素の1つと言えます。 kumofs関連資料まとめ や #kumofs@twitter にも、ぜひ注目してみてください^^; kumofsは既に、写真ストレージサービス Ficia（フィシア）での運用実績があります。（ITproニュース） ドワンゴ 研究開発ブログ 分散Key-Valueストア「kumofs
並列イベント駆動I/Oフレームワーク「mpio」リリース - Blog by Sadayuki Furuhashi
分散KVS kumofs のコードは、全体で約2万行です*1。 そのうち、ネットワークI/Oやプロトコルに関するコードは約1万行*2で、全体の約半分を占めています。 ロジックは残りの半分*3だけで実装されています。 この実例から分かりますが、kumofsのような分散アプリケーションを開発するにはI/O周りの実装が大変で、とてつもなく大きな障壁になっています。*4 さらに今日では、性能を稼ぐためにマルチスレッド化が必須です。また、多数のクライアントを少ないリソースで効率よく相手にするには、非同期・イベント駆動型のアーキテクチャも必要になります。さらに、究極的な性能を達成すべく GC を利用しない C++ においては、実装のみならず設計も大変です。 これに加えてソケットAPIの難解な挙動に対処にしなければならないため、C言語やC++によるネットワークプログラミングは、vimの使いこなしなどと同
PFIインターンに行ってきました。 - Blog by Sadayuki Furuhashi
8月1日から8月31日までの１ヶ月間、PFI夏期インターンに行ってきました。 はてなインターンの 講義・課題・チーム 形式とは趣を異にして、個々人が何か１つのプロジェクトに取り組む方針で進みました。取り組むテーマは 新たに取り組みたい/今取り組んでいる 内容を前提に、既存の問題の中から近いテーマを見つけます（あるいはこじつける^^;）。 インターンの期間中の１ヶ月か２ヶ月の間に成果を出すのが目標！ 取り組むテーマはスムーズに決まりました。何か自社で製品を作っていれば普通かと思いますが、探せば問題はいくらでもあるモノです^^ ちなみにPFIの製品は、全文検索エンジンやレコメンドエンジンなどです。 私は以下の４つのプログラムを実装しました： 既存の実装に代わるRPCフレームワーク MessagePack-RPC for PFI クラスタ管理ツール clx プロセス管理ユーティリティ daemo
MessagePack for Perl - 0.3.3 リリース - Blog by Sadayuki Furuhashi
バイナリシリアライズ形式 MessagePack のバージョン0.3.3をリリースしました。 id:tokuhirom さんによる perl バインディングができました！（MessagePack for perl 書いた sv_catpvn を連続で呼びまくると激しく遅いので気をつける） 最新のリリースはここからダウンロードできます：http://sourceforge.jp/projects/msgpack/releases/ ドキュメント等プロジェクトページ：http://msgpack.sourceforge.jp/ コピーしないシリアライズ用カスタムバッファを追加 msgpack::vrefbuffer（C++）と msgpack_vrefbuffer（C）を追加しました。msgpack::sbufferの代わりに使うと、大きいバイト列をシリアライズするときに中身をコピーせずに元の
Interopクラウドコン優勝は「えとらぼ」分散key-valueストレージ kumofs - Blog by Sadayuki Furuhashi
InteropTokyo 2009 クラウドコンピューティングコンペティション（通称クラウドコン）は、我等がえとらぼチームが優勝しました！ 実行委員･StarBEDプロジェクト･IBMの皆様を始め関係者の皆様、ありがとうございました。 プレゼンテーションムービーとポスターとパンフレット*1を公開しました。 プレゼンムービー（マウスクリック/矢印キーで進む） PDF版 ポスター パンフレット *2 …どれも相当に気合いが入っているので、ぜひご覧ください^^ Ustream.tvの録画もあります（えとらぼチームはちょっと細切れですが） 途中で行ったデモは、StarBEDの45台の物理サーバーを使ってkumofsを動かして、ランダムで選んだノードを自動的にkill/再起動するスクリプトを走らせたものです。サーバーが落ちてもシステムは全然止まらないし、どのサーバーにも均等に負荷が分散されます。 時
いま分散システムが面白い理由 - Blog by Sadayuki Furuhashi
最近 クラウド という単語が流行していますが、「大規模な計算資源を低コストで提供してくれるトコロがあるらしいので、自前で持っていた計算資源を委託しちゃえば運用する手間も知識も要らないし、そもそもサーバーを買う費用を省けちゃうから嬉しい」という発想に基づいているらしく、しかし技術的には 大規模な計算資源を低コストで構築する技術 がポイントでしょう。 大規模な計算資源をどうやって安く構築するか。 従来は、システムの能力を高めるためには、高性能・高機能（それゆえ高価な）マシンを導入するというスケールアップの手法が採られていたのだが、この手法では10倍に性能を上げるために、たとえば30倍のコストがかかるかもしれない。スケールアップと比べてスケールアウトでは、導入したコストにほぼ比例して、パフォーマンスの向上が見込める。 『UNIX magazine 2009年4月号』 p.31 *1 何百万円もす
memcachedプロトコルを使った非同期通知サーバー - Blog by Sadayuki Furuhashi
アプリケーションA：keyXをgetする アプリケーションA：getが待たされる アプリケーションB：keyXにvalueXをセットする アプリケーションA：getが帰り、valueXを取得できる このように非同期に通知する機構をmemcachedプロトコルを使って汎用的に利用することができます。 インストール ソースコードはCodeReposにあります：lang/ruby/lkserver $ svn co http://svn.coderepos.org/share/lang/ruby/lkserver $ cd lkserver # memcachedテキストプロトコルのパーサーをコンパイル $ ruby extconf.rb $ make # Rev（イベント駆動IOライブラリ）をインストール $ gem install rev # 11511/tcpで起動 $ ruby lkse
Ruby Rev + MessagePack による分散プログラム - Blog by Sadayuki Furuhashi
ネットワークプログラミングで面倒なのが、通信相手にバイト列しか送れないためプロトコルをシリアライズ方法から考えないといけないかったり、複数のクライアントに対応しようとするとスレッドやらイベント駆動やらを考えないといけないところで、なかなか本質的なロジックの実装に手を付けられずもどかしくなります。 そのあたりの面倒な部分をまとめて良きに計らってくれるRPCライブラリを作っておくと良さそうです。 とはいえ、RPCレイヤーはネットワークプログラミングの中でも速度と信頼性に大きく影響する部分でもあります。実装を丸々隠蔽されてしまうと、後になってカスタマイズできずに困ったことになるかもしれません。 最初のプロトタイピングとして簡単に使えるが、カスタマイズも効くような柔軟性が欲しいところです。 そこでRubyの高速なイベント駆動IOライブラリであるRevと、バイナリベースのシリアライズ形式であるMes
Aerial（エアリアル） - Ajax/Cometの次を行く リアルタイム双方向RPC - Blog by Sadayuki Furuhashi
JavaScript - サーバー間で双方向のRPC通信を行う技術は「Aerial」（エアリアル）という名前になりました*1。アイディアを出していただいた皆様、ありがとうございましたm(_ _)m Aerialは、通信にFlashを使い、JavaScriptとサーバープログラムとの間で双方向のRPC呼び出しを行う技術です。つまり、サーバー側からJavaScriptのメソッドを呼び出したり、逆にJavaScriptからサーバー側のプログラムを呼び出したりします。 サーバーから直接JavaScriptのコードを呼び出したり、逆にJavaScriptからサーバー側のメソッドを呼び出したりできるので、通信の内容を意識する必要がなく、バグの混入を抑えます。RPC成分入り！ ライブラリを開発するときも、HTTPやブラウザ間の実装の違いを意識する必要も無く、ごく普通のTCP接続で通信を行うので、Come
Comet/Ajaxの上を行く技術 - Blog by Sadayuki Furuhashi
上を行くかどうかは知りませんが :-p Ajaxはクライアントの都合でサーバーに通信を仕掛けるpull型の通信ができ、Cometはサーバーが好きなタイミングでクライアントへデータを送りつけるpush型の通信ができるわけですが、新たに双方向の通信ができる技術を開発しました。 具体的には、JavaScriptとサーバーの間で双方向のRPCができます。すなわち、サーバーからクライアント側のJavaScriptのメソッドが呼べるし、逆にクライアント側からサーバー側のメソッドを呼ぶこともできます。 サーバー側で call("addMessage", "Hello!") とやると、JavaScript側の function addMessage(msg) { ... } という関数が呼ばれたりします。 この技術を使って、試しにチャットシステムを作ってみました ＞ デモ （ソースコード）*1 リアルタイ
開発環境としてのMac OS X Leopard - Blog by Sadayuki Furuhashi
なかなかrootにならせてくれない、ハードウェアを選ばせてくれない、設定ファイルをviでいじらせてくれないなど、不自由なUNIX : Mac OS Xですが、それ故の自由が何物にも代え難い今日この頃。Leopardになってcron+pdumpfsの仕事まで持って行かれてしまいました。 前回のTiger版カスタマイズメモに引き続いて、Mac OS Xのカスタマイズを書いておこうと思います。 Terminal.app タブ機能が実装されたりssh-agentがKeychainと統合されたりと、Leopardで驚異的なアップデートが行われたターミナル周りですが、まだまだ改善できる余地があります。問題は以下の3点。 HomeキーとEndキーが使えない 色が見にくい ショートカットキーが使いにくい まずHomeキーやEndキーですが、これは環境設定で変更できます。Terminal.appの環境設定の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
