リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
イベントログ収集ツール fluent リリース！ - Blog by Sadayuki Furuhashi
こんにちは。Treasure Data の古橋です^^; 先日の Treasure Data, Inc. 壮行会 で、イベントログ収集ツール fluent をリリースしました！ Fluent event collector fluent は syslogd のようなツールで、イベントログの転送や集約をするためのコンパクトなツールです。 ただ syslogd とは異なり、ログメッセージに テキストではなく JSON オブジェクト を使います。また プラグインアーキテクチャ を採用しており、ログの入力元や出力先を簡単に追加できます。 Twitterでも話題沸騰中です：イベントログ収集ツール #fluent 周りの最近の話題 背景 「ログの解析」は、Webサービスの品質向上のために非常に重要です。Apacheのアクセスログだけに限らず、アプリケーションからユーザの性別や年齢などの詳しい情報を集め
Amazon EC2 で手元のホストとファイルを共有する - Blog by Sadayuki Furuhashi
Amazon EC2 はVMを好きなタイミングで好きなだけ使うことができるので、複数のサーバを使う分散システムの検証環境として非常に使いやすい*1。費用を計算してみても、自宅でクラスタを動かすことを考えれば、十分安く上がりそうである。 しかし、VMを起動するたびに環境を設定したり、新しいテストを実行するたびにファイルを配ったりするのは面倒なので、ファイルを共有したくなる。 通信の遅延がかなり大きいので、EC2上でssh越しにファイルを編集するのも少々つらい。 そこで、手元のホストとホームディレクトリを共有する。さらに、一度転送したデータはキャッシュさせる。 共有ホームディレクトリ環境の管理方法と組み合わせれば、便利に使えるに違いない。 戦略 ファイル共有には NFSv4 over ssh を使う。NFSv4はポート番号を１つしか使わない（portmapperも要らない）ので、ssh越しで使
丸レク2010「分散Key-valueストアkumofsの思想と設計」 - Blog by Sadayuki Furuhashi
分散Key-valueストアkumofsの思想と設計 と題して、丸レクセミナー2010で発表してきました。 kumofs を使いたくなるユースケースの紹介を中心に、kumofs のメリットを紹介しています。 会場は楽天タワーで、何やらスゴイ数の方に聞いていただけたようです。来場者数は500名を超えたと聞いています。 ネット中継でも多くの方に視聴していただいたようで、Twitterでも多くのフィードバックをいただきました。ありがとうございます。 分散Key-valueストアkumofsの思想と設計View more presentations from frsyuki. 発表スライド（PDF） Ustream.tvの録画 あわせて読みたい 情報システムの信頼性：対策は進んだが改善の余地も 企業IT動向調査2009 kumofsから学ぶNot only SQLの技術＠Developers Su
並列イベント駆動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
前回は、kumofsはなぜスケールするかということについて紹介しました。その中で最後に、耐障害性もスケーラビリティにとって重要だーと述べました。 そこで今回は、kumofsはなぜ落ちないのか、なぜ耐障害性が高いと言えるのかーということについて紹介したいと思います。 分散システムはテストが難しいことに定評がありますが（たぶん^^;）、その中でも耐障害性の検証は最上級に困難な部類です。 耐障害性は実際のところ、アルゴリズムの設計以前に実装上のバグが大きく影響するので、設計上は耐障害性が高いと言っていても、実際に使ってみると良く止まるという話はありがちな話です。（個人で開発している場合など、開発リソースが小さい場合はなおさら） そのため耐障害性の高いシステムを実現するためには、実装しやすくバグが入り込みにくい設計も重要かなーと思います（もちろん、アルゴリズムも重要ですが）。 分散システムには複雑
kumofsはなぜスケールするか - Blog by Sadayuki Furuhashi
先日、分散Key-valueストア kumofs を公開しました。 多く方から反響とフィードバックをいただいています。ありがとうございます。 今回は、kumofs はなぜスケールするのか、なぜスケールすると言えるのかーということについて紹介したいと思います。 ところでスケーラビリティとは何か？ スケーラビリティとは、利用者や仕事の増大に適応できる能力・度合い とされています（端的！）*1 。Scalability を日本語にすると、拡張性 と訳されるようです。 ただ一口でスケーラビリティと言っても、様々な側面があります。ITシステムでは主には処理性能と運用に関することを指す場合が多いと思いますが*2、その中にも様々な側面があります。 なぜスケーラビリティが必要か スケーラビリティは システムなどが持つべき望ましい特性 であって、高いに越したことはありません。しかし、高いスケーラビリティはタ
分散Key-Valueストア「kumofs」を公開しました！ - Blog by Sadayuki Furuhashi
分散Key-Valueストア kumofs を、本日オープンソースソフトウェアとしてリリースしました！ kumofs@SourceForge kumofs関連資料まとめ kumofsとは？ kumofs（クモエフエス）は、実用性を重視した分散データストアです。レプリケーション機能を備え、一部のサーバーに障害が発生しても動作し続けます。単体でも高い性能を持ちながら、サーバーを追加することで読み・書き両方の性能が向上する特徴を持ち、低コストで極めて高速なストレージシステムを構築・運用できます。 kumofsの大きな特徴は、システムの構成の簡単に変更できる点です。システムを止めることなく、簡単な手順でサーバーを追加したり復旧したりできます。アプリケーションには一切影響を与えません。 またkumofsは、広く利用されている分散キャッシュシステムの「memcached」と互換性のあるプロトコルを実装
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用などの小さな写真はキ
いま分散システムが面白い理由 - Blog by Sadayuki Furuhashi
最近 クラウド という単語が流行していますが、「大規模な計算資源を低コストで提供してくれるトコロがあるらしいので、自前で持っていた計算資源を委託しちゃえば運用する手間も知識も要らないし、そもそもサーバーを買う費用を省けちゃうから嬉しい」という発想に基づいているらしく、しかし技術的には 大規模な計算資源を低コストで構築する技術 がポイントでしょう。 大規模な計算資源をどうやって安く構築するか。 従来は、システムの能力を高めるためには、高性能・高機能（それゆえ高価な）マシンを導入するというスケールアップの手法が採られていたのだが、この手法では10倍に性能を上げるために、たとえば30倍のコストがかかるかもしれない。スケールアップと比べてスケールアウトでは、導入したコストにほぼ比例して、パフォーマンスの向上が見込める。 『UNIX magazine 2009年4月号』 p.31 *1 何百万円もす
「Metal」 based on Parsing Expression Grammar - 古橋貞之の日記
Parsing Expression Grammar (PEG)をベースとした構文解析器を生成するパーサジェネレータMetalを作りました。Rubyで書かれており、Rubyのコードを生成します。 Metalの多くはOMeta: an Object-Oriented Language for Pattern MatchingをRubyに移植したものです。 Metalの特徴： Rubyでアクションが書ける オブジェクト指向（継承、Mix-in、委譲、オーバーライド、super） PEGの特徴はそのまま 曖昧さが無い 左再帰が書けない（いまのところ） メモ化する ソースコードはCodeRepos:/lang/ruby/metalにあるので、ガツガツいじれます。 使い方 Ruby gemsでインストールできます。 $ gem install metal 文法定義ファイルを書いて、metalコマンド
バイナリシリアライズ形式「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などのシリアライズ形式では、何も考えずにシリアライズしたデータ
古橋貞之の日記 - 開発環境としての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）が付いてきますが、これがデフォルトではまったくイケてない。主要な
分散ファイルシステム/ブロックデバイスをまとめる - Blog by Sadayuki Furuhashi
昨日KLab勉強会#2の資料を公開しましたが、その中で動的な分散ファイルシステムを設計していると書きました。分散ファイルシステムというのは既にいろいろ存在しているわけですが、情報が分散していてサッパリ分からないので、このあたりでまとめてみたいと思います。 間違っていたり古かったりするに違いないので、正確な情報は本家の情報を参照してください。 ファイルシステムレイヤー NFS GFS(Global File System) OCFS GlusterFS Lustre 下位レイヤー Filesystem Block Device Block Device Filesystem Block Device 読み込み ○ ○ ○ ○ ○ 書き込み ○ ○ ○ ○ ○ アクセスの冗長化 × ○ ○ ○（負荷分散と排他） × データの冗長化 下位レイヤーに依存 下位レイヤーに依存 下位レイヤーに依存 ○
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
