三度の飯よりエラー処理。古橋です。 大変好評をいただいた序章リトライと冪等性のデザインパターンの続編です。 前回はほぼ前置きでしたが、今回は冪等でない操作を冪等にする具体的なテクニックもまとめていきます。 パターン２：エラーを区別してDELETEを冪等にする リソースに常に一意なIDが振られていれば、Deleteを冪等にするのは難しくない。そもそも同じリソースを2度削除することはできない。 一つ注意するべきなのは、削除されたリソースのIDが再利用されるケースでは、Deleteの冪等性は保証されない。例えば、kill -KILL <pid> コマンドはDelete系のAPIと考えられるが、pidは再利用されるので、何度も繰り返すと意図しないプロセスを殺してしまう可能性がある。 一般にIDの生成は非常に難しい問題だが、Deleteに関してのみ言えば再利用されなければいいので、単調増加する整数（
こんにちは。Treasure Data の古橋です^^; 先日の Treasure Data, Inc. 壮行会 で、イベントログ収集ツール fluent をリリースしました！ Fluent event collector fluent は syslogd のようなツールで、イベントログの転送や集約をするためのコンパクトなツールです。 ただ syslogd とは異なり、ログメッセージに テキストではなく JSON オブジェクト を使います。また プラグインアーキテクチャ を採用しており、ログの入力元や出力先を簡単に追加できます。 Twitterでも話題沸騰中です：イベントログ収集ツール #fluent 周りの最近の話題 背景 「ログの解析」は、Webサービスの品質向上のために非常に重要です。Apacheのアクセスログだけに限らず、アプリケーションからユーザの性別や年齢などの詳しい情報を集め
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
つくばで開かれたRubyKaigi2010で、多言語間通信ライブラリ MessagePack についてLTしてきました。 音声付きの動画をニコニコ動画で見られます（スバラシイ！）。ぴったり5分に収まりました^^; 発表資料（PDF） 発表資料（クリックで進む動画） Twitterを見る限りでは評判も良かったようで、ひとまず安心しています。 説明が足りなかった部分もあるので、ここで補足しておきます。 JSONと比べてどれくらい小さくなるの？ ある日のTwitterのpublic_timelineを使って比較してみたところ、JSONでは31KBだったものが、MessagePackでシリアライズし直すと25KBになり、約19%削減されました。 ただミニブログサービス「Amebaなう」に…等々の話にもあるように、「MessagePackを使えば必ず大幅にサイズ圧縮に成功する」という訳ではないです。
つい先日、ニコニコ動画モバイルの一部でkumofsを導入した というお話を伺いました。 まだまだ利用は一部でしか始まっていないようですが、これからデータを取りながら運用実績を作っていきたいとのことでした。 kumofsは、バージョン0.3.3でflagsの保存に対応し、バージョン0.3.5でexpireに対応しています。バージョン0.3.4では、Javaクライアントとの互換性を改善しています。 これらの機能の改善に加えて、運用実績やノウハウの蓄積も、オープンソースソフトウェアとして重要な要素の1つと言えます。 kumofs関連資料まとめ や #kumofs@twitter にも、ぜひ注目してみてください^^; kumofsは既に、写真ストレージサービス Ficia（フィシア）での運用実績があります。（ITproニュース） ドワンゴ 研究開発ブログ 分散Key-Valueストア「kumofs
分散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
前回は、kumofsはなぜスケールするかということについて紹介しました。その中で最後に、耐障害性もスケーラビリティにとって重要だーと述べました。 そこで今回は、kumofsはなぜ落ちないのか、なぜ耐障害性が高いと言えるのかーということについて紹介したいと思います。 分散システムはテストが難しいことに定評がありますが（たぶん^^;）、その中でも耐障害性の検証は最上級に困難な部類です。 耐障害性は実際のところ、アルゴリズムの設計以前に実装上のバグが大きく影響するので、設計上は耐障害性が高いと言っていても、実際に使ってみると良く止まるという話はありがちな話です。（個人で開発している場合など、開発リソースが小さい場合はなおさら） そのため耐障害性の高いシステムを実現するためには、実装しやすくバグが入り込みにくい設計も重要かなーと思います（もちろん、アルゴリズムも重要ですが）。 分散システムには複雑
先日、分散Key-valueストア kumofs を公開しました。 多く方から反響とフィードバックをいただいています。ありがとうございます。 今回は、kumofs はなぜスケールするのか、なぜスケールすると言えるのかーということについて紹介したいと思います。 ところでスケーラビリティとは何か？ スケーラビリティとは、利用者や仕事の増大に適応できる能力・度合い とされています（端的！）*1 。Scalability を日本語にすると、拡張性 と訳されるようです。 ただ一口でスケーラビリティと言っても、様々な側面があります。ITシステムでは主には処理性能と運用に関することを指す場合が多いと思いますが*2、その中にも様々な側面があります。 なぜスケーラビリティが必要か スケーラビリティは システムなどが持つべき望ましい特性 であって、高いに越したことはありません。しかし、高いスケーラビリティはタ
分散Key-Valueストア kumofs を、本日オープンソースソフトウェアとしてリリースしました！ kumofs@SourceForge kumofs関連資料まとめ kumofsとは？ kumofs（クモエフエス）は、実用性を重視した分散データストアです。レプリケーション機能を備え、一部のサーバーに障害が発生しても動作し続けます。単体でも高い性能を持ちながら、サーバーを追加することで読み・書き両方の性能が向上する特徴を持ち、低コストで極めて高速なストレージシステムを構築・運用できます。 kumofsの大きな特徴は、システムの構成の簡単に変更できる点です。システムを止めることなく、簡単な手順でサーバーを追加したり復旧したりできます。アプリケーションには一切影響を与えません。 またkumofsは、広く利用されている分散キャッシュシステムの「memcached」と互換性のあるプロトコルを実装
随時更新予定。 ツールなど 2010-01-08 kumofsの死活監視はこんな感じでNagiosでやってます - (ひ)メモ 検討と検証 2010-04-01 kumofsに10MBのvalueを入れるとどうなるか実験してみた - sdyuki-devel 2010-02-24 KVS(NoSQL)のまとめと「これから」の設計手法 - どっかのBlogの前置きのような 2010-02-01 kumofs その４・速度比較してみた - とあるWEBプログラマの軌跡（仮） 設計とアーキテクチャ 2010-04-26 hbstudy#10「ずばり動く！kumofs と ずばり動かないケース」 2010-04-25 丸レク2010「分散Key-valueストアkumofsの思想と設計」 2010-02-09 kumofsはなぜ落ちないか 2010-01-26 kumofsはなぜスケールするか 2
複数のプロセスが相互に連携して動くシステムのテストを自動化したい。 普通に書くとプロセスを起動したあと終了するまで待ってしまうので、複数のプロセスを同時に起動できなくて困ります。&を付けてバックグラウンドで起動させると、後で終了させたとき、まず ps aux | grepしてPIDを調べて、シグナルを飛ばして、しばらくポーリングして本当に終了するまで待つ、なんてことになって面倒です。 それから起動してからしばらくは初期化処理が走っているので、標準出力に「started」と表示されるまで待ちたかったりします。 そのあたりをうまく扱うためのライブラリを書いてみました。↓こんな感じで自動化できます。 #!/usr/bin/env ruby require 'chukan' include Chukan srv = spawn("server -arg1 -arg2") # 'server' コマ
Ruby と MessagePack-RPC があれば、簡単なkey-valueストレージは簡単に作れます。54行で書けます（レプリケーションと負荷分散機能付き。サーバー38行、クライアント16行）。 簡単なKVSをベースにして、ログ集計や遠隔デプロイ、遠隔管理機能などの機能を追加していけば、ちょっと便利なサーバープログラムをサクサク自作できるハズ。 この分散KVSは、（keyのハッシュ値 % サーバーの台数）番目のサーバーにkeyを保存します。また、サーバーの名前順でソートしたときの「次のサーバー」と「次の次のサーバー」にデータをレプリケーションします。 すべてのサーバーで同じ設定ファイルを使います。サーバーごとの設定は引数を自分のホスト名に書き換えるだけなので、デプロイが容易です。 MessagePack-RPC for Ruby を使うと、分散しないkey-valueストレージ*1は
8月1日から8月31日までの１ヶ月間、PFI夏期インターンに行ってきました。 はてなインターンの 講義・課題・チーム 形式とは趣を異にして、個々人が何か１つのプロジェクトに取り組む方針で進みました。取り組むテーマは 新たに取り組みたい/今取り組んでいる 内容を前提に、既存の問題の中から近いテーマを見つけます（あるいはこじつける^^;）。 インターンの期間中の１ヶ月か２ヶ月の間に成果を出すのが目標！ 取り組むテーマはスムーズに決まりました。何か自社で製品を作っていれば普通かと思いますが、探せば問題はいくらでもあるモノです^^ ちなみにPFIの製品は、全文検索エンジンやレコメンドエンジンなどです。 私は以下の４つのプログラムを実装しました： 既存の実装に代わるRPCフレームワーク MessagePack-RPC for PFI クラスタ管理ツール clx プロセス管理ユーティリティ daemo
間違ってrmしてしまったっ！！ ということは誰しも一度はあると思いますが、そう言うときのためにもバックアップやバージョン管理は重要なわけです。 しかしバックアップは１時間に１回や１日に１回程度しか行わないので、たとえば5分前に変更したプログラムをrmしてしまったら、その5分間の変更は水の泡です*1。何という損失！ 中でもやる気の損失が激しい。 上書き保存するたびにバックアップ そこで、これは受け売りなのですが、エディタでファイルを保存するときに常にバックアップを残すようにしています。 当然のことながら凄まじいファイル数になりますが、エディタで編集するのは大方プログラムや設定ファイルなので大した容量にはなりません。今私のバックアップディレクトリを見てみると 2008年4月2日16時15分30秒 から累積して約5万個のファイルが残っていますが、サイズは 400MB 程度です。 今時のHDDから
InteropTokyo 2009 クラウドコンピューティングコンペティション（通称クラウドコン）は、我等がえとらぼチームが優勝しました！ 実行委員･StarBEDプロジェクト･IBMの皆様を始め関係者の皆様、ありがとうございました。 プレゼンテーションムービーとポスターとパンフレット*1を公開しました。 プレゼンムービー（マウスクリック/矢印キーで進む） PDF版 ポスター パンフレット *2 …どれも相当に気合いが入っているので、ぜひご覧ください^^ Ustream.tvの録画もあります（えとらぼチームはちょっと細切れですが） 途中で行ったデモは、StarBEDの45台の物理サーバーを使ってkumofsを動かして、ランダムで選んだノードを自動的にkill/再起動するスクリプトを走らせたものです。サーバーが落ちてもシステムは全然止まらないし、どのサーバーにも均等に負荷が分散されます。 時
MessagePackフォーマット仕様のPull Request #209をマージし、MessagePackにTimestamp型を追加しました。 ※この記事の英語版は XXX にあります（翻訳中） Extension型の型コード -1 として定義されているため、後方互換性が維持されています。つまり、既にExtension型に対応しているデシリアライザであれば、Timestamp型を使用して作成されたデータを、Timestamp型に対応していない古いデシリアライズで読み出すことができます。 新しいTimestamp型には timestamp 32、timestamp 64、timestamp 96 の3つのフォーマットがあり、よく使う値をより少ないバイト数で保存できるようになっています。例えば、1970年〜2106年までの時刻で、秒までの精度しか持たない時刻であれば、合計6バイトで保存でき
Facebookで写真配信のために使われているストレージシステム「Haystack」に関する情報が公開されました。（Needle in a haystack: efficient storage of billions of photos） Facebookは最初はNFSを使っていたようです。しかし写真の1枚1枚をファイルとして保存していたため、ディレクトリエントリなどのinodeメタデータの総量がキャッシュに収まらないサイズになってしまい、一つの写真を保存したり取り出したりするのにHDDのシークが複数回発生していたのがボトルネックになっていたそうです。 （もしかしたら「NetAppは高すぎた」のがもっと重要だったかも知れません：Facebook、独自の写真配信ネットワーク、Haystackを完成―収益性の改善に寄与か？） シークの問題を軽減するために、profile用などの小さな写真はキ
bash-4.0がリリースされたので早速試す。 $ sudo port sync $ sudo port deactivate readline $ sudo port install bash $ bash NEWS CHANGES autocd ディレクトリ名を入力だけでcdする。 $ shopt -s autocd $ / cd / cdspell cdするときディレクトリ名をよしなに修正する。 $ shopt -s cdspell $ cd /user/inclde<Enter> cd /usr/include dirspell 補完するときディレクトリ名をよしなに修正する。 $ shopt -s dirspell $ vi /user/inclde<Tab> $ vi /usr/include/ globstar globで**が使える。 $ shopt -s globstar
※分散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
現状のmemcachedのバイナリプロトコルのクライアント（=libmemcached）は、リクエストの順番通りにレスポンスが返ってくることを期待しており、これはmemcachedバイナリプロトコルを「汎用的なkey-valueベースの分散ストレージのためのプロトコル」として考えると、ひどい実装である。 そのような実装は最適化の余地を大幅に制限してしまい、性能とスケーラビリティが悪化する。memcachedの仕様書は、そのようなクライアントの実装はバグであると明示するべきである。 現状のmemcachedクライアントの実装の問題点と、その解決策について述べる。 同期プロトコルと非同期プロトコル ネットワークプロトコルは以下の2つの種類に分けられる： 同期プロトコル リクエストの順番通りにレスポンスを返す（リクエストの順番とレスポンスの順番が同期している） 非同期プロトコル リクエストした順
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
