続々・リトライと冪等性のデザインパターン - あらゆる操作を冪等にする方法 - Blog by Sadayuki Furuhashi
いつも心に冪等性。古橋です。 リトライと冪等性のデザインパターンの完結編です。 だいぶ間が空いてしまいましたが！ 最後に冪等性を実装する汎用的な実装手法についてまとめていきます。 パターン６：操作ログとリクエストIDでUPDATEを冪等にする 同じIDで識別される値がUPDATEされる場合、つまりmutableである値の管理は、一般に冪等に行うのが難しい。 例えば、ユーザーごとに「最後に購入したアイテム」を更新する操作を考えてみると： 1. ユーザーAが最後に購入したアイテムをアイテム1に変更する（UPDATE） 2. ユーザーAが最後に購入したアイテムをアイテム2に変更する（UPDATE） この操作に何の対策もなくリトライを実装した場合、後続のUPDATE処理の結果を古い内容で上書きしてしまう可能性がある： 1. ユーザーAが最後に購入したアイテムをアイテム1に変更する（UPDATE）→
続・リトライと冪等性のデザインパターン - リトライはいつ成功するか - Blog by Sadayuki Furuhashi
三度の飯よりエラー処理。古橋です。 大変好評をいただいた序章リトライと冪等性のデザインパターンの続編です。 前回はほぼ前置きでしたが、今回は冪等でない操作を冪等にする具体的なテクニックもまとめていきます。 パターン２：エラーを区別してDELETEを冪等にする リソースに常に一意なIDが振られていれば、Deleteを冪等にするのは難しくない。そもそも同じリソースを2度削除することはできない。 一つ注意するべきなのは、削除されたリソースのIDが再利用されるケースでは、Deleteの冪等性は保証されない。例えば、kill -KILL <pid> コマンドはDelete系のAPIと考えられるが、pidは再利用されるので、何度も繰り返すと意図しないプロセスを殺してしまう可能性がある。 一般にIDの生成は非常に難しい問題だが、Deleteに関してのみ言えば再利用されなければいいので、単調増加する整数（
リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
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回くらい提案された実装を全部リジェクトした という経緯があるのですが（笑）、最
「分散システムのためのメッセージ表現手法に関する研究」 - 筑波大学大学院を卒業しました - Blog by Sadayuki Furuhashi
このたび筑波大学大学院を卒業し、修士号を取得しました。卒業にあっては本当に多くの方々にご助力いただきました。この場を借りて御礼申し上げます。ありがとうございました。 現在は起業して、12月からアメリカに在住しています。新たな価値を生み出すべく "下から上まで" システムの設計と開発に携わっており、エキサイティングな毎日を送っています。 修論シーズンに日本にいなかったので、修士論文はメールで送って提出し、卒業式にも出席していないというありさまなので、本当に卒業できたのかどうか実感がないのですが、友人によれば「学位記はあった」らしいので、きっと大丈夫でしょう。（写真はカリフォルニア州マウンテンビューにて） さて、せっかく時間を割いて書いたので、修士論文を公開することにしました。 分散システムのためのメッセージ表現手法に関する研究と題して、バイナリ形式のシリアライズ形式である MessagePa
イベントログ収集ツール fluent リリース！ - Blog by Sadayuki Furuhashi
こんにちは。Treasure Data の古橋です^^; 先日の Treasure Data, Inc. 壮行会 で、イベントログ収集ツール fluent をリリースしました！ Fluent event collector fluent は syslogd のようなツールで、イベントログの転送や集約をするためのコンパクトなツールです。 ただ syslogd とは異なり、ログメッセージに テキストではなく JSON オブジェクト を使います。また プラグインアーキテクチャ を採用しており、ログの入力元や出力先を簡単に追加できます。 Twitterでも話題沸騰中です：イベントログ収集ツール #fluent 周りの最近の話題 背景 「ログの解析」は、Webサービスの品質向上のために非常に重要です。Apacheのアクセスログだけに限らず、アプリケーションからユーザの性別や年齢などの詳しい情報を集め
Webサイトをgithubで管理してpush時に自動的に同期する方法 - Blog by Sadayuki Furuhashi
Webサーバに Subversion のサーバを立てておき、HTML や CSS を commit することでWebサイトを更新する方法は、良く知られているテクニック、らしいですね*1。更新の履歴を残すことができるし、ましてチマチマとFTPやsftpでアップロードするよりずっと簡単です。 しかし SVN の代わりに git を使おうとすると、pushしてもリポートリポジトリではファイルを更新してくれません。 また、リポジトリはWebサーバ上に作るよりも、便利な管理インタフェースがある github（や噂のgitosis）に置いておきたいところです。 そこで、github の Post-Receive Hook を使うと、リポジトリに変更を push すると同時に、Webサーバにも同期させることができます*2。 Webサーバに同期する前に、Sphinxでドキュメントを整形したり、SassをC
進化するMessagePackプロジェクト - Webサイトリニューアル - Blog by Sadayuki Furuhashi
MessagePack Project のWebサイトをリニューアルしました！ 新しいURLは、http://msgpack.org/ です。 シンプルなイメージから若干趣を変え、完成度が高くてリッチな印象を重視しました ;-) 文章ではシリアライズの速度に加えて、RPCの意欲的な設計を強調しています。 なお、Twitterのハッシュタグは #msgpack です。ぜひツイートしてください^^; 実は先日、MessagePackプロジェクトについて StumbleUpon の研究開発チームの方々にプレゼンテーションしてきました。（参考：FacebookとStumbleUponの方がTwitterよりトラフィックを生んでいる） 写真を一枚^^; さらに、LuceneやHadoop開発者であり、Avroの開発者でもある Doug Cutting 氏（Wikipedia!）ともディスカッションす
シリコンバレーにいます - Blog by Sadayuki Furuhashi
6月5日から6月27日までの約3週間の間、サンフランシスコ・マウンテンビューの周辺に滞在しています。 実は日本国外に脱出したのは今回が初めてで、飛行機に乗る段階から驚きの連続です^^; 滞在先のホテルから撮影した風景。眼前にはサンフランシスコの町並みと、見渡す限りの青空が広がっています。 初日にフィッシャーマンズ・ワーフで食べたお昼ご飯の光景。眼前には「カラマリ」なるイカのフライと、大量のポテトが広がっています。 サンフランシスコの朝は霧が濃い。 ダウンタウン・マウンテンビュー駅。道が広い。空が広い。空気はカラっと乾いて快適。そして町中で Google Wi-Fi が使える。快適な町 Mountain View。 これまでに、Cloudera社のDoug Cutting氏や、StumbleUpon社の研究開発チームとディスカッションする機会がありました。 ちなみにStumbleUpon社は
140行で作る分散リアルタイム検索エンジン（Twitter Streaming API対応） - 古橋貞之の日記
マトモに使えるRPCライブラリ MessagePack-RPC for Ruby のバージョン 0.2.0 をリリースしました！ 新たにコネクションプーリングの機能を追加しました。一度接続したコネクションを共有して使い回すことができます。コネクションを何度も張り直す負荷と遅延を削減でき、リソースの消費も抑えられます。 また、不意に切断されたコネクションを自動的に再接続する機能を導入し、信頼性を向上させています。 これを使って何か作ってみようと言うことで、twitterのリアルタイム検索エンジンを作ってみました。日本語を検索できないなど機能は貧弱ですが、プログラム全体がわずか140行に収まっています（クローラ27行、インデクサ48行、クラスタ管理ノード37行、検索クライアント28行）。 新しいつぶやきを受信するたびに、リアルタイムで転置インデックスを作成していきます。インデックスを作成するノ
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は
追記型オブジェクトストレージ「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用などの小さな写真はキ
memstored 0.1 = memcached + mpio + Tokyo Cabinet - Blog by Sadayuki Furuhashi
memstored は memcached のバイナリプロトコルをサポートしたハッシュストレージサーバーです。IO戦略ライブラリmpio の信頼性と性能をテストするために開発しました。 IOに mp::iothreads を使用し、バックエンドには Tokyo Cabinet の抽象データベースAPIを利用しているため、高速でスケーラビリティが高く、かつ柔軟性の高いアーキテクチャになっています。プログラムの大部分はライブラリによって実現されているため、プログラム全体の見通しが良く、行数で見ても非常に小さく収まっています。 SVN (memstored): http://svn.coderepos.org/share/lang/c/memstored/trunk SVN (mpio): http://svn.coderepos.org/share/lang/c/mpio/trunk パッケー
memcached binary protocol - Blog by Sadayuki Furuhashi
先日memcached Night in Tokyo #1に参加してきました。レプリケーションがアツイ。バイナリプロトコルがアツイ。 というわけでバイナリプロトコルのマイクロベンチマークをしてみました。 テストしたのは本家memcachedではなく、私が勝手に作ったストリームパーサです（すべてのプロトコルには対応していません）。get("key$i") と set("key$i", "value$i") を5,000,000回ずつリクエストしたときのプロトコルをファイルに保存しておき、mmap(2)してパースしました。 パーサとベンチマークに使ったプログラム一式はmemcached-protocol-bench.tar.gzからダウンロードできます。 AMD Athlon 64 X2 5000+, Memory 4GB Linux 2.6.22.9 SMP x86_64 gcc 4.2.2
memcachedプロトコルのストリームパーサ - Blog by Sadayuki Furuhashi
memcachedクライアントはほとんどの言語で実装されており、key-valueベースの何かを作るときにはmemcacheプロトコルをサポートしておくと、クライアントを実装する手間が省けるのでイケてます。 しかしmemcachedのテキストプロトコルのような「行」が主体となっているプロトコルは、スレッドを使った実装では比較的簡単に処理できるのですが（fgets(3)を使うなど）、selectやepollなどを使ったイベント駆動型の実装では非常に面倒なことになります。（一度パースしてみて、どうも全部データが到着していないようなら一度状態を変数に保存して、次にデータが到着したら変数から状態を復元して…） イベント駆動型の実装では、データを次々に投げ込んでいくと内部の状態が遷移していき、ゴールの状態にたどり着くとパース完了、という状態遷移型のパーサが必要になります。そこで、Ragel Stat
Comet/Ajaxの上を行く技術 - Blog by Sadayuki Furuhashi
上を行くかどうかは知りませんが :-p Ajaxはクライアントの都合でサーバーに通信を仕掛けるpull型の通信ができ、Cometはサーバーが好きなタイミングでクライアントへデータを送りつけるpush型の通信ができるわけですが、新たに双方向の通信ができる技術を開発しました。 具体的には、JavaScriptとサーバーの間で双方向のRPCができます。すなわち、サーバーからクライアント側のJavaScriptのメソッドが呼べるし、逆にクライアント側からサーバー側のメソッドを呼ぶこともできます。 サーバー側で call("addMessage", "Hello!") とやると、JavaScript側の function addMessage(msg) { ... } という関数が呼ばれたりします。 この技術を使って、試しにチャットシステムを作ってみました ＞ デモ （ソースコード）*1 リアルタイ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
