続・リトライと冪等性のデザインパターン - リトライはいつ成功するか - Blog by Sadayuki Furuhashi
三度の飯よりエラー処理。古橋です。 大変好評をいただいた序章リトライと冪等性のデザインパターンの続編です。 前回はほぼ前置きでしたが、今回は冪等でない操作を冪等にする具体的なテクニックもまとめていきます。 パターン２：エラーを区別してDELETEを冪等にする リソースに常に一意なIDが振られていれば、Deleteを冪等にするのは難しくない。そもそも同じリソースを2度削除することはできない。 一つ注意するべきなのは、削除されたリソースのIDが再利用されるケースでは、Deleteの冪等性は保証されない。例えば、kill -KILL <pid> コマンドはDelete系のAPIと考えられるが、pidは再利用されるので、何度も繰り返すと意図しないプロセスを殺してしまう可能性がある。 一般にIDの生成は非常に難しい問題だが、Deleteに関してのみ言えば再利用されなければいいので、単調増加する整数（
「分散システムのためのメッセージ表現手法に関する研究」 - 筑波大学大学院を卒業しました - Blog by Sadayuki Furuhashi
このたび筑波大学大学院を卒業し、修士号を取得しました。卒業にあっては本当に多くの方々にご助力いただきました。この場を借りて御礼申し上げます。ありがとうございました。 現在は起業して、12月からアメリカに在住しています。新たな価値を生み出すべく "下から上まで" システムの設計と開発に携わっており、エキサイティングな毎日を送っています。 修論シーズンに日本にいなかったので、修士論文はメールで送って提出し、卒業式にも出席していないというありさまなので、本当に卒業できたのかどうか実感がないのですが、友人によれば「学位記はあった」らしいので、きっと大丈夫でしょう。（写真はカリフォルニア州マウンテンビューにて） さて、せっかく時間を割いて書いたので、修士論文を公開することにしました。 分散システムのためのメッセージ表現手法に関する研究と題して、バイナリ形式のシリアライズ形式である MessagePa
mp::syncとMP_UTILIZE - Blog by Sadayuki Furuhashi
並列イベント駆動I/Oフレームワーク mpio のバージョン0.3.3をリリースしました。 mp::wavy::loopクラスに flush() 関数を追加 mp::pthread_scoped_{,rd,wr}lockクラスに owns() 関数を追加 mp/wavy.hでstdint.hをinclude Downloads mpioライブラリには、並列性の高いイベントループの実装だけでなく、便利なユーティリティライブラリが含まれています。 今回はその中から、mp::sync と MP_UTILIZE を紹介してみたいと思います。 mp::sync mp::syncは、マルチスレッドプログラムで便利なユーティリティで、mutexをロックしないとTにアクセスできないようにします。 参考：スレッド間で共有する変数のアクセス権制御を C++ コンパイラで強制する方法 次のように使います： #i
Introducing the MessagePack - Blog by Sadayuki Furuhashi
高速なシリアライズライブラリ MessagePack の新しいWebサイトをオープンしました！ The MessagePack Project Ruby Inside でも取り上げられたようです： MessagePack: Efficient, Cross Language Binary Object Serialization 昨今、効率を重視したシリアライズライブラリが数多く登場しています。特に、大量の処理を行う大規模な基盤システム向けに開発されていることが多いようです。 少し探してみるだけでも、次のような事例が見つかります： BERT（githubで採用：Introducing BERT and BERT-RPC） Thrift（Facebookが開発：Thrift: Scalable Cross-Language Services Implementation） Avro（Hado
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」と互換性のあるプロトコルを実装
MessagePack-RPC for C++ テクニカルプレビュー - Blog by Sadayuki Furuhashi
バイナリシリアライズ形式 MessagePack をプロトコルに利用したRPCライブラリ MessagePack-RPC の、C++版を開発しています。 以前に MessagePack-RPC for Ruby について 54行で実装する分散KVSや140行で作る分散リアルタイム検索エンジンを紹介しましたが、そのC++版です。 大まかな設計はRuby版と同じで、Ruby版と同じような使い勝手で利用できます。 しかしRuby版とは異なり、C++版では完全にマルチスレッドに対応しています。具体的には、マルチコア時代の高並列性IOアーキテクチャ Wavy を利用しています： 複数のスレッドでイベントループを共有しており、マルチスレッドでイベントハンドラを次々に処理していきます。 単純なイベント駆動I/Oと比べると、並列性が高いという利点があります。イベントハンドラの中で処理が多少ブロックしても、
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は
PFIインターンに行ってきました。 - Blog by Sadayuki Furuhashi
8月1日から8月31日までの１ヶ月間、PFI夏期インターンに行ってきました。 はてなインターンの 講義・課題・チーム 形式とは趣を異にして、個々人が何か１つのプロジェクトに取り組む方針で進みました。取り組むテーマは 新たに取り組みたい/今取り組んでいる 内容を前提に、既存の問題の中から近いテーマを見つけます（あるいはこじつける^^;）。 インターンの期間中の１ヶ月か２ヶ月の間に成果を出すのが目標！ 取り組むテーマはスムーズに決まりました。何か自社で製品を作っていれば普通かと思いますが、探せば問題はいくらでもあるモノです^^ ちなみにPFIの製品は、全文検索エンジンやレコメンドエンジンなどです。 私は以下の４つのプログラムを実装しました： 既存の実装に代わるRPCフレームワーク MessagePack-RPC for PFI クラスタ管理ツール clx プロセス管理ユーティリティ daemo
MessagePack + Wavy で高速なRPCサーバーを書く「ccf」 - Blog by Sadayuki Furuhashi
先日、追記型オブジェクトストレージKastorを紹介しました。そこで「C++でクラスタアプリケーションを書くためのフレームワーク（ccf; Cluster Communcation Framework）を実装中」などなど書きました。 最近C++でサーバープログラムを書くときには MessagePack（シリアライザ･デシリアライザ。プロトコルに利用）とmp::wavy（イベント駆動I/Oとスレッドプールを統合してうまく動かすライブラリ）という２つのライブラリを使うことが多い*1のですが、この2つを組み合わせるときにいつも似たようなコードを書いていたので、いっそまとめて1つのフレームワークのようにしたら便利そうだなーという動機でccfの開発を始めました。 …以下長々と書いていますが、論よりコード。このヘッダ と サーバーのサンプル と クライアントのサンプル を見れば、何ができるのかは大体分
memcachedバイナリプロトコルは同期プロトコルを禁止するべき - Blog by Sadayuki Furuhashi
現状のmemcachedのバイナリプロトコルのクライアント（=libmemcached）は、リクエストの順番通りにレスポンスが返ってくることを期待しており、これはmemcachedバイナリプロトコルを「汎用的なkey-valueベースの分散ストレージのためのプロトコル」として考えると、ひどい実装である。 そのような実装は最適化の余地を大幅に制限してしまい、性能とスケーラビリティが悪化する。memcachedの仕様書は、そのようなクライアントの実装はバグであると明示するべきである。 現状のmemcachedクライアントの実装の問題点と、その解決策について述べる。 同期プロトコルと非同期プロトコル ネットワークプロトコルは以下の2つの種類に分けられる： 同期プロトコル リクエストの順番通りにレスポンスを返す（リクエストの順番とレスポンスの順番が同期している） 非同期プロトコル リクエストした順
mmap＋POSIXセマフォによる高速なプロセス間通信 - mp::ipc_vector - Blog by Sadayuki Furuhashi
同じホストの異なるプロセスの間で、高速な通信を行いたいときがあります： fork() したプロセスと通信したい場合や、「アプリケーションたくさん → localhostのクライアントデーモン１つ → サーバー」という形で接続したい*1 *2 場合などなど。 あるいは共有リソースを管理するプロセスが必要なとき、具体的には memcached が localhost で動いるイメージ。 こんなときに高速なプロセス間通信がしたい。スレッドなみに高速だと嬉しい。 そこで、POSIXセマフォを使って排他制御をしつつ、mmap(2) を使って共有したメモリの上でデータをやりとりすることで、高速にプロセス間で通信を行えるようにするライブラリを作ってみました。 さっそくベンチマーク： 時間 スループット換算 UNIXドメインソケット 4.44 sec 25 MB/s ipc_vector（sleepなし）
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
