Archive for February, 2011

Memcached library for Ruby

February 14th, 2011 by naoya | 1 Comment | Filed in day

Ruby で Memcached を扱えるライブラリを比較してみました。候補としては、3種類あります。すべて gem コマンド一発でインストールすることができます。

memcached

Twitter 社で使われている Memcached 用のライブラリで、libmemcached のラッパーで libmemcached 0.32 が含まれています。2011/02/14 時点でのバージョンは 1.0.6 になっています。Memcached に対する主要な操作に対応しています。開発が盛んに行われている印象があります。ソースコードはここ、ドキュメントはここにあります。

memcache-client

Memcached にアクセスするための Ruby のライブラリです。2011/02/14 時点でのバージョンは 1.8.5 になっています。Memcached に対する主要な操作に対応しています。ソースコードはここ、ドキュメントはここにあります。おそらく、このライブラリがもっとも定番に使われると思います。ただし、2010年8月をもって非推奨になっています。かわりに Dalli というライブラリを使いましょう。

Dalli

Dalli は、memcache-client の後継にあたる高速な Ruby の Memcached ライブラリです。Dalli は、Memcached バージョン 1.4  以降のみサポートしています。ほとんどの API は、memcache-client と互換性があります。Dalli は、Membase の支援を受けて開発されているようです。2011/02/14時点でのバージョンは 1.0.2 です。

Ruby-MemCache

memcache-client と同じようなライブラリです。2011/02/14時点でのバージョンは0.0.1ですが、2004年以降アップデートされていませんので、候補から外しました。

memcache

memcache は、memcache-client からフォークしたライブラリです。libmemcached 0.38 が含まれています。ただし、memcache-client とはインターフェースが異なっています。例えば、memcache-client の get_multi にあたるメソッドは get に統一されています。2011/02/14時点でのバージョンは1.2.13です。ソースコードはここ、ドキュメントはここにあります。

ということで、Ruby で memcached にアクセスした場合、memcache-client か Dalli か memcached の選択肢になると思います。memcache-client は、すでに非推奨なので、今から使うには Dalli の方がいいですね。

set と get_multi のベンチマークをとってみました。

memached のベンチマーク結果

user system total real
memcached - set 0.000000 0.000000 0.000000 ( 0.001612)
memcached - get_multi 1 key"5nqil09sWT"
0.000000 0.000000 0.000000 ( 0.000339)
memcached - get_multi 5 keys 0.000000 0.000000 0.000000 ( 0.000133)
memcached - get_multi 10 keys 0.000000 0.000000 0.000000 ( 0.000131)
memcached - get_multi 100 keys 0.000000 0.000000 0.000000 ( 0.000227)

memcache-client のベンチマーク結果

user system total real
memcache-client - set 0.070000 0.020000 0.090000 ( 0.123381)
memcache-client - get_multi 1 key 0.010000 0.000000 0.010000 ( 0.016720)
memcache-client - get_multi 5 keys 0.030000 0.010000 0.040000 ( 0.039433)
memcache-client - get_multi 10 keys 0.000000 0.000000 0.000000 ( 0.005198)
memcache-client - get_multi 100 keys 0.000000 0.000000 0.000000 ( 0.003991)

dalli のベンチマーク結果

user system total real
dalli - set 0.070000 0.020000 0.090000 ( 0.110783)
dalli - get_multi 1 key 0.010000 0.000000 0.010000 ( 0.013051)
dalli - get_multi 5 keys 0.010000 0.010000 0.020000 ( 0.010724)
dalli - get_multi 10 keys 0.010000 0.000000 0.010000 ( 0.012202)
dalli - get_multi 100 keys 0.000000 0.000000 0.000000 ( 0.010550)

memcache のベンチマーク結果

user system total real
memcache - set 0.070000 0.020000 0.090000 ( 0.104050)
memcache - get_multi 1 key 0.010000 0.000000 0.010000 ( 0.012464)
memcache - get_multi 5 keys 0.000000 0.000000 0.000000 ( 0.005252)
memcache - get_multi 10 keys 0.010000 0.000000 0.010000 ( 0.004151)
memcache - get_multi 100 keys 0.000000 0.000000 0.000000 ( 0.003126)

やはり、memcached の方がかなり高速ですが、Dalli や memcache もなかなか高速です。memcached のライブラリでも、ベンチマーク結果が公開されていますので、興味のある人はチェックしてみるといいと思います。

使い方も見たところ、memcache-client や Dalli の方は若干使いやすいような気がしますが、memcached は Twitter で使われていることが考えるとかなり鍛えられていると思います。
現時点での Ruby 用のライブラリは、Dalli か memcached がいいと思います。

