並列イベント駆動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の使いこなしなどと同
古橋貞之の日記 - 開発環境としてのMac OS Xカスタマイズ
Mac OS Xを使っていないプログラマは、時間の80％を無駄にしている、かどうかは知りませんが、堅いGUIとUNIX系のコマンドラインツールを使えるMac OS Xは、開発環境として使いやすいことは確か。 が、デフォルトのままでは、Terminal.appで日本語が表示できないとか、lsやfindがGNU系じゃなくてBSD系だとか、要するにOSだってカスタマイズしてなんぼというわけであります。 というわけで、私のMac OS Xのカスタマイズをこのあたりに書いておきます。 ※2008/2/3追記: Leopard版書きました > 開発環境としてのMac OS X Leopard Terminal.app Mac OS Xにはデフォルトで「ターミナル」（/Applications/Utilities/Terminal.app）が付いてきますが、これがデフォルトではまったくイケてない。主要な
開発環境としての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の環境設定の
kumofsから学ぶNot only SQLの技術 - Blog by Sadayuki Furuhashi
NoSQLを知る〜kumofsから学ぶNot only SQLの技術 と題して、Developers Summit 2010で発表しました。 twitterの#devsumi2010 kumofsを見る限りでは大変ご好評をいただいたようで、ひとまずほっとしています。 プレゼンテーションの資料を公開しました。内容はどれも同じですが、クリックで進むムービー版がオススメです。 クリックで進むムービー（クリック/矢印キーで進む） PDF Keynoteファイル（Keynote '09が必要） NoSQLを知るView more presentations from frsyuki. Consistent Hashingとdouble-hash-spaceアルゴリズムの紹介は、68ページ以降にあります。 第101回 カーネル読書会 2月25日に楽天タワーで行われるカーネル読書会でも、kumofs関連
モダンネットワークプログラミング入門 WEB+DB PRESS vol.55 - Blog by Sadayuki Furuhashi
先日も少し書きましたが、WEB+DB PRESS vol.55 で特集記事を執筆させていただきました。本日発売です。 タイトルは、モダンネットワークプログラミング入門です。 マルチコアCPUから最高の性能を引き出す 本特集では，マルチコアCPUの性能を存分に引き出し，大量のクライアントからの莫大な数のアクセスにさらされても，常に爆発的な性能を発揮する先進的なネットワークプログラムの書き方を，実践的な実装パターンとしてやさしく解説します。 WEB+DB PRESS vol.55 特集3 弾さんの連載最終回は、えとらぼの皆さんです^^; 目次 第1章：ネットワークプログラミングの基礎知識 なぜいま「ネットワークプログラミング」なのか 第2章：ソケットAPI ネットワークプログラミングの基本を押さえる 第3章：ネットワークプログラムのI/O戦略 非同期，並列，イベント駆動，マルチスレッド 第4章
いま分散システムが面白い理由 - Blog by Sadayuki Furuhashi
最近 クラウド という単語が流行していますが、「大規模な計算資源を低コストで提供してくれるトコロがあるらしいので、自前で持っていた計算資源を委託しちゃえば運用する手間も知識も要らないし、そもそもサーバーを買う費用を省けちゃうから嬉しい」という発想に基づいているらしく、しかし技術的には 大規模な計算資源を低コストで構築する技術 がポイントでしょう。 大規模な計算資源をどうやって安く構築するか。 従来は、システムの能力を高めるためには、高性能・高機能（それゆえ高価な）マシンを導入するというスケールアップの手法が採られていたのだが、この手法では10倍に性能を上げるために、たとえば30倍のコストがかかるかもしれない。スケールアップと比べてスケールアウトでは、導入したコストにほぼ比例して、パフォーマンスの向上が見込める。 『UNIX magazine 2009年4月号』 p.31 *1 何百万円もす
Key Value Store勉強会に行ってきました by kumofsのひと - Blog by Sadayuki Furuhashi
※分散Key-Valueストア「kumofs」を公開しました！ 先日開催されたKey Value Store勉強会に行ってきました。私の発表資料は↓ここからダウンロードできます。 kvs-kumofs.pdf 合わせて読むと理解が深まるかもしれない： スマートな分散で快適キャッシュライフ - mixi Engineer's Blog：Consistent Hashについて バイナリシリアライズ形式「MessagePack」：kumofsのプロトコル。高速なストリームバッファとストリームデシリアライザの実装も含まれています。 Protocol Buffersは遅い：MessagePackのベンチマークとProtocol Buffersとの比較。タイトルは釣り。 memstored：IOアーキテクチャのプロトタイピング マルチコア時代の高並列性IOアーキテクチャ Wavy memcached
kumofsはなぜスケールするか - Blog by Sadayuki Furuhashi
先日、分散Key-valueストア kumofs を公開しました。 多く方から反響とフィードバックをいただいています。ありがとうございます。 今回は、kumofs はなぜスケールするのか、なぜスケールすると言えるのかーということについて紹介したいと思います。 ところでスケーラビリティとは何か？ スケーラビリティとは、利用者や仕事の増大に適応できる能力・度合い とされています（端的！）*1 。Scalability を日本語にすると、拡張性 と訳されるようです。 ただ一口でスケーラビリティと言っても、様々な側面があります。ITシステムでは主には処理性能と運用に関することを指す場合が多いと思いますが*2、その中にも様々な側面があります。 なぜスケーラビリティが必要か スケーラビリティは システムなどが持つべき望ましい特性 であって、高いに越したことはありません。しかし、高いスケーラビリティはタ
高速なイベント駆動IOライブラリ mpio - Blog by Sadayuki Furuhashi
まだまだ未完成で半分アイディアだけなのですが、なかなか進まないのでとりあえず公開してみます。CodeRepos:/lang/c/mpio/trunk/mp いわゆるlibeventのようなものなのですが、C++で書かれていて、より使いやすく、より最適化が効きやすいようになっています。 以下のような特徴があります（目指しています）。 オーバーヘッドの少ない低水準レイヤー、使いやすい高水準レイヤーという形でレイヤー構造になっている better Cなコードにもある程度なじむ メモリ管理機能を内蔵している ヘッダファイルをincludeするだけで使える（ライブラリをリンクしなくて良い） ライブラリ自体のコードが短く、モジューラブル 低水準なレイヤーから順に、mp::event、mp::dispatch、mp::io、mp::asioがあります。 mp::event OS依存のIO多重化システムコ
分散Key-Valueストア「kumofs」を公開しました！ - Blog by Sadayuki Furuhashi
分散Key-Valueストア kumofs を、本日オープンソースソフトウェアとしてリリースしました！ kumofs@SourceForge kumofs関連資料まとめ kumofsとは？ kumofs（クモエフエス）は、実用性を重視した分散データストアです。レプリケーション機能を備え、一部のサーバーに障害が発生しても動作し続けます。単体でも高い性能を持ちながら、サーバーを追加することで読み・書き両方の性能が向上する特徴を持ち、低コストで極めて高速なストレージシステムを構築・運用できます。 kumofsの大きな特徴は、システムの構成の簡単に変更できる点です。システムを止めることなく、簡単な手順でサーバーを追加したり復旧したりできます。アプリケーションには一切影響を与えません。 またkumofsは、広く利用されている分散キャッシュシステムの「memcached」と互換性のあるプロトコルを実装
Comet/Ajaxの上を行く技術 - Blog by Sadayuki Furuhashi
上を行くかどうかは知りませんが :-p Ajaxはクライアントの都合でサーバーに通信を仕掛けるpull型の通信ができ、Cometはサーバーが好きなタイミングでクライアントへデータを送りつけるpush型の通信ができるわけですが、新たに双方向の通信ができる技術を開発しました。 具体的には、JavaScriptとサーバーの間で双方向のRPCができます。すなわち、サーバーからクライアント側のJavaScriptのメソッドが呼べるし、逆にクライアント側からサーバー側のメソッドを呼ぶこともできます。 サーバー側で call("addMessage", "Hello!") とやると、JavaScript側の function addMessage(msg) { ... } という関数が呼ばれたりします。 この技術を使って、試しにチャットシステムを作ってみました ＞ デモ （ソースコード）*1 リアルタイ
54行で分散KVSを実装する（レプリケーション機能付き） - Blog by Sadayuki Furuhashi
Ruby と MessagePack-RPC があれば、簡単なkey-valueストレージは簡単に作れます。54行で書けます（レプリケーションと負荷分散機能付き。サーバー38行、クライアント16行）。 簡単なKVSをベースにして、ログ集計や遠隔デプロイ、遠隔管理機能などの機能を追加していけば、ちょっと便利なサーバープログラムをサクサク自作できるハズ。 この分散KVSは、（keyのハッシュ値 % サーバーの台数）番目のサーバーにkeyを保存します。また、サーバーの名前順でソートしたときの「次のサーバー」と「次の次のサーバー」にデータをレプリケーションします。 すべてのサーバーで同じ設定ファイルを使います。サーバーごとの設定は引数を自分のホスト名に書き換えるだけなので、デプロイが容易です。 MessagePack-RPC for Ruby を使うと、分散しないkey-valueストレージ*1は
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
Ruby で MessagePack-RPC - Blog by Sadayuki Furuhashi
高速なオブジェクトシリアライズ形式 MessagePack をプロトコルに採用したRPCライブラリをリリースしました。 Ruby を使って簡単にRPCサーバーやクライアントを実装できます。 msgpack-rpc MessagePack-RPC プロトコルは既にkumofsやクラスタ管理ツール「clx」などで利用しており、高速なサーバーの実装にも便利ツールの実装にも、幅広く使えるシンプルなプロトコル仕様になっています。 clxを使うと複数のサーバーをグループに分けて、同じグループに属するサーバーに対して同じコマンドを実行できます。コマンドは並列して実行されるので、ファイル転送（rsync）のような時間のかかるコマンドでも快適に使えます。 clxのコアは汎用的なRPCサーバーで、RPC以外の機能はすべてモジュールとして実装されています。モジュールは起動時に登録できるほか、実行中でも追加でき、
CGIでRailsをまともに動かす - Blog by Sadayuki Furuhashi
普通にRuby on RailsをCGI（dispatch.cgi）で動かすと遅すぎてやってられませんが、gateway.cgiを使うと、そこそこの速度で動くようになります。 最初に仕掛けを紹介してしまうと、1回目のアクセスがあったときに常駐プロセスを起動し、2回目以降のアクセスはその常駐プロセスに処理させるようになっています。CGI自体は常駐プロセスに処理を投げるだけなので軽い、というわけです。ただし、１回目のアクセスは通常通りCGIで動作させたくらいの遅さです。 常駐プロセスは一定時間アクセスがないと自動的に終了するので（次のアクセスがあったときにまた起動する）、いろいろ制限のある環境でも使える、かもしれません。 さて、そのgateway.cgiですが、Railsの標準パッケージの中に含まれています。まだexperimentalらしいですが、多少パッチを当てると動きます。 使い方は↓こ
MessagePack + Wavy で高速なRPCサーバーを書く「ccf」 - Blog by Sadayuki Furuhashi
先日、追記型オブジェクトストレージKastorを紹介しました。そこで「C++でクラスタアプリケーションを書くためのフレームワーク（ccf; Cluster Communcation Framework）を実装中」などなど書きました。 最近C++でサーバープログラムを書くときには MessagePack（シリアライザ･デシリアライザ。プロトコルに利用）とmp::wavy（イベント駆動I/Oとスレッドプールを統合してうまく動かすライブラリ）という２つのライブラリを使うことが多い*1のですが、この2つを組み合わせるときにいつも似たようなコードを書いていたので、いっそまとめて1つのフレームワークのようにしたら便利そうだなーという動機でccfの開発を始めました。 …以下長々と書いていますが、論よりコード。このヘッダ と サーバーのサンプル と クライアントのサンプル を見れば、何ができるのかは大体分
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
