ryshinozのブックマーク - はてなブックマーク

Ruby で MessagePack-RPC - Blog by Sadayuki Furuhashi

高速なオブジェクトシリアライズ形式 MessagePack をプロトコルに採用したRPCライブラリをリリースしました。 Ruby を使って簡単にRPCサーバーやクライアントを実装できます。 msgpack-rpc MessagePack-RPC プロトコルは既にkumofsやクラスタ管理ツール「clx」などで利用しており、高速なサーバーの実装にも便利ツールの実装にも、幅広く使えるシンプルなプロトコル仕様になっています。 clxを使うと複数のサーバーをグループに分けて、同じグループに属するサーバーに対して同じコマンドを実行できます。コマンドは並列して実行されるので、ファイル転送（rsync）のような時間のかかるコマンドでも快適に使えます。 clxのコアは汎用的なRPCサーバーで、RPC以外の機能はすべてモジュールとして実装されています。モジュールは起動時に登録できるほか、実行中でも追加でき、

ryshinoz 2009/10/19

ruby

リンク

Interopクラウドコン優勝は「えとらぼ」分散key-valueストレージ kumofs - Blog by Sadayuki Furuhashi

InteropTokyo 2009 クラウドコンピューティングコンペティション（通称クラウドコン）は、我等がえとらぼチームが優勝しました！実行委員･StarBEDプロジェクト･IBMの皆様を始め関係者の皆様、ありがとうございました。プレゼンテーションムービーとポスターとパンフレット*1を公開しました。プレゼンムービー（マウスクリック/矢印キーで進む） PDF版ポスターパンフレット *2 …どれも相当に気合いが入っているので、ぜひご覧ください^^ Ustream.tvの録画もあります（えとらぼチームはちょっと細切れですが）途中で行ったデモは、StarBEDの45台の物理サーバーを使ってkumofsを動かして、ランダムで選んだノードを自動的にkill/再起動するスクリプトを走らせたものです。サーバーが落ちてもシステムは全然止まらないし、どのサーバーにも均等に負荷が分散されます。時

ryshinoz 2009/06/19

リンク

追記型オブジェクトストレージ「Kastor」（pre-alpha） - Blog by Sadayuki Furuhashi

Facebookで写真配信のために使われているストレージシステム「Haystack」に関する情報が公開されました。（Needle in a haystack: efficient storage of billions of photos） Facebookは最初はNFSを使っていたようです。しかし写真の1枚1枚をファイルとして保存していたため、ディレクトリエントリなどのinodeメタデータの総量がキャッシュに収まらないサイズになってしまい、一つの写真を保存したり取り出したりするのにHDDのシークが複数回発生していたのがボトルネックになっていたそうです。（もしかしたら「NetAppは高すぎた」のがもっと重要だったかも知れません：Facebook、独自の写真配信ネットワーク、Haystackを完成―収益性の改善に寄与か？）シークの問題を軽減するために、profile用などの小さな写真はキ

ryshinoz 2009/05/31

リンク

ブラウザから１クリックでアプリケーションを起動する - Java Web Start 〜 JavaFX - Blog by Sadayuki Furuhashi

festivoice.netはブラウザから1クリックで専用のクライアントソフトウェアが起動して、簡単に音声チャットが始められます。この1クリックでアプリケーションを起動する仕組み - Java Web StartはJavaに標準で搭載されているので、大抵の環境でインストールする手間を掛けることなくクライアントを配布できます。またサーバーに置いてあるパッケージを更新するとクライアントも自動的にアップデートされます。Webサービスの提供者側からすると、Java Web Startはかなり便利です。 Java Web Startを利用するには、サーバー上に 1)普通のJavaのアプリケーションと、2) JNLPファイルを用意します。JNLPファイルはXMLの設定ファイルで、以下のようなフォーマットになります： <?xml version="1.0" encoding="UTF-8"?> <

ryshinoz 2009/02/25

java
javafx

リンク

マルチコア時代の高並列性IOアーキテクチャ Wavy - Blog by Sadayuki Furuhashi

シングルスレッドではもう遅い。以前にマルチコア時代の高速サーバーの実装で、「ネットワークIOはマルチスレッドで動かすが、その他の部分はシングルスレッドで動かす」というIOアーキテクチャの実装（mp::iothreads）を紹介しました。iothreadsはロジック部分をシングルスレッドで書けるため実装の手間を抑えることができ、ネットワークIOがボトルネックになるプログラムには特に適していると思われます。しかし実際にiothreadsを使ってプログラムを書いてみると、非常に負荷が高い状況でシングルスレッドの部分の処理速度がボトルネックになってしまうことがありました。そこでマルチコアCPUの性能を引き出すために、徹頭徹尾マルチスレッドで動かすIOアーキテクチャを実装してみました。 1つのスレッドが、ある時はepoll_wait()し、ある時はread(2)を行い、ある時はイベントを処理す

ryshinoz 2009/02/01

リンク

memcachedバイナリプロトコルは同期プロトコルを禁止するべき - Blog by Sadayuki Furuhashi

現状のmemcachedのバイナリプロトコルのクライアント（=libmemcached）は、リクエストの順番通りにレスポンスが返ってくることを期待しており、これはmemcachedバイナリプロトコルを「汎用的なkey-valueベースの分散ストレージのためのプロトコル」として考えると、ひどい実装である。そのような実装は最適化の余地を大幅に制限してしまい、性能とスケーラビリティが悪化する。memcachedの仕様書は、そのようなクライアントの実装はバグであると明示するべきである。現状のmemcachedクライアントの実装の問題点と、その解決策について述べる。同期プロトコルと非同期プロトコルネットワークプロトコルは以下の2つの種類に分けられる：同期プロトコルリクエストの順番通りにレスポンスを返す（リクエストの順番とレスポンスの順番が同期している）非同期プロトコルリクエストした順