# 追記 2/15
@nuna さんに指摘されましたので dalli も追加しました。ありがとうございます！

# さらに追記 2/15
@tmtms さんに指摘されましたので memcache も追加しました。ありがとうございます！

別のエントリで、今回の調査から候補に挙がった、memcached、dalli、memcache、の 3 種類のライブラリを実際に使うために、機能比較を行いたいと思います。

Tags:

qpstudy #5 に行ってきた

February 13th, 2011 by naoya | No Comments | Filed in day

qpstudy #5 に行ってきた。2010年から始まった qpstudy も、毎回会を重ねることにたくさんの人、そして女性の人の参加者が増えて、いろいろな人と出会える素晴らしい勉強会になってきた。

今回は、メイン枠は Linux のディストリビューション、LT 枠はインフラエンジニアのための UStream 入門、ざびたん、自宅サーバ、の話でした。

Linux のディストリビューションの話では、それぞれのディストリビューションごと 3 分でアピールしてからディスカッションをするという流れでした。僕は「Gentoo」「Debian」「Fedora」「Debian」「Ubuntu」「Vine」のすべてのディストリビューションを使ったことはないですが、使ったことがないディストリビューションの特長がすこし分かってよかった。インフラエンジニアから見た視点のアピールやデモがあるとよかったと思う。間違いなく CentOS が一番業務で使われていると思いますが、途中でどのディストリビューション名が一番つぶやかれているのか集計してみたら「Gentoo」が一番だった。おそらく、一番インパクトのあるディストリビューションだったのだと思う。

LT 枠では、いつも qpstudy の UStream を中継している @H_Shinonome さんによる UStream 入門はなかなか面白かった。UStream という素晴らしいウェブサービスを使う上での Tips が凝縮されていたと思う。

そして @sechiro さんのざびたんは、おそらく今回の qpstudy の中で一番インパクトがあった発表に違いないと思う。ざびたんは、きっと海外でうけると思うので、ぜひ Velocity かなんかでぜひ発表してほしい（ぜひ、Velocity での発表をお手伝いしたい！）。今後、qpstudy ではぜびたんのアップデートがたびたび報告されると思うので、期待できますね！

@int128 さんの自宅サーバの話。僕もずっと自宅サーバをたていて遊んでいるけれど、自宅サーバも大事だけれど、最近だとクラウドの使い方もかなり大事だと思うので、両方を試すのが大事になってくると思う。どちらを使うにしても、今の時代ではあまりお金がかからないのがいいですよね！

その後のビアバッシュの LT は、毎回思うけれど独自の雰囲気でまじめな技術ネタをやるのがよいのか、ちょっと軽めのネタをやるのか、分からないけれど、qpstudy ならではの独特の雰囲気なので、一度は参加してみるといいと面白いと思います。
個人的には、自宅で SAN の話が強烈でした。SAN は一度も仕事とかでも使ったことがないけれど、SAN で遊んでみるのもいいかもしれない。

今回の qpstudy #5 の資料は、Slideshare の方にアップされると思うので、興味のある人はチェックしてみるといいと思います。

qpstudy に参加していて思うのは、普段あまり表舞台に出ていないと思われるインフラエンジニアがこれほど多くいることに感激します。インフラエンジニア同士の情報共有の場所はあまりないと思うので、qpstudy は貴重な場所だと思います。qpstudy はどなたでも参加できますので、ぜひ興味のある方は参加してみるといいと思います。これからも末永く続く勉強会でありますように！

最後に、会場を提供してくださったニフティのみなさん、qpstudy のリーダー！ @iara さんをはじめとするスタッフのみなｓんに、感謝したいと思います。

懇親会の最中に小悪魔さんから、サインをいただきました！会場に行く途中で、小悪魔本を買ってよかった！

# 僕は前に急な都合で発表をすることができなかったので、次回リベンジする予定です。内容的は、「今さら聞けない puppet と chef の違い」、「フリーランスという生き方」、などを考えています。

# qpstudy の公式ブログ: http://blog.qpstudy.com/Entry/2/

rubygems 1.5.0 でミラーをする方法

February 7th, 2011 by naoya | No Comments | Filed in day

Rubygems 1.5.0 がリリースされました。メインは、Ruby 1.9.2 サポートとしてのリリースのようですが、最近 REE 1.8.7 を使って generate_index するとエラーが出てしまって、gem のローカルミラーの構築に失敗して困っていました。そこで、思い切って Rubygems 1.5.0 にアップデートしてみました。Rubygems 1.5.0 の変更点は、こちらです。

