日本OSS貢献者賞を受賞しました - Blog by Sadayuki Furuhashi
このたび、第10回 日本OSS貢献者賞 を受賞いたしました。 非同期メッセージングライブラリ「MessagePack」、分散Key-Valueストア「kumofs」、ログコレクタ「Fluentd」、バルクデータローダ「Embulk」、Presto向けゲートウェイサーバ「Prestogres」など、大学生時代から現在に至るまで、多数のOSSプロジェクトを立ち上げ、開発を主導している。2010年度 日本OSS奨励賞を受賞。 推薦していただいた皆様、審査員の皆様、ありがとうございます。もちろん、OSSは1人で作っている物ではありません。かつては名も無いOSSに果敢にも参加していただいた皆様、本当にありがとうございます。 何年も前からコミュニティを支えていただいているMessagePackの開発者の皆様や、Fluentdのコミッタやコントリビュータの皆様、Embulkプラグイン、Fluentdプラ
イベントログ収集ツール fluent リリース！ - Blog by Sadayuki Furuhashi
こんにちは。Treasure Data の古橋です^^; 先日の Treasure Data, Inc. 壮行会 で、イベントログ収集ツール fluent をリリースしました！ Fluent event collector fluent は syslogd のようなツールで、イベントログの転送や集約をするためのコンパクトなツールです。 ただ syslogd とは異なり、ログメッセージに テキストではなく JSON オブジェクト を使います。また プラグインアーキテクチャ を採用しており、ログの入力元や出力先を簡単に追加できます。 Twitterでも話題沸騰中です：イベントログ収集ツール #fluent 周りの最近の話題 背景 「ログの解析」は、Webサービスの品質向上のために非常に重要です。Apacheのアクセスログだけに限らず、アプリケーションからユーザの性別や年齢などの詳しい情報を集め
MessagePack for PHP＠Webホスティング - Blog by Sadayuki Furuhashi
先日 phpのserializeを使うより高速でサイズもコンパクトに仕上げる「MessagePack」とPHP拡張 でも紹介されている MessagePack for PHP ですが、Webホスティングサービスにも標準で組み込まれ始めているようです： Joe’sウェブホスティング、高速シリアライズライブラリ「MessagePack」のPHP拡張モジュールを全共用サーバーに提供開始 MessagePackはオープンソースで開発が進んでいるプロジェクトです。そして各言語版はそれぞれの言語のエキスパートによって実装されるという形態になっています（自然にそうなったのですが^^;）。 PHP版はadvectさんによる実装です。 実はPHP版には以前に別の実装があり、advectさんから新しい実装が送られてきたときは 2,3回くらい提案された実装を全部リジェクトした という経緯があるのですが（笑）、最
kumofs-0.3.5リリース - expire対応 - Blog by Sadayuki Furuhashi
分散Key-Valueストア kumofs のバージョン0.3.5をリリースしました。 今回のアップデートで、expiration timeに対応しました。 kumofs-0.3.5.tar.gz kumo-gateway に -E オプションを付加すると、memcachedのテキストプロトコルでexpiration timeを指定することができます。 指定した時間が過ぎると、その値がgetできないようになります（実際には削除されていないことに注意してください。本当に削除するにはdeleteコマンドを発行してください） 以前のアップデートで、-Fオプションを指定するとflagを保存できるようになりました。-Eと-Fを両方指定すると、flag と expiration time の両方を保存することができます。 -Fオプションと同じように、同じクラスタの中には、-Eオプションが有効なkumo
並列イベント駆動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の使いこなしなどと同
kumofsはなぜスケールするか - Blog by Sadayuki Furuhashi
先日、分散Key-valueストア kumofs を公開しました。 多く方から反響とフィードバックをいただいています。ありがとうございます。 今回は、kumofs はなぜスケールするのか、なぜスケールすると言えるのかーということについて紹介したいと思います。 ところでスケーラビリティとは何か？ スケーラビリティとは、利用者や仕事の増大に適応できる能力・度合い とされています（端的！）*1 。Scalability を日本語にすると、拡張性 と訳されるようです。 ただ一口でスケーラビリティと言っても、様々な側面があります。ITシステムでは主には処理性能と運用に関することを指す場合が多いと思いますが*2、その中にも様々な側面があります。 なぜスケーラビリティが必要か スケーラビリティは システムなどが持つべき望ましい特性 であって、高いに越したことはありません。しかし、高いスケーラビリティはタ
PFIインターンに行ってきました。 - Blog by Sadayuki Furuhashi
8月1日から8月31日までの１ヶ月間、PFI夏期インターンに行ってきました。 はてなインターンの 講義・課題・チーム 形式とは趣を異にして、個々人が何か１つのプロジェクトに取り組む方針で進みました。取り組むテーマは 新たに取り組みたい/今取り組んでいる 内容を前提に、既存の問題の中から近いテーマを見つけます（あるいはこじつける^^;）。 インターンの期間中の１ヶ月か２ヶ月の間に成果を出すのが目標！ 取り組むテーマはスムーズに決まりました。何か自社で製品を作っていれば普通かと思いますが、探せば問題はいくらでもあるモノです^^ ちなみにPFIの製品は、全文検索エンジンやレコメンドエンジンなどです。 私は以下の４つのプログラムを実装しました： 既存の実装に代わるRPCフレームワーク MessagePack-RPC for PFI クラスタ管理ツール clx プロセス管理ユーティリティ daemo
追記型オブジェクトストレージ「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用などの小さな写真はキ
高速ログフォーマットと簡単な解析機能の実装 - Blog by Sadayuki Furuhashi
先日の高速ログフォーマットの提案を実際に実装してみました。 ログを MessagePack でシリアライズしてバイナリ形式で出力することで、生のバイト列をBase64などでエンコードしなくてもログに書き出せるようにし、また高速に解析できるようにしようというアイディアです。 ソースコード：logpack.tar.gz（コンパイルするにはMessagePackのC++用ヘッダとgem install msgpackが必要） twitterやコメントでいただいたアイディアを参考に、いちばんシンプルなフォーマットにしてみました： ログサイズ [アクセスログ, {"時刻": 1230415655, "URL": ["index.html"], "UA": "Mozilla/5.0 ... Firefox 3.0.5"}] ログサイズ [アクセスログ, {"時刻": 1230415656, "URL"
memcachedバイナリプロトコルは同期プロトコルを禁止するべき - Blog by Sadayuki Furuhashi
現状のmemcachedのバイナリプロトコルのクライアント（=libmemcached）は、リクエストの順番通りにレスポンスが返ってくることを期待しており、これはmemcachedバイナリプロトコルを「汎用的なkey-valueベースの分散ストレージのためのプロトコル」として考えると、ひどい実装である。 そのような実装は最適化の余地を大幅に制限してしまい、性能とスケーラビリティが悪化する。memcachedの仕様書は、そのようなクライアントの実装はバグであると明示するべきである。 現状のmemcachedクライアントの実装の問題点と、その解決策について述べる。 同期プロトコルと非同期プロトコル ネットワークプロトコルは以下の2つの種類に分けられる： 同期プロトコル リクエストの順番通りにレスポンスを返す（リクエストの順番とレスポンスの順番が同期している） 非同期プロトコル リクエストした順
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 リアルタイ
P2P分散ストレージ「Cagra」 - Blog by Sadayuki Furuhashi
id:nyaxt氏との共同開発の分散ストレージ「Cagra」（かぐら）のアルファ版をリリースしました。 cagra α3リリース cagra テクニカルデモ α２リリース 分散ストレージエンジンテクニカルデモ α版リリース cagraのα版試してみたよ - takumalog Cagraは以下のような特徴を持った（目指した）P2P分散ストレージです。 Zeroconf マルチマスタでレプリケーションするWrite 高速な分散Read オプションで高速な非同期Write インターネットレベルよりもLANレベルのマシン台数に特化 巨大データサポート 高速イベント駆動システムコール＋軽量スレッド 超アジャ〜イルな開発体制 まだα版で全部が実装されているわけではないですが、とりあえず動きます。 Zeroconf UDPマルチキャストでノードを自動的に発見するので、一切設定ファイルを書かずに動作せる
高速なイベント駆動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多重化システムコ
WikiForme 0.2 - 構造化Wiki記法パーサ - Blog by Sadayuki Furuhashi
はてな記法、PukiWiki記法、tDiary記法などなど、世の中「なんとか記法」が溢れているわけですが、往々にして「自分にぴったり合う記法なんてどこにも無い！」という結論に達する場合が多く、結果として「なんとか記法」の乱立を生んでいるのではないでしょうか。 というわけで、自分専用のWiki記法を簡単に作れるカスタマイザブルパーサ WikiForme を作ってみました。乱立乱立！ 記法を統一しようなんてムリですよね。もはや宗教論争です。自分専用の記法があればいいんです。 と、このバージョン0.0.1から約２ヶ月、大きくパワーアップしたWikiForme 0.2を公開します。 ※2007/09/23: バージョン 0.3をリリースしました > WikiForme 0.3 リリース！ - 構造化Wiki記法パーサ wikiforme-0.2.0.tar.gz ダウンロードして展開したら、./e
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
