リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
20行できる高精度ハードウェア自動認識 - Blog by Sadayuki Furuhashi
さえないTips系のようなタイトルになってしまいましたが、これは驚きです。しかし一方で悲しい（今までの苦労は…）。 これまでLinuxのハードウェア自動認識と言えば、/sys/bus/pci/devices以下と、/lib/modules/`uname -r`/modules.pcimapを照らし合わせて解析していくのが定石でした。USBにも対応しようとすると、もう一つ大変です。 しかしこれからの常識は、/sys/bus/*/devices/*/modaliasと/lib/modules/`uname -r`/modules.aliasです。 /lib/modules/`uname -r`/modules.aliasを見てみると、↓このようになっています。 # Aliases extracted from modules themselves. alias usb:v1604p8005d*
Zeroconf - Blog by Sadayuki Furuhashi
そろそろネットワーク周りのところに差し掛かってきたので、Zeroconfについて計画を練らないと。 VIVERはローカルエリアネットワークがターゲット、と決めてしまっているので、Zeroconfは極めて便利。極めて便利。便利なんです。 Zeroconfと総称してしまうと微妙だけど、Zeroconf = DNS-SD(DNS Service Discovery) + mDNS(Multicast DNS) + Auto-IP の総称。 VIVER本体での利点は３つ。 DNS-SDでNBDサーバー(あるいは、ブートパラメータサーバーのようなモノ)を自動検出できる mDNSでクライアントマシンの名前解決が出来る Auto-IPでIPアドレスをDHCP無しでうまく振れる DNS-SDは、要するにDNSのSRVレコードやTXTレコードに入れる情報を規格化して、DNSを使ってサービスを検出してやろうと
高速なイベント駆動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多重化システムコ
共有ホームディレクトリ環境の管理方法 - Blog by Sadayuki Furuhashi
MacPorts や apt などのパッケージ管理システムでインストールできないアプリケーションやライブラリ、自分で書いたツールなどを、ホームディレクトリにインストールしたいことは良くある。 ホームディレクトリならroot権限が要らないし、rootを持っている場合でも思わぬ操作ミスや設定ミスのリスクを抑えられる利点がある。アンインストールもしやすい。gem や easy_install などのスクリプト言語の管理システムが、OS全体のパッケージ管理システムと競合してしまう問題も回避できる。 このようにホームディレクトリにアプリケーションをインストールするときに、複数のバージョンを同時にインストールしたいことがある。また、異種のOSやCPUアーキテクチャのマシンでホームディレクトリを共有したかったりする*1 *2。 以上のような要求があるときに、ホームディレクトリ環境をどうのように構築し、P
富豪的バックアップのススメ - Blog by Sadayuki Furuhashi
間違ってrmしてしまったっ！！ ということは誰しも一度はあると思いますが、そう言うときのためにもバックアップやバージョン管理は重要なわけです。 しかしバックアップは１時間に１回や１日に１回程度しか行わないので、たとえば5分前に変更したプログラムをrmしてしまったら、その5分間の変更は水の泡です*1。何という損失！ 中でもやる気の損失が激しい。 上書き保存するたびにバックアップ そこで、これは受け売りなのですが、エディタでファイルを保存するときに常にバックアップを残すようにしています。 当然のことながら凄まじいファイル数になりますが、エディタで編集するのは大方プログラムや設定ファイルなので大した容量にはなりません。今私のバックアップディレクトリを見てみると 2008年4月2日16時15分30秒 から累積して約5万個のファイルが残っていますが、サイズは 400MB 程度です。 今時のHDDから
mplexでソースコードレベルメタプログラミング - Blog by Sadayuki Furuhashi
Webアプリケーションを作るとき、HTMLを生成するテンプレートエンジンをよく使いますが、これはパラメータに応じて様々なコードを生成する自動生成ツールであると言えます。 mplexは、プログラムを生成するためのテンプレートエンジンです。 実は MessagePack-RPC for C++ の実装に使っています。似たような関数をたくさんオーバーロードするために活用しています。（そろそろ可変長templateを使いたいですねぇ） 昔はeRubyを使っていたのですが、HTML用のテンプレートエンジンはソースコードがあまりに読みにくくなるので自作しました。 mplexを使うと、普通のプログラムの中にRubyのコードを埋め込むことができます： // クラスを4つ生成 %4.times do |i| class Test[%i%] { public: %if i % 2 == 0 int even;
世界の「NoSQL」開発者が東京に集結 - NOSQL afternoon in Japan - Blog by Sadayuki Furuhashi
NoSQLと呼ばれる新型の分散データストアの開発者が一堂に会するイベント NOSQL afternoon in Japan が、2010年11月1日、楽天タワーで開かれました。 海外からは「Cassandra」のサポートを行う Riptano や、「MongoDB」を開発する 10gen、「Couch DB」の Cloudant、「Hadoop」の Cloudera のエンジニアが登壇し、日本からは Hibari、Okuyama、ROMA、そして kumofs の開発者が講演しました： ContentsPresenters HibariJoe NortonGemini Mobile Technologies OkuyamaTakahiro Iwase CassandraNate McCallRiptano ROMAMuga NishizawaRakuten Mongo DBRoger Bo
バイナリシリアライズ形式「MessagePack」 - Blog by Sadayuki Furuhashi
Googleが公開したバイナリエンコード手法であるProtocol Buffersは、クライアントとサーバーの両方でシリアライズ形式を取り決めておき（IDL）、双方がそれに従ってデータをやりとりするようにします。 この方法では高速なデータのやりとりができる反面、IDLを書かなければならない、仕様を変えるたびにIDLを書き直さなければならない（あらかじめしっかりとIDLを設計しておかないとプログラミングを始められない）という面倒さがあります。 ※追記：Protocol BuffersのデシリアライザはIDLに記述されていないデータが来ても無視するので（Updating A Message Type - Protocol Buffers Language Guide）、仕様を拡張していっても問題ないようです。 一方JSONやYAMLなどのシリアライズ形式では、何も考えずにシリアライズしたデータ
マルチコア時代の高並列性IOアーキテクチャ Wavy - Blog by Sadayuki Furuhashi
シングルスレッドではもう遅い。 以前にマルチコア時代の高速サーバーの実装で、「ネットワークIOはマルチスレッドで動かすが、その他の部分はシングルスレッドで動かす」というIOアーキテクチャの実装（mp::iothreads）を紹介しました。iothreadsはロジック部分をシングルスレッドで書けるため実装の手間を抑えることができ、ネットワークIOがボトルネックになるプログラムには特に適していると思われます。 しかし実際にiothreadsを使ってプログラムを書いてみると、非常に負荷が高い状況でシングルスレッドの部分の処理速度がボトルネックになってしまうことがありました。 そこでマルチコアCPUの性能を引き出すために、徹頭徹尾マルチスレッドで動かすIOアーキテクチャを実装してみました。 1つのスレッドが、ある時はepoll_wait()し、ある時はread(2)を行い、ある時はイベントを処理す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