$ sudo /opt/ruby/bin/gem update –system

そして、1.5.0 にアップデートしたところ、ちゃんと generate_index することができました。

これで問題なしと思ったのですが、Rubygems 1.5.0 から mirror コマンドが削除されてしまいました。。。代わりのものがないかどうか調べてみると、rubygems-mirror がありました。rubygems-mirror は、gem になっていないので、github から落としてくる必要があります。

$ git clone https://github.com/rubygems/rubygems-mirror.git

そして、rake タスクを実行するだけです。

$ cd rubygems-mirror

$ /opt/ruby/bin/rake mirror:update

すると、次のようなエラーが発生していまいました。

…

rake aborted!
unsupported signal SIGINFO

…

調べてみると、同様の報告があって、master には取り込まれていないようなので、同じように、次のパッチをあてます。


--- lib/rubygems/mirror/command.rb-org 2011-02-07 12:21:33.000000000 +0900
+++ lib/rubygems/mirror/command.rb 2011-02-07 12:18:14.000000000 +0900
@@ -54,7 +54,7 @@
progress = ui.progress_reporter num_to_fetch,
"Fetching #{num_to_fetch} gems"
- trap(:INFO) { puts "Fetched: #{progress.count}/#{num_to_fetch}" }
+ #trap(:INFO) { puts "Fetched: #{progress.count}/#{num_to_fetch}" }
mirror.update_gems { progress.updated true }
@@ -63,7 +63,7 @@
progress = ui.progress_reporter num_to_delete,
"Deleting #{num_to_delete} gems"
- trap(:INFO) { puts "Fetched: #{progress.count}/#{num_to_delete}" }
+ #trap(:INFO) { puts "Fetched: #{progress.count}/#{num_to_delete}" }
mirror.delete_gems { progress.updated true }
end

とりあえずは、これでちゃんと gem をローカルのサーバへミラーすることができました。

あとは、これを cron に仕込めば、問題なしですね。

# 2011.02.09 追記

次のような cron を、仕込んでみました。generate_index –update オプションを付けると、更新のあった gem だけ差分更新をしてくれるために非常に高速に gem の index を作成することができます。–update すると、数時間くらいかかるの注意してください。

また、自分の gem もまとめて管理しているため、自分の gem は /home/naoya/gems に置いてあるため、mirror してしまうと既存の自分の gem は削除されるため、mirror 後にコピーして、まとめて一つのローカル Rubygems リポジトリを作成しています。

0 4 * * * cd /home/naoya/src/rubygems-mirror && /opt/ruby/bin/rake mirror:update && cp /home/naoya/gems/*.gem /var/www/rubygems/gems/ && /opt/ruby/bin/gem generate_index –update –quiet -d /var/www/rubygems

Tags:

keepalived のヘルスチェック続編

February 3rd, 2011 by naoya | No Comments | Filed in day

先日、keepalived のヘルスチェックを改善してみましたが、しばらく運用すると、当然ながら予想された次の問題が発生しました。

  • あるウェブサーバで、レスポンスが低下してしまったとき、ヘルスチェック用の仮想ホストではレスポンスが当然ながら良好のため、レスポンスが低下したウェブサーバがはずれない
  • あるウェブサーバで、503 が発生したとき、こちらも当然ながらヘルスチェック用の仮想ホストでのヘルスチェックでは絶対に 200 のため、503 が発生したウェブサーバがはずれない

ということで、結論的にはヘルスチェックは、実際にサービスをしているプログラムに対して行うのがよいという結論に達しました。

そこで、プログラム側にヘルスチェック用の処理を作って、その部分に Rails なら RAILS_ROOT/tmp/disable.txt があった場合は 503、それ以降内部プログラムが正しく動いているかチェックして問題がなければ 200、を返すように変更しました。

こうしておくことで、意図的なメンテナンス時、デプロイ時、には RAILS_ROOT/tmp/disable.txt を作成することで正しく外れますし、keepalived のヘルスチェックのタイムアウトや httpd レスポンスコードのチェックによってもエラーで外れる（当時に nagios でアラートがある）ため、しばらくこの方式で行ってみようかと思います。

2011/02/04 追記:

  • 当然ながら、LVS 側からウェブサーバを一時的に外すこともできますが、プログラムをデプロイするときも一時的にウェブサーバを外してからウォームアップして投入したいので、ウェブサーバ側からはずせるようになった方が便利という理由もあります

Tags: