そろそろ本格的に kumofs を使ってみようかなと思いたって、CentOS 5.5 x86_64 向けの RPM を作ってみました。 まず、kumofs には、次のものが必要です（以下の情報は公式ドキュメントを参照しました）。 linux >= 2.6.18 g++ >= 4.1 ruby >= 1.8.6 Tokyo Cabinet >= 1.4.10 MessagePack for C++ >= 0.3.1 MessagePack for Ruby >= 0.3.1 libcrypto (openssl) zlib Linux と g++ と libcrypto と zlib は、CentOS 5.5 x86_64 の標準パッケージに含まれているので標準パッケージをインストールすれば問題ありません。 Ruby は、以前紹介した方法で作成したバージョン 1.8.7 系を RPM でイン
先日えとらぼより公開された、kumofs を自宅マシンの ubuntu に導入して、動くところまでを確認してみた。Key-Valueストアを利用する機会を作ろうと考えている手前、実際のところちゃんと利用したことがなかったので、まずは基本部分から。ドキュメント通りの導入ステップと、簡単なアクセスによる利用テストのみ。 なお kumofs のアーキテクチャについてはこちらで紹介されている。 今回導入した環境は以下のとおり。 OS: Ubuntu 9.10 (KVM) 必要パッケージの導入 コンパイルや動作のために必要となるパッケージを導入。 $ sudo apt-get install libtokyocabinet-dev $ sudo apt-get install ruby rubygems $ sudo apt-get install g++ MessagePack for C/C++
前回は、kumofsはなぜスケールするかということについて紹介しました。その中で最後に、耐障害性もスケーラビリティにとって重要だーと述べました。 そこで今回は、kumofsはなぜ落ちないのか、なぜ耐障害性が高いと言えるのかーということについて紹介したいと思います。 分散システムはテストが難しいことに定評がありますが（たぶん^^;）、その中でも耐障害性の検証は最上級に困難な部類です。 耐障害性は実際のところ、アルゴリズムの設計以前に実装上のバグが大きく影響するので、設計上は耐障害性が高いと言っていても、実際に使ってみると良く止まるという話はありがちな話です。（個人で開発している場合など、開発リソースが小さい場合はなおさら） そのため耐障害性の高いシステムを実現するためには、実装しやすくバグが入り込みにくい設計も重要かなーと思います（もちろん、アルゴリズムも重要ですが）。 分散システムには複雑
先日、分散Key-valueストア kumofs を公開しました。 多く方から反響とフィードバックをいただいています。ありがとうございます。 今回は、kumofs はなぜスケールするのか、なぜスケールすると言えるのかーということについて紹介したいと思います。 ところでスケーラビリティとは何か？ スケーラビリティとは、利用者や仕事の増大に適応できる能力・度合い とされています（端的！）*1 。Scalability を日本語にすると、拡張性 と訳されるようです。 ただ一口でスケーラビリティと言っても、様々な側面があります。ITシステムでは主には処理性能と運用に関することを指す場合が多いと思いますが*2、その中にも様々な側面があります。 なぜスケーラビリティが必要か スケーラビリティは システムなどが持つべき望ましい特性 であって、高いに越したことはありません。しかし、高いスケーラビリティはタ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
